CompTIA CYSA+ CS0-002 – Incident Response Preparation Part 1

1. Incident Response Preparation (Introduction)

In this section of the course, we’re going to discuss incident Response Preparation. Now, over the next few sections together, we’re going to cover the full Incident Response process. But in this section, we’re really going to dive in deep into the Incident Response Preparation phase. This will help us in our coverage of Domain Four, and we’ll focus on Objectives 4. 1 and 4. 2. Objective 4. 1 states that you have to be able to explain the importance of the Incident Response process. Objective 4. 2 states that given a scenario, you must apply the appropriate Incident Response procedure. As I said though, in this section of the course, we’re only going to be focusing on the preparation phase, which includes things like training and testing and documenting portions of this objective as we start going through this preparation phase.

Now, as we move through this section, we’re going to start with a broad look at the Incident Response Process so you have a good overview of the next few sections of the course. Then we’re going to dive into the concepts covered by documenting the instant Response process. After that, we’re going to talk about seven types of data criticality for you to consider when you’re developing your Incident Response plans. Then we’re going to talk about communication plans and reporting requirements, since these are critical to have preplanned before an incident occurs. Next, we’ll cover how to best coordinate your response actions across your organization and with external stakeholders.

Finally, we’ll discuss training and testing, as these are both critical to the success of any incident response. If you are not well prepared, your incident response is going to fail and it will become even more costly and disastrous to your organization. So it’s really important that you focus on the preparation phase. After all these days, it’s not really a matter of if you’re going to have an incident response, it’s more a matter of when cyberattacks and data breaches are increasing at an alarming rate. So it’s really important that we are well prepared for these events. So let’s start talking all about incident responses by considering the different phases of an instant response and then focusing in on preparation.

2. Incident Response Phases (OBJ 4.2)

Incident response phases. In this lesson, we are going to talk about the different phases of an incident response. But before we do that, we have to first talk about what is an incident. Now, an incident is an act of violating an explicit or implied security policy. There are lots of different things that could be categorized as an incident. For instance, if I went and stole your password and tried logging into the computer as you, that would be classified as an incident because it goes against the organization’s security procedures. Now, similarly, let’s say an attacker wanted to install malware on a system, that too would be considered an incident because it’s breaking the security policies inside of your organization.

There are lots of different things that could be categorized as an incident. And right now, we’re not too worried about exactly all of those different things. But as we go through our instant responses, we’re going to be thinking about if something bad happens, what are we going to do in response to it? And that’s what an instant response is all about. Now, there are lots of different ways to break down the different phases of an instant response. The most commonly used one is the one that’s produced by NIST, the National Institute for Standards and Technology. Now, NIST has a guide called the Computer Security Incident Handling Guide, which is one of their special publications and it’s number 861. You don’t have to memorize this number for the exam though.

The reason this guide is important though, is it goes through all four of the incident response phases and describes what you should do in each of them. Now, these four phases that NIST covers are preparation, detection, analysis, containment, eradication, recovery and post incident activity. Now, as you see here, there are different arrows going all over the chart here. And that’s because a lot of times when you start an incident, you’re going to start preparing. Then you’re going to move into detection and analysis. You’re going to find something and move over to containment, eradication, recovery. You’re going to think you got everything, and then you’re going to find out you really didn’t. And so you detect something else and you keep going through the spiral over and over until you have everything done and finally get into your post incident activity.

We’re going to talk more about these phases as we go through this lesson. Now, inside all of these different phases, there are different actions we’re going to take. And these are all based on different procedures. When we talk about incident response procedures, these are procedures and guidelines that are covering the appropriate priorities, actions and responsibilities in the event of security incidents. And these are all divided into the preparation, detection, analysis, containment, eradication, recovery and post incident stages as we go through our process. Now, for the exam, let me give you a quick exam tip. As we go through the next couple of sections of this course, we’re going to dive deep into all the different phases of an incident response.

For the exam, it is very important for you to know the phase of an instant response that’s used by CompTIA. During the exam, you’re going to get questions about the five phases and the different actions that you may be required to take during those five phases. Now that’s right, I just said five phases, but when I showed you the NIST model, there was only four. Now why is that? Well, it’s because CompTIA made an adjustment to those four phases and broke them into five. Here you can see the five phases of the CompTIA incident response cycle. We have preparation, detection and analysis, containment, eradication, recovery and post incident activity. Now notice here there’s a slight difference. We took the containment, eradication and recovery from one step inside of NIST and broke it into two steps here in the CompTIA model.

And as I go through and teach you this, that’s how we’re going to do it as well. We’re going to keep it to five steps. But just remember that if you’re working in the real world and your organization prefers the NIST model, you may combine those into one step. So let’s go ahead and look at the five phases in a little bit more depth. First, preparation. Preparation is the phase where we make the system resilient to attack by hardening our systems. We’re going to be writing policies and procedures and setting up confidential lines of communication all during this preparation phase. As we’re working on preparation, we are doing everything we need to to get ready for some future incident that may occur.

This includes doing testing and exercises and preparing our kits and training our staff. All of that is done inside of preparation. Next, we move into detection and analysis. And this is where we’re going to determine if an incident has actually taken place. And if it has, we’re going to triage it, which means we’re going to categorize it and then we’re going to notify the relevant stakeholders so we can start doing follow on actions to try to respond to that incident. The third phase is containment. And this is going to limit the scope and magnitude of the incident by securing data and limiting the impact to business operations and your customers. Think about it this way. You have detected there’s a piece of malware on a system.

What should you do next? Well, you should stop that malware from spreading. And you do that through containment. That’s the idea when you’re dealing with containment. Our fourth phase is eradication and recovery. Now that we’ve stopped it from spreading, what do we want to do? We want to remove the cause of the incident and bring the system back to a secure state. So in the case of a malware example, we have stopped it from spreading. We’re now going to remove that malware and then we’re going to patch the system and do hardening and things like that so we can’t get reinfected. That’s the idea of eradication recovery. And then finally, we’re not done yet.

We have to move into our post incident activity. Now this is called Post Incident Activity because we’ve already cleaned the systems, we’ve recovered them, we’ve brought them back to the normal state. But there’s still something we have to do. We need to analyze the incident and our responses to it and that way we can identify whether the procedures and systems that we had worked as they should or if there’s things we should do better. For example, maybe we found that the reason the malware was able to get on our system was because somebody forgot to install a security patch. Well, that’s something that we can figure out in our Post Instant Activity and figure out how we’re going to make sure everybody patches all of their systems to make sure this doesn’t happen again.

We’ll talk more about each of these five phases as we go through the next couple of sections in the course. Now one other thing we have to talk about when we talk about Instant Response phases is who is doing all of this stuff? Well, that is going to be your incident response team. And when we ask the question, what is an Incident Response Team? We have to think about the different positions that may be there. Well, your Incident Response Team is key people that are going to be available to respond to any incident that meets the severity and priority thresholds that are set out by your Incident Response Plan. Because not everything that you’re running to is going to require you to activate your Instant Response Team.

Some things can just be handled by your Incident Handlers and you don’t need the full team to do it. But if you have a big issue like an ongoing data breach or something like that, you’re going to want the entire Incident Response Team. So what type of positions are on this Incident Response Team? Well, first you’re going to have an incident response manager or team lead. This person is going to oversee and prioritize actions during the detection, analysis and containment of an incident. This is a position that I have personally filled numerous times and I can tell you it is a difficult position that requires a lot of good soft skills in addition to those traditional in depth technical skills that some other positions are going to require.

This is because your Instant Response Manager or Team Lead is going to be responsible for conveying information about the response and recovery efforts to the executives and management within your organization. And oftentimes they also could be thrust into the role of being the public face of the company to the media or law enforcement during an Incident Response. The second position we have is a security analyst. Your team needs to have one or more security analysts assigned in order to work directly on the affected network and to play detective in order to determine what happened. Up to this point, your security analyst may be assigned into two categories, although some analysts may be working in both categories simultaneously when dealing with a smaller scale incident.

The first of these is known as a Triage analyst. A Triage analyst is a security analyst that’s assigned to work on the network during the incident response. Triage analysts are going to help filter out false positives by properly configuring intrusion detection and protection systems, as well as performing ongoing monitoring and analysis to detect any new or potential intrusions during your incident response. Another type of security analyst we use is what’s known as a forensic analyst. Now, a forensic analyst, on the other hand, is going to be more focused on the detective work and trying to piece together what has already occurred on the network.

They’re going to focus on recovering key artifacts and evidence from the network and then use these to build a timeline of the different events that led up to the incident itself, and that way we can understand what happened up to this point. Beyond that, you’re also going to want to have a threat researcher. This is another key part of your team. These threat researchers are able to compliment your analysts by providing threat intelligence and overall context during your incident response. These specialists work to always remain up to date on the current threats that are facing your organization and your specific industry, as well as keeping up to date with previous incidents that may have occurred.

I like to think about these folks as both a combination of a futurist in terms of guessing what the bad guys might do, as well as a historian, because they know all the bad things that the bad guys have done in the past. By using this, they can help us build better security and defenses as well as trying to get one step ahead of the bad guys who have already broken into our network. Finally, we have cross functional support. In addition to all the critical roles I already talked about, we also want to expand our team with additional cross functional support. This includes people from management or the executive team, somebody from human resources if you’re dealing with an employee insider threat, or an attorney or lawyer in the case that the company may want to take legal action against the perpetrator or the attacker.

Sometimes you might even have somebody from public relations because you may have media interest into the incident as well. In addition to all this, you may have to pull in technical experts on specific systems like system administrators, network administrators, or database administrators to help you recover back to normal operations as part of your response. All of these are considered cross functional support because they’re coming from outside of the incident response team itself and across the entire organization. Now this Incident Response Team is often known as a CSIRT. A C cert is the Computer Security Incident Response Team.

And your C cert should be the single point of contact for security incidents. Now this C Cert may be part of the Sock, the Security Operations Center, or they could be an independent team. It just depends on how your organization has set this up. In fact, some organizations have chosen to outsource their security response and their C Cert teams. This way, whenever there’s an incident, they would call in this third party contractor who will bring their experts to help you bring your systems back online and get the bad guys out of your network. Now, regardless of which way you decide to do it, it’s important to realize that being a part of an Instant Response Team is a 24/7 job.

Instant Response teams will typically require 24/7 availability and because of this, this can become a very expensive thing to provide. It’s also important for you to consider how you’re going to rotate out members of your C Cert because they can get burnout being on call 24/7. If you happen to work for a small or medium sized organization, it’s most likely the case that you’re going to have an outsourced C Cert team because it’s really expensive to have your own C Cert team for your organization. So really, unless you have a really large organization, you’re probably not going to have a dedicated C Cert team because the expense of maintaining this and having them ready to run at any time 24/7 can get very costly.

The other benefit of using an external team is these external agents can often deal more efficiently with the different problems that we have inside of our networks. For example, if you’re investigating an insider threat, using a third party team that’s coming from outside your organization would actually be better because they don’t know all the people involved and they will have a clear eye to look. Through all of the logs and try to figure out exactly who the insider threat is, as opposed to having bias based on knowing these people personally.

3. Documenting Procedures (OBJ 4.2)

Documenting procedures. One of the first steps inside of your preparation phase is going to be to document procedures. Now again, let’s review the preparation phase and what it does. When we’re in the preparation phase, we are trying to make the system resilient to attack by hardening our systems, writing policies and procedures, and setting up confidential lines of communication. So writing these policies and procedures and documenting them is, is very important. By preparing for an instant response, we’re going to make sure we are documenting our procedures, putting resources in place and the different procedures in place, as well as conducting training. All of this is really important to us because it’s going to make sure that we’re ready to respond when an incident occurs. For example, most organizations are going to have instant response plans on file and ready to go.

Essentially, these are your war plans. When you see something happen, you can look up, what do you do in response to that particular thing? For instance, maybe you’re going to be dealing with a DDoS attack, or a virus, or a worm outbreak, or a Phishing attack, or data exfiltration, whatever it is. You’re going to have different responses and different procedures for each of those things. And so as part of your detection, later on you’re going to classify what that incident is and then respond appropriately. But here in preparation, this all happens before there’s an incident. We have to have these standard steps ready to go that are tested and we’re ready to respond. So one of the best ways to do this is making sure you have a playbook.

Now a playbook is a standard operating procedure and it tells our junior analysts and incident handlers exactly what they should do in response to different scenarios. Now, if you don’t have these already, you can actually go to a website known as instantresponse. Complaybook. And when you go there, you’re going to click on I want to make a plan. Once you get there, you’re going to find a playbook gallery that has a bunch of playbooks already created for you. For instance, let’s take a look at Phishing. If we click on Phishing, it will open up and give us a document that’s about ten or twelve pages that tells us exactly what we should do in terms of phishing. Now as it goes through, it’s going to tell us how we can automate our response, how we can detect it, what actions we should take.

And each part, it has a flow chart that gives us the actions. For instance, we can go through preparation and how we can determine what we’re going to do and how we’re going to train people, and how we’re going to do interviews with all the different functions. And as we go through that, we have internal and external pass and then we can move into our detection phase and it shows us all the different ways that we can detect this type of a phishing attack and then we go into our analysis phase. What type of things are we looking for as we’re trying to triage and categorize this? And then we go into our containment phase.

How are we going to stop this phishing attack and then we can look at eradication, how are we going to triage it and confirm the report, what kind of communications we’re going to have, how are we going to eradicate any malware that may have been downloaded as part of this phishing attack and things like that. And then we move into our recovery phase, and then after that we move into our post incident phase and it tells us all the things we need to do. Now, again, I went through this very quickly because you don’t need to know all the details of all these flow charts that I went through on the screen. But the important thing is to realize that you can get these type of playbooks as a starting point and then customize them for your organization.

At the end of the playbook, it’s even going to give you some different things that you should be doing, such as what does a proactive response look like, what does a quick containment look like, what does effective remediation look like and what should your action plan be? All of this is information that’s contained inside this playbook and allows a junior analyst to do this work very quickly because they can follow these flowcharts and know exactly what to do. Now, in addition to the playbooks, it’s also important for us to know who we’re going to call as we start escalating things and notifying people. And this is a really important thing to ask who are we going to call? And no, the answer is not Ghostbusters.

Instead the answer is we’re going to consult our call list. Now a call list is a predefined list of incident response contacts in hierarchical order for notification and escalation. Essentially, if you’re the analyst and you’re working at three in the morning and you detect something, who are you going to call? Who are you going to wake up? Are you going to use a phone? Are you going to use a landline? A cell phone? A satellite phone? What about email? Is it going to be a corporate account or a personal account? Well, all of this depends on what your plan says and how you want to make contact. Now, the reason why this is so important is because if that incident happens to be where an attacker has gotten into your systems and they have control of your network, you don’t want to send an email over that network because you’re going to tip your hand and let the adversary know that you’ve detected them in your network. So you need to have secondary and tertiary ways of contacting people.

Your call list is going to help you define that. Who are you going to call? When are you going to call them and at what level are you going to call your manager or your manager’s manager or the director or the CEO? The answer is it depends. Depending on how bad the incident is, it will determine how high up the chain of command and how far up your organization you need to call. Another thing you need to work on inside the preparation phase is the creation of an incident form. Now an incident form is going to be used to record all the details about the reporting of an incident and assign it a case or a job number. In a lot of organizations this has become a digital form or some kind of a SharePoint website or a database where it can collect all this information.

In the old days, it was actually a form that was filled out with pen and paper. Regardless of which one you’re using, you’re going to have a lot of the same type of information though. You’re going to have things like the date, the time and the location of the incident and the detection of the incident. You’re going to have the reporter and the incident handler’s names and contact details. You’re going to have things like how the incident was observed or detected, what was the log or the alert, or the thing that made you think, ah, we have an incident here. We also are going to define what type of incident we have. Is this a worm, a data breach, a piece of malware, unauthorized privileges, or whatever the type type of thing is, we want to put that down and then we’re going to look at the scope of the incident.

Is this a small scope or a big scope? Is it affecting the entire organization or just a small part of the organization? For instance, let’s say you had a system error that was taking down your entire website. That’d be a big deal. And it’s probably going to go further up the chain of command than if you had something that was taking out maybe just the payroll system and it was three weeks before payroll is going to be due. All of these are issues we’re going to have to address. But depending on how big or small the issue is, that’s going to tell us what the scope of the incident is. And finally, we have to have the incident description and event logging. This is where we’re going to have all the information we have about the incident. For example, if I’m working as an incident handler and somebody calls into the sock and I’m taking down the report and they say I’m having some issues, I think there’s malware on my system.

As I’m moving my mouse to the right, it’s going to the left. When I click on this, it doesn’t work. Those are indications that there could be some kind of remote access Trojan on that system. So I can get that information from the user and then pass that information over to the incident handler or the incident responder who’s going to work that specific case. As we’re moving through the incident, this is all the information we want to gather. So we have more information and we understand what happened, when it happened, and all the steps that have happened up to this point. So we pass it off to responder. They can continue that log and we can use that later on as a way to go back and look at this event.