secure design: threat modeling

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

http://www.cigital.com/

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

4

Cigital Touchpoints

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

Threat Model Process

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:

9

Threat Modeling Vocabulary

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:

System Threat Models

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

16

Diagrams from Development/Infrastructure Teams

Deployment Model

Layer Model

Logical Model

17

Layer Model (from Development)

18

Logical Model (from Development)

19

Deployment Model (from Infrastructure)

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




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


• 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


24

25

Model the Attack Possibilities: Assets

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




HTTPS


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


• User connectivity and interface to backend services uses HTTPS [C03]


27

28

Model the Attack Possibilities: Security Controls

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

31

Model the Attack Possibilities: Threat Agents

These zones contain TA02 and TA03

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:

35

Interpret the Threat Model

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:

https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx

https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx

https://www.schneier.com/attacktrees.pdf

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

mailto:[email protected]

mailto:[email protected]

secure design: threat modeling

Software