2. Agenda
Why Worry?
Creating a Security Process
Threat Models
The Threat Modeling Process
Secure Programming Principles
Security Testing
Questions?
3. 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 a CERT Incidents
requirement or (http://www.cert.org/stats/cert_stats.html)
a competitive
140000
advantage
120000
100000
80000
60000
40000
20000
0
88
89
90
91
92
93
94
95
96
97
98
99
00
01
02
03
19
19
19
19
19
19
19
19
19
19
19
19
20
20
20
20
4. Creating a Security Process
•Train and keep current in application security.
•Architects, developers, testers
People •Stay disciplined about security.
•Stay current with the state of the art.
•Make security a critical part of design, development,
testing, and deployment.
Process •Security threat analysis part of every design
•Design and code reviews
•External audits.
•Build tools, automate as much as possible.
Technology •Select technology a security focus.
5. A Security Framework: SD3
•Engineer training
Secure •Secure architecture
•Security code reviews
By Design •Threat modeling
•Reduce vulnerabilities in code
Secure •Reduce attack surface area
•Unused features off by default
By Default •Run with least privilege
Secure •Protect, detect, defend, recover, manage
•Process: how to’s, architecture guides
In Deployment •Proper training
6. 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
7. The Sample Application
Administrative
Application
Administrator
Authentication Admin Bill Payment
Data interface logic Data
User
Interface
User
Bill payment
business logic
Web server
Web service
client
User
Upload
interface
Developer
8. 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
9. 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
10. 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
11. Context Data Flow Diagram
Data center
Internet
Admin
Admin task request
Admin task response
Bill payment request Bill Payment
application
User
Bill payment response
Update files
Developer
12. Level 1 Data Flow Diagram (partial)
Data center
Machine boundary
Internet Authentication
Bill payment
Data
data
Cred-
entials Auth Bill payment
status data request
Bill payment Bill payment
Bill payment request data request
request Service Enforce
bill payment Access
User client
policy data
request
Bill payment Bill payment Bill payment
response response data
Request Requested
page code
Web
Web
service
Pages
code
13. 2. Determine The Threats
Use STRIDE to categorize the threats
Spoofing identity
Tampering with data
Repudiation
Information disclosure
Denial of service
Elevation of privilege
14. 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
15. 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
16. 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
17. 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
18. Denial Of Service
Attacker denies service to valid users
Examples
DDoS attacks
Poorly behaved components that can be exploited
Disabling a credential store
19. 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
21. Threat Trees
Describes the attacker’s process
Threat #1
Gain user’s credentials
I, S, E
1.1 1.3 1.4
1.2
Snoop Compromise Malicious software
Guess valid
authentication server credential reads local user’s
credentials
connection store password
1.4.1
1.4.2
User acquires
Install malicious
virus that reads
code on computer
password
22. 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
23. 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 …
24. 3. Rank The Threats
Calculate using DREAD
Damage potential
Reproducibility
Exploitability
Affected users
Discoverability
Rank by decreasing risk
Rank each from 1 – 10
Threat risk = average
25. 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
26. 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!
27. 5. Choose Mitigation Techniques
Spoofing identity Appropriate authentication
Don’t store secrets
Tampering with Data Appropriate authorization
Hashes, digital signatures
Tamper-resistant protocols
Repudiation Digital signatures
Audit trails
Information disclosure Authorization
Encryption
Don’t store secrets
Denial of service Filtering, Throttling, QoS
Appropriate Authorization
Elevation of Privilege Run with least privilege
28. 5. Choose Mitigation Techniques continued
Update your threat documentation to include mitigation
Threat #1
Gain user’s credentials
I, S, E
1.1 1.3 1.4
1.2
Snoop Compromise Malicious software
Guess valid
authentication server credential reads local user’s
credentials
connection store password
1.4.1
1.4.2
User acquires
Install malicious
Enforce strong virus that reads
Using SSL code on computer
passwords password
Need physical
Need physical
access to
access to server
machine
29. 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
30. 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?
