CompTIA Cloud+ CV0-003 Exam: Incident Response Procedures

Objective: Explain the importance of incident response procedures.

What is an incident? In many cases an incident refers to a security breach, often the result of a cyberattack. However, in a broader sense, an incident can include other events that are not really an attack but can affect the operations of your organization. You can consider natural disasters, accidental loss of company technology, and similar events as incidents.
In this guide you will learn how to implement incident response procedures, including how to prepare for an incident and how to react when an incident occurs. Note that each incident is different and, as a result, needs to be handled differently.
The goal of this guide reflects the Cloud+ 2.6 exam objective (see the beginning of this guide) and is not intended to provide complete coverage of incident reporting.

Topics:
- Preparation
- Incident Response Procedures

1. A(n) _____ is used to clearly define who to contact, when to make the contact, and how to contact each person when an incident occurs.
2. A(n) _____ is an exercise in which individuals of an incident response team are gathered and presented with a scenario. The goal is to walk through the steps that would be taken to handle the incident.
3. What should be the first phase of an incident response process?
4. The _____ of an incident describes how widespread the effect of the incident is.

1. Call tree
2. Tabletop
3. Preparation
4. Scope

Preparation
A quote often attributed to Woody Allen states that “80 percent of success is showing up.” In terms of incident response, you might consider following a slightly different philosophy: “80 percent of incident response is preparation.”
Putting together a practical, well-thought-out incident response plan is key to successfully dealing with any serious incident. However, the plan must include several important elements, such as good documentation, a process to train key personnel, and a clear definition of the roles and responsibilities of the incident response team.

Documentation
When you’re dealing with an incident, it is critical to be able to rely on good documentation. Documentation provides the information that the incident response team needs to address the incident in a timely manner. Without documentation, it is often hard to determine what actions to take, by whom, and exactly what steps to take when performing these actions.

Good documentation should include all of the following:
- Be verified for accuracy.
- Be up to date.
- Be easily accessible.
- Be available from more than one source.
- Be clear and concise.
- Be reviewed by the incident response team in advance.
- Include roles and responsibilities.
- Include a communication plan.

Call Trees
When an incident takes place, people need to be notified. A call tree is used to clearly define who to contact, when to make the contact, and how to contact each person.

Often there are multiple call trees within an organization to handle different types of incidents, and different individuals may have different sets of call trees. Say a website administrator notices that the company website may have been hacked. The website administrator may have the following call tree that needs to be followed:

Call the direct manager immediately.
Call the other website administrators immediately.

After assessing the situation, the manager may discover that sensitive company information has been compromised. This discovery results in the manager using another call tree to do the following:

1. Call the CIO immediately.
2. Call the IT security manager immediately.
3. Call the HR manager after conducting a review of what data has been compromised.

A regular review of a company’s call trees is necessary to ensure that the correct individuals are contacted. A review is also important because turnover in a company can impact the call tree. Changes in contact data (new phone numbers, changes in positions within the company, and so on) can also affect the call tree.

Training
Training for incident response is an ongoing process. During the training process, each individual needs to be made aware of responsibilities and procedures to follow.

Tabletops
A tabletop is an exercise in which individuals of an incident response team are gathered and presented with a scenario. The goal is to walk through the steps that would be taken to handle the incident. This exercise is called a tabletop because traditionally it was conducted with all participants in the same room, typically a conference room, and all the work was performed “on the tabletop.” In other words, this exercise does not include any actual actions but is more of a verbal walkthrough of the actions that should take place.

You might wonder what sorts of scenarios could be used in a tabletop exercise. There are many good suggestions available, including the following suggestions found on the Washington State Office of Cybersecurity (https://cybersecurity.wa.gov/tabletop-exercises):
- An employee casually remarks about how generous state officials are to provide the handful of USB drives embossed with the state logo on the conference room table. After making some inquiries, you find there is no state program to provide USB drives to employees.
- Your agency has received various complaints about slow Internet access and that your website is inaccessible. After further investigation, it is determined that your agency is a victim of a DNS amplification attack that is currently overwhelming your DNS server and network bandwidth.
- Local news reports indicate that a major chemical plant, located two miles away, has had a significant toxic chemical leak. There is a chemical cloud, and your office building is in the path of the plume.
- A pandemic flu starts. Employees start calling in sick, but it’s not clear if they are ill or afraid to go out in public. Enough people are absent that the organization struggles to maintain the IT infrastructure.

Documented Incident Types/Categories
The purpose of identifying incident types or incident categories is to generate a method of organizing incidents into groups. For example, you may decide to create an incident category called “natural disasters,” which would include incidents such as fires, floods, and earthquakes, but this category would not include an incident like a hacking attempt.

Creating incident categories is important for several reasons, including the following:
- Determining impact:Different types of incidents will have different impacts on your organization. For example, a natural disaster could affect the entire organization, whereas a hacking attempt may impact only the IT department. Additionally, some types of incidents will have long-term impacts, whereas others will have short-term impacts.
- Determining the response order:You could also decide to place incidents into the severity of the incident. For example, suppose the following two incidents occur at roughly the same time: (1) An employee loses a company laptop that contains potentially sensitive information, and (2) the company’s primary data center suffers major damage due to fire. Of the two incidents, you would probably categorize the damage to the data center as a higher priority than the lost laptop. Without categorizing based on severity, the priority might be placed on the less severe incident.
- Helping to determine weak spots in your organization:If you place incidents into categories, it can be easier to determine where your company’s weak spots are. The reason is that an analysis of incidents sorted by category will highlight which types of incidents happen more often, as well as how long it takes to respond to and address each incident type.
- Helping to determine the response level:Categories are often based on the severity of the incident. Categorizing this way allows you to determine the appropriate response for an incident. Below is a table from the DevOps Zone (https://dzone.com/articles/how-to-classify-incidents) that demonstrates the response that should be taken based on the severity of the incident and the impact on the customer.


Response Based on Severity Category

Roles and Responsibilities
Tasks that need to be performed when handling an incident are divided into roles. A role is typically associated with a position in an organization (for example, a customer support manager). Each role is given specific responsibilities to handle during the incident.
Examples of roles include the following:
- Incident manager
- Incident coordinator
- Technical lead
- Communications manager
- Incident operator
- Service desk agent
- Service desk manager
- Customer support manager
- SME (subject matter expert)
- Documenter (also called the scribe)
- User
To make the responsibilities for each role clearer, an RACI matrix is often used. (RACI stands for Responsible, Accountable, Consulted, and Informed.) This matrix makes it easy to determine which role is responsible for handling specific actions or activities. The figure is an example of an RACI matrix provided by Micro Focus (https://docs.microfocus.com/SM/9.60/Hybrid/Content/BestPracticesGuide_PD/IncidentManagmentBestPractice/RACI_matrix_for_IM.htm).


Sample RACI Matrix

Incident Response Procedures
Planning is a critical part of incident response, but if the right actions are not taken when the incident occurs, the planning is meaningless. The process for handling incidents is typically broken into phases. Different organizations have broken these phases down in different ways. For example, the SANS (SysAdmin, Audit, Network, and Security) Institute has described the following six phases of Incident Response:
Preparation
Identification
Containment
Eradication
Recovery
Lessons Learned
Because the Preparation phase was covered earlier in this guide, the remainder of this guide will focus on the other five phases.

Identification
To respond to an incident, you first need to identify the incident. Sometimes identification is easy; for example, a power outage is easy to identify. In other cases, the incident may be noticeable only when specific monitoring processes are put in place.

When you’re identifying an incident, it is best to collect as much information as possible. An identification report sheet should include specific questions like the following:
- When did the incident take place?
- What led to the discovery of the incident?
- Who (or what) discovered the incident?
- What has the incident impacted?
- How does the incident affect users and services?
- If a breach occurred, what was the point of entry?
- What is the scope of the breach?

Scope
The scope of an incident describes how widespread the effect of the incident is. For example, consider a security breach in which a hacker gains access to your company’s web server. Is only the web server affected, or was the hacker able to then launch further attacks on other systems (database servers, development servers, and the like) and breach more systems?
The scope of the incident will have a major impact on how to handle the incident. You also don’t want to fix only some of the problems that the incident created and then have to go back and fix more problems at a later time.

Investigation
The identification phase also includes a component referred to as the investigation. The answers to the questions asked during the identification may not be plain or obvious. Investigation may be required to fully understand the incident and the scope of the problem.
The investigation steps will be different depending on the incident. For example, you would not look at login log file entries to determine the details about why a fire broke out, but you may look at monitoring equipment, such as temperature gauges.

Containment, Eradication, and Recovery
Containment is the process of ensuring that the systems that have been affected by the incident no longer pose a threat or an issue. For example, if a hacker has breached the security of your web server, keeping that web server isolated and separate from the rest of the network provides containment.
Containment typically includes at least three components: isolation, evidence acquisition, and chain of custody. These components will be covered in later sections.
After the affected systems have been contained, the process of eradication can begin. In this process you remove any changes that have caused the incident. In the recovery part of this step, you fix any of the problems that the incident caused.
It is important to note that incident response plans should treat containment, eradication, and recovery as distinct phases of the incident response plan. Attempting to do all of these steps at once will lead to incomplete solutions and will leave your organization open to more potential incidents.

Isolation
Isolation is the process of separating systems that have been affected by an incident from the rest of your operations.

Evidence Acquisition
Collecting evidence serves multiple purposes. This evidence can be used to prevent further incidents or make the recovery process of future incidents easier and quicker. The evidence may also be used to handle internal disciplinary actions or even to take legal action against an individual or another organization.

Chain of Custody
The chain of custody is a document that describes how evidence is handled during the lifecycle of evidence gathering. This document is critical when taking any legal action against an individual or when reporting possible crimes to the authorities.

Postincident and Lessons Learned
You work isn’t done yet. After the incident has been resolved, the results need to be documented and reviewed. Many organizations conduct a postmortem in which the incident, its cause, and the effect it had on the organization are discussed.
Based on this information, the portmortem team creates a report of what was learned during the incident response process and what actions should be taken to avoid future incidents.

Root Cause Analysis
A critical component of the postincident process is determining the root cause. The incident is analyzed to determine the primary cause of the incident, which can then be used to help determine what lessons were learned by the incident and how to prevent similar incidents in the future.

Quiz:
1. Which of the following is not likely to be a reason for creating incident categories? A.Determining impact B.Determining the response order C.Determining who attacked your organization D.Determining weak spots in your organization
2. What does the I in RACI stand for? A.Informed B.Illustrated C.Ignored D.Immobilized
3. What is the last phase of incident response? A.Containment B.Eradication C.Recovery D.Lessons Learned
4. _____ is the process of ensuring that the systems that have been affected by the incident no longer pose a threat or an issue. A.Confinement C.Containment
5. The _____ is a document that describes how evidence is handled during the lifecycle of evidence gathering. A.Chain of information B.Chain of authority C.Chain of evidence D.Chain of custody

Answers:
1. Determining who attacked your organization
2. Informed
3. Lessons Learned
4. Containment
5. Chain of custody