Using threat models for incidents (and how incidents helped me like attack trees)
By: Tash Norris
Tags: Soc, Threat Model, Security, Infosec, Appsec

Using threat models for incidents (and how incidents helped me like attack trees)

A run down on how your Security Engineering / Application Security teams can support your incident process. Tash Norris Jun 17, 2019·4 min read

My favourite part; when we’re remediating issues during incidents we’re not just fixing the root cause, but also identifying other potential causes and remediating those too.

Threat Modeling

I really enjoy talking about threat models, they’re kind of like art to me. There are so many different ways to do them, they can look so different and they all provide the owners a unique type of value. However, the one type of modelling I’ve never really got, is attack trees.

Example attack tree, ref Bruce Schneier.

I understand how to use them, but I’ve never really understood where they fit in a agile threat modelling world. For me, personally, they’ve never really fit into the threat modelling flow, when we have a delivery team together and we’re working through a new feature, following a 4 question structure (+ STRIDE) has allowed for the progression of quick but solid models.

A reminder on the 4 questions (ref: Adam Shostack):

What are you doing?

What can go wrong?

What can you do about it?

Did you do a good job?

This structure serves our teams and I well during threat models, we’re able to scale it between quick small feature models, through to much longer evaluations of entire services. We’ve even started to work the questions into some teams definitions of done (future blog post). However, in the last 6 months I’ve been experimenting with using attack tree’s in certain scenarios, and so far, they’re working really well.

Intro the incident.

We all experience incidents, of different scales and different causes. From infected hosts to clicked links on phishing attempts to worse, we’ve seen them all in the news, on reddit, in the Register and probably even in person. So when we go into full incident response mode, how can threat modelling help your teams? Here’s my 2¢.

Whilst your SOC team/ IR folk are running their playbook (if you’re lucky enough to have one for your particular scenario) here’s the flow our SecEng/AppSec team take to support.

1. Understand the what

Pretty straight forward for your normal threat model flow, this is the recap of what you’re building. Except, in incident flow, we’re focusing on what went wrong. It may be limited information at first, but the point of this stage is to understand the initial issue and the scope.

Don’t underestimate how useful these diagrams can be for teams making decisions during incidents, but DON’T spend too long on it, the intent is to ensure common understanding, not update documentation.

Example diagram highlighting service impacted, relevant data flows and trust boundaries.

2. Determine what could have gone wrong

Using just the context of the incident we look at what can go wrong, and this is where I’ve been using attack tree’s.

First off, I cover potential causes, pulling out any potentials and in this case I follow a common idiom in security; Trust, but verify. This is where you’ll see I’ve either ruled out or accepted certain possibilities and marked them with either a I(mpossible) or P(ossible).

Why do I cover the impossible? Because I want to write tests, tests to validate it’s still impossible, and tests that can continuously run, to validate that impossibility through every production change.

Example incident attack tree

The next round is pulling some characteristics that would allow that vector to be true (or rather, present vulnerabilities that would allow a vector to be exploited). This then allows me to get closer to a possible cause.

Finally tests, these allow validation of the vulnerability and ultimately the exploit path.

3. Keep the SOC team in the loop

The reason we do the attack tree is to help guide investigations during incidents. Occasionally (and not always — which importantly, means this isn’t always required) the cause of the incident isn’t clear, so the aim of the attack tree here is to continually guide our SOC team.

Thus, as we identify characteristics/ vulns for a potential attack vector we’ll be liaising with the SOC team to guide their search through their various sources. The aim is to help guide the investigation as quickly as possible, with the intent of discovering and remediating the cause quickly.

4. Evolve the model and update playbooks

What’s interesting about this approach is that we can use it to not only update the threat model for the service in question but also the playbooks. We’ve potentially discovered a couple of other attack vectors and now we can write tests to continuously test whether those vectors are still im|possible.

My favourite part; when we’re remediating issues during incidents we’re not just fixing the root cause, but also identifying other potential causes and remediating those too. Sometimes, there’s just no better way to understand a service than to manage an incident for it..

Do you use attack trees? Let me know.