Threat modeling: What’s all the buzz about?

Keen observers will have noted an uptick in activity around threat modeling within the information security community recently with new tools being released and strategies and methodologies being discussed on social media; culminating in a week-long threat modeling track at the Open Security Summit (formally OWASP Summit).

What is threat modeling?

In order to answer this question I will refer to the recently updated OWASP application threat modeling page:

Threat modelling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

This is achieved by addressing the four following questions:

1. What are we building? Architecture / Data flow / Data classification.

2. What can go wrong? Main threats that apply to your application.

3. What are we going to do about that? Actions to take in response to this.

4. Did we do a good enough job? Retrospective analysis of the above.

Why is threat modeling gaining momentum now?

Never before has so much been spent on cyber security and yet despite this we have seen an exponential growth in data breaches with the number of cyber incidents doubling last year. This forces business and security to ask a painful question: Are we doing something wrong?

Security has become an siloed appendage in the development life cycle

Historically security has been an independent activity which takes place at the end of the development life cycle through methods such as pentesting and auditing. This has become increasingly untenable as the speed of development has increased aided by the DevOps movement unifying software development (Dev) and software operations (Ops) together. Compounding this the number of applications has grown significantly in our Software-driven economy and microservices architecture adds an additional multiplier.

With a major tenet of DevOps being automation and increased deployment frequency, appending security to the end of this process has created a bottleneck. Throwing the application “over the wall” to an increasingly siloed and comparatively small security team (BSIMM 8 study gives 1.6 appsec professionals per 100 developers) to perform time intensive testing just before deployment is simply not working.

And slowing down the the development life cycle is just one problem caused as a by-product of security being an “appendage” at the end of the process.

The other is if security is not involved from the inception of the development cycle – the design phase – security is not baked-in from the beginning.

Research has found it takes 5 hours work to fix & detect defects in the coding/development stage, 5 – 7 times longer in the final testing phase and 10 – 15 times longer in production.

This research found that early and ongoing security testing cuts the time to production by as much as 25%.

So, counter to what might be intuitively thought, building security early and continuously into the software development life cycle is both cheaper and faster.

In terms of security being siloed, we have become known as the “department of no”. Perceived as always telling people what they cannot do and impeding business. Although Development and Operations may be fusing together, security still sits aloof. After all, who wants to communicate with people always saying “no”.

Threat modeling as a solution

Threat modeling is all about secure design. Finding and fixing threats early when they are cheaper and easier to remedy. As iterative changes are made in design, the appropriate area of the threat model is re-appraised as a “living document” which helps prioritise investment and unblock the security bottleneck at the end of the pipeline. This has the additional benefit of bringing predictability to the business in terms of delivery and consistency.

And for those security activities that must take place at the end of the cycle, threat modeling does not replace them, but rather facilitates pentesters, auditors & reviewers by informing them of the assets in play, controls already in place, attack surfaces, data-flows, trust-zones boundaries and accepted risks. This all whilst reducing the design flaws allowing them to focus on other potential security weaknesses.

At the heart of threat modeling is collaboration. It is about bringing all stakeholders together to communicate a shared understanding of what we are building, what could go wrong and what we can do about it. All of this whilst considering issues such as compliance, risks, usability and others not strictly related to security but important to other stakeholders.

Threat modeling facilitates dialogue and allows everybody the opportunity to challenge assumptions and learn from each other in a blame-free environment. It puts security knowledge into the hands of our cross-discipline partners and educates us of the constraints & demands on them.

Conclusion

There is no silver bullet in security, but we are missing a vital ingredient without threat modeling.

Threat modeling most certainly passes the effort / reward test and has a true ROI. The threat modelling process can become in itself the much-needed medium of integration & communication. Using this method we have an opportunity to turn around our backwards approach of detecting and fixing problems at the end of the process and architect security in the design phase at the beginning of the process and break many of the negative cycles we currently find ourselves in.

It is never too late to begin threat modeling, we can start small, with the projects we have at hand now, even if they are already in production.

It’s time for us as security to glue together with DevOps and become DevSecOps and advocate for the Agile/DevOps shift left testing approach to include security through the medium of threat modeling.