Threat modeling, at least within the context of software, is an exercise to identify vulnerabilities within your solution. There are many ways that you can go about this, however they typically boil down to the following steps:
- Decompose the Application
- Identify Threats
- Rank Threats
- Determine Countermeasures and Mitigation
The Threat Agents game recommends that you use a Data Flow Diagram for the first stage. This involves identifying the external entities, processes, data stores, data flows and trust boundaries within your software.
The next stage is to identify threats. Software Engineers (including architects, developers and testers) will analyse the system, or an area of it, and work to identify where there may be security risks. This involves putting yourself in the mindset of an attacker.
There are a bunch of techniques to do this but I will focus on S.T.R.I.D.E., developed by engineers at Microsoft, as that is the basis of Threat Agents.
| Threat | Desired Property |
|---|---|
| Spoofing | Authenticity |
| Tampering | Integrity |
| Repudiation | Non-repudiability |
| Information disclosure | Confidentiality |
| Denial of Service | Availability |
| Elevation of Privilege | Authorization |
This is easier said than done and without a bit of structure to a threat modeling session, you could just be all staring at a (virtual) whiteboard going “errrr”. Methods to help facilitate this are:
- STRIDE-by-element: Going through the DFD each element in turn, applying each for the 6 STRIDE principles.
- STRIDE-by-interaction: Applying STRIDE to each interactions. Very thorough and personally I think only works for a very focused session.
- Elevation of Privilege card game
- Threat Agents card game
Once you’ve completed this, you will want to review, rank/prioritise and then determine actions for the threats that you have found.
How you assess the risk level and prioritise is up to you and your team/company. I don’t have any advice here. However once you’ve understood the vulnerabilities in your solution you have one of four approaches to take. I like to dub them as MATA:
- Mitigate – Fix the issue or lessen the risk by adding better controls, improving documentation etc.
- Accept – Some vulnerabilities might be considered so obscure and hard to fix that you are willing to accept them.
- Transfer – This could be transferring the risk to the customer, taking out insurance or using a third party to provide protection.
- Avoid – If you remove a vulnerable feature from your software, it can’t be attacked.
Which Juan of the MATA approaches you take is up to you.
And finally once you’ve completed this, remember that your job is not done. Ensure that you are running vulnerability scans. Revisit your threat model when you are introducing a new element or changing an interaction. Stride forward!