Threat modeling

1. Threat modeling Aalto University, autumn 2013

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?

3. [Internet, originalsourceunknown]

4. 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. [Internet, originalsourceunknown]

6. 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?

7. Case study • Mobile phoneapp shop

8. Assets • Money • Apps • Feedback, reputation • App shop: servers, software, service • Right to publish apps • Customer account • Customer’s phone, e.g. control and integrity • User PII incl. location and purchases

9. Potential attackers and their motivation Shop • Customers • Want free apps • Shopkeeper • Selling more • Paying less to the authors • App authors • Selling more • Avoiding publishing fees • Better feedback and reputation • Spying on users • Outsiders, colluding third parties • Attackers on the Internet or in the cloud infrastructure Payment,feedback Payment App Apps, adds Author Customer

10. Threats / potential attacks Against the customer or phone: • Malware, spyware • Unauthorized access to personal data, or misuse of authorized access • By the shop, by apps, by someone with access to your account • Compromised customer accounts, unauthorized purchases • Unauthorized purchases on the phone Against the shop: • Fake positive feedback • Disputed purchases • Compromised servers or cloud infrastructure • False sales data or feedback, malware distribution, leak of business secrets,... • DoS attacks Against the authors: • Negative feedback for competitors, especially free apps • Shop paying the authors too little, reporting lower sales • Copying apps to use without paying, to sell for profit, to insert malware Others: • Attacks against Internet communication (sniffing, spoofing, MitM) • Tax avoidance, money laundering

11. Systematicthreatanalysis

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 [source: Microsoft]

14. 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:

16. [source: Microsoft]

17. 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?

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 • 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 • Swiderskiand 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 3http://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