Written by Georges Bolssens

The added benefit to early threat modeling that nobody talks about.

At Toreon, we have a handful of customers that subscribe to our “Threat model coaching subscription” after having followed our world-renowned Whiteboard Hacking aka Threat Modeling course. This is a form of repetitive consulting where we sit down with engineers on a weekly basis to help them build security into new and evolving products. While basic threat modeling knowledge is presumed to already be present, we see this as a highly effective way to cement the habit of iterative threat modeling into the SDLC and also get a grip on what hands-on threat modeling looks like when it is done right.

During one of the first few sessions in such a coaching subscription, we usually get the following question in some form:

“When designing a new feature, the elicited threats are often too vague to be actionable for a developer. When waiting too long, we risk having to redo days or even weeks of coding. Where’s the sweet spot?”

The answer to this question is that there is no single, best moment in a software design to threat model: every iteration brings a different value that changes with increasing clarity of answers to “The Four Questions”. The reason for this is the fact that designing mitigative measures against a “generic” vulnerability often leads to more questions about how to design a system in a secure way.

Seeking answers to these questions at an early point in the design has an unintended, but extremely valuable side-effect: the inception of reference architectures and company-wide security standards.

To avoid having to reinvent the wheel, writing down these decisions and reusing them in your next project saves time and money for a very obvious reason: There is now a documented, agreed upon, and correct way to solve a software design problem that recurs in your line of business. While threat modeling a system the next time, a security champion aware of these standard security requirements can solve this problem in a heartbeat: They can provide a (largely pre-threat-modeled !) building block that prevents having to spend time pondering vague solutions to vague issues. In more giant corporations, we even see accompanying central code libraries that can be imported to handle security-critical operations.

For example, this can entail a ready-to-go encryption library with built-in secure key management and -rotation functionalities, pre-approved by your CISO and your DPO!