1
OS II: Dependability & Trust
Threat Modeling & Security Metrics
Dependable Embedded Systems & SW Group www.deeds.informatik.tu-darmstadt.de
Prof. Neeraj Suri
Abdelmajid Khelil Daniel Germanus
Dept. of Computer ScienceTU Darmstadt, Germany
2
Terminology Threat: The adversary‘s goals Threat Profile: The collection of all threats of a system Threat Model: A document that provides background
information on a system, its threat profile, and analysis of the current system against that threat profile. Threat modeling results in a living threat model.
Vulnerability: A security flaw in the system. Risk: A characterization of the danger of a vulnerability or
condition. Security Weakness: An insufficient mitigation of a threat
(usually resulting in a vulnerability).
Asset: An abstrat/concrete resource that a system must protect from misuse by an adversary.
3
Motivation
Threat Model is a master plan for securing software
systems
Reckoning applications and technologies w.r.t. their
attackability
Acquire attacker’s way of thinking
Minimize impact in case of successful attack
Prioritize development of fixes for discovered
weaknesses
4
Outline of Today’s Lecture
Discuss fundamental components of a Threat
Model
Example of security metrics: Attack surface
measure
© DEEDS GroupSWFT WS ‘07
5
Threat Model Components
D. Germanus, A. Johansson, N. Suri “Threat Modeling and Dynamic Profiling”, Book chapter in Annals of Emerging Research in Information Assurance, Security and Privacy Services, Elsevier Press, 2008.
6
Roles and Phases
Threat Modeling
Involves different roles: Analysts
System architects
Software engineers
Security engineers
Software testers
Is performed in three phases: Inception
Object identification
Reaction
© DEEDS GroupSWFT WS ’07-08
7
The Three Phases of Threat Modeling
© DEEDS GroupSWFT WS ’07-08
DFD: Data Flow Diagram
Threat effects:STRIDE- Spoofing- Tampering- Repudiation- Information disclosure- Denial of service- Elevation of privilege
Ranking of risk:DREAD- Damage potential- Reproducibility- Exploitability- Affected users- Discoverability
S/O: Subject/Object
8
Threat Modeling: Inception Phase
Sketch data flow diagrams (DFD)
Gain understanding of the system‘s composition &
interactions
Find system entry points
How to interact – UI, resources (local, remote), 3rd party SW
Determine assets
Locality can be derived from DFDs
Output:
DFDs, entry points, assets
© DEEDS GroupSWFT WS ’07-08
9
Threat Modeling: Object Identification Phase
Evaluate which user actions are allowed and the
objects involved
Different methods exist (use scenarios, feature
scenarios etc.), will focus on Subject/Object (S/O) Matrix
Logical, systematic
Output:
External dependencies
Unresolved questions
Deployment constraints
Possible vulnerabilities
© DEEDS GroupSWFT WS ’07-08
10
Object Identification Phase: Subjects & Objects
Identify system‘s subjects and objects
Subjects:
Active entities, carrying out operations on objects
Processes, users
Use DFDs as a basis
Objects:
Subjects are also objects: Processes, users..
Data stores
Data flows
© DEEDS GroupSWFT WS ’07-08
11
Object Identification Phase: S/O Matrix
Subject/Object Matrix generation:
Subjects represented as rows, objects as columns
Assign each subject-object relation an operation
Operations:
Authenticate, Authorize, No Access (Users, Processes)
Load, Read, Execute, Absolute control (Data stores)
When matrix is set-up, first columns and secondly
rows are contracted yielding a compacted matrix
If necessary expand respective rows/columns
e.g., to differ between disparate roles© DEEDS GroupSWFT WS ’07-08
12
Object Identification Phase: Example
Example: Airline quick checkin terminal Terminal capabilities:
Operations: Choose seat, print boarding pass Users: Anonymous (pre auth.), clients (post auth.)
© DEEDS GroupSWFT WS ’07-08
Object contraction
Su
bje
cts
Objects
An: authenticate, Az: authorize, S: send, R: receive
13
Object Identification Phase: Attacker Subject
Finally, append an Attacker subject to the matrix
Attacker subject may perform *every* operation
Discuss in null hypothesis discussion which operations may
be canceled due to infeasibility from attacker subject row
New unresolved questions, deployment constraints, or external
dependencies come up during this discussion
Remaining operations of the attacker are regarded as possible
vulnerabilities
© DEEDS GroupSWFT WS ’07-08
14
Object Identification Phase: Survey Next, a survey is developed using a catalog of questions for
each object class Question catalogs are grouped and refer to:
OS specifics Hardware/driver related issues High level software technology Experiences from the past Reported security flaws (BugTraq, …)
Should be answered by system architects, software and security engineers
More external dependencies, unresolved questions, deployment constraints and possible vulnerabilities (may/will) arise, input for next phase
© DEEDS GroupSWFT WS ’07-08
15
The Three Phases of Threat Modeling (Recall)
© DEEDS GroupSWFT WS ’07-08
DFD: Data Flow Diagram
Threat effects:STRIDE- Spoofing- Tampering- Repudiation- Information disclosure- Denial of service- Elevation of privilege
Ranking of risk:DREAD- Damage potential- Reproducibility- Exploitability- Affected users- Discoverability
S/O: Subject/Object
16
Threat Modeling: Reaction Phase
Previously generated lists and export knowledge are required
to distill potential threats
Threats are
directed against assets
put assets at risk
Reflect an attacker‘s intentions
Next: STRIDE & DREAD ratings, Threat trees …
17
Reaction Phase: STRIDE
STRIDE scheme used for classification of expected impact
Acronym for:
Spoofing – allows attackers to act as another user or component
( vs. authentication)
Tampering – illegal modification of data (integrity)
Repudiation – inability of tracing operations back to a specific user
(non-repudation)
Information disclosure – gain access to data in transit or in a data
store (confidentiality)
DoS – denial of service attack (availability)
Elevation of privilege – illegal raise of access privileges
(authorization)
18
Reaction Phase: Threat Tree
Threat trees helpful to understand dependencies among a
threat‘s partial requirements
Semantics of threat trees similar to that of fault trees in fault
tree analysis (FTA)
Root node represents a threat,
Leaves represent entry points to be used for an attack,
Inner nodes represent partial goals during an attack.
By default, nodes on the same level underly OR-relationship,
i.e., sufficient to fulfill one condition on level n to proceed on
level n-1
Very important node attribute: if condition is mitigated or not
19
Threat Tree Example
Below: threat tree on information leakage of a precious
document
Right subtree is mitigated (as leaves 2.1 and 2.2 are
mitigated)
Left subtree unmitigated, potential entry point: condition 1.2
20
Reaction Phase: DREAD DREAD: used to classify each node in threat trees
Acronym for: Damage potential – rates the affected assets and the
expected impact Reproducibility – rates the effort to bring the attack
about Exploitability – estimates the threat‘s value and an
attacker‘s objectives Affected users – estimates the fraction of installation
which are subject to the attack Discoverability – a measure for the likelihood of
discovering the attack
Rates are measured on a discrete scale, for simplicity in further assessments not too large, e.g., 1: low; 2: medium; 3: high.
21
Reaction Phase: Mitigation?
Based on threat trees, DREAD, and STRIDE ratings,
mitigations are planned
Multiple selection criteria may be of interest in
prioritization, e.g.,
Most easily reproducible vulnerabilities,
Conditions occuring in more than one threat tree,
Strictly damage potential oriented.
After having mitigated one or more conditions,
rerun Threat Modeling process on the respective
component(s)© DEEDS GroupSWFT WS ’07-08
22
Microsoft Threat Modeling Tool
Download:http://www.microsoft.com/downloads/
details.aspx?familyid=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en
23
24
Attack Surface Measure
P. Manadhata and J. Wing. “An Attack Surface Metric" CMU-CS-05-155, July 2005.
P. Manadhata, J. Wing, M. Flynn, M. McQueen. "Measuring the Attack Surfaces of Two FTP Daemons", QoP '06: Proceedings of the 2nd ACM workshop on Quality of Protection, 2006.
25
Attack Surface Measure
Reasoning: Applications should provide a minimum of
accessible services
E.g., API methods, Resources, etc.
Attack Surface is a three dimensional vector
Required input for computation: Entry points – methods that receive data from the
environment
Exit points – methods that send data to the environment
Channels – communication media, e.g., sockets, pipes, etc.
Untrusted data – e.g., DBs or FSs (or single elements like
key/value pairs, data rows/cols in a DB, files).© DEEDS GroupSWFT WS ’07-08
26
Attack Surface Measure
Computation yields a vector <M, C, D> with M(ethods): weighted sum of entry and exit points
C(hannels): weighted channel sum
D(ata): sum of untrusted data items and their weights
How to assign weights?
Damage potential-effort ratio
Attack Surface vector allows comparison, but: Only systems of similar nature comparable, e.g., two
different versions of one system
Cannot compare text processors with database server
applications – disadvantage?
© DEEDS GroupSWFT WS ’07-08
27
Attack Surface Measure: Computation (1)
Automatize computation Imagine systems with several MLoC
But: many concepts are implemented differently among
disparate technologies
Static analysis good for evaluation task of entry/exit
points Need call graphs to distinguish between internal methods (not
directly callable from the environment) and API methods which
constitute an entry/exit point
Channels and untrusted data items evaluated during
runtime
© DEEDS GroupSWFT WS ’07-08
28
Attack Surface Measure : Computation (2)
© DEEDS GroupSWFT WS ’07-08
manually
29
Attack Surface Measure – FTP Daemons (1) Attack Surface for 2
FTP daemons [5] Wu-FTPD ProFTPD
© DEEDS GroupSWFT WS ’07-08
The number of channels opened by both
daemons:
The number of direct entry points (DEP) and direct
exit points (DExP) in both codebases:
AR: Access rights, RU: Remote unauthorized
Data (in default exe): files such as config,
log..:
30
Attack Surface Measure – FTP Daemons (2)
Damage potential estimation Define ordering in each resource class Assign values
Table: Numeric values assigned to the values of the attributes
Channel’s damage potential in terms of
the channel’s protocol
A data item’s damage potential in terms of the data item’s type
Estimate a method’s damage potential in
terms of the method’s privilege.
Estimate the effort the attacker needs to
spend to use a resource in an attack
in terms of the resource’s access
rights.
31
Attack Surface Measure – FTP Daemons (3)
9,18121812
11
9,321101910272516
11
41
51
11
14
14
34
15
35
55
: M
: C
: D
ProFTPD attack surface
32
Attack Surface Measure – FTP Daemons (4)
ProFTPD Attack Surface: < 321,9 ; 1 ; 18,9 >
Wu-FTPD Attack Surface: < 392,33 ; 1 ; 17,6 > - Wu-FTPD has a higher
measure along the method dimension as it has a larger number of methods running with root privilege and accessible with unauthenticated user access rights.
– ProFTPD has a higher measure along the data dimension as it has a larger number of files accessible with world access rights.
33
Other Comparisons of FTP Daemons
There are more vulnerability reports forWu-FTPD 2.6.2 than for ProFTPD 1.2.10.
From vulnerability databases:
34
Literature[1] D. Germanus, A. Johansson, N. Suri “Threat Modeling and Dynamic
Profiling”, In Annals of Emerging Research in Information Assurance, Security and Privacy Services, Elsevier Press, 2008.
[2] F. Swiderski, and W. Snyder “Threat Modeling”, Microsoft Press, 2004. [3] S. Lipner, and M. Howard, “The Trustworthy Computing Security
Development Lifecycle”, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp Microsoft, 2005.
[4] P. Manadhata and J. Wing. “An Attack Surface Metric" CMU-CS-05-155, July 2005.
[5] P. Manadhata, J. Wing, M. Flynn, M. McQueen. "Measuring the Attack Surfaces of Two FTP Daemons", QoP '06: Proceedings of the 2nd ACM workshop on Quality of protection, 2006.
[6] B. Schneier "Attack Trees: Modeling security threats", Dr. Dobb's Journal, Dec. 1999.
[7] Boström et al., “Extending XP practices to support security requirements engineering”, SESS '06: Proceedings of the 2006 international workshop on Software engineering for secure systems, 2006.