threat modeling

22
Tuomas Aura T-110.4206 Information security technology Threat modeling Aalto University, autumn 2012

Upload: jabari

Post on 25-Feb-2016

52 views

Category:

Documents


1 download

DESCRIPTION

Threat modeling. Aalto University , autumn 2012. 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 ?. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Threat modeling

Tuomas AuraT-110.4206 Information security technology

Threat modeling

Aalto University, autumn 2012

Page 2: Threat modeling

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

Page 3: Threat modeling

3[Internet, original source unknown]

Page 4: Threat modeling

4[Internet, original source unknown]

Page 5: Threat modeling

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

5

Page 6: Threat modeling

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: what have we learned from the past?

6

Page 7: Threat modeling

Case study Public transportation tickets

7

Page 8: Threat modeling

8

Assets Transport capacity (seats) Right to travel Payment Ticket Balance on the card Money from ticket purchases IT system and its components– Card reader (ticket validator) in vehicle or station– Backend system

(The list is by no means complete)

Page 9: Threat modeling

9

Potential attackers and attacks Passengers: don’t want to pay, want to travel free

– Travel without ticket• Bypass check-in: jumping the gate, use middle door, using HSL rail traffic without a ticket

– Counterfeit tickets• Load money or time on the travel card (technical attacks against smart card)• Sale of fake tickets

– Travel with wrong ticket or share tickets: • Travel in the wrong zone, use wrong discount ticket, intentionally broken ticket• Travel with another person’s period tickets, pass-back, reselling daily tickets

– Ticket theft and sale of stolen tickets– DoS: all get in free, vandalism

Bus driver: wants more money– Steal fare money, sell tickets without paying in the money (without receipt?)– Let friends in free

Bus operator– Tax fraud– Subsidy fraud

Traffic authority?

Page 10: Threat modeling

10

Public transport ticketingClearing

Operator backend system

Station and depot systems

POS terminal

Vehicle terminal

Travel card

Internetshop

NFC interface

Connectionsover Internet

Wireless data

Possibly multipleoperators

Page 11: Threat modeling

SYSTEMATIC THREAT ANALYSIS

11

Page 12: Threat modeling

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?

12

Page 13: Threat modeling

Threat trees

13[source: Microsoft]

Page 14: Threat modeling

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 system14

Page 15: Threat modeling

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:

15

Spoofing Tampering Repudiation Information disclosure

Denial of service

Elevation of privilege

Data flow x x x

Data store x x x

Process x x x x x x

Interactor x x

Page 16: Threat modeling

16[source: Microsoft]

Page 17: Threat modeling

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?

17

Page 18: Threat modeling

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

Page 19: Threat modeling

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– Psychological acceptability: design security mechanism that are

easy to use correctly

19

Page 20: Threat modeling

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

Page 21: Threat modeling

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 3http://msdn.microsoft.com/en-us/library/ff648644.aspx

21

Page 22: Threat modeling

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