1 software fault tolerance (swft) threat modeling dependable embedded systems & sw group prof....

1

Software Fault Tolerance (SWFT)Threat Modeling

Dependable Embedded Systems & SW Group www.deeds.informatik.tu-darmstadt.de

Prof. Neeraj Suri

Daniel GermanusAbdelmajid Khelil

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.

Trust Level: A charcterization of an external entity, often based on how it is authenticated and what privileges it has.

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 components of a (good) Threat Model

Integration of Threat Modeling into software

development processes

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

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 GroupSWFT WS ’07-08

7

The Three Phases of Threat Modeling


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


9

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


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:

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


12

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

subje

cts

objects

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


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


15

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 …

16

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

17

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

18

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

19

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.

20

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)


21

Threat Modeling: Process Integration

Boström et al., “Extending XP practices to support security requirements engineering”,

SESS, 2006.

22

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.


23

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


24

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


25


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“


26


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


27


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


28


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


29


Definition of security-related coding-standards

Can be implicitly compared to TM‘s question catalog

survey

Static catalogs can be interpreted as coding conventions


30


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


31

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.

32


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.


33


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?


34

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


35

Attack Surface Measure : Computation (2)


36

Attack Surface Measure – Example

Attack Surface for two FTP daemons [5] Wu-FTPD ProFTPD


The number of channels opened by

both daemons:

The number of direct entry points and

directexit points in both

codebases:

37


Damage potential estimation

Define ordering in each resource class

Assign values

Numeric values assigned to the values

ofthe attributes:

38


918121812

11

93211019102516

11

41

51

11

14

14

34

35

55

,

,

: M

: C

: D

39


918121812

11

93211019102516

11

41

51

11

14

14

34

35

55

,

,

ProFTPD Attack Surface: <321,9; 1; 18,9>

Wu-FTPD Attack Surface: <392,33; 1; 17,6>

40

Microsoft Threat Modeling Tool

Download:http://www.microsoft.com/downloads/

details.aspx?familyid=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en

42

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.

1 software fault tolerance (swft) threat modeling dependable embedded systems & sw group prof....

Documents