In the previous post we discussed the background for my knowledge within incident response. Now we will jump into the exciting stuff and talk about “The Why?”
I guess a pretty good place to start in defining the incident response process, is understanding why do we need incident response at all?
Incident response wouldn’t exist without something to actually trigger the process. To trigger the process you need an incident, and what will generate that incident?
Incidents are generated from a threat, whether this threat is a nation state attacker, a script kiddie, a pandemic, or even some sort of natural disaster. So then what is a threat, and how do we define it?
I like to start out this explanation by showing the following diagram:-
Intent + Capability + Opportunity = Threat
Each one of these conditions needs to be met to fulfill the criteria to create a threat. To make it more understandable I use an example of whether there is a threat at home from my child trying to steal Nutella from the cupboard.
Intent is pure and simple, does my child want the Nutella? Do they have the desire and drive to get it? Without intent, I could leave Nutella all over the house and not be worried about anything happening to it.
Does my child have the capability to get the Nutella? I may have left the cupboard door open, and my child may desperately want the Nutella. But they haven’t learned to open a jar yet. So the threat is not there…
Did I leave the Nutella jar open on the kitchen top? So now my child has the perfect chance to get hold of it. The opportunity has been given to them, now they can combine it with their intent and capability to create the threat!
Well what can we do about this?
You may look at these three points, and think there is alot to be done to protect against each part of the “threat process”. But there isn’t… You cannot take actions to reduce the capabilities of your attackers yourself.
You also cannot influence an attackers intent against you. In some niche cases, you could argue that by “doing good things” you might reduce the intent. But this is a relatively difficult issue to measure.
So this leaves only “opportunity” where you can have some sort of impact. I say “some sort of” because an attacker will always get an opportunity. An opportunity can be something as simple as a misconfigured firewall, a vulnerability in a public facing server and many more.
But you can do your best to restrict the number of opportuntities presented to an attacker. A good example of this, is vulnerability management, when an exploit or vulnerability is released and this effects you, taking actions to patch or mitigate it can help reduce the attackers opportunity to become a threat.
But what about incident response?
You may be thinking, well wait a minute, where does incident response fit into this? Incident reponse assumes that the attacker had the opportunity to become a threat and then carried out actions against you which have resulted in an incident needing to be handled. Incident response is purely a reaction process and is driven by threats.
In some cases the lessons learned from the root cause analysis within the incident response process can also assist with reducing the attacker opportunities. An example of this… Imagine having a perimeter firewall hole, which is too wide and allows external access to a number of test servers which are not patched. The subsequent incident from an attacker compromising these servers, can lead to a report which identifies the broad firewall rule and gives advice on how to fix it. Thus reducing the next attackers opportunity to become a threat!
In the next post we will look at how we can have an understanding of the threat landscape, and how to figure out which threats might be relevant to us…