Incident Response Processes, Teams, and Policies Part 1
3 hours 20 minutes
everyone. My name is Peter Sip alone, and this is the network Security course. This is going to be module three lesson to and in this lesson we're going to cover incident response.
So the prerequisites before this lesson, our modules one into module one being the introduction module to being the basic core knowledge of cybersecurity, principles and infrastructure and module three. Lesson one was where we took a look at data loss prevention.
Now, if you haven't seen any of these modules or lessons yet, I encourage you to just kind of pause this video real quick
and go back and take a look.
So, objectives for this lesson, we're going to take a look. Everything about incident response. We take a look at the process, the teams, the policies and how to handle security incidents in a responsible fashion.
So this is the NIST incident response process, and this is kind of how it's handled. Now, most security incidents are handled at this level and the incident response teams use this process to guide them through, obviously, the incident response process.
So the first step is to always prepare. You got to be prepared. It is foolish to think that something bad will not happen. It's You want to be ready for when something bad does happen. So in the preparation phase, you want to just document and create all kinds of policies
determining how would you are going to handle the response? You want to take a look at what you're going to do when this happens? You have to look at who am I gonna call when something happens, One of the most steps we can take. This is where you come across things like statement of management, objectives, scope, roles and responsibilities
and communications planning.
After we're done processing and preparing for an incident comes the detection and analysis phase. In this phase is where we determine that something went wrong and there was an incident that occurred. So in this phase year, you know, an I. D. S or an I. P. S like some sort of a warm gets tripped
and something something that happens that determines that an incident has occurred.
From there we go into the containment eradication and recovery phase. In this section is where we kind of try to contain the incident. Whatever happened, eradicated and then obviously remove it and make sure it doesn't happen again in the containment phase, we want to make sure it doesn't spread to all parts of the network.
Usually, security incident happens on like one computer
or maybe like a certain section off the business,
and then we really just want to make sure that doesn't spread to the rest of the network or any other computers. The eradication step is where we physically remove the malware virus or whatever the problem was and then the recover.
Sometimes we might have to bring back, you know, some type of data if there's data loss, or we might have to remove the computer and set up a new one. So we have to do something to get ourselves back into working condition.
So after we've done the containment eradication and recovery step, we want to go back to the detection and analysis step just to make sure that there is nothing left over and that the recovery has been successful. We want to continue this process until there is no more
problems or a situation on the network or computer.
After that is done, we're gonna go toothy post incident activity. This is where we break down. What happened? What We did, Howard, how things went wrong. And what can we do to fix? Obviously we don't want this to happen again. So this is where you determine what you should do in order to ensure
it doesn't happen anymore.
Steps in this area usually include things like the alteration or creation of new policies or some type of user awareness training.
So just a couple quick vocab words which will really flush out the incident response process. First is an event. An event is simply something happening right? At that point, if we didn't play or something is an event, that means something happened and we don't know what it could be. It could be bad. Could be not bad. We don't know.
All we do know is that something happened.
Ah, security incident is a violation or an imminent threat of violation of a security policy which can cause significant harm. It's at this point when a security incident comes about
is that when you determine that the event was in fact ah, bad event and then from there you can start the incident response process Now, obviously, the incident response process has to be worked on and completed by the incident Response team members. This includes people like management
I t. The Incident Response Handlers,
Legal counsel If there is a public company or if there's a loss of data, h r and obviously, public relations.
This is a sample incident response process flow chart for detecting that an incident occurred. Now this one is specifically identified for fishing.
So obviously you want to start of your up at the top and then you come down to threat indicators. These air usually alerts either from ah user or some type of anti virus agent or some type of email provider some something like that, something to indicate that something is happening from there. You want to go down to
the identify risk factors,
which is the blue diamond in the very center, and then you want to kind of figure out what's the financial loss? One of the losses. How bad could this be?
After you identify the risk factors, you coming all the way down to the data collection, and this is where you kind of take some of the fishing messages. You kind of figure out where they came from what the country the I P is originating from. And then from there you can categorize, you can categorize. You could determine whether it's just spam.
What kind of fishing is it?
And then from there you condone triage. Then at this point, you can determine how severe is this incident. What's the impact? What am I gonna have to do? Your check out the scope. And then from there you want, take the appropriate response.