Threat modeling

Tuomas Aura
T-110.4206 Information security technology

Aalto University, autumn 2011

2
 Threat modeling approaches
 Different angles to threat modeling:
– Checklists: what have we learned from the past?
– Engineering: what parts are there in the system
and how could they be caused to fail?
– Attackers and their motivations: who would want
to do something bad and why?
– Assets: where is the value in the system and how
could it be lost?
– Defenses: what could still be done to prevent or
mitigate attacks?

3
 Basic security goals
 Consider first the well-known security goals:
– Confidentiality
– Integrity
– Availability
– Authentication
– Authorization
– Non-repudiation
 Which goals apply to the system? How could
they be violated?

4
 STRIDE
 STRIDE model used at Microsoft:
– Spoofing vs. authentication
– Tampering vs. integrity
– Repudiation vs. non-repudiation
– Information disclosure vs. confidentiality
– Denial of service vs. availability
– Elevation of privilege vs. authorization
 Idea: divide the system into components and
analyze each component for these threats
– Note: security of components is necessary but not
sufficient for the security of the system

5
 STRIDE
 Model the system as a data flow diagram (DFD)
– Data flows: network connections, RPC
– Data stores: files, databases
– Processes: programs, services
– Interactors: users, clients, services etc. connected to the system
 Also mark the trust boundaries in the DFD
 Consider the following threats:

Spoofing Tampering Repudiation Information Denial of Elevation of

6
7
Threat trees

[Microsoft]
8
 Risk assessment
 Risk assessment is very subjective
– Risk = probability of attack × damage in euros
– 0 < Risk < 1
– Risk = low / medium / high
 Numerical risk values tend to be meaningless:
– What does risk level 0.4 mean in practice?
 Usually difficult to assess absolute risk but easier to
prioritize threats
 Risk assessment models, e.g. DREAD
– Damage: how much does the attack cost to defender?
– Reproducibility: how reliable is the attack
– Exploitability: how much work to implement the attack?
– Affected users: how many people impacted?
– Discoverability: how likely are the attackers to discover the
vulnerability?
9
 Saltzer and Schroeder
 Saltzer and Schroeder design principles [CACM 1974]:
– Economy of mechanism: keep the design simple
– Fail-safe defaults: fail towards denying access
– Complete mediation: check authorization of every access
request
– Open design: assume attacker knows the system internals
– Separation of privilege: require two separate keys or
checks whenever possible
– Least privilege: give only the necessary access rights
– Least common mechanisms: ensure failures stay local
– Psychological acceptability: design security mechanism
that are easy to use correctly
 Violations of these principles usually indicate
vulnerabilities
10
 Security “pixie dust”
 Security mechanism are often applied without
particular reason
– Cryptography, especially encryption
 If there is no explanation why some security
mechanism is used, ask questions:
– What threats does it protect against?
– What if we just remove it?
– Is there something simpler or more suitable for
the purpose?

11
 Case studies
 GPS-based road tolls
 Public transportation tickets
 Library card with bar code

12
GPS-based road toll: system

13
Data-flow diagram, STRIDE

14
Threats 1

15
Threats 2

16
 What next?
 After identifying threats, we should assess the
risk, prioritize the threats and choose
countermeasures
 The process is iterative i.e. new analysis should
be done after designing the system with
countermeasures
 More detailed threat models can be done for
each system component
 Threat analysis should be done during system
design but can also be done on exisiting systems
17
 Reading material
 Dieter Gollmann: Computer Security, 2nd ed., chapter
1.4.3
 Ross Anderson: Security Engineering, 2nd ed., chapter
25

 Online resources:
– OWASP, Threat Risk Modeling,
https://www.owasp.org/index.php/Threat_Risk_Modeling
– MSDN, Uncover Security Design Flaws Using The STRIDE
Approach,
http://msdn.microsoft.com/fi-fi/magazine/cc163519(en-us).aspx
– MSDN, Improving Web Application Security: Threats and
Countermeasures, Chapter 3
http://msdn.microsoft.com/en-us/library/ff648644.aspx

18
 Exercises
 Analyze the threats in the following systems:
– Oodi student register, https://oodi.aalto.fi/
– Noppa
– Remote read electric meter
– University card keys
– Traffic light priority control for public
transportation
– Lyyra student card, https://www.lyyra.fi/ (based
on Sony FeliCa contactless ICC)
 Apply the STRIDE model or threat trees
19