Threat modelling in a post-C.I.A world — focus on D.I.E

A while ago I created the following Wardley map of Threat Modelling. You can find the actual MapScript code for this map (where in the code I’ve added commentaries with the rationale for component placement here https://t.co/ex2aWDiXAk?amp=1)

I then added more to detail in its different sections so that I could highlight how it adheres to Adam Shostack 4 questions of Threat modelling. In his classic book, “Threat Modelling — Designing for Security” he mentions and uses examples of STRIDE though he does refer that isn’t mandatory and that both the Methodology and the Threat Categories are required to be contextualised and useful to the teams doing the Threat Model. I believe this flexibility of his approach to modelling threats is a big part of its success over the years.

I do use Threat Modelling using STRIDE as mnemonic that tech teams can quickly get their heads around, but I’ve been wondering if there’s a complementary way of considering the threat categories which are associated with commoditised computing perhaps ?

Post-C.I.A

The C.I.A. triad is still to this day, touted as the way to do security work. All our literature as a field references it, and anyone taking any type of courses relating to Cyber security will be indoctrinated with it. But is that going to help us address the threats of the next decade ?

As we move to a different type of good and best practices relating to how we develop and operate our software, we’re now at a point where a focus on C.I.A is likely to be an impediment to security more than it is an assurance of it.

IT patterns using technologies such as Content Distributed Networks, Copy-on-write, Cloud Providers, Containerisation and Orchestration, Serverless architectures and even Blockchain and others are fundamentally changing the value provided by that old paradigm.

As Sounil Yu says “More than helping with security, these new patterns can eliminate the need for security at all”.

These new patterns he calls D.I.E (Distributed, Immutable and Ephemeral). Due to confidentiality reasons, I’m not comfortable with sharing (even uncharacterised) any Threat models I’ve done with customers, but I highly favour adding the STRIDE mnemonic letters to the diagram we’re using for Threat modelling (as suggested by the Rapid Threat Model Prototyping methodology from Tutamantic Security which I like to use https://github.com/geoffrey-hill-tutamantic/rapid-threat-model-prototyping-docs) so that at a glance one can understand the threats we’ve identified for each component.

What if we started using D.I.E in addition to STRIDE ? Or even have a Threat model just for D.I.E ?

The questions we could ask in a Threat modelling session to assert exposure could be:

Distributed — Is that system distributed in a way which takes full advantage of orchestration capabilities ? do we have limits in place to how many systems can be scaled to and are there any financial or anomaly detections which re-assess operational needs periodically ? do we understand the system’s behaviour as and when it scales and upstream or downstream impact in other components ? are we reliant on single zones, regions or cloud providers and is that acceptable ? do we know how the system behaves when it happens ? are all of the architecture elements distributed or just a few ?
Immutable — is that change reflected declaratively ? if we re-provision our systems, are we certain all latest changes and minor updates will be applied ? are there other access methods besides CI/CD by which code could be put in production ? would we know if someone did that and has it been tested ? could code be put in production outside of our trusted registries ? how are we admitting artefacts into our production environment ? how are we sure that referenced packages are actually the vendor provided versions and do we have mechanisms which validate this ? how long does it take between developers writing code and it being in production and why isn’t that shorter ? What’s the gap or constraint ?can your teams get shell access to production and if so, why do they need it and would you detect misuse ?
Ephemeral — how often are we re-provisioning our systems ? do we have systems with more than 30 days uptimes, and if so why is that ? for the longer lived systems, would we know how to detect attacker persistence ? is our data engineering practices exposing confidential information ? are we mitigating this threat with the use of privacy enhancing techniques to reduce the value of the exposed data ? after a certain task is performed, why is the underlying system not terminated ?

Many of these aren’t necessarily “new questions” but they’re a different lens at looking at some of the same problems, with the added benefit of the language being aligned to the current engineering best practices and the mental model of modern Development and DevOps paradigms.

Conclusion

The new design patterns and operational paradigms, mean that C.I.A. is often not the best lens to look at security of systems for the 2020s. The main reason is economic, and as an industry our security management has his right already.

You’d find few leaders that would argue that it you should £500k in protecting a system which is valued at 500£. At that point, security wouldn’t make economic sense. But we need to appreciate that time is the new constraint so a key insight must be related to it. For instance, if a system is ephemeral that it only lives for 10 min, should I spend 8 min securing it ?Maybe not. We need more aligned ways of taking care of the security our organisations, and I believe that means embracing the new paradigms.

Thinking about the threats to our systems from a D.I.E perspective as opposed to a C.I.A. perspective means that our threat identification is directly related to the design patterns of modern systems as opposed to fostering the continuity of the “bolt-on” mentality that typically accompanies C.I.A thinking, and these are ultimately direct threats to business and not to our systems.

Our organisations require the speed, agility and market responsiveness which DevOps enables and D.I.E thinking is the best way I know of to align those incentives. Let’s try this please 🙂

References:

Sounil Yu https://www.slideshare.net/sounilyu/distributed-immutable-ephemeral-new-paradigms-for-the-next-era-of-security