Two incident response phases most organizations get wrong
t's important to remember: Incident response isn't a thing, it's a process.
There is a baseline for incident response — six phases familiar to anyone who has spent time around a SANS classroom.
Those phases — preparation, identification, containment, eradication, recovery, and lessons learned — define the basic outline constructed to help a business manage a situation while keeping damage and recovery time to a minimum.
Coming up in IT, this reporter was introduced to SANS by a mentor, and while this is not a sponsored post, I don't shy away from the fact that I'm a fan of the organization, as well as several of its instructors.But there are some aspects to this baseline that organizations routinely get wrong.
While interviewing those impacted by a string of recent ransomware attacks, I was reminded that incident response is a living process that changes constantly depending on the situation.
Most organizations either offer or rely on SaaS platforms to function, and many of the incident response plans they have in place don't really adapt to fluid environments such as those.
Instead they're focused on the static environments of the early 2000s (or older). While there is a good deal of crossover, there are little things that can trip an organization up, harming their reputation as well as their bottom line if they're not careful.
With that said, I started the conversation by asking about what's not getting enough attention when it comes to the baseline? Where are the gaps?
"The biggest gap that I see initially is a failure to understand that incident response is a process, it's not a thing," says Lee. "You don't do incident response, you do a phase of incident response."
In addition, there is a failure to understand the difference between containment and eradication. "Many people feel that if you go directly to eradication, we're essentially achieving containment because we're eradicating at the same time," Lee adds.
But they're not.
The reason containment exists, Lee says, is that it gives incident response teams time to do proper scoping of the incident. This goes back to the identification phase, which some organizations confuse. The identification phase isn't about intrusion detection, it's about determining how bad the cancer is within your organization.
You have to find every location with infection. If you don't, the adversary or infection will maintain its foothold on the network, even if all six phases are followed and completed.
To put it another way, containment is essentially heavy monitoring with the ability to get in the way of the final goals or objectives of the adversary, which really makes organizations feel nervous, Lee explained.
"During this stage you're still mapping out and learning about the adversary. You're learning about how bad the infection is. But it feels like you're doing nothing, you're just watching. And that's one of the hard parts in most organizations," Lee said.
"Unless you've been in law enforcement, you have a really hard time making that connection that says containment is there for a reason, it gives you the ability to make sure you've fully scoped out everything and the ability interdict if something really bad is about to happen. But if you don't do that step properly and move immediately to eradication… you've essentially accomplished nothing. You're back at square one again."
The second gap in most incident response programs centers on recovery and lessons learned. Most organizations, Lee said, are really failing here.
"They almost always feel that how they were attacked, or how the situation occurred in the first place was anomalistic," Lee explained.
But it wasn't just bad luck that led to the incident in the first place. These organizations aren't taking the opportunity to say 'listen, the likelihood of this occurring again is extremely high' — a true statement in today's environment.
"They don't take the time to say 'what, truly, did we do to make sure that we have not only recovered from the previous incident, but we have enough in play to detect and defeat the second one?'," Lee added.
Once an organization is known to be vulnerable, the odds are stacked against it as other bad actors line up to take their shot. Not to mention, dealing with the same bad actors again.
"The likelihood that an adversary, if they were not able to meet their initial objectives, will potentially come back a second time is almost near one-hundred percent," Lee said.
It takes incredible self-awareness for an organization to admit they failed and own up to the fact they have to do better in the long run, which is why the recovery and lessons learned phases are so important. Achieving this level of awareness though, will require some cultural changes within the organization.
After an incident, most organizations focus on patching or adding additional layers of intrusion detection, forgetting about the root cause of the problem.
You actually have to go back and measure some things during those initial stages. For example, how long has that breach been there before you detected it? Doing so is a metric known as dwell time to many in the industry.
"If you're not reducing your dwell time every single time another incident occurs, then that shows there's a more systemic problem in your organization in dealing with intrusion detection in the first place," Lee said.
Interestingly enough, most organizations don't talk about dwell time. Rarely will you see an organization discuss how many incidents they deal with in a given year and how quickly they can respond.
Bottom line? Incident response is a loop, and for the most part you're always in the lessons learned phase.
"So, you'll never actually finalize the loop," Lee said. "You're actually moving back into the identification phase thinking, 'something else is going to happen, can we find it?'"
This is where incident response becomes a security model that most organizations don't just pick up and dust off when a bad thing happens, Lee added. It becomes what they use on a daily basis.
In fact, he said, those in the security industry who have adopted incident response as a day-by-day task, end up faring better than those who resort to a dusted off incident response manual that was created two to three years ago.
Comments