No matter how well you apply your security controls, no matter how careful you are, incidents will take place. And that's what this episode is all about. incident response, what do we do as an organization when an incident takes place? Now, luckily for us, the entire exam is based very heavily on the famous computer incident response process. So, pretty much all of the objectives you're seeing are taken directly from this well known and popular source. And that's a good source for it.
So what I want to do is, first let's talk about what actually is the incident response process. The first step to the incident response process is preparation. This is the big plan. First of all, we have to define the organization who's going to do what in case an incident takes place. Secondly, we need to organize the types of incidents we might be anticipating and defining who does what depending on the type of party good preparation is actually going through and drawing some scenarios and seeing how that works out. Next, we have to talk about reporting, in the case that a incident takes place, what reports go to whom, so that we're aware of this.
And also important issues like escalation if the job really gets big number two, and this is actually part of preparation, our practice scenarios. Next is identification. You need to be able to recognize that an incident has occurred. So we need to be watching things like reports from users, we need to be checking the monitoring tools that we might have watching alerts and logs. As part of that we also have to assess the impact and define who's involved. Next is containment.
Containment boils down to mitigating the damage, stopping the attack, do what we have to do, do we segregate the network? Do we shut down the system? Do we turn off a service This is where we handle that type of situation. Next is eradication and now it's time to clean up the mess. We remove the malware, we close off the vulnerability, we add new controls, we do what we need to do to eradicate the problem. After that comes recovery, and now it's time to get back to normal.
Here we restore from backups, we pull snapshots, we hire replacement personnel. And very important as part of recovery is we monitor for a while to ensure good operations. Last is lessons learned. Here we document the incident, what failed, what worked and generating the final report. So really, the big part to all this is preparation. So what I want to do right now is go through the fairly complicated process of creating a decent Incident Response Plan.
The cornerstone of any incident response plan is your cyber Incident Response Team, or sometimes also called your computer incident. response team. These are a group of people within your organization whose job is to respond to all incidents. These can be full time part time or both. A cir T is going to consist of an IT security team. These are going to be security pros who understand the incident response process.
They also understand issues like for example, forensics. It might also include your IT department to provide technical skills. It might include human resources in case there's a person involved with the issue. It could include legal in case there any legal issues, and of course, public relations to deal with the public. Next, we're going to have to document incident types and category definitions. We should be able to define things like Well, what do we do if the incident is physical access?
Or what if it's malware? What if it's phishing? What if we have a social engineering issue or what if somebody's accessing our data in a way that we don't want. Third is roles and responsibilities. How do we get information to the CIO party that incidents have taken place? Who has that job?
So things like for example, users, how does a user report that something's taking place, or perhaps a helpdesk, maybe someone's been socially engineered through the help desk, and they need some source to be able to say, I'm recognizing an incident. Human Resources may notice someone quitting and might want to be able to let people know that an issue could be taking place. A database manager might see a corruption that he had not anticipated before and need to make that call. That's why we often see what we call an incident hotline, pretty much a one stop tool that almost anybody within your organization can use to determine that there is an incident on the other end of that is going to be a incident response manager or maybe an incident response. Officer whose job is to feel these and to determine if they need to go to the team.
Next, our reporting requirements and escalation. Any incident is going to have some level of severity. and determining that severity is important for us to be able to understand what we do with it. If it's a big deal, we need to escalate it, we need to send it up the chain to the right people within our organization who know how to deal with it. escalation comes into play in a lot of other ways, for example, reporting law enforcement, none of these tools are going to work together unless you practice any organization is going to have at a minimum, annual and in some organizations virtually ongoing practice scenarios so that they can deal with incident response. I'm not going to fib yet, there's not going to be that many questions on the exam that actually hit on incident response.
However, it is a critical tool, any organ ization of any size absolutely must have an incident response plan in place first so that they can get back online and secondly to be able to show that they've done good due diligence in case people create a question.