High-Level Threat Modelling Process

The following is a (slightly modified) version of a document I wrote for the VSTO team way back in the day. You might find it useful as you plan threat modelling for your product(s). You should of course read the Threat Modelling book from Microsoft Press if you want to go into great details about how to do a good job of threat modelling, but this might be enough to get you started on a plan.

One important thing that people often miss is that a good threat model is critical for enabling your test teams to attack the product from a hacker's perspective (and to really find those juicy security bugs that might otherwise go unnoticed). Anyone who thinks that threat modelling is purely a developer or PM responsibility needs a smack upside the head. QA must be involved so that they can understand the areas of weakness in the product and so that they can provide constructive input into the process as well (testers aren't just there to clean up your mess once it's coded, you know!). QA can provide critical insight into how a product performs under various unexpected situations, and thus they help to drive the enumeration of threats and gauge the effectiveness of the various mitigations employed, etc.

I also hope to post something much more useful than this soon; it's just taking a while to write (whereas posting old documents is dead easy 😉 ). Anyway, here it is:

Suggested Threat Modelling Process

This document outlines a suggested threat modelling process for product teams. It is designed to assist teams in building high-quality threat models without turning everyone into a "security expert" and without overly taxing the resources of existing "security experts" in the team.

The process consists of six (possibly repeated) steps, outlined below in more detail:

1. Preparation

2. Brainstorming

3. Drafting

4. Review

5. Verification

6. Closure

Note that any significant bug fixes or design changes that affect the component after the threat model has been completed will require this process to be revisited to some degree.

References to the "SWAT" team below refer to the assigned "security experts" in the product team, as well as any external security consultants that have been recruited for the process.


The PM and development owners identify Entry Points, Trust Levels, and Access Categories for the component, and use these to build one or more Data Flow Diagrams (DFDs). They also identify all known consumers of the component and which entry points / access categories they utilise.

·This task should take around one hour for a reasonably-sized component. Larger components may need to be broken up into smaller components to make them more manageable.

·SWAT team members may be called on to help at this stage, but are not required for this process. The PM and dev should be able to identify the entry points into their component without the assistance of a security expert.

·Actual threats are not enumerated at this stage; only the ways in which external entities can interact with the component.


In this phase, the component team works from the context diagrams and other deliverables from the Preparation Phase to perform STRIDE-based modelling against the component. This will identify the threats and against the component, and highlight any possible weaknesses or vulnerabilities that need to be addressed.

·This task should take around one to two hours for a reasonably-sized component. Additional meetings should be scheduled as appropriate if all avenues are not fully explored.

·The results of the Preparation phase (entry points, DFDs, etc.) should be made available to the brainstorming attendees at least 2 days before the session so that the meeting doesn't just become a walk-through of the DFDs.

·The existing documents (DFDs, access categories, etc.) may be updated during the brainstorming session if new information comes to light, or if a particular feature was overlooked.

·Core component team members (dev, test, PM) must be present, and at least one SWAT team member must be present at the brainstorming session to assist with the process, answer questions, and so on. If the component is particularly high-risk or is heavily based on technology provided by another team, external experts should be invited as appropriate.

·All reasonable threats are enumerated at this stage, even those that already have mitigating strategies or that have been explicitly designed for. The point is not to just identify security bugs, but to document all known threats the component must protect against, and how it does so.


After the Brainstorming session, the PM owner takes all the ideas generated from the meeting and organises them into a Threat Model document as appropriate for the team. This document will contain the (potentially updated) DFDs, the entry points, trust levels, and access categories, and all identified threats along with their mitigating factors (if any)

·This task should take one to two hours, depending on the amount of data captured in the brainstorming session.

·SWAT team members may be called on to help at this stage (eg to provide guidance on technical terms), but the PM should be able to formalise the data without the help of an expert.


After the threat model has been drafted, it is subjected to a normal review process like any other document. At this stage there may be minor (cosmetic) changes required to the document, or it may need to go back through a more thorough drafting phase. In the worst case, where a fundamental assumption is shown to be false or some other deep issue invalidates the work done so far, the process may need to go back to the preparation / brainstorming.

·This task should take one to two hours, similar to a normal spec review.

·The draft threat model must be made available at least 2 days before the meeting.

·The members of the Brainstorming session should be present, and the invitation should extend to any other interested parties (the whole PM / QA teams, management, etc.), and the SWAT team.

·Although the document may undergo cosmetic changes at this stage, it is not acceptable to merely patch it up if a serious hole is found in the document. The process must be re-started, although perhaps in a reduced capacity.


Once the threat model is reviewed, the QA team updates existing test plans and augments / writes new test cases to verify assumptions made in the brainstorming phase and to perform directed testing on identified weaknesses.

·This phase can actually start any time after the Brainstorming phase, but because of the possibility of changes during the review phase it has deferred to this position.

·If necessary, external teams may be called in to help with penetration testing or other attack strategies if the details of a particular threat are not well understood, or if the mitigation strategies are believed to be lacking.


Based on the Review, the PM owner makes final edits to the threat model and publishes it (including the context diagrams, etc.) to the appropriate team web site. The PM also logs bugs for investigating / fixing potential weaknesses identified both in the spec and the implementation (these will be followed-up on by dev and QA).

·This task should take one to two hours

·Remember that threat modelling is never really done! New classes of attacks are always being found, and bugs in dependencies or changes that invalidate assumptions may manifest themselves as new vulnerabilities in the component.

Comments (9)

  1. Peter Torr has an interesting article/a> about high level threat modeling. The gist of his article is that the process consists of six (possibly repeated) steps, outlined below in more detail: Preparation Brainstorming Drafting Review Verification Closure I highly recommend you go read his article to dig into the depth of each step. Good job Peter….

  2. But was your threat model DIGITALLY SIGNED?

  3. Peter Torr says:

    Some of us don’t have certificates, you insensitive clod!

  4. Not bad, but you end early.

    – I always thought that other key benefits to do threat modelling are, that you could

    a) show the morons that want to introduce insecurity later on in the project, what that will do to them easily and illustratively

    b) have a readily available, nice residual risk piece for final sign-off



  5. A crash-course in developing Data Flow Diagrams in support of software threat models

  6. A recent comment on the IE Blog made it pretty apparent that not everybody is aware…

Skip to main content