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

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