Threat analysis
Tuomas Aura
CSE-C3400 Information security
Aalto University, autumn 2014
Threats
 Threat = something bad that can happen
 Given an system or product
– Assets: what is there to protect?
– What are the threats against these assets?
– How serious are the threats i.e. what is the risk?
2
[Internet, original source unknown]
3
Security “pixie dust”
 Security mechanism are often applied without
particular reason
– Cryptography, especially encryption does not in itself
make your system secure
 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?
 Must understand threats before applying
security mechanisms
4
[Internet, original source unknown]
5
Threat modeling approaches
 Different angles to threat modeling:
– Assets: what is valuable in the system and how
could it be lost?
– Attackers and their motivations: who would want
to do something bad and why?
– Engineering: what parts are there in the system
and how could they be caused to fail?
– Defenses: what (more) could be done to prevent
or mitigate attacks?
– Checklists, lessons learned: what has gone wrong
in the past?
6
Case study
 Drink vending machine with text-message
payment
 Public-transport ticketing
 Electronic postage stamps
7
Public transport ticketing
Clearing
Operator
backend
system
Connections
over Internet
Internet
shop
Possibly
multiple
operators
Station and
depot systems
Wireless data
POS
terminal
Vehicle
terminal
NFC interface
Travel
card
8
Assets
 Travel
– Right to travel
– Transport capacity (seats)
 Money
–
–
–
–
Money spent on ticket purchases
Stored value tickets: balance on card
Money received from ticket sales
Money received from public subsidies
 Personally identifiable information (PII)
– Passenger identity, travel history
 Secondary:
–
–
–
–
Terminals in vehicle or at the station, POS terminals
Cards
Keys
Back-end IT system
9
Potential attackers and their motivation
 Passengers: want to travel and save money
 Criminals: want to make money
 Insider attackers: want to make money or get
other benefits
– Operator employees, IT staff
– Sales staff, bus drivers
 Nosy people and organizations (passengers’
family, police, stalker etc.): want PII
 Operators: extra payment, subsidies, tax savings
– Competitors might want to hurt business
 Outsiders, vandals, hackers (on the Internet)
10
Threats / potential attacks

By passengers:
–
–
–
–
–
–
–
–

By criminals:
–
–
–
–

Learning passenger identity or route, from card or backend database
Keeping personal information unnecessarily
By traffic operators:
–
–

Free tickets or rides for themselves and for friends
Keeping money from sold tickets
Selling rides without giving a ticket or receipts
By nosy people and organizations:
–
–

Counterfeit tickets
Sale of fake tickets that might not even not work
Ticket theft, sale of stolen tickets
Resale of used tickets (e.g. London ticket touts)
By insiders:
–
–
–

Sharing tickets: passback etc.
Ticket copying and counterfeit tickets
Misuse of discount tickets, using a cheaper ticket
Intentionally losing or breaking cards and getting replacement or free rides
Misuse of customer complaints
Riding without a ticket in open ticketing (e.g. Helsinki Metro and trains)
Vandalism of readers to get free rides for everyone
Credit default on postpaid tickets
Misuse of public subsidies, tax fraud
Anything to damage competing business
By outsiders and hackers:
–
–
Vandalism
All kinds of Internet attacks
11
SYSTEMATIC THREAT MODELING
12
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?
13
Threat trees
14
[source: Microsoft]
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
15
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
disclosure
Denial of
service
Data flow
x
x
x
Data store
x
x
x
x
x
Process
x
Interactor
x
x
x
Elevation of
privilege
x
x
16
17
Risk assessment
 Risk assessment is very subjective, many definitions:
– 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?
18
Pitfalls in risk assessment
 The systematic threat analysis methods help but
there is no guarantee of find all or even the most
important threats
 You need to understand the system: technology,
architecture, stakeholders and business model
 Attackers are clever and invent new threats while
threat analysis often enumerates old ones
 Always start by considering assets and attackers,
not technology or security mechanisms
19
Saltzer and Schroeder
 Design principles that help avoid problems
– Violations often indicate vulnerabilities
 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 other ways
to check authorization whenever possible
– Least privilege: give only the necessary access rights
– Least common mechanisms: ensure failures stay local, diversity
– Psychological acceptability: design security mechanism that are
easy to use correctly
20
What next?
 After identifying threats, we must assess the risk,
prioritize the threats and choose
countermeasures
 The process is iterative i.e. new analysis must 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 existing systems
21
Reading material
 Dieter Gollmann: Computer Security, 2nd ed., chapter
1.4.3; 3rd ed., chapter 2
 Ross Anderson: Security Engineering, 2nd ed., chapter
25
 Swiderski and Snyder, Threat modeling, 2004
 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
22
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)
 What are the assets and potential attackers?
 Apply the STRIDE model or threat trees; this will
require you to model the system first
23