1 of 47

Threat Modeling

Laurie Williams �laurie_williams@ncsu.edu

1

OWASP Threat Dragon Apache 2.0

2 of 47

Announcements

Hope to get the grading done ASAP

The TAs has spring break too … but we’re all back now
Workshops 6, 7, 8; Midterm; Project 2

Project 2 Peer Eval due Wednesday (3/19) @ 10AM

Was incorrect in Gradescope

Project 3 released, due Wednesday, April 2

Was incorrect on class schedule

3 of 47

Where we are in this class

Just scratching the surface, but …

Mechanisms

(Vulnerabilities)

Devious Thinking

Prevention

Implementation bugs
Design flaws
OWASP Top 10
CWE Top 25

ATT&CK
CAPEC

Attack trees
Threat modeling
Abuse/misuse cases
Security Requirements

4 of 47

What is a threat? A threat model?

Threat = potential event that will have an unwelcome consequence

Threat model = model you employ to think about … then address or mitigate potential threats� …. thinking like an attacker, or an “innocent user” who makes a (security) mistake

5 of 47

The simplest threat model: Four Questions�

What are we working on? (”greenfield” �project or enhancement)
What can go wrong? (Who wants to cause �harm? What security mistakes can be made?)
What are we going to do about it? �(functionality to prevent “what can go �wrong”)
Did we do a good job? (testing the �functionality)

6 of 47

Discuss with your neighborStory

As a physician, I want to edit my patient records so that I can manage their care as can other health care providers.

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

7 of 47

More systematic software security threat modeling

Set of techniques aimed at identifying threats to a system based upon how it is architected and how it supposed to behave
Process of decomposing a system architecture:

Key structural elements
Assets
Attack surface
Data and control flow
Security mechanisms
Trust boundaries

8 of 47

Who

Building a threat model

Program Manager (PM) owns overall process
Testers

Identify threats in analyze phase
Use threat models to drive test plans

Developers create diagrams
Business analysts

Customers for threat models

Your team
Other features, product teams
Customers, via user education
“External” quality assurance resources, such as pen testers

You’ll need to decide what fits to �your organization

So who’s involved in creating the threat model? “You” isn’t a very precise answer. There’s two groups involved: first are the team that builds it, and second are the teams that consume it.

The folks that build it are dev, test and PM. At Microsoft, program managers are a mix of project manager, product manager and architect who define what the overall product will be. All three have a role in the creation of threat models. Some teams have their testers own the threat model—the tester’s approach to the world is often a good one for finding issues with designs.

Creating great threat models is going to require that the threat models be part of your development process, not just documents that sit on a shelf. Working to ensure that threat models are widely consumed is important. So let’s look at some of the customers for threat models:

Your team, when new people come on board, or when you hit major development milestones.
If you’re working on a large project, talk to other feature teams. Review your threat models together to make sure you understand the security expectations of each side.
If there are external security notes in your threat model, some of that data may go to your customers.
If you hire pen testers or other security QA, showing them your threat models will save you time and money.

9 of 47

Why

Produce software that’s secure by design

Improve designs the same way we’ve improved code

Because attackers think differently

Creator blindness/new perspective

Allow you to predictably and effectively�find security problems early in the process
Understand your security requirements

10 of 47

How?

11 of 47

The Process

Diagram

Identify Threats

Address

Threats

Validate

12 of 47

Diagram

Sketch high level view of system
Most commonly a Data Flow Diagram (DFD)

Sketching DFD 🡺 Understand the system
Analyzing DFD 🡺 Understand the threats

13 of 47

Data Flow Diagram (DFD): Symbols

External Entity / Interactor

Process

Data store

Data flow

Trust boundary

14 of 47

DFD Elements: Examples

External Entity	People, other systems
Process	DLLS, Components, Services, Web Services
Data Flow	Function call, Network traffic, Remote procedure call
Data Store	Database, file, registry, shared memory, queue
Trust Boundary	Process boundary, file system, system boundary

15 of 47

Data Flow Diagram – Detailed

https://www.owasp.org/index.php/Application_Threat_Modeling

16 of 47

Diagrams Should Not Resemble

Flow charts
Class diagrams
Call graphs

17 of 47

The Process: Identify Threats

Diagram

Identify Threats

Address

Threats

Validate

18 of 47

Identify Threats

Use a systematic approach to identify the application exposure to threats

Attack libraries (ATT&CK, CAPEC), common vulnerabilities (implementation bugs & design flaws)
Attack trees
Analyze DFD via (Microsoft’s) STRIDE
Elevation of Privilege game (to come)
Abuse and misuse cases (to come)
Unstructured Brainstorm

Outcome: List of threats relevant to the application environment, the hosts, �and the application tiers

19 of 47

(Microsoft) STRIDE

Threat Property we want
Spoofing	Authentication
Tampering	Integrity
Repudiation	Nonrepudiation
Information Disclosure	Confidentiality
Denial of Service	Availability
Elevation of Privilege	Authorization

20 of 47

Threat: Spoofing

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

21 of 47

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

22 of 47

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!”

23 of 47

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

24 of 47

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

25 of 47

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

26 of 47

Different Threats Affect Each Element Type�

Process

Data Store

S T R I D E



ELEMENT

?

Data Flow

External Entity

27 of 47

What STRIDE Threats Exist?

https://www.owasp.org/index.php/Application_Threat_Modeling

28 of 47

STRIDE: Review

Threat Property we want
Spoofing	Authentication
Tampering	Integrity
Repudiation	Nonrepudiation
Information Disclosure	Confidentiality
Denial of Service	Availability
Elevation of Privilege	Authorization

29 of 47

The Process: Address Threats

Diagram

Identify Threats

Address

Threats

Validate

30 of 47

Addressing Threats is the Point of Threat Modeling

Protect customers
Design secure software
Why bother if you:

Create a great model
Identify lots of threats
Stop

So, find problems and fix them

31 of 47

Address Threats: META

For each threat,

Mitigate

What have similar software packages done and how has that worked out for them?

Eliminate

Redesign

Transfer

Another part of the system or entity

Accept

“wait and see”

32 of 47

STRIDE: Standard Mitigations

Threat	Property
Spoofing	Authentication	To authenticate principals: Basic authentication Digest authentication Cookie authentication Windows authentication (NTLM) Kerberos authentication PKI systems, such as SSL or TLS and certificates IPSec Digitally signed packets To authenticate code or data: Digital signatures Message authentication codes Hashes

33 of 47

STRIDE: Standard Mitigations

Threat	Property
Tampering	Integrity	Windows Vista mandatory integrity controls ACLs Digital signatures Message authentication codes

34 of 47

STRIDE: Standard Mitigations

Threat	Property
Repudiation	Nonrepudiation	Strong authentication Secure logging and auditing Digital signatures Secure time stamps Trusted third parties

35 of 47

STRIDE: Standard Mitigations

Threat	Property
Information Disclosure	Confidentiality	Encryption Access Control Lists (ACLs)

36 of 47

STRIDE: Standard Mitigations

Threat	Property
Denial of Service	Availability	ACLs Filtering Quotas Authorization High-availability designs

37 of 47

STRIDE: Standard Mitigations

Threat	Property
Elevation of Privilege	Authorization	ACLs Group or role membership Privilege ownership Permissions Input validation Least Privilege

38 of 47

The Process: Validate

Diagram

Identify Threats

Address

Threats

Validate

39 of 47

Validate DFDs

Can we tell a story without changing the diagram?
Can we tell that story without using words such as “sometimes” or “also”?
Can we look at the diagram and see exactly where the software will make a security decision?
Does the diagram show all the trust boundaries, such as where different accounts interact? Do you cover all user roles, all application roles, and all network interfaces?
Does the diagram reflect the current or planned reality of the software?
Can we see where all the data goes and who uses it?
Do we see the processes that move data from one data store to another?

40 of 47

Validate Threats

Have we looked for each of the STRIDE threats?
Have we looked at each element of the diagram?
Have we looked at each data flow in the diagram?
For each threat: Does it:

Describe the attack
Describe the context
Describe the impact

41 of 47

Validate “Addressing Threats”

Is there a proposed/planned/implemented way to address each threat?
Is the mitigation correctly implemented?

Test cases?
Software passed tests?

42 of 47

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

43 of 47

OWASP Threat Dragon

44 of 47

Granularity

Way too big in terms of granularity for a web application as big as OpenEMR. Break up into major modules of functionality.

45 of 47

OWASP Threat Dragon

46 of 47

The simplest threat model: Four Questions�

What are we working on? (”greenfield” �project or enhancement)
What can go wrong? (Who wants to cause �harm? What security mistakes can be made?)
What are we going to do about it? �(functionality to prevent “what can go �wrong”)
Did we do a good job? (testing the �functionality)

47 of 47

Summary

Threat models helps you find and proactively mitigate security design flaws before the system is built
Threat models help you understand your application better and find bugs.
Threat models help new team members (and other teams) understand the application in detail.
Threat models can be used by testers to plan test cases.
Treat model bugs are entered into the defect tracking system.

47