Hickman threat modeling
31
Transcript of Hickman threat modeling
Agenda
Why Worry?
Creating a Security Process
Threat Models
The Threat Modeling Process
Secure Programming Principles
Security Testing
Questions?
Why Worry?
Attacks are increasing
Attack complexity is increasing
stack overruns, heap overruns, format strings, integer overflow, …?
Time from vulnerability discovery to exploit is decreasing
Security is arequirement or a competitiveadvantage
CERT Incidents(http://www.cert.org/stats/cert_stats.html)
020000400006000080000
100000120000140000
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
Creating a Security Process
People•Train and keep current in application security.•Architects, developers, testers•Stay disciplined about security.•Stay current with the state of the art.
•Make security a critical part of design, development, testing, and deployment.•Security threat analysis part of every design•Design and code reviews•External audits.
Process
Technology •Build tools, automate as much as possible.•Select technology a security focus.
A Security Framework: SD3
•Engineer training•Secure architecture•Security code reviews•Threat modeling•Reduce vulnerabilities in code
SecureBy Design
SecureBy Default
•Reduce attack surface area•Unused features off by default•Run with least privilege
SecureIn Deployment
•Protect, detect, defend, recover, manage•Process: how to’s, architecture guides•Proper training
Threat Models
You cannot build secure applications unless you understand your threats
“We use SSL!”
“We have a firewall!”
Create a security analysis of your application
Find different bugs than code review and testing
Find layered security bugs
Quantify your attack surface
Starting point for testing
The Sample Application
Web server
AuthenticationData
Bill PaymentData
Admininterface logic
Bill paymentbusiness logic
UserInterface
Web serviceclient
User
User
AdministrativeApplication
Administrator
Uploadinterface
Developer
The Threat Modeling Process
1. Decompose the application
2. Determine the threats
3. Rank the threats by decreasing risk
4. Choose how to respond to the threats
5. Choose mitigation techniques
1. Decompose The Application
Diagram the flow of data and/or control
Data flow diagrams
UML activity diagrams
Recursively decompose the application into systems
First determine trust boundaries
Define subsystems
1. Decompose The Application continued
Go n levels deep
2, 3, 4, …
Until you understand the processes in the application
Consider:
Define the scope, not every inner working
Identify data sources and processes
Identify request target and response recipients
Flow of data/control across trust boundaries
Context Data Flow Diagram
Bill Paymentapplication
Admin
User
Developer
Admin task request
Admin task response
Bill payment request
Bill payment response
Update filesIn
tern
et
Dat
a ce
nter
Level 1 Data Flow Diagram (partial)
UserServiceclient
request
Enforcebill payment
policyAccess
data
Bill paymentrequest
Bill paymentrequest
Bill paymentdata request
Bill paymentdata
Bill paymentresponse
Bill paymentresponse
AuthenticationData
WebPages
Webservicecode
Bill paymentdata
Cred-entials
Requestpage
Bill paymentdata request
Authstatus
Inte
rnet
Dat
a ce
nter
Mac
hine
bou
ndar
y
Requestedcode
2. Determine The Threats
Use STRIDE to categorize the threats
Spoofing identity
Tampering with data
Repudiation
Information disclosure
Denial of service
Elevation of privilege
Spoofing Identity
An attacker poses as another user or a machine poses as a valid/trusted machine
Examples
Basic HTTP authentication sends credentials in the clear
Credentials or tokens stored in HTTP cookies
Authentication tokens in the clear on the wire
Intercepting DNS requests – DNS spoofing
Tampering With Data
Attacker modifies data
Examples
SQL injection to modify database data
Modifying data on the wire, in transit
Unsecured access to pages and components
HTTP Cookies
Repudiation
No way to know what an attacker or user did
Examples
User performs an illegal operation and there is no trace of what happened
Attacker gets a product ordered without paying and there is no audit trail
Information Disclosure
Exposure of information to a user who is not supposed to see it
Examples
Reading on the wire
Unsecured pages and components
Error messages that reveal implementation details
Denial Of Service
Attacker denies service to valid users
Examples
DDoS attacks
Poorly behaved components that can be exploited
Disabling a credential store
Elevation Of Privilege
Unprivileged user gains privileged access
Examples
Install an .exe and wait for an admin logon
Unsecured components that communicate to other services with admin rights
Impersonation
Document The Threats
Threat Trees
Threat Outlines
Threat Details
Threat Trees
Threat #1Gain user’s credentialsI, S, E
1.2Guess validcredentials
1.3Compromiseserver credentialstore
1.4.1User acquiresvirus that readspassword
1.4.2Install maliciouscode on computer
1.4Malicious softwarereads local user’spassword
1.1Snoopauthenticationconnection
Describes the attacker’s process
Threat Outlines
1 Gain user’s credentials
1.1 Snoop authentication connection
1.2 Guess valid credentials
1.3 Compromise server credential store
1.4 Malicious software reads local user’s password• 1.4.1 User acquires virus that reads password• 1.4.2 Install malicious code on computer
Threat Details
Title Gain user’s credentials
Threat target Bill payment request
Threat types Information disclosure, Spoofing identity, Elevation of privilege
Risk …
Mitigation techniques Use SSL
Bug number …
3. Rank The Threats
Calculate using DREADDamage potentialReproducibilityExploitabilityAffected usersDiscoverability
Rank by decreasing riskRank each from 1 – 10Threat risk = average
3. Rank The Threats
Calculate by following the path of least resistance
1 Gain user’s credentials
Damage potential: 8
Reproducibility: 10
Exploitability: 7
Affected users: 10
Discoverability: 10
DREAD Risk: 7.5
4. Choose How To Respond
Do nothing
You’ll eventually pay for this choice
Warn the user
Will the user know what to do?
Remove the problem
Rather than ship a security bug
Fix the problem
Yes!
5. Choose Mitigation Techniques
Spoofing identity Appropriate authenticationDon’t store secrets
Tampering with Data Appropriate authorizationHashes, digital signaturesTamper-resistant protocols
Repudiation Digital signaturesAudit trails
Information disclosure AuthorizationEncryptionDon’t store secrets
Denial of service Filtering, Throttling, QoSAppropriate Authorization
Elevation of Privilege Run with least privilege
5. Choose Mitigation Techniques continued
Threat #1Gain user’s credentialsI, S, E
1.2Guess validcredentials
1.3Compromiseserver credentialstore
1.4.1User acquiresvirus that readspassword
1.4.2Install maliciouscode on computer
1.4Malicious softwarereads local user’spassword
1.1Snoopauthenticationconnection
Using SSL
Need physicalaccess to server
Need physicalaccess tomachine
Enforce strongpasswords
Update your threat documentation to include mitigation
Secure Programming Principles
Don’t trust user input
Run with least privilege
Secure failure and defaults
Defend with depth
Don’t store secrets
Assume external systems are insecure
Security Testing
The QA process must include a security focus
Think ‘evil’
Threat model drives testing
Each threat gets tested
STRIDE drives techniques
DREAD drives priorities
Mutate data for attacks
Can you identify new threats?
Questions?
Passionate about technologyStrategy & ConsultingEducation & MentoringApplication DevelopmentApplication Security
http://www.sftsrc.com
