The problem with incident response is that you take one wrong step, and you’re in quicksand and sinking.
“It’s a volatile and ever-changing process,” said Veronica Schmitt, incident response director at DFIR Labs and assistant professor at Noroff, who presented on ‘Incident response bloopers: When IR goes wrong’, at the ITWeb Security Summit 2020, being held this week as a virtual event.
“I’ve often found that when dealing with organisations that have been breached or hacked or convinced to give over their data willingly, there’s a level of stress that is seen within victims of violent crimes, and an emotional impact on that organisation. You will often find the security department running around looking like chickens with their heads cut off because now the finger is pointed at them, as if they were the cause of the breach.”
But the simple fact is that the most feared system that could be deployed today might be vulnerable tomorrow and could be exploited. “It’s an inevitability that at least once in a lifetime a company will be breached. And it's not about when or how you will be breached, but how you will handle it.”
One big mistake she said organisations often make when it comes to incident response is that they act too quickly, or too rashly. “Because in the society in which we live today, everything is fast-paced and we want to get systems up and working in the least amount of time. This isn't always the best approach. Sometimes we need to slow down, we need to assess and watch. Incident response isas much about intelligence-gathering as it is about stopping and attacking.”
We need to bear in mind that when you discover an attacker on your network, they could have already been there for months, gathering intelligence and they might already have the information they want. And yes, we need to get them of the network as quickly as possible, but why not gather intelligence while we can?
Unfortunately, Schmitt said, this isn’t as easy as CSI Cyber and other Hollywood blockbusters make out. “It doesn’t happen in a day; incident response takes time. Root cause analysis to find out what happened takes time,and there are several phases you need to walk through.”
Incident response takes years to properlyunderstand how systems work, to understand what is normal and what is not. “The process of combing through thousands of lines of logs to find that one anomalous entry that could point you to the incident is what we love and strive for,” she said.
“Is incident response about finding the hacker behind the keyboard, which is highly unlikely, or is it about identifying what is taking place, mitigating it, and learning from it.”
What is important is understanding how they got in, what has been taken and what needs to be fixed. “I want to complete the narrative of what exactly is happened and what we can do better moving forward. While I have worked a couple of high-profile cases, and sometimes we find the hacker behind the keyboard, more often than not, that task is too big and practically possible, particularly when dealing with nation state actors in cyber warfare.”
Schmitt said in the aftermath of an incident, she tells her clients to calm down. “Often, when we start to panic on a scene, that's when we start making mistakes. Examples of this would be pulling the plug and bringing down the entire network, when you could have isolated the attacker or isolated a single machine.”
This is a human response and a knee-jerk reaction to feeling threatened and stressed. “The best approach is to systematically take stock of what's happened. You need audit trails and logs. Remember, you cannot investigate what you don't have. Data in this situation is your friend. We prepare, we identify, we isolate. But we have to dig deeper to understand step by step what happened.”
You need to know how they gained entry, because that is a weakness that has to be secured. “You need to know how they move, so that you can gather intelligence on the behaviour, which will also help to identify weaknesses within your infrastructure and your protection. You need to understand why you didn't realise that they were in your system, and what worked and what didn't work. You need to go back to the drawing board and take the lessons learned and your root cause analysis, and understand what you need to do better.”
Share