Everyone keeps asking me about it, so here it is...
So you want to know about threat modeling? Congratulations, you have taken the first step toward software security. Software security should be the first thing we think about when we write software, but somehow it ends up being the last thing in a lot of cases. We should really be designing software with security as Feature 0. A Threat model is a nice element of an overall security plan, which really should be figured out before code line 1 gets written. This article gives a basic overview of how to create a Threat Model document, which can be used as a basis for a security plan for the system.

What is a Threat Model?
A Threat Model is a Document. The document describes a system in more or less a standardized way, so people can easily understand the system's overall architecture and design, and how it functions - from a security perspective.
A typical Threat Model Includes:

• Architectural Components
• Data flows
• Points of Entry
• Possible Attack Vectors or Scenarios
• Remedies or Counters to the Threats

How-to create a Threat Model
We can work backward from the goal: Ship secure software. To do this, we need to eliminate or mitigate security threats. To find these threats, we need to identify what's important to us, and how it can be used (for us and against us). We need to be specific about what we have that needs protection. Only then can we be clear about how to protect. We can use a Dataflow Diagram to help us identify these things in our system. Here is the suggested process:

1. Create a Dataflow Diagram
   1. See my separate post here: How to create a Dataflow Diagram
2. Identify the protected resources (Assets) that are of value to us.
   1. Everything on the DFD is an asset. Every dataflow, every process, interactor, and data store.
   2. Servers may be assets, as well as their operating systems, and other software on them.
   3. There may be intangible assets as well, such as bandwidth, or industry reputation. Imagine the damage if a security company's web server got owned by a hacker.
   4. What other specific things for the organization might be of value?
      
3. Identify the Entry Points - all places where data can enter the system.
   1. Entry points are more than just services listening on ports.
   2. Input or data files
   3. RSS feeds or external data feeds
      
   4. Configuration files or business rules engines
   5. Unintended services left running on the server
      
4. Locate the Trust-Level boundaries.
   1. Where are there components that communicate with each other at different levels of trust?
   2. Server and client are definitely different trust levels...
   3. Consider server boundaries
   4. process boundaries
   5. application boundaries
      
5. Brainstorm Threats
   1. Get the whole team together (developers, testers, program managers, and even management) and discuss each of the things on the dataflow diagram, to see what if anything there is that is possible, or potentially a threat. Don't exclude any ideas at this point, just write it all down. We can eliminate and prioritize later.
   2. Keep in mind that each of the asset types has a set list of potential threat vectors for it, these can be used to examine each asset for a thorough evaluation.
      1. Threat types are [STRIDE] Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Escalation of privilege.
         
   3. No threat is to big, to small, or too outlandish to record. "Someone could bribe our sysadmin for the root password" is still a valid threat...
   4. It’s sometimes difficult to identify the threats. We can use a trick to find threats by identifying them from mitigations:
      “We use SSL to protect the data flow between the server and the user.”
      That’s a Mitigation… but what’s the Threat? Man-in-the-middle, data disclosure, etc.
      How about “SSL authenticates the server.” => Threat: “Hacker could impersonate our server”
      
6. Refactor, revise, amend, prioritize, categorize Threat list.
   1. Go through the list, and evaluate each of the suggestions, giving each a priority. If there are non-valuable suggestions, discard them at this time.
   2. Threats need to be linked to a asset(s), and entry point(s)
      
7. Brainstorm mitigations to threats, starting with the highest priority
   1. Mitigations include firewalls, SSL encryption, PKI security, certificates, and the like.
   2. Sometimes a mitigation for a denial of service threat is to increase the performance of the application, such that the expensive issue is no longer expensive. Other times we can mitigate by throttling, or something akin.
   3. Mitigation Examples:
      1. Code Reviews - #1 most effective means to prevent security defects
      2. SSL protects in-transit data and authenticates the server (does NOT authenticate the client…)
      3. Input validation for user input
      4. XSD validation for XML documents
      5. Use Stored Procedures to access all data
      6. Access Control Lists prevent unintended access
      7. Firewalls prevent unintended access
      8. Least-Privilege accounts lower the amount of potential damage a compromise can effect
      9. Bandwidth Throttling can help prevent DOS attacks.
         
8. Document all of these things in a "standardized template"
   1. Different organizations use different templates, I don't have a good example yet but when I do I will post it.
      
9. Present and Review the threat model with the team producing the software.
   1. Everyone should be on the same page. The threat model is a great way for everyone to come to a common understanding of the architecture and focus on the things that can keep it secure.
      
10. Keep the document secured, and release it only on a need-to-know basis.
    1. This document tells everyone what we know are potential shortcomings of our system. Keep it under wraps!
    2. Only allow access to specific personnel, and make it a short list.
       
11. Review and Revise this document EACH SPRINT.
    1. Even if no new features are shipped in a sprint, it is worth reviewing the model document, just to make sure it is still accurate and relevant.
    2. If there ever is a security incident, the information most definitely should be added to the Threat Model document. One would wonder at this point what in the process of security and system design let this flaw in. This would be an opportunity to evaluate the design process and make some changes.
12. Use the Threat Model as a guide to designing and developing software
    1. Now that you have a basis to start, use it as a springboard to design and implement better software!
       

Using this method, we should be able to produce a document that gives us a base starting point to talk about security of our system, and help even non-technical people get on the same page to understand what any potential issues are. With this understanding of the system, we can then move forward and focus on the areas that are most important.

There are some tools available, here is one from Microsoft. It has some pro's and con's. There isn't much else out there that I know of at the moment in terms of tools that help with Threat Modeling.

Here is also a nice article on MSDN about Threat Modeling that is similar to this method I describe.

PS - some terms used in Threat Modeling
Terminology

• Asset        (Protected Resource) Something we have that someone might want to get
• DREAD        Ranking system – how serious is it
  • Damage, Reproducibility, Exploitability, Affected users, Discoverability
• Entry Point        Interface between the system and the world
• Exploit        Using a vulnerability to compromise something
• External Interactor    an entity not in scope for this threat model
• Mitigation        lessening impact of or elimination of a threat
• Penetration Test    third party is hired to find a way to hack in
• Vulnerability        a security flaw that could be exploited
• Vector        the mechanism of entry
• STRIDE        Classification system – what kind of threat is it
  • Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
• Threat        an adversary’s goal