Crafting a Cybersecurity Incident Response Plan: A MindMap Approach
Download FREE Audio Files of all the MindMaps
and a FREE Printable PDF of all the MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Transcript
Introduction
Hey, I’m Rob Witcher from Destination Certification, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major incident response topics in Domain 7, to understand how they interrelate, to guide your studies, and help you pass the CISSP exam.
This is the second of six videos for domain 7. I have included links to the other MindMap videos in the description below. These MindMaps are one part of our complete CISSP MasterClass.
Before we get into the incident response process, lets define two terms. We’ll start with an event? What’s an event? An event is an observable occurrence. Someone logging in is an event. A file being written to a drive is an event. Someone scanning the external firewall is an event. We do not particularly care about the vast majority of events.
Now, what is an incident? An incident is an event that negatively impacts the organization in some way. A server crashing. A password being brute forced. An attacker getting through the firewall. These are all incidents. We definitely care about incidents
Incident Response
Incident response is focused on detecting these incidents, providing an effective & efficient response to reduce the impact to the organization, maintaining or restoring business continuity and defending against future attacks.
The diagram I’m showing you here is a typical incident response process. There’s an important point I want to make while I’m showing you this though: there are lots of different incident response processes out there from different authoritative sources such as NIST & CSIRT. These different incident response frameworks define slightly different number of steps or names of steps. I wouldn’t overly focus on the exact steps and names - all of these incident response processes have the same underlying goals in mind: be prepared for an incident, be able to detect an incident and then respond quickly, minimize the damage, return to normal operations, and learn from the incident so you can improve things and try to prevent future incidents.
So given that warning about not overly focusing on the exact steps, lets now get into them:
Preparation
To effectively respond to an incident, you must first do a fair bit of preparation: create an incident response policy and procedures, identify and train the appropriate people, put in place monitoring capabilities, etc. etc.
Triage
The incident response process can be categorized into three high-level buckets: Triage, Action & Investigation, and Recovery. We’ll start at the beginning of the incident response process: triage.
Detection
The first, and absolutely most important step in incident response is detection. If you cannot detect an incident, there is no way you can activate your incident response process and do all the rest of the stuff we are about to talk about. If you are asked on the exam to put the incident response process steps in order, always look for detection as the first step.
Sources (SIEM, IDS/IPS, DLP, Fire detectors, Etc.)
There are all sorts of ways that we can identify and detect incidents from the flood of events that are constantly occurring. We can use tools like Intrusion Detection systems which feed into our Security Information and Event Management Systems. Or building monitoring systems like fire alarms. Or a report from an employee. Among many other ways.
Event
And remember the difference between an event, an observable occurrence.
Incident
And an incident which is an event that has a negative impact on the organization.
Response (IR Team Deployed)
Once we have detected an incident the next step is to Respond by activating out incident response team. And one of the first things the incident response team is going to conduct is an impact assessment, they are going to try to determine the severity of the incident and how long it will take to recover. This impact assessment drives the rest of the process, and if the Maximum Tolerable Downtime is going to be exceeded, then this will not be treated as an incident, but rather we will declare a disaster and enact our BCP or DRP plans. More on that in Video 6 when I talk about Business Continuity Management. I’ll link to that video below.
Action / Investigation
The next category is Action & Investigation
Mitigation (Containment)
And the next step is mitigation. This is where we try to minimize the damage and contain the incident. For example, if we have a worm spreading across our network, we may decide to disconnect systems from the network, or if we have a fire, activate the fire suppression system. These are ways we can try to minimize the damage.
Reporting (Relevant Stakeholders)
Reporting is actually conducted throughout the incident response process. What is important to remember is that there should be one dedicated contact person on the incident response team who is reporting out to all the relevant stakeholders (management, investors, regulators, customers, the media, etc.) while the rest of the team stays focused on responding to the incident.
Recovery
The recovery category is where we work on getting things back to business as usual and making improvements so that the same incident doesn’t occur again.
Recovery (Return to normal)
The recovery step is where we work on returning things to business as usual. In the worm outbreak example, we eradicate the worm and begin re-connecting systems to the network, or in the fire example, we clean up the charred soaking mess of the office, install new carpeting, paint the walls, move in new furniture etc. These are examples of recovering to get back to business as usual.
Remediation (Prevention)
Remediation actually begins in parallel with mitigation. Remediation is where we are performing root cause analysis to determine how we can prevent say the continued spread of the worm while we recover systems or prevent the re-ignition of the fire. Remediation continues through the recovery and the closure of the incident and leads into Lessons learned.
Lessons Learned (Improve Process)
Lessons learned is the post incident step where we do some soul searching: how did this happen? How can we prevent it from happening again? Why us? Just why?
The goal of lessons learned is to improve processes, and systems, and teach people to try and prevent future incidents, and if they do occur, detect them more quickly and respond more effectively.
And that is an overview of Incident Response within Domain 7, covering the most critical concepts you need to know for the exam.
If you’re looking for a PDF version of all these MindMaps, you can download a completely FREE version. The link to download is in the description below.
If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.
I will provide links to the other MindMap videos in the description below.
Thanks very much for watching! And all the best in your studies!
