Threat modeling is dead

STRIDE has not aged well…

I’ve seen first-hand the thick PDFs and Excel files that my clients have had delivered to them by consultants. Those docs have about a million data flow diagrams, giant tables with columns spanning over multiple pages, and a bunch of unactionable data.

Software engineers and hackers both move much faster than in the past. A list of high-level threats is not really useful when it comes to agile secure software development, because exploitable attack vectors are usually down in the weeds. It’s the detail that is missing from STRIDE reports, despite the huge amount of documentation.

What can we do instead?

Attack Modeling

I’ve been favouring Attack Modeling over Threat Modeling for some time now. It has only 3 steps:

1. Analyse attack surface for each component of the design
2. Produce an Attack Register: a list of potential attacks against the exposed attack surface
3. Produce a list of associated security controls to mitigate the attacks

Attack modeling cuts the documentation significantly, and produces relevant, actionable data with none of the fluff.

Another bonus? The Attack Register can be used as a scope for the pentest!