Upload
cigital
View
288
Download
3
Embed Size (px)
Citation preview
Copyright © 2016, Cigital and/or its affiliates. All rights reserved. | Cigital Confidential Restricted
Secure Design: Threat Modeling
OWASP-Cleveland ChapterOctober 2016
Amit SethiSenior 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
5
The Defect Universe – Bugs and Flaws
(Implementation) BUGS (Design) FLAWS
Cross Site ScriptingBuffer 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
8
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:
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
12
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:
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
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
21
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
22
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.
Identifying Assets 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
Information collected in development interviews:
23
Identifying Assets from Interviews
• Social-networking payment application • Some content [A01] and features [A02] membership-only;
some, free • App is JavaEE app; uses WebLogic as JavaEE container• Backend database [A03] 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 [A04] for user-specific
content • User connectivity and interface to backend services uses HTTPS
Information collected in development interviews:
24
Identifying Controls 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
Information collected in development interviews:
26
Identifying Controls from Interviews
• Social-networking payment application • Some content and features membership-only [C01][C02]; some,
free • App is JavaEE app; uses WebLogic as JavaEE container• Web UI built using JQuery JavaScript library• Web UI calls third-party REST services for user-specific content • Backend database is Oracle
• Stores user’s preferences • Produces some membership-only reports
• User connectivity and interface to backend services uses HTTPS [C03]
Information collected in development interviews:
27
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 Attacker2. Unauthorized Internal/External (client-side), LAN-based Attacker3. Authorized External, Malicious User4. 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
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
33
Evaluating Pivots Using Threat Agents
Intermediate attack objectives (pivots) can be done by creating a threat agent for the compromised component.
34
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:
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
37
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.”
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
38
Traceability Matrix EntryThreat 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.
39
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:
40
Thank you for your time!
To contact instructor: [email protected] For information about services offered by Cigital:
http://[email protected]
Phone: 800.824.0022