scalable threat modelling with risk patterns
Post on 22-Jan-2017
139 Views
Preview:
TRANSCRIPT
Stephen de Vries @stephendv •Founder of Continuum Security SL
•17 years in AppSec consulting
•Dev/Sec skill split
•Open Source BDD-Security project
•IriusRisk SDLC Risk Management solution
•Do you currently perform threat modelling?
•Is the security team involved in every threat model?
•Do you build more than 20 applications per year?
BSIMM 6
37% Perform design review of high risk applications
28% Have Software Security Group lead design review efforts
85% Perform security feature review
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.
Acc
urac
y
25%
50%
75%
100%
Resources required (Time + Skill)
Threat Modelling Process
The hard stuff
The easy stuff
Acc
urac
y
25%
50%
75%
100%
Resources required (Time + Skill)
Threat Modelling Process
The hard stuff
The easy stuff
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
Use a 3rd party auth provider
Countermeasure 2
Only if Countermeasure 2is not an option
Use Company X SSO for allInternet facing applications
Problems with a one size fits all approach
100% AccurateThreat Model
of System
Threat Model Template
Deconstruct the template into components
TMTemplate for DB
TMTemplate forWeb Service
TMTemplate 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
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 ServiceU/P Authenticate
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
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 APIToken Auth
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
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
OS NTP ServiceGet Time
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
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
Hierarchical Risk Pattern Library
AuthN
AuthN-SF AuthN-2FA
UserPass Token
Client-side Session
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 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
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
Advantages
Speed and scale threat modellingCreate a persistent Threat/Countermeasure knowledge-base
Improved consistency
https://github.com/continuumsecurity/IriusRisk
www.continuumsecurity.net
Questions?
@stephendv
top related