CompTIA Security SY0-601 Exam: Incident Response

Objective: Summarize the importance of policies, processes, and procedures for incident response.

Topics:
- incident response plan
- incident response process
- tabletop exercise
- MITRE ATT&CK
- Diamond Model of Intrusion Analysis
- cyber kill chain
- disaster recovery planning (DRP)
- business continuity planning (BCP)
- continuity of operations planning (COOP)
- incident response team (IRT)

Attack Frameworks
Many incidents occur inadvertently, but others are malicious attacks (either internal or external). Such incidents happen in most organizations, no matter how strict their security policies and procedures. Planning for such events is vital to ensure effective incident handling and response when the time comes. Proper planning can mean the difference between quick recovery and ruin.

Cyber Kill Chain
Incident response requires an understanding of the process of an attack and how attacks are executed. This is particularly important where automation is desired as part of the incident response program. An intrusion kill chain is often used to describe the stages of a cyberattack. Lockheed Martin developed a framework to help defend its networks based on the chain of actions that an attacker takes. This model, which has since been adopted by the security industry, is known as the cyber kill chain.

The cyber kill chain shows the steps an attacker takes from beginning to end. The idea is that not all infiltrations are immediately thwarted, and it’s necessary to disrupt or break the chain wherever the attacker is as early as possible. The chain can use different solutions, instruments, and response types. While there are variations on of the cyber kill chain, the Lockheed Martin cyber kill chain includes the following seven phases, from the attacker’s perspective:
- Reconnaissance: Identifying and researching the target
- Weaponization: Preparing for and staging the attack
- Delivery: Launching the attack
- Exploitation: Gaining access by taking advantage of a vulnerability
- Installation: Establishing persistence
- Command and control: Enabling remote control for further manipulation
- Actions on objectives: With control, achieving the goals
In order to defend and respond in each of these phases, it’s important to understand the attacker’s actions. An intrusion kill chain can further describe the adversarial actions and what the corresponding defenders’ actions should be. Ideally, an organization will break the chain before an attacker can achieve his or her ultimate goal.

MITRE ATT&CK
MITRE ATT&CK is another framework that is similar to a kill chain but focuses more on a knowledge base of different attack techniques in order to understand and defend against an attacker. MITRE ATT&CK defines the following 12 tactics:
- Initial access
- Execution
- Persistence
- Privilege escalation
- Defense evasion
- Credential access
- Discovery
- Lateral movement
- Collection
- Command and control
- Exfiltration
- Impact
MITRE ATT&CK also includes many different matrices for attack planning, mobile device attacks, and attacks across various operating system platforms. Further, a number of high-level tactics and corresponding lists of techniques are provided in the framework. MITRE ATT&CK can be used in a number of different scenarios across a security organization and provides a reference for incident response. Incident response teams can use the framework to plan ahead and also to mitigate attacks because the framework aids in understanding the specific threats.

Diamond Model of Intrusion Analysis
Another similar framework to be familiar with is the Diamond Model of Intrusion Analysis. This model places the basic components of malicious activity at one of the four points on a diamond shape: adversary, infrastructure, capability, and victim. The model provides for analysis of threats related to intrusion. While it appears simple, this model provides a flexible framework that is self-referential, providing much more intrusion analysis detail with varying analytics. It takes a more scientific approach to the process and even provides a mathematical framework for analysis and decision making.
Be sure you are familiar with attack frameworks, including the cyber kill chain, MITRE ATT&CK, and the Diamond Model.

Incident Response Plan
An incident response plan needs to include preparation, roles, rules, and procedures. Incident response procedures should define how to maintain business continuity while defending against further attacks. An organization may have a specific team of technical and security investigators that respond to and investigate security incidents, but many do not. If an organization has no such explicitly defined team, first responders need to handle the scene and the response. Systems should be secured to prevent as many incidents as possible and should be monitored to detect security breaches as they occur.
The National Institute of Standards and Technology (NIST) has issued a report on incident response guidelines that can help an organization spell out its own internal procedures. These guidelines serve as best practices and can be found at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.

Organizational policies and practices provide structural guidance to ensure quality and efficiency in the workplace. To properly preserve evidence, an organization must put together an incident response team (IRT) that knows how to handle incidents. Incident response plans help this team intelligently react to an intrusion. If a plan is not in place and duties are not clearly assigned, the organization could end up in a state of panic. An incident response plan provides a formal approach for how the organization will respond to incidents. Incident response methodologies typically emphasize preparation so that the organization is ready to not only respond to incidents but also prevent them by ensuring that systems, networks, and applications are sufficiently secure. The components of an incident response plan should include preparation, roles, rules, and procedures. Specifically, the “NIST Computer Security Incident Handling Guide” (SP 800-61) provides guidance on the important elements, which include the following:
- Mission, strategies, and goals of incident response
- Senior management approval
- Approach to incident response
- Response team communications
- Metrics for measuring response capabilities and effectiveness
- Roadmap for maturing response capability
- How the incident response program fits into the organization
The plan starts with the mission, strategies, and goals of incident response; this information lays the groundwork for the required capabilities. The plan can then be implemented immediately. Of course, the plan also should continually evolve to make sure it meets the defined mission, strategies, and goals. Occasionally revisiting the plan helps ensure that the program continues to mature based on the defined roadmap. Keep in mind, however, that an organization’s mission and strategies can change. For this reason, companies should revisit the program at least annually to assess changes and adjust accordingly.

Documented Incident Type/Category Definitions
Planning for every conceivable type of incident is impractical. Still, incidents vary, and different types of response strategies are needed. Let’s consider incidents that take place in the real world. Terrorism events might be classified based on attack vector, but focusing on and planning incident responses to every potential tactic is not feasible. Even at the airport, for example, security might face the threat of liquids one day, shoes the next, and so on. The following are common network attack vectors, each potentially meriting its own incident response procedures:
- Web and cloud: Attacks perpetrated through websites and cloud-based applications and infrastructure
- Email: Attacks through email, such as with phishing and dangerous attachments
- Improper usage: Incidents that violate acceptable use policies, Internet policies, and other organizational policies
- Equipment damage, loss, or theft: Incidents that involve computing equipment, including laptops and mobile devices, as well as other information systems

Roles and Responsibilities
An incident response program must include stakeholder management, which defines roles and responsibilities. Even with proper communication and notification following an incident, plans will be less effective if any confusion surrounds what role people are supposed to play and what they must do. Formal definition also grants clear authority for actions to be taken during an incident. Consider who can perform the following actions:
- Confiscate computers and other information systems
- Disconnect data networks and other information systems
- Monitor systems for further analysis and activity
- Communicate with the press

Reporting Requirements and Escalation
An incident response plan should be clear about how an incident or a potential incident should be reported and escalated. This involves the use of a formal communication plan. Incident identification involves gathering events from various sources (such as log files, intrusion detection systems, and firewalls) to procure evidence on whether an event is an incident. When an incident is analyzed and prioritized, the incident response team needs to notify the appropriate individuals so that all people who need to be involved can play their roles.
The exact reporting requirements vary among organizations, but parties that are typically notified include the chief information officer (CIO), chief information security officer (CISO), other internal incident response team members, system owners, human resources officials, public affairs officers, legal department personnel, federal agencies, and law enforcement personnel, when necessary.
In 2013, a data breach incident at Target put some 110 million people at risk of credit fraud and identity theft. Companies such as Neiman Marcus, eBay, Home Depot, and Sony have also made headlines due to large-scale data breaches. One of the most important points about a data breach is that mitigation of further data loss is necessary. An organization needs to conduct a thorough investigation of a suspected or confirmed loss or theft of account information within 24 hours of the compromise. Incident notification is often a legal requirement in responding to a data breach. Data breach notification laws provide direction on steps to take following a data breach and might define both responsibilities and liabilities involved in a breach. A key challenge in responding to a data breach is determining whether and when notification is an appropriate response; the legal team often makes this determination. Data breach notification laws are continually changing, and businesses should consider the statutes of all states in which they do business or where residents have personal information.

Cyber-Incident Response Teams
A cyber-incident response team (CIRT) has a key role that is defined as part of an incident response plan. The team should consist of technical and security investigators who respond to and look into security incidents. When a suspected or confirmed incident occurs, the CIRT should be notified to handle the situation and execute the incident response process.
A CIRT is also referred to as a computer incident response team, a computer security incident response team (CSIRT), a cyber-security incident response team, or simply an incident response team (IRT).

Most large organizations have response teams that are made up of full-time employees. However, many of these same organizations also partially outsource some of the responsibilities, particularly for more serious incidents. Other organizations choose to outsource the entire team and process. Varying structures are used, depending on the team’s makeup. Most structures fall within one of the three models described by NIST:
- Central: A single team is responsible for incidents. This model is common in smaller organizations, particularly companies that aren’t geographically dispersed.
- Distributed: Multiple teams are involved. Each team might be assigned specific areas, based on different components of the organization or physical geography.
- Coordinating: As in the central model, a single team is established. However, this team only provides guidance for other teams. The coordinating model therefore also has attributes of the distributed model.
Regardless of the model, the CIRT needs to collaborate with others during an incident. Management, information security, physical security, support, legal, human resources, public affairs, privacy, and potentially other personnel are critical to the CIRT’s success. These groups have specific expertise and responsibilities and can assist each other throughout the response process.

Training, Tests, and Exercises
An incident response plan should include requirements for training, tests, and simulated exercises. Mature incident response programs also likely have dedicated plans that focus on these activities. Executing these activities has two primary purposes: to ensure effectiveness during an incident and to identify any deficiencies that should be addressed or mitigated. For these activities to actually translate to better results in the future, however, they must be part of the lessons learned in the post-incident activities. (These activities are discussed in further detail later in this guide below.)
Proper training is critical to the success of any formal program. Specific to incident response, training starts with clear communication of the roles and responsibilities discussed earlier. Within each role, the specific set of skills needed to perform the corresponding responsibilities should be considered. Each role must get adequate training.
Tests, unlike exercises (discussed next), apply specifically to systems that are usually operational. For example, this might include the capability to recover a system from a backup. Where possible, tests should include the actual systems in operation. For example, if failover is to be tested, the system should be taken offline to determine whether it actually cuts over to the next system as expected.
Exercises tend to be simulations—that is, they don’t affect operational systems. Exercises are scenario based. For example, an exercise might involve an attacker exfiltrating a database of customer data. The two primary types of exercises are tabletop and functional exercises. As the name implies, in a tabletop exercise, the appropriate individuals and teams are brought together (typically around a table) for a discussion. In an exercise on a customer data breach, for example, the group members would discuss their individual roles and how they would coordinate. In contrast, in a functional exercise, participants go through the motions of their response as they would during an actual emergency. Again, however, the response is simulated, so it does not affect systems in operation.
Incident response exercises are either discussion oriented (as with tabletop exercises) or more focused on simulated response (as with functional exercises).
Consider the simple analogy of a fire alarm response. Children and staff members in school are trained on what to do when they hear the fire alarm. Tests are conducted to ensure that the fire alarms function. Exercises are performed to ensure that the staff and students can execute what they have been trained for by actually exiting the building and congregating at a specified location.

Incident Response Process
A process generally consists of a series of steps or phases. The incident response life cycle includes four primary phases:
- Preparation
- Identification and analysis
- Containment, eradication, and recovery
- Post-incident events

The figure below illustrates the flow and loops of this process. As mentioned earlier, the key components of an incident response plan should include preparation, roles, rules, and procedures that are critical to the incident response process and life cycle.



Incident response process

Preparation
Organizational policies and practices offer structural guidance designed to ensure quality and efficiency in the workplace. To properly preserve evidence, an organization should have an incident response team that knows how to handle incidents. Incident response methodologies typically emphasize preparation so that the organization is ready to not only respond to incidents but also prevent incidents by ensuring that systems, networks, and applications are sufficiently secure.

Various tools and resources are needed to handle an incident. Proper preparation starts with ensuring that these resources are defined and available. “NIST Computer Security Incident Handling Guide” (SP 800-61) provides a wealth of information to use as a baseline and highlights specific tools and resources. The following list covers the broad categories of resources that incident handlers need, along with some examples:
- Communications and facilities: Contact information, encrypted communications, secure storage facility, and phones
- Hardware and software for analysis and mitigation: Forensics workstations, protocol analyzers, portable printer, cameras, and blank media
- Ancillary analysis resources: Port lists, documentation, network diagrams, and existing system baselines
An incident response team commonly has a jump kit. Much like a first-aid kit, a jump kit is pre-prepared and available for immediate use in case of an incident. The jump kit should contain tools and resources from the categories just listed.

Incident Identification and Analysis
Many risks to enterprise networks relate both to vulnerabilities present in system and service configurations and to network and user logon weaknesses. Signs of an incident are either precursors or indicators. A precursor is a sign that an incident might occur in the future. An indicator is a sign that an incident might have occurred or might be occurring now. Not every precursor or indicator is guaranteed to be accurate. For example, intrusion detection systems can produce false positives. Thousands or millions of indicators can be generated daily, and each indicator must be evaluated to determine its legitimacy. An accurate indicator does not necessarily mean that an incident has occurred, so determining whether an event is truly an incident is a matter of judgment.

The first step is to analyze and validate the incident or incidents. When the response team has determined that an incident has occurred, the next step involves taking a comprehensive look at the incident activity to determine its scope. Documentation is important for eliminating errors and ensuring an efficient process. A proper determination of the scope of an incident helps prioritize potential needs for deeper analysis, as well as the next step in the process for containment. To help with prioritization efforts, the response team should consider and categorize the impact and recoverability effort. This includes the following:
- Functional impact of the incident: A categorization that uses varying degrees of impact severity, from none (no effect) to high (unable to provide critical services).
- Information impact of the incident: The type of impact on information. For example, if personally identifiable information of individuals was accessed, this might be categorized as a privacy breach.
- Recoverability from the incident: The extent of the recoverability efforts. This can include a defined category, from simple, in which recovery is well understood and does not require additional resources, to severe, in which recovery is not possible.
Finally, the incident response team should notify the proper individuals and teams, according to procedures defined in the incident response program.

Containment, Eradication, and Recovery
The process by which evidence is handled at the scene is often much more important than the laboratory analysis work done later. First responders are the first ones to arrive at the incident scene. The success of data recovery and potential prosecution depends on the actions of the individual who initially discovers the computer incident. How the evidence scene is handled can strongly affect the organization’s capability to successfully prosecute the perpetrator. Police officers are trained to have a good understanding of the limits of applicable laws, but many systems administrators and network security personnel are not. The entire work area—not just the computer involved—is a potential crime scene. Evidence might include removable media, voicemail messages, and handwritten notes. The work area should be secured and protected to maintain its integrity. Under no circumstances should anyone be allowed to remove items from the scene without proper authorization.
Isolating systems or devices involved in an incident gives a forensics team time to develop a tailored remediation strategy. The infected systems need to be isolated and quarantined. Quarantining involves finding each infected machine and disconnecting, removing, or blocking it from the network so that it cannot infect other unpatched machines on the network.
For example, when a malware-infected machine that regularly reports back to a designated host fails to report as expected, the malware might overwrite or encrypt all the data on the host’s hard drive. Incident response personnel should not assume that they have prevented further damage to the host simply because they have disconnected a host from the network. In cases such as this, the organization can redirect the attacker to a sandbox, where the team can monitor the attacker’s activity to gather additional evidence and more clearly understand the attack. This approach comes with additional risks, of course, including possible legal ramifications.
Although removing an attacked device from a network is generally advisable, this process can cause additional damage when sophisticated malware is involved.
Incident response functions can take many forms, depending on the severity of the incident and the organizational policy. The response team might send out recommendations for mitigation, recovery, containment, and prevention to systems and network administrators, who then complete the response steps. Alternatively, team members might perform the mitigation actions themselves.
In keeping with the severity of the incident, the organization can mitigate the impact of the incident by containing it and eventually restoring operations to normal. Mitigation needs to occur before an incident damages resources. Because of the need to act quickly, mitigation is often based on judgment and fast decision making. Decisions are easier to make if strategies and procedures for incident mitigation are already in place. Organizations should define acceptable risks in dealing with incidents and develop strategies accordingly. The incident type determines the mitigation type. Organizations should create separate mitigation strategies for each major incident type, with criteria clearly documented.
Mitigation refers to the action of minimizing the impact of an incident. Accurately determining the cause of each incident is important so that the team can fully contain the attack and any exploited vulnerabilities to prevent similar incidents from occurring in the future.
Depending on the nature of the incident, the organization might opt for destruction of physical property. In such a case, rebuilding or reconstituting the organization could be necessary. Reconstitution options include continuing to operate from the current alternate site, beginning an orderly phased return to the original site, and beginning to establish a reconstituted organization at another location. In recovery, administrators restore systems to normal operation and confirm that the systems are functioning normally.
Higher levels of system logging or network monitoring are often part of the recovery process. After a resource is successfully attacked, it is often attacked again, or other resources in the organization are attacked in a similar manner. Eradication and recovery should be done in a phased approach that prioritizes remediation steps. Eradication means removing elements of the incident, such as malware. Recovery is about restoring systems to normal, which often includes restoring from backups or rebuilding systems. For large-scale incidents, recovery can take months.
Not all incidents require eradication. Sometimes systems only need to be recovered. On the other hand, sometimes eradication goes hand-in-hand with recovery. For example, whereas eradication might include disabling breached user accounts, recovery would include changing passwords.

Post-Incident Activities
After mitigating an incident, an organization issues a report containing details about the incident, such as the cause, the cost, and recommendations for preventing future incidents. Incident reporting allows the organization to review and adjust its processes in order to reduce additional incidents and losses. Organizations might be subject to industry requirements for reporting certain types of incidents. Where they are, requirements and guidelines cover external communications and information sharing (what can be shared with whom, when, and over what channels) and identify the handoff and escalation points in the incident management process. In addition, forensic analysis of information might require further reporting to law enforcement or clients, depending on the findings and evidentiary data.
The follow-up response can involve sharing information and lessons learned with other response teams and appropriate organizations and sites. One of the most important parts of incident response is lessons learned. A lessons-learned meeting should be conducted within a few days of a major incident; alternatively, a lessons-learned report can be filed. A lessons-learned meeting or report provides incident closure by reviewing what occurred, describing the action taken to mitigate and contain the incident, and summarizing how well the mitigation worked. Lessons-learned reports provide valuable information for updating incident response policies and procedures. Postmortem analysis of incident handling often reveals missing steps or procedures.

Following a data breach, a company typically incurs costs related to notifying customers and processing claims for damages. Expenses related to the following may be incurred when a data breach results in the loss or theft of third-party information:
- A forensic examination to determine the severity and scope of the breach
- Notification of third parties
- Call center hotline support
- Credit or identity monitoring
- Public relations, for damage control
- Legal defense
- Regulatory proceedings, fines, and penalties
In addition, regulatory settlements might require the breached organization to produce or implement a comprehensive written information security program that is subject to periodic audits.

Continuity and Recovery Plans
Business continuity planning (BCP) and continuity of operations planning (COOP) ensure the restoration of organizational functions in the shortest possible time, even if services resume at a reduced level of effectiveness or availability. Disaster recovery planning (DRP) extends this process to ensure full recovery of operational capacity following a disaster (natural or human caused). Instructions and details for recovery should occur before an incident. Plans should be determined, and they also should be regularly updated and tested to ensure that the appropriate stakeholders are identified, communication plans can be implemented, and responders can properly execute response and recovery plans. These plans should address different scenarios for incident handling responses and notification procedures following identification, short-term recovery of key service and operational data access functions as part of continuity of operation preparedness, and long-term sustained recovery to full operational status in disaster recovery planning. A business recovery plan, business resumption plan, and contingency plan are also considered part of business continuity planning. If an incident occurs, an organization might also need to restore equipment (in addition to data) or personnel lost or rendered unavailable by the nature or scale of the disaster.

Disaster Recovery
Failure to recover from a disaster could destroy an organization. Many organizations realize the criticality of disaster recovery planning only after a catastrophic event (such as a hurricane, flood, or terrorist attack). However, disaster recovery is an important part of overall organization security planning for every organization. Natural disasters and terrorist activity can overcome even the most rigorous physical security measures. Common hardware failures and even accidental deletions might require some form of recovery capability.

Disaster recovery involves many aspects, including the following:
- Disaster recovery plan: This plan is a written document that defines how the organization will recover from a disaster and how to restore business with minimal delay. The document also explains how to evaluate risks; how data backup and restoration procedures work; and the training required for managers, administrators, and users. A detailed disaster recovery plan should address various processes, including backup, data security, and recovery.
- Disaster recovery policies: These policies detail responsibilities and procedures to follow during disaster recovery events, including how to contact key employees, vendors, customers, and the press. They should also include instructions for situations in which bypassing the normal chain of command might be necessary to minimize damage or the effects of a disaster.
- Service-level agreements: SLAs are contracts with ISPs, utilities, facilities managers, and other types of suppliers that detail the minimum levels of support that must be provided (including during failure or disaster).

Fundamental to any disaster recovery plan is the need to provide for regular backups of key information, including user file and email storage; database stores; event logs; and security principal details such as user logons, passwords, and group membership assignments. Without a regular backup process, loss of data through accidents or directed attack could severely impair business processes.
Disaster recovery planning should include detailed system restoration procedures, particularly in complex clustered and virtualized environments. This planning should explain any general or specific configuration details that might be required to restore access and network function.
A restoration plan also should include contingency planning to recover systems and data in case of administration personnel loss or lack of availability. This plan should include procedures to follow if a disgruntled employee changes an administrative password before leaving. Statistics show that more damage to a network comes from inside than outside. Therefore, any key root-level account passwords and critical procedures should be properly documented so that another equally trained individual can manage the restoration process. This documentation must also include backout strategies to implement if the most recent backup proves unrecoverable or if alternative capacity and equipment are all that remain available.
As part of redundancy and recovery planning, an organization can contract annually with a company that offers redundancy services (for a monthly service charge or a fee that is otherwise negotiated). When contracting services from a provider, be sure to carefully read the contract. Daily fees and other incidental fees might apply. In addition, in a large-scale incident, the facility could well become overextended.
In the beginning stages of the organizational security plan, the organization must decide how it will operate and how it will recover from any unfortunate incidents that affect its capability to conduct business. Redundancy planning encompasses the effects of both natural and human-caused catastrophes. Often these catastrophes result from unforeseen circumstances. Site planning for recovery is key.

Continuity of Operations Planning
Business continuity is mostly synonymous with continuity of operations planning (COOP). Specifically, COOP is an initiative that U.S. President George W. Bush implemented in 2007 to ensure that government departments and agencies can continue operation of their essential functions under circumstances involving natural, human-caused, and technological threats and national security emergencies. Continuity of operations is generally viewed as being the same as business continuity, but it primarily focuses on the government and public sectors. Policies and procedures are designed to ensure that an organization can recover from a potentially destructive incident and resume operations as quickly as possible following an event.

The main goal of preventing and effectively dealing with any type of disruption is to ensure availability. This primarily includes making sure of the following:
- Failover is available for required system redundancy. This can be automatic or manual.
- Alternate processing sites are available that are geographically different from the primary facilities.
- Alternate business practices are available in case systems or logistics prevent normal operating practices.

A continuity of operations plan provides guidance to ensure that the organization can continue operation of its essential functions under emergencies. It should include details about relocation to alternate sites, if needed.
An organization should also consider contingencies for personnel replacement in the event of loss (death, injury, retirement, termination, and so on) or lack of availability. Succession planning is a process in which an organization ensures that it recruits and develops employees to fill each key role within the organization. Clear lines of succession and cross-training in critical functions are key. Organizations also need communications plans for alternative mechanisms of contact to alert individuals of the need for succession. Such considerations are imperative for meeting recovery time objectives (RTOs) and recovery point objectives (RPOs).

Proper continuity of operations planning should allow for training and tabletop exercises, similar to those discussed earlier in this guide for incident response. Tabletop exercises involve key personnel participating in an informal, simulated scenario setting. The exercises are conducted to evaluate an organization’s capability to execute one or more portions of a business continuity or disaster recovery plan. Tabletop exercises should be conducted on a regular basis to accomplish the following:
- Test and evaluate business continuity or disaster recovery policies, as well as procedures to identify plan weaknesses and resource gaps.
- Train personnel and clearly define roles and responsibilities to improve performance, communication, and coordination.
- Meet regulatory requirements.

A progressive exercise program is made up of gradually more complex exercises, with each one building on the previous one until the exercises are as close to reality as possible. When escalated to a full-scale exercise, this should involve a wide range of organizations, including fire, law enforcement, and emergency management personnel, as well as, when necessary, other entities such as local public health and public safety agencies.
Any disaster recovery or business continuity plan that involves contingencies, backup and recovery, or succession must include regular testing of restoration and recovery processes. The organization must ensure that personnel can transition and that backup media and procedures can adequately restore lost functionality.
Lessons learned play a key role after incident response. The same applies with continuity of operations. After training exercises and actual events, it is important to debrief and identify what went well and where improvement is needed. Some organizations, particularly government agencies, refer to these as after-action reports. In addition to identifying strengths and weaknesses, these reports should maintain a clear outline of what occurred.

Quiz questions:

1. Your rapid response team has been alerted about and identified a highly dangerous virus on a couple systems in one of your subnets. What step should your team take next? A. Identification B. Containment C. Recovery D. Eradication

2. Which of the following stakeholders are typically notified first when a confirmed incident has occurred? (Select two.) A. Press B. CISO C. End users D. Legal

3. What is the term given to a framework or model outlining the phases of attack to help security personnel defend their systems and respond to attacks? A. Command and control B. Intrusion kill chain C. Cyber-incident response D. CIRT

4. Which of the following is a written document that defines how an organization will recover from a disaster and how to restore business with minimal delay? A. Tabletop agreement B. Service-level agreement C. Disaster recovery policy D. Disaster recovery plan

Answer 1: B. The team now knows that the virus has been identified and should seek to contain or isolate the virus to prevent its spread. If the team fails to contain the virus, it needs to take mitigating actions. Answer A is incorrect because the team has already identified the virus. As a result, answers C and D are incorrect. Eradication and then recovery would typically follow containment.
Answer 2: B and D. The exact reporting requirements vary among organizations, but parties that are typically notified include the chief information officer (CIO), chief information security officer (CISO), other internal incident response team members, human resources officers, public affairs personnel, the legal department, and law enforcement officers, when necessary. Answer A is incorrect because the press is not normally notified when an incident occurs. Answer C is incorrect because the end users are not normally notified initially when an incident occurs.
Answer 3: B. An intrusion kill chain is often used to describe the stages of a cyberattack; it also helps security teams defend their systems and helps incident response teams respond to attacks. Answers A, C, and D are incorrect. Command and control usually represents a stage of an attack in which the attacker tries to gain remote capabilities. Cyber-incident response would certainly respond to incidents but does not represent a framework or model attack phase. Similarly, CIRT is the acronym for cyber-incident response team.
Answer 4: D. A disaster recovery plan is a written document that defines how the organization will recover from a disaster and how to restore business with minimal delay. The document also explains how to evaluate risks; how data backup and restoration procedures work; and the training required for managers, administrators, and users. Answer A is incorrect and invalid. However, in tabletop exercises, the appropriate individuals and teams are brought together for a discussion. In an exercise on a customer data breach, for example, the group members would discuss their individual roles and how they would coordinate. Answer B is incorrect because service-level agreements (SLAs) are contracts with ISPs, utilities, facilities managers, and other suppliers that detail the minimum levels of support that must be provided during a failure or disaster. Answer C is incorrect because a disaster recovery policy details the responsibilities and procedures to follow during disaster recovery events, including how to contact key employees, vendors, customers, and the press.