Threat Modeling with
Architectural Risk Patterns
By
Stephen de Vries
@stephendv
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
• Do you currently perform threat modeling?
• Is the security team involved in every threat model?
• Do you build more than 20 applications per year?
…why aren’t you threat modeling?
A) Too time consuming
B) Lack of skills
C) Don’t see the value
BSIMM 6
• 85% Perform security feature review
• 37% Perform design review of high risk applications
• 28% Have Software Security Group lead design review efforts
rticipating Firms
78 participating organizations are drawn from four well-represented verticals (with some overlap): financ
ices (33), independent software vendors (27), consumer electronics (13), and healthcare (10). Verticals wit
er representation in the BSIMM population include: insurance, telecommunications, security, retail, and en
se 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
average, the 78 participating firms had practiced software security for 3.98 years at the time of assessmen
ging from less than a year old to 15 years old as of October, 2015). All 78 firms agree that the success of th
oftware security it has not previously been
ied at this scale. Previous work has either
cribed the experience of a single organization
ffered prescriptive guidance based only on a
bination of personal experience and opinion.
simply reported.
Security cannot slow down development
Artisanal Handcrafted Threat Models since 1999
Accuracy
25%
50%
75%
100%
Resources required (Time + Skill)
Threat Modeling Process
Accuracy
25%
50%
75%
100%
Resources required (Time + Skill)
Easy
Hard
Threat Modeling Process
Accuracy
25%
50%
75%
100%
Resources required (Time + Skill)
Easy
Hard
Threat Modeling Process
Workshop/Analysis based
Threat Modeling
Threat Modeling with
Templates / Patterns
Optimising with templates / checklists
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 1
If the DB is compromised then
attackers could also compromise
users’ authentication credentials
Threat
Only if Countermeasure 2
is not an option
Use Company X SSO for all
Internet facing applications
Web Application Threat Model Template
Problems with a one size fits all approach
100% Accurate
Threat Model
of System
TM
Template
Problems with a one size fits all approach
100% Accurate
Threat Model
of System
TM
Template
Deconstruct the template
into components
TM
Template for DB
TM
Template for
Web Service
TM
Template for
WebUI
• 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
• 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
• 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
Web UI Web ServiceAuthenticate
Worked Example: Web Authentication
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
Use Case: Authenticate
Threat A: Dictionary attack against username using common password
Countermeasure 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
• 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
Threat A: Dictionary attack against username using common password
Countermeasure 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
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
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
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
Risk Pattern:
Generic-Service
Threat D: Legitimate users cannot access service because of DoS
Countermeasure 7: Enable up-stream DoS protectionWeb Service
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?
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
Web UI
Web
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
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 DoS
Enable up-stream DoS prevention
Web UI
Web
ServiceAuthenticate
Generated Threats & Countermeasures
Threat B: Login bypassed by replaying credentials stored in Browser
Set 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
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
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 DoS
Enable up-stream DoS prevention
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 DoS
Enable up-stream DoS prevention
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 DoS
Enable up-stream DoS prevention
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
Sensitive
Data-Transport
Risk Pattern Library
AuthN
AuthN-SF AuthN-2FA
UserPass Token
Client-side
Session
Risk Pattern: Sensitive data storage on Client
Threat 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 App
Threat 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
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
What type of component are
you building?
Web Service
Mobile client
Web UI
How are users authenticated?
Username & Password
2FA
No auth
Rules Engine
Generic-Service
HTTP-Service
Stateful-Session
SF-Auth
SF-Auth-HTTP-Service
Sensitive-DataTransport
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
Be-aware!
• No data flows or trust boundaries
• Resulting model only as good as it’s input
• Checklists short-circuit thinking about the problem
Advantages
• Speed and scale threat modeling
• Create a persistent Threat/Countermeasure
knowledge-base
• Improved consistency
Questions?

Threat modeling with architectural risk patterns

  • 1.
    Threat Modeling with ArchitecturalRisk Patterns By Stephen de Vries @stephendv
  • 2.
    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
  • 3.
    • Do youcurrently perform threat modeling? • Is the security team involved in every threat model? • Do you build more than 20 applications per year?
  • 4.
    …why aren’t youthreat modeling? A) Too time consuming B) Lack of skills C) Don’t see the value
  • 5.
    BSIMM 6 • 85%Perform security feature review • 37% Perform design review of high risk applications • 28% Have Software Security Group lead design review efforts rticipating Firms 78 participating organizations are drawn from four well-represented verticals (with some overlap): financ ices (33), independent software vendors (27), consumer electronics (13), and healthcare (10). Verticals wit er representation in the BSIMM population include: insurance, telecommunications, security, retail, and en se 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 average, the 78 participating firms had practiced software security for 3.98 years at the time of assessmen ging from less than a year old to 15 years old as of October, 2015). All 78 firms agree that the success of th oftware security it has not previously been ied at this scale. Previous work has either cribed the experience of a single organization ffered prescriptive guidance based only on a bination of personal experience and opinion. simply reported.
  • 6.
    Security cannot slowdown development
  • 7.
  • 8.
  • 9.
    Accuracy 25% 50% 75% 100% Resources required (Time+ Skill) Easy Hard Threat Modeling Process
  • 10.
    Accuracy 25% 50% 75% 100% Resources required (Time+ Skill) Easy Hard Threat Modeling Process
  • 11.
    Workshop/Analysis based Threat Modeling ThreatModeling with Templates / Patterns
  • 12.
  • 13.
    Use a 3rdparty 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 1 If the DB is compromised then attackers could also compromise users’ authentication credentials Threat Only if Countermeasure 2 is not an option Use Company X SSO for all Internet facing applications
  • 14.
    Web Application ThreatModel Template
  • 15.
    Problems with aone size fits all approach 100% Accurate Threat Model of System TM Template
  • 16.
    Problems with aone size fits all approach 100% Accurate Threat Model of System TM Template
  • 17.
    Deconstruct the template intocomponents TM Template for DB TM Template for Web Service TM Template for WebUI
  • 18.
    • HTML WebUI 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
  • 19.
    • HTML WebUI 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
  • 20.
    • HTML WebUI 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
  • 21.
    Web UI WebServiceAuthenticate Worked Example: Web Authentication
  • 22.
    Threat A: Dictionaryattack 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
  • 23.
    Use Case: Authenticate ThreatA: Dictionary attack against username using common password Countermeasure 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
  • 24.
    • Are thethreat+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
  • 25.
    Threat A: Dictionaryattack against username using common password Countermeasure 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
  • 26.
    Does the patternapply in a more generic form? Can a variation of the pattern be applied to a similar component or use-case? Optimise for re-use
  • 27.
    Threat A: Dictionaryattack 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
  • 28.
    Risk Pattern: Authentication fromWebUI Threat B: Login bypassed by replaying credentials stored in Browser Countermeasure 4: Set AUTOCOMPLETE to false on login formWebUI +Authentication
  • 29.
    Risk Pattern: Generic-Service Threat D:Legitimate users cannot access service because of DoS Countermeasure 7: Enable up-stream DoS protectionWeb Service
  • 30.
    Risk Pattern: Authentication fromMobile 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?
  • 31.
    Risk Pattern: User/Pass Authenticationagainst 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
  • 32.
    Web UI Web 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 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 DoS Enable up-stream DoS prevention
  • 33.
    Web UI Web ServiceAuthenticate Generated Threats& Countermeasures Threat B: Login bypassed by replaying credentials stored in Browser Set 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
  • 34.
    Web UI on Mobile Web ServiceAuthenticate GeneratedThreats & 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
  • 35.
    Web UI RESTAPIAuthenticate 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 DoS Enable up-stream DoS prevention
  • 36.
    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 DoS Enable up-stream DoS prevention
  • 37.
    Web UI SMTP serviceSend Mail GeneratedThreats & 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 DoS Enable up-stream DoS prevention
  • 38.
    Generic-Service HTTP-Service JSON-Service Server-side Session Data-store SQL DB NoSQLDB Generic-Client Thick Client HTML/JS Client Mobile Client SOAP-Service Sensitive Data-Transport Risk Pattern Library AuthN AuthN-SF AuthN-2FA UserPass Token Client-side Session
  • 39.
    Risk Pattern: Sensitivedata storage on Client Threat 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 App Threat 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
  • 41.
    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
  • 42.
    What type ofcomponent are you building? Web Service Mobile client Web UI How are users authenticated? Username & Password 2FA No auth Rules Engine Generic-Service HTTP-Service Stateful-Session SF-Auth SF-Auth-HTTP-Service Sensitive-DataTransport
  • 43.
    rule “SF-AUTH forHTTP-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
  • 44.
    Be-aware! • No dataflows or trust boundaries • Resulting model only as good as it’s input • Checklists short-circuit thinking about the problem
  • 45.
    Advantages • Speed andscale threat modeling • Create a persistent Threat/Countermeasure knowledge-base • Improved consistency
  • 46.