Threat modeling – in its simplest form – is about looking at a system or situation from an adversary’s perspective. From that unique perspective it is possible to identify specific potential threats that otherwise would not be considered by non-adversaries. A threat model, then, is an analytical approach to understanding the potential threats by which a possible adversary may act in a harmful way. Simply put, a threat model tells us how bad guys can do bad things. Knowing that allows the good guys to figure out the best ways to stop the bad guys. From that perspective, threat modeling is for everyone.
Threat Modeling Recess on the Playground
For example, remember back to your days on the elementary school playground. If your situation was like mine, the relative safety to be found within the school building was inaccessible during recess. Well-meaning administrators considered recess a necessary time of fun and diversion for the school children. In reality, though, recess meant navigating a minefield of flying balls, running kids mysteriously not looking where they are going, and – of course – any number of playground bullies.
The easy part of navigating this minefield was being aware of the flying balls and potential collisions with other kids. The more challenging part of playground safety required understanding where the bullies might be hiding and their potential means of attack. While I didn’t understand it at the time, being on the lookout for bullies within the playground environment was threat modeling.
Certainly I wasn’t the only kid on the playground who sought to avoid the bullies. Even the bullies needed to be aware of potential threats – there are always bigger kids looming somewhere, and playground monitors are well-known for their ability to sneak up at the most inconvenient times. Bullies, too, needed to threat model.
Threat Modeling is for Everyone in DevOps
Just as threat modeling is for everyone on the playground, it is also for everyone involved with the output of functional applications. Traditionally SDLC security concerns have been the sole responsibility of the security team. However, as organizations move toward developing a DevOps culture to increase functional application throughput, they discover traditional security practices are an unyielding bottleneck negating the increased application throughput gains.
In an attempt to remove the bottleneck at the testing and scanning development phase, organizations brought threat modeling into the process. It was thought that, if developers received the secure initial coding requirements that mitigate the identified potential threats, the bottleneck at testing and scanning created as applications go back to developers for remediation of vulnerabilities would be eliminated.
When considering one application in isolation, the hypothesis holds true. However, because traditional threat modeling continues to be a resource-intensive activity requiring security subject matter experts, the security bottleneck remains when enterprises attempt to scale beyond a few critical applications. Traditional threat modeling built upon engineering concepts and compliance checklists is not effective at reducing overall organizational risk.
The concept of shifting security left – that is, bringing up security concerns as early as possible within a given agile sprint – is not enough. Consider, the weaker child on the playground is not free from or safe from bullies simply because a handful of monitors are vigilantly watchful during recess – even if those monitors are on the playground in advance of the children. Only if the weaker child learns to be properly aware of his surroundings – that is, if he learns to properly threat model the playground – will the child’s risk of being bullied be reduced.
Making Security Accessible on the Left
In the same way, if threat modeling remains the exclusive domain of security subject matter experts, the process cannot effectively reduce organizational risk – even if the threat modeling is shifted as far left as possible. Security-centric threat modeling cannot scale sufficiently to meet the increased throughput of an effective DevOps culture. Shifting security left is not enough. Security also needs to be accessible on the left.
Thus, threat modeling is for everyone involved with application SDLC – especially in a DevOps culture. However, to make the threat modeling process accessible to everyone, it cannot be based in the same engineering concepts as traditional threat modeling. If threat modeling is for everyone, then it needs to be based in concepts familiar to developers and application architects who initiate the agile sprint.
An architecture-based approach to threat modeling is for everyone on the development team. Developers and application architects are experts in converting business requirements to use cases, and connecting various use cases to create functional applications.
Developers live in a world of use cases, communication protocols, data elements, and various means by which a system obtains and maintains state. When specific threats are mapped to these architectural components, the appropriate mitigating security controls will naturally be identified by the development team during the design phase. Architecture-based threat modeling shifts security left as far as possible and makes security accessible to the development.
Threat Modeling is for everyone. Click here to schedule a demo to see how ThreatModeler™ makes it possible.
