Threat modeling. Tuomas Aura T Informa1on security technology. Aalto University, autumn 2012

Size: px

Start display at page:

Download "Threat modeling. Tuomas Aura T Informa1on security technology. Aalto University, autumn 2012"

Logan Henderson
6 years ago
Views:

1 Threat modeling Tuomas Aura T Informa1on security technology Aalto University, autumn 2012

2 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

3 [Internet, original source unknown] 3

4 [Internet, original source unknown] 4

5 Security pixie dust Security mechanism are oren applied without par1cular reason Cryptography, especially encryp1on does not in itself make your system secure If there is no explana1on why some security mechanism is used, ask ques1ons: 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

6 Threat modeling approaches Different angles to threat modeling: Assets: what is valuable in the system and how could it be lost? AZackers and their mo1va1ons: 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 mi1gate azacks? Checklists: what have we learned from the past? 6

7 Case study Public transporta2on 2ckets 7

8 Assets Transport capacity (seats) Right to travel Payment Ticket Balance on the card Money from 1cket purchases IT system and its components Card reader (1cket validator) in vehicle or sta1on Backend system (The list is by no means complete) 8

9 Poten1al azackers and azacks Passengers: don t want to pay, want to travel free Travel without 1cket Bypass check- in: jumping the gate, use middle door, using HSL rail traffic without a 1cket Counterfeit 1ckets Load money or 1me on the travel card (technical azacks against smart card) Sale of fake 1ckets Travel with wrong 1cket or share 1ckets: Travel in the wrong zone, use wrong discount 1cket, inten1onally broken 1cket Travel with another person s period 1ckets, pass- back, reselling daily 1ckets Ticket ther and sale of stolen 1ckets DoS: all get in free, vandalism Bus driver: wants more money Steal fare money, sell 1ckets without paying in the money (without receipt?) Let friends in free Bus operator Tax fraud Subsidy fraud Traffic authority? 9

10 Public transport 1cke1ng Clearing Connec1ons over Internet Operator backend system Internet shop Possibly mul1ple operators POS terminal Sta1on and depot systems NFC interface Travel card Wireless data Vehicle terminal 10

11 SYSTEMATIC THREAT ANALYSIS 11

12 Basic security goals Consider first the well- known security goals: Confiden1ality Integrity Availability Authen1ca1on Authoriza1on Non- repudia1on Which goals apply to the system? How could they be violated? 12

13 Threat trees [source: MicrosoR] 13

14 STRIDE STRIDE model used at MicrosoR: Spoofing vs. authen1ca1on Tampering vs. integrity Repudia1on vs. non- repudia1on Informa1on disclosure vs. confiden1ality Denial of service vs. availability Eleva1on of privilege vs. authoriza1on 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 14

15 STRIDE Model the system as a data flow diagram (DFD) Data flows: network connec1ons, 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 Repudia1on Informa1on disclosure Denial of service Data flow x x x Data store x x x Eleva1on of privilege Process x x x x x x Interactor x x 15

16 16

17 Risk assessment Risk assessment is very subjec1ve Risk = probability of azack 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 prac1ce? Usually difficult to assess absolute risk but easier to priori1ze threats Risk assessment models, e.g. DREAD Damage: how much does the azack cost to defender? Reproducibility: how reliable is the azack Exploitability: how much work to implement the azack? Affected users: how many people impacted? Discoverability: how likely are the azackers to discover the vulnerability? 17

18 Piqalls in risk assessment The systema1c 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 AZackers are clever and invent new threats while threat analysis oren enumerates old ones Always start by considering assets and azackers, not technology or security mechanisms 18

19 Saltzer and Schroeder Design principles that help avoid problems Viola1ons oren indicate vulnerabili1es Saltzer and Schroeder design principles [CACM 1974]: Economy of mechanism: keep the design simple Fail- safe defaults: fail towards denying access Complete media1on: check authoriza1on of every access request Open design: assume azacker knows the system internals Separa1on of privilege: require two separate keys or other ways to check authoriza1on 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

20 What next? ARer iden1fying threats, we must assess the risk, priori1ze the threats and choose countermeasures The process is itera1ve i.e. new analysis must be done arer 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 exis1ng systems 20

21 Reading material Dieter Gollmann: Computer Security, 2nd ed., chapter Ross Anderson: Security Engineering, 2nd ed., chapter 25 Online resources: OWASP, Threat Risk Modeling, hzps:// MSDN, Uncover Security Design Flaws Using The STRIDE Approach, hzp://msdn.microsor.com/fi- fi/magazine/cc163519(en- us).aspx MSDN, Improving Web Applica1on Security: Threats and Countermeasures, Chapter 3 hzp://msdn.microsor.com/en- us/library/ff aspx 21

22 Exercises Analyze the threats in the following systems: Oodi student register, hzps://oodi.aalto.fi/ Noppa Remote read electric meter University card keys Traffic light priority control for public transporta1on Lyyra student card, hzps:// (based on Sony FeliCa contactless ICC) What are the assets and poten1al azackers? Apply the STRIDE model or threat trees; this will require you to model the system first 22

Threat analysis. Tuomas Aura CS-C3130 Information security. Aalto University, autumn 2017

Threat analysis. Tuomas Aura CS-C3130 Information security. Aalto University, autumn 2017 Threat analysis Tuomas Aura CS-C3130 Information security Aalto University, autumn 2017 Outline What is security Threat analysis Threat modeling example Systematic threat modeling 2 WHAT IS SECURITY 3