All right, So now we're gonna move into the elements of an incident response plan. Per the document provided to us by the University of California and you see here we're gonna have six stages of the plan.
And again, it's not so much that you be able to say, Well, this is the University of California. This is the S E I. It's more that you get the steps that are taken as part of incident management
and ultimately, how the pieces all come together.
So in this piece, what are the sections that you should have when you're writing an incident response plan?
All right, so we're gonna start with preparation and you're gonna see that's just like planning in the priest previous set of processes our approach and what's our methodology?
Preparation? Planning is all about defining what we're going to do. We're not doing anything yet except determining how we're going to do it,
right. So our policy is going to dictate what our steps are and it's gonna lead into our process is we're gonna talk about in preparation again. We're gonna outline the criteria for labeling something an incident.
We're gonna make sure that the necessary tools are available as well as training on how to use those tools.
All right, so we have to look at preparation is the first stage of any incident response.
Then we're going to document how we identify an incident.
And again, that's called violation analysis. Not everything is as it appears.
An intrusion detection system could sound an alarm, but it could be a false positive could just be normal network traffic that, for whatever reason, triggered an alert.
When we do a side or determine that something is legitimately an incident, that's when we assign ownership two individuals on the incident response team, and we're gonna immediately establish a chain of custody for any evidence that will be collected as part of the next step. Also,
we need to get the idea of how severe this incident
is. It may be that we find ourselves operating outside our capabilities. It may be that we need to escalate to senior management or perhaps toe outside authorities.
All right, we've identified it as an incident we know in incidents going on, we have to move into containment.
How do we contain an incident? What are we allowed to do, making sure that we have processes in place again. Maybe segment systems or even sub nets from the network pulled the switch, pull him off the network.
Any virus software? Um,
what we need to do to preserve evidence should that evidence be presented in court again, there's a line between just incident response and forensics evidence collection. So what is going to define that line? We're gonna make sure that we control our communications to the public
and, you know, in relation to
controlling communications, we need to be very aware of the fact that it's not always the CEO that is best prepared to go out in front of the public,
right. If any of you remember the BP oil spill
every time that guy was gonna be on an interview, I just got myself a little bag of popcorn.
I was just waiting to hear what he was going to say, because he made a tremendous amount off poor statements that really left BP looking unprepared.
Um, certainly made them look very uncaring to the general population. So in this piece, we're gonna make sure that we have selected people that are going to contain the damage not just of the incident itself from a technical standpoint,
but contained the damage to our organization
and how we present ourselves to the media,
then eradication. And with containment, we're limiting the damage. But with eradication, we're eliminating it. We are
removing the virus we are restoring from back up. We are looking to get to the root of problems,
right. We want to figure out if there any sort of,
um, additional weaknesses. We want to make sure that,
the means that we've used to protect our system is gonna leave our system's clean and not susceptible to further compromise.
Okay, recovery. Get back to where we were before the incident. Okay, so we're gonna meet those service level objectives, service, delivery objectives, maybe something you'll see. It's the same thing's a service level agreement. We have to get back to where we're providing
the degree of service our customers expect from us.
Will also look to the BCP, and we may find things like recovery time objectives, recovery point objectives whenever those will be. But recovery's not about Just getting rid of the malicious file. Were back up and running to a state that we were.
I won't say to the state we were before the incident, but to a state of
permanence. We really don't want to get to where we work for the incident because we just got burned, right? So to a state of permanence. And then last once again, documentation,
get those lessons learned, conduct a postmortem
document. What happened? Analyzed the events that happened. Ultimately analyze that and figure out how we can get better next time. And then that report is gonna be provided to whatever stakeholders we determined were relevant
back in the preparation face.