Okay, So in introducing incident response, we defined an incident when we said that it's a series of events that has a negative impact on my system.
Um, and that's absolutely true whether that system is an individual computer or network or whatever's been affected. So when we look to incident, response the ideas, how can I respond in relation to that incident? And here's the key piece
so that we can minimize disruption to the business.
Um, and the reason extra says at first that seems like of course, that's it. Give me That's what we're trying to do.
But incident response is different from, for instance, forensics With forensics, our primary focus is on evidence collection, right? We're gonna collect that evidence in such a way that we can guarantee the evidence hasn't been modified, and we're gonna analyze.
And ultimately forensics is gonna have the in Goa
of presenting information in court.
Now, when we focus just on incident response, the focus is a little bit different because what we're primarily concerned with is minimizing disruptions to the business,
and how this is gonna happen is gonna be driven by how well we plan.
And we know that we plan well ahead of the incidents. Incident response is not anything that should happen on the fly. As a matter of fact, we should have a company wide approach to incident. Response. Um, we have our team selected well, ahead of time
we train our incident response team, or if we find out that we don't have the skills in house to properly respond to incidents, then we would create a tool kit that would include full numbers of who to call and steps that we do feel comfortable
taking within the organization. Same idea with forensics, right?
If we're not qualified to do this in house, then we find someone. That is because this will make or break us. And I've heard incident response *** stories where you know
the wrong person made the wrong decision. Or, sadly, the right person made the wrong decision. You know, I remember an incident where
with an organization. One of my clients, they had left the office Friday afternoon and as they were leaving, one of those sort of junior network technicians from Kaiser network utilization is up a little bit more than it was this morning, which is weird because people are going home.
Yeah, so I brought that to the attention of a supervisor who said,
That's Friday afternoon. Let's go home.
The entire network was saturated. Network utilization was at 99%. A whole lot of action on a network. That's 99% you'd alive.
And where do you think the incident response plan was documented? And where could I go to get those procedures for what to do in the event of an incident
so ultimately not very good planning was in place. Poor decision making, um, poor escalation. You know, escalation ideally happens because we trust those ah, in a hierarchy above us to make good business decisions, whether or not it's Friday afternoon at 4 30
but then also having your incident response procedures
on a network server when half the time the incident is affecting the network is a whole and basically a worm had gotten on. The network was just bouncing around from post to hope.
So making sure that we're well that we have planning in place, that we have multiple locations for incident response procedures, that our team knows where to get them that they have reporting, they understand the reporting hierarchy that those
that handled the incident response reports take them seriously
and know how to evaluate whether or not a response or report is is actually an incident or not. You know, how do we conduct a violation analysis? Is it malicious? Isn't something that happened accidentally? Is it a part of normal network behavior
and the answers? We have to be ableto analyze this. We have to be ableto analyze
this traffic this activity very quickly to make these key determination. So we have a team that we've chosen. We make sure teams are trained. The chief information security officers heavily involved in riding our incident response policy. Uh, things like,
you know, what are the steps
in order? What is the incident Response team authorized to do? How do they isolate a system? How that they begin their investigations? What type of documents must be filled out? All of that information. We also have to make sure that our incident response team has the proper tools.
You know, they're gonna be investigating or analyzing hard drives and devices.
Ah, you know, do they have access to write protected system so that we can guarantee the original disk doesn't get modified if they are gonna take the next step and go to go through forensics. Investigation's making sure that they have tools like in Case and some of the other forensic software that's out there is essential.
And then finally, support from senior management
an understanding of how critical having a robust incident response plan is. And how important is that we test these plans with salt or these attacks occur. These incidents occur that we respond as appropriately as possible
stakes in our original response plan.
So ultimately, incident response is all the procedures that go into spotting
a cyber incident in such a way that we minimize disruptions to the business that's ultimately are built.