Threat Modeling for Dev and Ops
As a means to develop our business we like to think about and prototype new ideas on how to improve and extend threat modeling, attack simulations and securiCAD. This happens down in the foreseeti mine where our engineers are most happy. We have different shafts with different topics open. This blog series summarizes some of that work
We are doing threat modeling. So, what is threat modeling, where did it come from, and how is it evolving? As with most emerging fields, people have different opinions about who was first and most influential with what. And some will say that there is nothing new under the sun at all; we were doing this already back then, we only didn’t call it that at the time. So, let us not go down that path. Instead, we would like to focus on a mental model of the threat modeling practice and community that we hope can help us better contribute to its future. It is an easy model consisting of two communities;
Threat Modeling for Dev (TMD) and Threat Modeling for Ops (TMO).
The TMD movement is certainly the most recognized of the two. The community is perhaps best represented by the work originating out of Microsoft and their work with developing the secure development lifecycle and with Adam Shostack’s now-classic book on the subject. Boiling this approach down, the goal is to identify vulnerabilities in a system during the architecture design phase of the development process. Finding vulnerabilities far to the left is good for many reasons, e.g. that fixing them there is comparatively cheap. So, bottom line, the more vulnerabilities found the better.
The TMO movement is perhaps best represented by the CISO role; in an IT-using organization, someone is responsible for keeping the ICT infrastructure secure. Here the bottom line is not to only identify vulnerabilities but in addition have some mechanism for how to prioritize them. For the CISO there will always be more vulnerabilities than what can be remedied (given allowed budget and time), so the underlying logic is closer to that of risk assessment and management. We can prioritize according to on impact of attacks, the likelihood that someone will exploit vulnerabilities, and how difficult it is to exploit the vulnerabilities. Or a mix thereof. With a prioritized list, the CISO gets actionable decision support for addressing the vulnerabilities.
A common theme in both camps is the conviction that models are a good tool supporting the task. Another common theme, that is at the heart of foreseeti, is the idea that attack vector analysis is key to understanding structural vulnerabilities in complex system architectures. Attack graphs and attack trees are the main formalism for this, commonly accredited to Bruce Schneier.
One of the beauties of attack graphs is that we see it as a mechanism that can help unite the TMD and TMO schools seamlessly and elegantly. Because the severity of a vulnerability is not only determined by its local CVSS value but also dependent on where it is located in the system architecture. If the vulnerability is located at the internet-facing system or a system deep into the internal system architecture. Well, to be more precise, the severity depends on the amount of protection is put “in front of” the vulnerability.
In a future with increasing system complexity and where the vast majority will find themselves in a DevOps paradigm, rather than dev or ops, we are convinced that this structural analysis is key for the future.
So, in the meantime we say: all types of threat modelers unite! And then we keep scratching our heads about how we can build solutions supporting that movement. Have any ideas to share – holler down the mine!