Threat modeling. Tuomas Aura T-110.4206 Information security technology. Aalto University, autumn 2011



Similar documents
Mobile Application Threat Analysis

Introduction to Information Security

Threat Modeling. Frank Piessens ) KATHOLIEKE UNIVERSITEIT LEUVEN

Threat Modeling. 1. Some Common Definition (RFC 2828)

Threat Modeling: The Art of Identifying, Assessing, and Mitigating security threats

Microsoft STRIDE (six) threat categories

BEST PRACTICES FOR SECURITY TESTING TOP 10 RECOMMENDED PRACTICES

Security Testing. How security testing is different Types of security attacks Threat modelling

Entire contents 2011 Praetorian. All rights reserved. Information Security Provider and Research Center

Secure By Design: Security in the Software Development Lifecycle

Threat Modeling. Categorizing the nature and severity of system vulnerabilities. John B. Dickson, CISSP

Rapid Threat Modeling Techniques

Security and Privacy in Cloud Computing

Introduction to Microsoft Security Development Lifecycle (SDL) Threat Modeling

In Building Security In, Gary McGraw proposes three pillars to use throughout the lifecycle: I: Applied Risk Management

Secure Programming Lecture 9: Secure Development

Agile and Secure: OWASP AppSec Seattle Oct The OWASP Foundation

Development Processes (Lecture outline)

Agile and Secure Can We Be Both? Chicago OWASP. June 20 th, 2007

Introduction to Security

A Practical Approach to Threat Modeling

Challenges of Software Security in Agile Software Development

Threat Modeling Architecting & Designing with Security in Mind OWASP. The OWASP Foundation Venkatesh Jagannathan

A Methodology for Capturing Software Systems Security Requirements

Threat Modeling/ Security Testing. Tarun Banga, Adobe 1. Agenda

Weighted Total Mark. Weighted Exam Mark

An Approach to Threat Modeling in Web Application Security Analysis

tj.jmffliim.upij II, 14 1" H'H'.i.U.' Threat Modeling Designing for Security Adam Shostack WILEY

Functional vs. Load Testing

Security Threats in Demo Steinkjer

Threat Modeling Using Fuzzy Logic Paradigm

ISSECO Syllabus Public Version v1.0

Threat Modeling for Secure Embedded Software

Chap. 1: Introduction

APPLICATION THREAT MODELING

Threat Modeling Smart Metering Gateways

Web application testing

Network Security. Instructor: Adam Hahn

Host Hardening. Presented by. Douglas Couch & Nathan Heck Security Analysts for ITaP 1

Vulnerability Management in an Application Security World. AppSec DC November 12 th, The OWASP Foundation

CS 356 Lecture 25 and 26 Operating System Security. Spring 2013

Principles of Computer Security. Dr George Danezis

Software Development: The Next Security Frontier

Design Principles for Protection Mechanisms. Security Principles. Economy of Mechanism. Least Privilege. Complete Mediation. Economy of Mechanism (2)

Plain English Guide To Common Criteria Requirements In The. Field Device Protection Profile Version 0.75

Web Application Security Considerations

Security Goals Services

CSE331: Introduction to Networks and Security. Lecture 1 Fall 2006

Web Application security testing: who tests the test?

OWASP AND APPLICATION SECURITY

Web Application Security

Securing Enterprise Web Applications at the Source: An Application Security Perspective

Securing the Sage Notebook

The introduction covers the recent changes is security threats and the effect those changes have on how we protect systems.

Integrating Security into the Application Development Process. Jerod Brennen, CISSP CTO & Principal Security Consultant, Jacadis

white SECURITY TESTING WHITE PAPER

Threat Modeling: Lessons from Star Wars. Adam

Software Security Touchpoint: Architectural Risk Analysis

Threat Modelling (Web)Apps Myths and Best Practices OWASP The OWASP Foundation Matthias Rohr

Revision History Revision Date Changes Initial version published to

FISMA / NIST REVISION 3 COMPLIANCE

SECURING YOUR SMALL BUSINESS. Principles of information security and risk management

OWASP Cornucopia. Ecommerce Website Edition. The OWASP Foundation. OWASP London 3rd June 2013

How To Protect Privacy In A Computer System

Threat Modeling. Deepak Manohar

White Paper. Information Security -- Network Assessment

Chapter 6: Fundamental Cloud Security

IT-Risk-Management. Secure Software Design Secure Development Lifecycle

Cyber Essentials Scheme

3 Web Services Threats, Vulnerabilities, and Countermeasures

FIREWALL CHECKLIST. Pre Audit Checklist. 2. Obtain the Internet Policy, Standards, and Procedures relevant to the firewall review.

Introduction to Computer Security

Risk Management Guide for Information Technology Systems. NIST SP Overview

Cyber Security Risk Mitigation Checklist

90% of data breaches are caused by software vulnerabilities.

Threat Modelling and Risk Assessment Within Vehicular Systems

THREAT MODELLING FOR ACTIVE DIRECTORY

Protecting Your Organisation from Targeted Cyber Intrusion

Application Security Testing

Columbia University Web Security Standards and Practices. Objective and Scope

Transcription:

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

Threats Threat = something bad that can happen Given an system or product what are the threats against it? how serious are the threats i.e. what is the risk? 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 disclosure Denial of service Data flow x x x Data store x x x Elevation of privilege Process x x x x x x Interactor x x 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