Threat Modeling summary

Threat modeling is the heart of any application securuty design.

I am often being asked about threat modeling so I wanted to write about it:

Enjoy:

Threat Modeling

Goal: Describe what  is threat modeling, and how it should be implemented.

Terms:

• Attacker - Someone who could do harm to a system
• Threat - An attacker goal
• Vulnerability - A flaw in the system that could help an attacker realize a threat
• Mitigation - Something to do to protect against a threat.
• Attack - The process in which attackers takes advantage of a vulnerability
• Asset - Something of value to valid users vendors and attackers

Background: Application security is too complex to implement without a clear methodology.

One of the subject's most important methodology is the SDL - Secure Development Life Cycle.

An important part of the methodology is the Threat modeling which is the heart of the design phase.

Why Threat Modeling

Understand the motivation for threat modeling.

The Economic side of Threat Modeling

• It is easy to spend an endless amount of money on application security.
  Threat modeling should define the security objectives of the software and thus can help to control the budget spent on application security.

What should be protected?

• It is common that only in the threat modeling phase the company understands what are its assets. Understanding that there assets to protect is a key element is threat modeling.

Understand the attacks.

• It is well known that for a secure design you have to think out of the box, think like an attacker etc... but by the end of the day you do not know what to do. No one knows ALL the attacks. You can never cover everything...
  Threat modeling will helps you by creating a systematic method to review you system.

Not everything should be protected.

• Threat modeling takes as an assumption that "There is no and there will never be a perfect system that is protected against everything.
• It is the designers decision where to protect and where not to. What to secure and what to leave as is.
• One of Threat Modeling Goals is to prioritise security-related efforts

Everyone uses the outcome of threat modeling.

• The threat modeling outcome will be the basis for design decisions and documents.
• It will be used in the implementation phase (before writing code the programmer should read it)
• The threat modeling outcome will be the basis for the security test plan .
• Using the Threat modeling the developer can understand why the designer told him to use a certain Technology

From past experience approx 50% of security issues come from threat models

Threat Modeling Stages

 Identify Assets

• Ask yourself the following questions to figure out what are the assets you need to protect:
• What is most important to the end customer (the customer of your customer)
• What is most important to your customer
• What is most important to the vendor (you)
• What / who can damage the above
• What does the law / regulation tells you to protect

Create an Architecture Overview

• Look at the system you designed so far. This phase tells us that threat modeling cannot be done before initial design was achieved.
  Only after you have a view of the overall design you can think of threat modeling.

Decompose the System

• Threat modeling should be done on the "whole" system to enable a "Holostic (global) view" of the system but it must also be done on specific modules as well.

Identify the Threats

• After you know your assets. You know your system globally and specifically you can start identifying threat.
• There are different methods of how to do that

Document the Threats

• There are many threats. They must be documented. This documentation will be used later to identify the threats that will be mitigated

Rate the Threats

• Not all the threats can be mitigated form practical reasons (budget)
• Threats must be rated so only the important ones will be chosen to be mitigated.

Plan Mitigations

• For each threat that was chosen to be mitigated, the technology to implement the mitigation must be chosen.

How to identify threats

There are different methods of how to do the main part of the threat modeling phase.

Check lists.

• There are numerous check lists to use. These will assure you that you did not forget anything.

Brain storming

• They say that threat modeling is like penetration testing on the design. Take the relevant architects and designers put them around a round table and start "breaking" the system. Make them think like an attacker. A lot of value will come out of this meeting. Try to break their assumptions taken in the initial design.

Tools

• There are tools like "Microsoft Threat Analysis & Modeling v2.1" that can help you create a list of threat. You enter the high level design of the system into the tool in a Visio like diagram and the tool outputs numerous threats.

DFD - Data Flow Diagram

• A DFD is a great diagram from which you can extract a list of threats.
• The DFD shows where the data flows inside the system.
• Data is the most valuable of all. Understanding where the data flows can ease the process of indentifying threats.
• Make sure the DFD is not too specific. DFD level 0, level 1 and level 2 are usually enough.

Attacks classification

Another method to identify threats is to use attacks classification.

Attacks were classified into 6 groups.

Spoofing

• All the attacks in which someone uses someone else identity in the system.

Tampering

• All the attacks in which someone changes some information without permission.

Repudiation

• All the attacks in which someone denies a transaction that was performed. For example someone deny a purchase order after receiving the merchandise and denying the payment)

Information Disclosure

• All the attacks in which someone gets to see information she has no right to access.

Denial of Service

• All the attacks in which someone breaks the system and prevent it from working normally and supplying the service it should. The fact that the system does not work can serve for the interest of the attacker (or the one who sent him).
  There a numerous ways to implement such an attack.

Elevation of Privilege

• All the attacks in which someone enhance its capabilities by raising its privileges. For example: The attacker manages to get administrative rights.

Rating Threats 

It is very difficult to rate threats.

Finding an absolute scale to rate threats is nearly impossible as rating is a subjective matter.

The DREAD scale was designed to help.

In the DREAD scale we ask the following questions:

• Damage - How great can the damage be?
• Reproducibility - How easy is it to get the potential attack work?
• Exploitability - how much effort and expertise is required to mount the attack?
• Affected users - How many users will be affected?
• Discoverability - How easy is it to find the vulnerability?

For each question we answer with:
1 - Low    2 - Medium   3 - High

We sum up to divide the threats into 4 groups:

• Critical
• Important
• Moderate
• Low

Threat Trees

• A graphical representation of security-relevant pre-conditions in a system
• First outlined in Amoroso's "Fundamentals of Computer Security Technology"
• Based on hardware fault trees
• There are many "threat tree patterns"

Using threat trees it is possible to create patterns that we can use to search for threats and Vulnerabilities.

Each leaf is a secondary threat to be evaluated

1. Plan mitigation

After the threat was identified and rated mitigation should be planed. The following options are possible:

• Leave as is. The threat is not important enough to be mitigated. There is no money for the mitigation etc.
• Remove the feature that contains the threat from the product.
• Remedy with technology countermeasure
• Warn the user. (Must be done with care as most users do not have the knowledge to take good security decisions.

If technology mitigation was decided the proper technology for the project should be chosen. For example to prevent information disclosure SSL can be chosen but it is not always the right choice.

The phase of security design is out of scope of this document.

Resources:

Threat modeling book:
http://www.microsoft.com/MSPress/books/6892.asp

MSDN Threat Modeling

http://msdn.microsoft.com/security/securecode/threatmodeling

http://msdn.com/threatmodeling