Transcript Software Fault Tolerance (SWFT) Threat Modeling Prof. Neeraj Suri Daniel Germanus Abdelmajid Khelil Dept. of Computer Science TU Darmstadt, Germany Dependable Embedded Systems & SW Group www.deeds.informatik.tu-darmstadt.de Terminology  Threat:

Software Fault Tolerance (SWFT)
Threat Modeling
Prof. Neeraj Suri
Daniel Germanus
Abdelmajid Khelil
Dept. of Computer Science
TU Darmstadt, Germany
Dependable Embedded Systems & SW Group
www.deeds.informatik.tu-darmstadt.de
1
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.
 Trust Level: A charcterization of an external entity, often based
on how it is authenticated and what privileges it has.
2
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
3
Outline of Today’s Lecture
 Discuss components of a (good) Threat Model
 Integration of Threat Modeling into software
development processes
 Attack surface measure
© DEEDS Group
SWFT WS ‘07
4
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.
5
Components of a Threat Model
 Threat Modeling involves different roles:
 Analysts
 System architects
 Software engineers
 Security engineers
 Software Testers
 and is performed in three phases:
 Inception
 Object identification
 Reaction
© DEEDS Group
SWFT WS ’07-08
6
The Three Phases of Threat Modeling
DFD: Data Flow Diagram
S/O: Subject/Object
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
© DEEDS Group
SWFT WS ’07-08
7
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 Group
SWFT WS ’07-08
8
Threat Modeling: Object Identification Phase
 Evaluate which user actions are allowed and the objects involved
 Different methods exist, will focus on Subject/Object (S/O)
Matrix
 Thorough, systematic
 Output:
 External dependencies
 Unresolved questions
 Deployment constraints
 Possible vulnerabilities
© DEEDS Group
SWFT WS ’07-08
9
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 Group
SWFT WS ’07-08
10
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:
 Users, Processes: Authenticate, Authorize, No Access
 Data stores: Load, Read, Execute, Absolute control
 When matrix is set-up, first columns and secondly rows are
contracted yielding a compacted matrix
 If necessary, e.g., to differ between disparate roles, expand
respective rows/cols again
© DEEDS Group
SWFT WS ’07-08
11
Object Identification Phase: Example
 Example: Airline quick checkin terminal
 Terminal‘s capabilities:
 Operations: Choose seat, Print Boarding Pass
 Users: Anonymous (pre auth.), Clients (post auth.)
Object contraction
subjects
objects
© DEEDS Group
SWFT WS ’07-08
12
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 Group
SWFT WS ’07-08
13
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 Group
SWFT WS ’07-08
14
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 …
15
Reaction Phase: STRIDE
 STRIDE scheme used for classification of expected impact
 Acronym for:
 Spoofing – allows attackers to act as another user or component
 Tampering – illegal modification of data
 Repudiation – inability of tracing operations back to a specific user
 Information disclosure – gain access to data in transit or in a data
store
 DoS – denial of service attack
 Elevation of privilege – illegal raise of access privileges
16
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 underlie 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
17
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
18
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.
19
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 Group
SWFT WS ’07-08
20
Threat Modeling: Process Integration
Boström et al., “Extending XP practices to support
security requirements engineering”, SESS, 2006.
21
Threat Modeling: Process Integration
 TM may be simply put as an extra stage of an existing development
process – no big conceptual win
 Other processes exist which include TM or comparable concepts:
 Microsoft Security Development Lifecycle (SDL)
• No real development lifecycle, focusses on security and reliability,
12 iterative stages
 Secure Extreme Programming
• Agile method, derived from eXtreme Programming (XP), 7 stages.
© DEEDS Group
SWFT WS ’07-08
22
Secure Extreme Programming - Overview
 Stages:
1. Identification of security sensitive assets
2. Formulation of abuser stories
3. Abuser story risk assessment
4. Abuser story and user story negotiation
5. Definition of security-related user stories
6. Definition of security-related coding-standards
7. Abuser story countermeasure cross-checking
© DEEDS Group
SWFT WS ’07-08
23
Secure Extreme Programming – Stage 1
 Identification of security sensitive assets
 High-level assets which need protection are identified
 Corresponds to TM‘s Inception phase
 Paper actually does not specify how to achieve this goal
© DEEDS Group
SWFT WS ’07-08
24
Secure Extreme Programming – Stage 2
 Formulation of abuser stories
 Analogously to the concept of „user stories“, a security
engineer phrases an attacker‘s potential intentions
 Abuser stories should be asset centric to provide the customer
a uniform view on his business processes´ criticalities
 Example: „All communication between user terminal and
backend systems need to be encrypted to anticipate man in the
middle attacks and guarantee user data integrity“
© DEEDS Group
SWFT WS ’07-08
25
Secure Extreme Programming – Stage 3
 Abuser story risk management
 Corresponds to TM STRIDE and DREAD rating
 Beside security-related measures, the estimated complexity
and cost required to anticipate the abuser story are taken into
account
© DEEDS Group
SWFT WS ’07-08
26
Secure Extreme Programming – Stage 4
 Abuser story and user story negotiation
 Planning of the next development iteration
 Short iterations of 5-10 days preferred
 User stories (functionality) and abuser stories (threat
mitigation) are considered
© DEEDS Group
SWFT WS ’07-08
27
Secure Extreme Programming – Stage 5
 Definition of security-related user stories
 Transcription of abuser stories into security-related user stories
 Abuser stories reflect requirements of a secure system
 Security-related user stories offer software engineers precise
information how to achieve, i.e., implement, a secure system
© DEEDS Group
SWFT WS ’07-08
28
Secure Extreme Programming – Stage 6
 Definition of security-related coding-standards
 Can be implicitly compared to TM‘s question catalog survey
 Static catalogs can be interpreted as coding conventions
© DEEDS Group
SWFT WS ’07-08
29
Secure Extreme Programming – Stage 7
 Abuser story countermeasure cross-checking
 This stage keeps track of threats being mitigated
 Each abuser story needs mappings to either one or more
security-related user story of any iteration, or has to be
documented in deployment constraints or unresolved questions
 Otherwise, a threat has not been mitigated and represents a
possible vulnerability
© DEEDS Group
SWFT WS ’07-08
30
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.
31
Attack Surface Measure
 Idea: Applications should provide a minimum of accessible services
 Services are, 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, single elements like
key/value pairs, data rows/cols in a DB, files.
© DEEDS Group
SWFT WS ’07-08
32
Attack Surface Measure
 Computation yields a vector <M, C, D> with
 M: weighted sum of entry and exit points
 C: weighted channel sum
 D: sum of untrusted data items and their weights
 How to assign weights?
 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 Group
SWFT WS ’07-08
33
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 Group
SWFT WS ’07-08
34
Attack Surface Measure : Computation (2)
© DEEDS Group
SWFT WS ’07-08
35
Attack Surface Measure – Example
 Attack Surface for two FTP daemons [5]
 Wu-FTPD
 ProFTPD
The number of direct
entry points and direct
exit points in both
codebases:
The number of channels
opened by both daemons:
© DEEDS Group
SWFT WS ’07-08
36
Attack Surface Measure – Example
Damage potential estimation
 Define ordering in each resource class
 Assign values
Numeric values assigned
to the values of
the attributes:
37
Attack Surface Measure – Example
16 55  25 53  10 43  19 14  10 14  321,9
1 11  1
12 15  18 14  12 11  18,9
38
:M
:C
:D
Attack Surface Measure – Example
16 55  25 53  10 43  19 14  10 14  321,9
1 11  1
12 15  18 14  12 11  18,9
ProFTPD Attack Surface: <321,9; 1; 18,9>
Wu-FTPD Attack Surface: <392,33; 1; 17,6>
39
Microsoft Threat Modeling Tool
Download:
http://www.microsoft.com/downloads/details.aspx?
familyid=62830f95-0e61-4f87-88a6e7c663444ac1&displaylang=en
40
41
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/enus/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.
42