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 INS part of 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 is 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 here 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 C I R T is going to consist of an I.T. 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 I.T. 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 are 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 is accessing our data in a way that we
don't want.
Third is roles and responsibilities.
How do we get information to the CRT 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 being socially engineered through the helpdesk 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 field these and to determine if they need to go to the team.
Next our reporting requirements an 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 organization of any size absolutely must have an incident response plan in place first so that they
can get back on line.
And secondly to be able to show that they've done good due diligence in case people create a question.