Secure Design: Threat Modeling

Copyright © 2016, Cigital and/or its affiliates. All rights reserved. | Cigital Confidential Restricted
Secure Design: Threat Modeling
OWASP-Cleveland Chapter
October 2016
Amit Sethi
Senior Principal Consultant, Cigital

About Cigital
Cigital is one of the world’s largest application
security firms. We go beyond traditional testing
services to help organizations find, fix and
prevent vulnerabilities in the applications that
power their business.
Our holistic approach to application security offers a balance of
managed services, professional services and products tailored to
fit your specific needs. We don't stop when the test is over. Our
experts also provide remediation guidance, program design
services, and training that empower you to build and maintain
secure applications.
Cigital is headquartered near Washington, D.C. with regional
offices in the U.S., London and India.
For more information, visit us at www.Cigital.com
2

Why Code Reviews and Pen Tests Are Not Enough
This section is excerpted from a presentation at the
February 2015 OWASP Belgium Chapter Meeting
Jim DelGrosso, Architecture Practice Lead at Cigital

The Defect Universe – Bugs and Flaws
5
(Implementation) BUGS (Design) FLAWS
Cross Site Scripting
Buffer Overflow
Weak/Missing/Wrong
Security Control
Architecture Analysis
Code Review
Penetration Testing

Examples of Bugs and Flaws
• SQL Injection
• XML/XPath/* Injection
• Cross-Site Scripting
• Buffer Overflow
• Unsafe system calls
• Predictable Identifiers
• Hardcoding secrets in
code
• Misuse of cryptography
• Broad trust between
components
• Client-side trust
• Broken or illogical access
control (RBAC over tiers)
• Missing defense for
replay attacks
• Insecure auditing
Implementation BUGS Design FLAWS

What Is Threat Modeling?
• Identifies secure-design weaknesses
• Missing security controls
• Weak or inappropriate security controls
• Potential vulnerabilities
• Finds weaknesses that cannot be found by other
techniques
It is not a replacement for pen-testing or secure code
review.
Threat modeling (TM) is software design analysis that looks
for security weaknesses by juxtaposing software design
views against a set of threat agents:
8

Threat Modeling Process
• Define scope and depth of analysis
• Gain understanding of what is being threat modeled
• Decompose and model the software
• Model the attack possibilities
• Identify assets, security controls and threat agents
• Juxtapose attack possibilities and software model
• Interpret the threat model
• Produce the list of attacks
• Create the traceability matrix for reporting the attacks
• Rank the risk of the attack
• Propose mitigations
Threat modeling process includes the following steps:
10

System Threat Model
• Holistic view of application’s security posture
• Considers both application and infrastructure
• Builds roadmap for additional security activities
Characteristics of the System Threat Model include:
11

Protocol/Sequence/API Threat Model
• Analysis of message
structure and component
interaction
• Bridges gap between
system threat model and
code review
Protocol/Sequence/API Threat Model
Characteristics include:
12

Decompose and Model the System
• Understand how the system works (before trying to
break it)
• Who uses the system
• What are the business goals
• What are the dependencies between systems
• What systems (components) does this system make use of
• What systems (components) use this system
• Review (some) development documentation
• Interview members of various teams
To decompose and model the system:
14

Gain Understanding from Interviews
• Social-networking payment application
• Some content and features membership-only; some, free
• App is JavaEE app; uses WebLogic as JavaEE container
• Backend database is Oracle
• Stores user’s preferences
• Produces some membership-only reports
• Web UI built using JQuery JavaScript library
• Web UI calls third-party REST services for user-specific
content
• User connectivity and interface to backend services uses
HTTPS
From the interview, you learn:
15

Diagrams from Development/Infrastructure Teams
16
Deployment Model
Layer Model
Logical Model

Layer Model (from Development)
17

Logical Model (from Development)
18

Deployment Model (from Infrastructure)
19

Modeling the System Structure
• Which components are in-scope for this “release”
• How control flows between these components
• How components and flows relate to host boundaries
and network zones
• Application layer communication protocols that connect
components
Model can use an existing diagram or one you create:
• For this presentation, we’ll create our own to help
understand the most relevant parts for a threat model
• Creating a separate diagram is optional
Based on the interviews and development/infrastructure
diagrams, create a model that shows:
20

Simplified System Model
Components come from
the Logical and Layer
Models
Protocols come
from the
Deployment Model
Machine boundaries come
from the Deployment Model
Network zones come from
the Deployment Model
Forum is out of
scope
21

Modeling the Attack Possibilities
To model the attack possibilities, continue to analyze the
information we’ve collected in our interviews. And now add
the related threat model elements:
Assets Data and functions that the system
must protect
Security Controls Mechanisms currently designed and
implemented to protect the Assets
Threat Agents Actors that want to harm the system
Juxtaposing the attack possibilities and the system creates
the actual threat model. Interpreting the model produces a
list of potential attacks.
22

Identifying Assets from Interviews
• App is JavaEE app; uses WebLogic as JavaEE
container
content
HTTPS
Information collected in development interviews:
23

Identifying Assets from Interviews
• Some content [A01] and features [A02] membership-
only; some, free
container
• Backend database [A03] is Oracle
• Web UI calls third-party REST services [A04] for user-
specific content
HTTPS
24

Model the Attack Possibilities: Assets
25

Identifying Controls from Interviews
• App is JavaEE app; uses WebLogic as JavaEE container
content
HTTPS
26

Identifying Controls from Interviews
• Some content and features membership-only
[C01][C02]; some, free
container
content
HTTPS [C03]
27

Model the Attack Possibilities: Security Controls
28

Identify Threat Agents
• Start with the canonical threat agents for the software
• Associate the threat agent with system components they
directly interact with
• Minimize the number of threat agents by treating them
as equivalence classes
• For example, assume a technically sophisticated threat agent and
a script-kiddie are the same
• Assume that a threat agent can be motivated to attack
the system
• Consider motivation when evaluating likelihood
Threat agents are primarily based on access. To identify
threat agents:
29

System TM Canonical Threat Agents
1. Unauthorized External, Internet-based Attacker
2. Unauthorized Internal/External (client-side), LAN-based Attacker
3. Authorized External, Malicious User
4. Authorized Internal, Malicious App/System Admin
Cloud-hosted applications should account for:
5. Authorized Malicious Cloud Provider Admin
Mobile client applications should account for:
6. Malware on a Jailbroken/Rooted device
Most internet-based applications can start using canonical
set of threat agents:
30

Model the Attack Possibilities: Threat Agents
These zones contain
TA02 and TA03
31

Additional Threat Agents
• Are business or application specific
• Generate additional potential attacks in the traceability
matrix; otherwise, the threat agent is superfluous
• Increase the depth of the threat model, but also adds
time to the analysis
Additional threat agents:
32

Evaluating Pivots Using Threat Agents
Intermediate attack objectives (pivots) can be done by creating a
threat agent for the compromised component.
33

Interpret the Threat Model
• Is there any path where threat agent can reach asset
without going through a control?
• For any security control along each of those paths:
• What must threat agent do to defeat the control?
• Can threat agent defeat the control?
Record missing or weak controls in the traceability matrix
To interpret the threat model, start with threat agent and
follow flow-of-control paths to reach an asset:
34

Create the Traceability Matrix
• Identifies a potential attack
• Identifies impact if the potential attack were to succeed
• Proposes mitigations to development to reduce the risk
to an acceptable level
• Mitigations should be practical and implementable
• Important to create a “shared vision” with the development team
Create the traceability matrix where each entry:
36

Traceability Matrix – In One Sentence
“A threat agent, trying to compromise some asset, using
attack, interacting via attack surface, in order to achieve
attack goal, having impact, mitigated to an acceptable risk
level by control.”
37
Threat Agent Asset Attack Attack Surface Attack Goal Impact Control
Threat Agent Asset
com-
promised
Actual
exploit
Entry point
used by
attacker
Goal of
attack
Impact Mitigation

Traceability Matrix Entry
Threat Agent
• An entity (e.g., object, substance, human) that can act against an asset and cause harm.
Asset
• Data, functionality, or a property of the system that a threat agent wants to access.
Attack
• The combination of software, system state, input data, and steps required to achieve
successful attack.
Attack Surface
• The collection of points that the threat agent directly interacts with the system.
Attack Goal
• What the threat agent wants to do with access to an asset. Often considered the
consequence of the attack — that is, what can go wrong.
Impact
• The impact severity associated with a successful attack (high/medium/low).
Security Control
• The mechanism that protects an asset, either completely or partially, from one or more
threat agents. A control only needs to reduce the overall risk of a successful attack to an
acceptable level.
Mitigation
• Recommended mitigations if the potential attack turns out to be possible.
38

Other Threat Models
• Microsoft STRIDE. focuses on six threat categories,
namely Spoofing, Tampering, Repudiation, Information
disclosure, Denial of service, Elevation of privilege.
• https://msdn.microsoft.com/en-
us/library/ee823878%28v=cs.20%29.aspx
• Attack Trees are conceptual diagrams showing how a
target might be attacked.
• https://www.schneier.com/attacktrees.pdf
The Cigital threat model is relatively simple and teachable
and straightforward to practice. There are other models:
39

Thank you for your time!
To contact instructor: asethi@cigital.com
For information about services offered by Cigital:
http://www.cigital.com
info@cigital.com
Phone: 800.824.0022
40

Secure Design: Threat Modeling

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Secure Design: Threat Modeling (20)

More from Cigital (11)

Recently uploaded (20)

Secure Design: Threat Modeling