2 of 33

INTRODUCTION TO THREAT MODELLING

Potential Harm
Probability of Occurrence
Priority of Concern
Means to Eradicate or Reduce Threat

Threat modelling is a way to identify, categorize and analyse threats looking at:

Threat Modeling is a process that helps the architecture team:

One of the reasons for Threat modelling is being able to identify where to deploy resource based on risks and the importance of the data and systems.
In the real world, you need to identify the risks and deploy appropriate resources accordingly.
The threat modelling is also important for all services but the actual risks and resources may vary based on different systems.

Accurately determine the attack surface for the application
Assign risk to the various threats
Drive the vulnerability mitigation process
It is widely considered to be the one best method of improving the security of software

3 of 33

INTRODUCTION TO THREAT MODELLING

Threat Modelling is a key security analysis technique that Development, IT and Security teams use to identify critical risks and make better security decisions.

Whether performed on an existing application or throughout the SDLC, it is the starting point in creating, deploying and maintaining secure software applications.

Benefits include:

Fast and practical - allows for many applications to be analysed in a short period of time.

Exposes REAL threats - not hypothetical or potential threats (very few or no false positives).

Maps to each phase of the SDLC - drives design decisions, implementation guidelines, and testing activities

Produces a persistent and tangible asset - can be leveraged whenever new risks are uncovered

4 of 33

THREAT MODELLING PHASE(S)

Use Scenarios what are the boundaries of the security problem
Identify external dependencies OS, web server, network, …
Define security assumptions

What can you expect with regard to security; will the DB encrypt columns? Is there a key manager?
What are the limitations you are working with..

Understand the security requirements

Identify assets
Identify roles
Their interaction

2. Create an activity matrix (actor-asset-action matrix

5 of 33

THREAT MODELLING PHASE(S)

Identify threats that put assets at risk
Identify attacks that can be used to realize each threat

Threat Trees
Abuse Cases

Determine the risk for each attack and prioritize (if needed)
Define the conditions required for each attack to be successful

3. Create Trust Boundaries

4. Plan and implement your mitigation

6 of 33

Understand the terms “Threat” and “Risk” in

a threat modelling context

All risks and threats cannot be eliminated, Mitigation comes in during those scenarios

Mitigate

Few risks and threats have to be accepted at that point of time and later can be checked.

Threats and risks can be transferred as well

Transfer

Eliminating risk and threat through planning and implementing proper strategies

Eliminate

Overall, there are four main strategies for addressing threats:

7 of 33

The Approach

Identify Security Objectives

Application Overview and walkthrough

Breakdown/Decompose Application

Identify Vulnerabilities

Threat Identification

8 of 33

Selecting Methodology

STRIDE

PASTA

Trike

Continuous Threat

Modeling

Spoofing Tampering

Repudiation Info. Disclosure

Elevation of Privilege

Process for Attack Simulation

& Threat Analysis

Risk Centric

High levels of automation

possible from the defensive

perspective

Spoofing Tampering

Repudiation Info. Disclosure

Elevation of Privilege

ATASM

DREAD

Threat

Surging

Rapid Threat

Modeling

Architecture. Threats.

Attack Sudaces, and

Mitigations

Damage Reproducibility

Exploitability Affected Users

Discoverability

Analysis and feedback of

Threat rnodelling

results

range of processes that use lighter-weight variations

of other methodologies

9 of 33

When to do Threat Modelling

Requirements and Use-Cases

Architecture and Design

Test Plans

Code

Testing and Test Results

Feedback from the Field

Abuse Cases

Security Requirements

Risk Analysis

Risk-based Security Testing

Risk analysis

Penetration Testing

Security Operations

Code Review (Tools)

10 of 33

Defining the Scope

Focussing only on application layer is not enough, that is considering some vulnerabilities in source code , some issues with configurations, etc. The typical recommendations are usually to protect the application from attacks like OWASP Top 10 and any similar threats.

Based on your scope; you may include other layers including infrastructure, Operating Systems, virtualization, Docker images, Kubernetes, other layers that could be source to other threats.

You may also need to consider other security threats and related mitigations at the org. level and part of risk management process.

The most critical part of Threat Modelling

11 of 33

Architecture

External Entity

Other systems
Source
People

Actor

Data Flow

Function calls
Network Traffic

Data Rest

DB
Registry
File shares
Memory

Boundary

Firewall
Access Control

Process

Services
Executables
DLLs
APIs
We App

12 of 33

Understand the Attack Surface

Vulnerability: a software defect with security consequences
Threat: a potential danger to the software
Attack: an attempt to damage or gain access to the system
Exploit: a successful attack
Trust Boundary: where the level of trust changes for data or code

13 of 33

The STRIDE per Element Approach to Threat Modeling

Diagram

Identify Threats

Mitigate

Validate

14 of 33

Context

Use DFDs (Data Flow Diagrams)

Include processes, data stores, data flows
Include trust boundaries
Diagrams per scenario may be helpful

Update diagrams as product changes
Enumerate assumptions, dependencies

Diagram - Checks

Where does the data come from ? External or from Data stores
Data is used by whom ? Or for what purpose ?
How does the data flow ?

15 of 33

Identify Threats

To be discussed among the teams
How to do this without being an expert?

Use STRIDE to step through the diagram elements
Get specific about threat manifestation

16 of 33

Threat: Spoofing

Threat	Spoofing
Property	Authentication
Definition	Impersonating something or someone else
Example	Pretending to be any of billg, microsoft.com, or ntdll.dll

17 of 33

Threat: Tampering

Threat	Tampering
Property	Integrity
Definition	Modifying data or code
Example	Modifying a DLL on disk or DVD, or a packet as it traverses the LAN

18 of 33

Threat: Repudiation

Threat	Repudiation
Property	Non-Repudiation
Definition	Claiming to have not performed�an action
Example	“I didn’t send that email,” “I didn’t modify that file,” “I certainly didn’t visit that Web site, dear!”

19 of 33

Threat: Information Disclosure

Threat	Information Disclosure
Property	Confidentiality
Definition	Exposing information to someone not authorized to see it
Example	Allowing someone to read the Windows source code; publishing a list of customers to a Web site

20 of 33

Threat: Denial of Service

Threat	Denial of Service
Property	Availability
Definition	Deny or degrade service to users
Example	Crashing Windows or a Web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole

21 of 33

Threat: Elevation of Privilege

Threat	Elevation of Privilege (EoP)
Property	Authorization
Definition	Gain capabilities without proper authorization
Example	Allowing a remote Internet user to run commands is the classic example, but going from a “Limited User” to “Admin” is also EoP

22 of 33

Threats Affecting Each Element Type

23 of 33

Threats Affecting Each Element Type

Trusted/ high code reading from untrusted/low

Validate everything for specific and defined uses

High code writing to low

Make sure your errors don’t give away too much

Threats and Distractions

Don’t worry about these threats

The computer is infected with malware
Someone removed the hard drive and tampers
Admin is attacking user
A user is attacking himself

You can’t address any of these (unless you’re the OS)

24 of 33

The Process: Mitigation

Diagram

Identify Threats

Mitigate

Validate

25 of 33

Mitigation Is the Point of Threat Modeling

Mitigation

To address or alleviate a problem

Protect customers

Design secure software

Why bother if you:

Create a great model
Identify lots of threats
Stop

So, find problems and fix them

26 of 33

Mitigate

Address each threat

Four ways to address threats

Redesign to eliminate
Apply standard mitigations
What have similar software packages done and how has that worked out for them?
Invent new mitigations (riskier)
Accept vulnerability in design

SDL rules about what you can accept

Address each threat

27 of 33

Standard Mitigations

Spoofing	Authentication	To authenticate principals: Cookie authentication Kerberos authentication PKI systems such as SSL/TLS and certificates To authenticate code or data: Digital signatures
Tampering	Integrity	Windows Vista Mandatory Integrity Controls ACLs Digital signatures
Repudiation	Non Repudiation	Secure logging and auditing Digital Signatures
Information Disclosure	Confidentiality	Encryption ACLS
Denial of Service	Availability	ACLs Filtering Quotas
Elevation of Privilege	Authorization	ACLs Group or role membership Privilege ownership Input validation

28 of 33

The Process: Validation

Diagram

Identify Threats

Mitigate

Validate

29 of 33

Validating Threat Models

Validate the whole threat model

Does diagram match final code?
Are threats enumerated?
Minimum: STRIDE per element that touches a trust boundary
Has Test / QA reviewed the model?

Tester approach often finds issues with threat model or details

Is each threat mitigated?
Are mitigations done right?

Did you check these before Final Security Review?

Shipping will be more predictable

30 of 33

Validate Quality of Threats and Mitigations

Threats: Do they

Describe the attack
Describe the context
Describe the impact

Mitigations

Associate with a threat
Describe the mitigations
File a bug

Fuzzing is a test tactic, not a mitigation

31 of 33

Validate Information Captured

Dependencies

What other code are you using?
What security functions are in that other code?
Are you sure?

Assumptions

Things you note as you build the threat model

“HTTP.sys will protect us against SQL Injection”

“LPC will protect us from malformed messages”

GenRandom will give us crypto-strong randomness

32 of 33

Effective Threat Modeling Meetings

Develop draft threat model before the meeting

Use the meeting to discuss

Identify most interesting elements

Assets (if you identify any)
Entry points/trust boundaries

Walk through STRIDE against those elements

Threats that cross elements/recur

Consider library, redesigns

1 of 33

2 of 33

3 of 33

4 of 33

5 of 33

6 of 33

7 of 33

8 of 33

9 of 33

10 of 33

11 of 33

12 of 33

13 of 33

14 of 33

15 of 33

16 of 33

17 of 33

18 of 33

19 of 33

20 of 33

21 of 33

22 of 33

23 of 33

24 of 33

25 of 33

26 of 33

27 of 33

28 of 33

29 of 33

30 of 33

31 of 33

32 of 33

33 of 33