threat modeling with architectural risk patterns

46
Threat Modeling with Architectural Risk Patterns By Stephen de Vries @stephendv

Upload: stephen-de-vries

Post on 22-Jan-2017

725 views

Category:

Software


6 download

TRANSCRIPT

Page 1: Threat modeling with architectural risk patterns

Threat Modeling with Architectural Risk Patterns

By Stephen de Vries

@stephendv

Page 2: Threat modeling with architectural risk patterns

Stephen de Vries • Founder of Continuum Security

• Open Source BDD-Security project

• IriusRisk SDLC Risk Management solution

• Dev/Sec skill split

• 17 years in AppSec consulting

Page 3: Threat modeling with architectural risk patterns

• Do you currently perform threat modeling?

• Is the security team involved in every threat model?

• Do you build more than 20 applications per year?

Page 4: Threat modeling with architectural risk patterns

…why aren’t you threat modeling?

A) Too time consuming

B) Lack of skills

C) Don’t see the value

Page 5: Threat modeling with architectural risk patterns

BSIMM 6

• 85% Perform security feature review• 37% Perform design review of high risk applications• 28% Have Software Security Group lead design review efforts

8 | Building Security In Maturity Model (BSIMM) Version 6

Participating Firms

The 78 participating organizations are drawn from four well-represented verticals (with some overlap): financial services (33), independent software vendors (27), consumer electronics (13), and healthcare (10). Verticals with lower representation in the BSIMM population include: insurance, telecommunications, security, retail, and energy.

Those companies among the 78 who graciously agreed to be identified include:

Adobe, Aetna, ANDA, Autodesk, Bank of America, Black Knight Financial Services, BMO Financial

Group, Box, Capital One, Cisco, Citigroup, Comerica, Cryptography Research, Depository Trust and

Clearing Corporation, Elavon, EMC, Epsilon, Experian, Fannie Mae, Fidelity, F-Secure, HP Fortify,

HSBC, Intel Security, JPMorgan Chase & Co., Lenovo, LinkedIn, Marks & Spencer, McKesson, NetApp,

NetSuite, Neustar, Nokia, NVIDIA , PayPal, Pearson Learning Technologies, Qualcomm, Rackspace,

Salesforce, Siemens, Sony Mobile, Symantec, The Advisory Board, The Home Depot, TomTom,

trainline, U.S. Bank, Vanguard, Visa, VMware, Wells Fargo, and Zephyr Health

On average, the 78 participating firms had practiced software security for 3.98 years at the time of assessment (ranging from less than a year old to 15 years old as of October, 2015). All 78 firms agree that the success of their initiative hinges on having an internal group devoted to software security—the SSG. SSG size on average is 13.9 people (smallest 1, largest 130, median 6) with a “satellite” of others (developers, architects, and people in the organization directly engaged in and promoting software security) of 27.1 people (smallest 0, largest 400, median 3). The average number of developers among our targets was 3,680 people (smallest 23, largest 35,000, median 1,200), yielding an average percentage of SSG to development of 1.51% (median 0.7%).

All told, the BSIMM describes the work of 1,084 SSG members working with a satellite of 2,111 people to secure the software developed by 287,006 developers.

“thou shalt not steal thy neighbors’ bananas,” or any other value judgments. Simple observations, simply reported.

Our “just the facts” approach is hardly novel in science and engineering, but in the realm of software security it has not previously been applied at this scale. Previous work has either described the experience of a single organization or offered prescriptive guidance based only on a combination of personal experience and opinion.

Simple observations,

simply reported.

Page 6: Threat modeling with architectural risk patterns

Security cannot slow down development

Page 7: Threat modeling with architectural risk patterns

Artisanal Handcrafted Threat Models since 1999

Page 8: Threat modeling with architectural risk patterns

Acc

urac

y

25%

50%

75%

100%

Resources required (Time + Skill)

Threat Modeling Process

Page 9: Threat modeling with architectural risk patterns

Acc

urac

y

25%

50%

75%

100%

Resources required (Time + Skill)

Easy

Hard

Threat Modeling Process

Page 10: Threat modeling with architectural risk patterns

Acc

urac

y

25%

50%

75%

100%

Resources required (Time + Skill)

Easy

Hard

Threat Modeling Process

Page 11: Threat modeling with architectural risk patterns

Workshop/Analysis basedThreat Modeling

Threat Modeling with Templates / Patterns

Page 12: Threat modeling with architectural risk patterns

Optimising with templates / checklists

Page 13: Threat modeling with architectural risk patterns

Use a 3rd party auth provider

Countermeasure 2

OWASP ASVS as a Threat Model Template

V2.13 Verify that account passwords are protected using an adaptive key derivation function, salted using a salt that is unique to that account…

Countermeasure 1If the DB is compromised then attackers could also compromise users’ authentication credentials

Threat

Only if Countermeasure 2is not an option

Use Company X SSO for allInternet facing applications

Page 14: Threat modeling with architectural risk patterns

Web Application Threat Model Template

Page 15: Threat modeling with architectural risk patterns

Problems with a one size fits all approach

100% AccurateThreat Model

of System

TMTemplate

Page 16: Threat modeling with architectural risk patterns

Problems with a one size fits all approach

100% AccurateThreat Model

of System

TM Template

Page 17: Threat modeling with architectural risk patterns

Deconstruct the templateinto components

TMTemplate for DB

TMTemplate forWeb Service

TMTemplate for

WebUI

Page 18: Threat modeling with architectural risk patterns

• HTML Web UI Threat Template.xlsx• Mobile Device Threat Template.xlsx• NoSQL Database Threat Template.xlsx• SQL Database Threat Template.xlsx• HTTP Service Threat Template.xlsx• REST Web Service Threat Template.xlsx• SOAP Web Service Threat Template.xlsx• Amazon EC2 Threat Template.xlsx• Connection to Third Party API Threat Template.xlsx

Page 19: Threat modeling with architectural risk patterns

• HTML Web UI Threat Template.xlsx• Mobile Device Threat Template.xlsx• NoSQL Database Threat Template.xlsx• SQL Database Threat Template.xlsx• HTTP Service Threat Template.xlsx

• Authentication• Credentials Reset• User Registration• Profile Update• Inter account funds transfer• National funds transfer • International funds transfer• …

• REST Web Service Threat Template.xlsx• SOAP Web Service Threat Template.xlsx

Page 20: Threat modeling with architectural risk patterns

• HTML Web UI Threat Template.xlsx• Authentication

• Mobile Device Threat Template.xlsx• Authentication• Credentials Reset• Profile Update

• NoSQL Database Threat Template.xlsx• SQL Database Threat Template.xlsx• HTTP Service Threat Template.xlsx

• Authentication• Credentials Reset• User Registration• Profile Update• Inter account funds transfer• National funds transfer • International funds transfer• …

• REST Web Service Threat Template.xlsx• Authentication• Profile Update• Funds Transfer

• SOAP Web Service Threat Template.xlsx

Page 21: Threat modeling with architectural risk patterns

Web UI Web ServiceAuthenticate

Worked Example: Web Authentication

Page 22: Threat modeling with architectural risk patterns

Threat A: Dictionary attack against username using common password

Threat B: Login bypassed by replaying credentials stored in Browser

Threat C: Credentials posted to a spoofed server

Web UI Web ServiceAuthenticate

Threat D: Legitimate users cannot access the site because of DoS

Page 23: Threat modeling with architectural risk patterns

Use Case: Authenticate

Threat A: Dictionary attack against username using common passwordCountermeasure 1: Implement password quality checks

Countermeasure 2: Rate limit authentication attempts from same IP

Threat B: Login bypassed by replaying credentials stored in Browser

Countermeasure 4: Set AUTOCOMPLETE to false on login form

Countermeasure 5: Enable TLS on the server

Countermeasure 6: Set the HSTS Header

Threat C: Credentials posted to a spoofed server

Countermeasure 3: Require the use of 2FA

Threat D: Legitimate users cannot access service because of DoS

Countermeasure 7: Enable upstream DoS protection

Page 24: Threat modeling with architectural risk patterns

• Are the threat+countermeasures inherent in this type of component ?

• Are the threat+countermeasures inherent in the use-case?

• Are the threat+countermeasures specific to this use-case in this component?

Web UI Web ServiceAuthenticate

Identify Patterns

Page 25: Threat modeling with architectural risk patterns

Threat A: Dictionary attack against username using common passwordCountermeasure 1: Implement password quality checks

Countermeasure 2: Rate limit authentication attempts from same IP

Threat B: Login bypassed by replaying credentials stored in Browser

Countermeasure 4: Set AUTOCOMPLETE to false on login form

Countermeasure 5: Enable TLS on the server

Countermeasure 6: Set the HSTS Header

Threat C: Credentials posted to a spoofed server

Countermeasure 3: Require the use of 2FA

Threat D: Legitimate users cannot access service because of DoS

Countermeasure 7: Enable upstream DoS protection

Web Service+ Authentication

WebUI+Authentication

Web Service+Authentication

Web Service

Page 26: Threat modeling with architectural risk patterns

Does the pattern apply in a more generic form?

Can a variation of the pattern be applied to a similar component or use-case?

Optimise for re-use

Page 27: Threat modeling with architectural risk patterns

Threat A: Dictionary attack against username using common password

Countermeasure 1: Implement password quality checks

Countermeasure 2: Rate limit authentication attempts from same IP

Countermeasure 3: Require the use of 2FA

Risk Pattern: User/Pass Authentication against a Service

Web Service + Authentication

Countermeasure 5: Enable TLS on the server

Countermeasure 6: Set the HSTS Header

Threat C: Credentials posted to a spoofed server

Risk Pattern: Authentication against an HTTP Service

Web Service+Authentication

Page 28: Threat modeling with architectural risk patterns

Risk Pattern: Authentication from WebUI

Threat B: Login bypassed by replaying credentials stored in Browser

Countermeasure 4: Set AUTOCOMPLETE to false on login formWebUI+Authentication

Page 29: Threat modeling with architectural risk patterns

Risk Pattern: Generic-Service

Threat D: Legitimate users cannot access service because of DoS

Countermeasure 7: Enable up-stream DoS protectionWeb Service

Page 30: Threat modeling with architectural risk patterns

Risk Pattern: Authentication from Mobile Client

Threat B: Login bypassed by replaying credentials stored on device

Countermeasure 4: Do not store credentials on the device

Countermeasure 5: Encrypt the credentials stored on the device using the passcode

Risk Pattern: Authentication from WebUI

Threat B: Login bypassed by replaying credentials stored in Browser

Countermeasure 4: Set AUTOCOMPLETE to false on login form

Can a variation of the pattern be applied to a similar component or use-case?

Page 31: Threat modeling with architectural risk patterns

Risk Pattern: User/Pass Authentication against a Service

Risk Pattern: Authentication against an HTTP Service

Risk Pattern: Authentication from WebUI

Risk Pattern: Authentication from Mobile Device

Client ServerAuthenticate

Generated Threats & Countermeasures

Risk Pattern: Generic-Service

Page 32: Threat modeling with architectural risk patterns

Web UI Web ServiceAuthenticate

Generated Threats & Countermeasures

Threat A: Dictionary attack against username using common passwordImplement password quality checks

Rate limit connections from the same IP address

Require the use of 2FA

Threat B: Credentials posted to a spoofed server

Set the HSTS header

Enable TLS on the server

Risk Pattern: User/Pass Authentication against a Service

Risk Pattern: Authentication against an HTTP Service

Risk Pattern: Authentication from WebUI

Risk Pattern: Authentication from Mobile Device

Risk Pattern: Generic-Service

Threat D: Legitimate users cannot access service because of DoSEnable up-stream DoS prevention

Page 33: Threat modeling with architectural risk patterns

Web UI Web ServiceAuthenticate

Generated Threats & Countermeasures

Threat B: Login bypassed by replaying credentials stored in BrowserSet AUTOCOMPLETE to false on login form

Risk Pattern: User/Pass Authentication against a Service

Risk Pattern: Authentication against an HTTP Service

Risk Pattern: Authentication from WebUI

Risk Pattern: Authentication from Mobile Device

Risk Pattern: Generic-Service

Page 34: Threat modeling with architectural risk patterns

Web UI on Mobile

Web ServiceAuthenticate

Generated Threats & Countermeasures

Threat B: Login bypassed by replaying credentials stored on device

Do not store credentials on the device

Encrypt the credentials stored on the device using the passcode

Risk Pattern: User/Pass Authentication against a Service

Risk Pattern: Authentication against an HTTP Service

Risk Pattern: Authentication from WebUI

Risk Pattern: Authentication from Mobile Device

Risk Pattern: Generic-Service

Page 35: Threat modeling with architectural risk patterns

Web UI REST APIAuthenticate

Generated Threats & Countermeasures

Threat B: Credentials posted to a spoofed server

Set the HSTS header

Enable TLS on the server

Risk Pattern: User/Pass Authentication against a Service

Risk Pattern: Authentication against an HTTP Service

Risk Pattern: Authentication from WebUI

Risk Pattern: Authentication from Mobile Device

Risk Pattern: Generic-Service

Threat D: Legitimate users cannot access service because of DoSEnable up-stream DoS prevention

Page 36: Threat modeling with architectural risk patterns

Web UI SSH ServiceAuthenticate

Generated Threats & Countermeasures

Threat A: Dictionary attack against username using common password

Implement password quality checks

Rate limit connections from the same IP address

Require the use of 2FA

Risk Pattern: User/Pass Authentication against a Service

Risk Pattern: Authentication against an HTTP Service

Risk Pattern: Authentication from WebUI

Risk Pattern: Authentication from Mobile Device

Risk Pattern: Generic-Service

Threat D: Legitimate users cannot access service because of DoSEnable up-stream DoS prevention

Page 37: Threat modeling with architectural risk patterns

Web UI SMTP serviceSend Mail

Generated Threats & Countermeasures

Risk Pattern: User/Pass Authentication against a Service

Risk Pattern: Authentication against an HTTP Service

Risk Pattern: Authentication from WebUI

Risk Pattern: Authentication from Mobile Device

Risk Pattern: Generic-Service

Threat D: Legitimate users cannot access service because of DoSEnable up-stream DoS prevention

Page 38: Threat modeling with architectural risk patterns

Generic-Service

HTTP-Service

JSON-Service

Server-side Session

Data-store

SQL DB NoSQL DB

Generic-Client

Thick Client

HTML/JS Client

Mobile Client

SOAP-Service

SensitiveData-Transport

Risk Pattern Library

AuthN

AuthN-SF AuthN-2FA

UserPass Token

Client-side Session

Page 39: Threat modeling with architectural risk patterns

Risk Pattern: Sensitive data storage on ClientThreat A: Sensitive data is compromised if the client is compromised

Countermeasure 1: Do not store credentials on the client

Countermeasure 2: Encrypt data stored on the client

Risk Pattern: Sensitive data storage on iOS AppThreat A: Sensitive data is compromised if the mobile device is compromised

Countermeasure 2: Encrypt by storing it in the keychain and…

Generated Threats & Countermeasures

Countermeasure 2: Encrypt by storing it in the keychain and…

Threat A: Sensitive data is compromised if the mobile device is compromised

Countermeasure 1: Do not store credentials on the client

Inheritance and Method overloading

Page 40: Threat modeling with architectural risk patterns
Page 41: Threat modeling with architectural risk patterns

Rules Engine

rule “HTTP Service - dependency"when RiskPattern(ref == "HTTP-SERVICE")then insertLogical(new RiskPattern("GENERIC-SERVICE"));end

rule “JSON Service - dependency“when RiskPattern(ref == "JSON-SERVICE")then insertLogical(new RiskPattern("HTTP-SERVICE"));end

rule “User chooses JSON Service“when Question(id == “json.service”, answer == true)then insertLogical(new RiskPattern("JSON-SERVICE"));end

Inheritance relationships with JBoss Drools

Page 42: Threat modeling with architectural risk patterns

What type of component are you building?

Web ServiceMobile clientWeb UI

How are users authenticated?Username & Password2FANo auth

Rules Engine

Generic-Service

HTTP-Service

Stateful-Session

SF-Auth

SF-Auth-HTTP-Service

Sensitive-DataTransport

Page 43: Threat modeling with architectural risk patterns

rule “SF-AUTH for HTTP-Service“when RiskPattern(ref == “HTTP-SERVICE") RiskPattern(ref == “SF-Auth“)then insertLogical(new RiskPattern(“SF-Auth-HTTP-Service“)); insertLogical(new RiskPattern(“Stateful-Session“)); insertLogical(new RiskPattern(“Sensitive-DataTransport“));end

rule “User chooses Web Service“when Question(id == “web.service”, answer == true)then insertLogical(new RiskPattern("HTTP-SERVICE"));end

rule “User chooses User/Pass auth“when Question(id == “auth.user.pass”, answer == true)then insertLogical(new RiskPattern(“SF-Auth"));end

Page 44: Threat modeling with architectural risk patterns

Be-aware!

• No data flows or trust boundaries• Resulting model only as good as it’s input• Checklists short-circuit thinking about the problem

Page 45: Threat modeling with architectural risk patterns

Advantages

• Speed and scale threat modeling• Create a persistent Threat/Countermeasure

knowledge-base• Improved consistency

Page 46: Threat modeling with architectural risk patterns

Questions?