Application Security and

Threat Modeling

Ben Hickman
VP Engineering
ben.hickman@sftsrc.com
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 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
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.
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
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
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
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

Data center
Internet
Admin

Admin task request

Admin task response

Bill payment request Bill Payment

application
User
Bill payment response

Update files

Developer
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
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

„ 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
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 DREAD

™ Damage potential
™ Reproducibility
™ Exploitability
™ Affected users
™ Discoverability
„ Rank by decreasing risk
™ Rank each from 1 – 10
™ Threat 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 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

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
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 technology

™ Strategy & Consulting
™ Education & Mentoring
™ Application Development
™ Application Security

http://www.sftsrc.com