As I am diving deeper into modern security incident response (IR) practices, one shocking realization reigns supreme: the arrow is dead. Well, let me take this back: as we all know, nothing in security is ever dead. Password guessing, an attack from the 1970s (if not earlier), is alive and well. Stateless firewalls are not dead. No countermeasure and no threat has been fully retired – even though some say that the risk of punch cards being damaged in the mail is 100% gone…
In any case, the “arrow model” of incident response where the normal IT operation is suddenly interrupted by an incident which is then remediated has been losing steam in this day and age. Think about it! We have constant infection rates at 1-2% of systems (source), ongoing attack campaigns, persistent adversaries, (even our compliance gets to be “continuous”) – why should IR be different?
|
 |
| ‘Normal –> incident –> back to normal’ is no more – or at least not the only case anymore. | More common today – the only case for advanced threats; multiple IR loops happening at any given time. |
While some will try to draw a clear line between monitoring (before/after the incident) and incident response (during the incident), the line is getting much blurrier than many think. Ongoing indicator scans (based on external and internal sources), malware and artifact reversing, network forensics “hunting”, etc all blur the line and become continuous incident response activities.
BTW, in this model, the question “what do incident responders do between incidents?” makes no sense…
Possibly related posts:
- My Next Research Area: Incident Response
- All posts tagged security incident response
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
8 Comments
That is unfortunate, because one of the key parts of Incident Response has (to date) always been the after action analysis of the incident, lessons learned, and improving the processes and controls (to hopefully remediate any weaknesses, control gaps, policy issues, detection gaps, etc.). Without this how will Incident Responders be able to contribute to the improvement of the environment?
Pierre, I think it’s more that incident response is a nuanced job where you have multiple activities going on simultaneously all the time. You are always discovering and refining indicators, you are always discovering incidents, you are always cleaning up, you are always doing the lessons-learned process. Teams that stopped after an incident, breathed a sigh of relief, and did a post mortem weren’t paying much attention to the reality of their network.
It’s like a real estate agent (or any client based business), you are in a different stage of a process with any number of clients at the same time. Three cheers for concurrency in work!
@pierre Basically, what Seth said 🙂
You are right, “lessons learned” is a key part of IR, but in this new model learning has to happen simultaneously with a) preparation b) detection c) whatever other stage of (likely) more than one incident ongoing.
So, still need to learn, but in a faster loop rather than “at the end”
DFIR continues to evolve and is now pulling in the threat intelligence and detection functions vs. just response operations. I like the term of “active response” vs. “active defense”. Semantics aside, DFIR is compartmentalizing information security peeps into respective compartments of resistive and responsive and for good reason as they can feed each other, but have different missions.
I am actually going to be doing a presentation on IR soon. Unfortunately IR is not spun up until it is a bit too late but one must assess whether or not this is an active or post incident. Lessons learned are not to be shelved which occurs most of the time without using the raw data as threat intelligence. Most do not dig further into the capability of the attacker and try to figure out motive. There really should be no downtime whether or not there is the arrow method or continuous loop.
@nels Yeah, active defense started to freak out a few people due to those stupid connotations about “hacking back.”
I like the active response term as well – it sounds like one who ‘actively responds’ doesn’t just sit there waiting to be owned.
@matt
>IR is not spun up until it is a bit too late
What’s worse, at unenlightened orgs it is often spun DOWN after they have a quiet period (which may as well be due to their own blindness…)
>Most do not dig further into the capability of the attacker and try to
>figure out motive.
… and their excuse is that they are too busy. Busy doing what? reimaging owned Windows boxes? 🙂
As long as the results or lessons learned are some how being communicated to the people who can make the changes or need to understand the impacts and \whys\ of why/how an incident occurred then that is fine. If not then the process is becoming less effective at feeding back into the overall IT or Security program, which could lead to more breaches for the incident responders to deal with, that potentially could have been prevented or detected earlier.
So if that is how the current trend is – how effective is it? at either 1) detecting/responding to an incident 2) taking the steps needed to prevent a repeat of the same incident.
Thanks for the info 🙂
Of course!! The loop implies rapid and ongoing lessons learned WHILE responding to other incidents rather than a relaxed lessons learned at the end when you are “done” (since you are never truly done)