This chapter covers Certified Information Security Manager (CISM) Domain 4, “Incident Management,” part B, “Incident Management Operations.” The entire Incident Management domain represents 30 percent of the CISM examination.

One Supporting Task in the CISM job practice aligns with the Incident Management / Incident Management Operations domain:

37.   Conduct post-incident reviews to facilitate continuous improvement, including root-cause analysis, lessons learned, corrective actions, and reassessment of risk.

Security incidents cannot be prevented—at least not all of them. In this asymmetric cyber war, attackers have innovation, time, and the element of surprise on their side. It is imperative that every organization using IT develop formal security incident response plans, train their personnel, and continually practice with walk-throughs, drills, and simulations.

Formal, organized security incident response techniques have undergone continuous improvement over many decades and are described in this chapter. These are the phases of incident response:

•   Planning

•   Detection

•   Initiation

•   Analysis

•   Containment

•   Eradication

•   Recovery

•   Remediation

•   Closure

•   Post-incident review

•   Retention of evidence

Planning

This step involves the development of written response plans, guidelines, and procedures to be followed when an incident occurs. These procedures are created after the organization’s practices, processes, and technologies are well understood. This helps to ensure that incident response procedures align with security policy, business operations, the technologies in use, as well as practices regarding organizational architecture, development, management, and operations. The plans, guidelines, and procedures should identify and include key external partners. The planning cannot be conducted in a vacuum, because many organizations rely on partners for key business functions.

Detection

Detection represents the moment in which an organization is initially aware that a security incident is taking place or has taken place. Because a variety of events can characterize a security incident, an organization can become aware of an incident in several ways, including the following:

•   Application or network slowdown or malfunction

•   Alerts from intrusion detection system (IDS), intrusion prevention system (IPS), data loss prevention (DLP) system, web content filter, cloud access security broker (CASB), extended detection and response (XDR), antivirus, firewalls, and other detective and preventive security systems

•   Alerts from a security information and event management (SIEM) system

•   Media outlets and their investigators and reports

•   Notification from an employee or business partner

•   Anonymous tips

•   Notification from a regulator

•   Notification from a media outlet

Initiation

This is the phase in which response to the incident begins. Typically, it includes declaration of an incident, followed by notifications sent to response team members so that response operations may begin. Depending upon the severity of the incident, notifications may be sent to business executives.

Analysis

In this phase, response team members collect and analyze available data to understand the incident’s cause, scope, and impact. This may involve the use of forensic analysis tools to understand activities on individual systems. During this phase, partners or vendors may be engaged to collect information from their systems to determine the extent of the compromise.

Containment

Incident responders perform or direct actions that halt, or contain, the progress or advancement of an incident. The steps required to contain an incident will vary according to the means used by the attacker. Techniques include blocking command and control traffic or taking storage systems offline. Senior leadership is usually involved in approving the containment actions of the team. In some cases, a mature incident response program will already have rules of engagement so the technical teams know which actions are approved and which need input from senior leadership.

Eradication

In this phase of incident response, responders take steps to remove the source of the incident. This could involve removing malware or physically removing an intruder.

Recovery

When the incident has been evaluated and eradicated, there is often a need to recover systems or components to their pre-incident state. This can include restoring data or configurations or replacing damaged or stolen equipment.

Remediation

This activity involves any necessary changes that will reduce or eliminate the possibility of a similar incident occurring in the future. This may take the form of process or technology changes.

Closure

Closure occurs when eradication, recovery, and remediation have been completed. Incident response operations are officially closed.

Post-incident Review

Shortly after the incident closes, incident responders and other personnel meet to discuss the incident: its cause, impact, and the organization’s response. Discussion can range from lessons learned to possible improvements in technologies and processes to improve defense and response further.

Retention of Evidence

Incident responders and other personnel direct the retention of evidence and other materials used or collected during the incident. This may include information used in legal proceedings such as prosecution, civil lawsuits, and internal investigations. A chain of custody may be required to ensure the integrity of evidence.

Incident Management Tools and Techniques

Security incident management is driven primarily by automation in all but the tiniest organizations. Because a wide variety of security-related events may occur, most organizations rely upon centralized log management and a SIEM system that automatically collects security event log data and generates alerts based on rules, or use cases. Incident response plans, then, consist of the manual and tool-assisted steps taken by personnel when a SIEM generates an alert.

The discovery of security incidents can take on many forms. A SIEM may alert personnel to a security incident, but an organization can become aware of a potential incident in several other ways. The types of detection that may occur are outlined later in this chapter. The framework of security incident response is the main topic of this chapter.

Incident Response Roles and Responsibilities

A security incident response plan contains information about specific roles and responsibilities to ensure that a security incident is handled correctly and promptly. Typical defined roles and responsibilities include the following:

•   Reporting security problems   Many organizations enact policies that require all personnel to report suspicious issues to security personnel.

•   Incident detection   This may occur via dedicated security event monitoring personnel (in a security operations center, or SOC) or by people with other responsibilities. In the former case, personnel will periodically examine event logs or be sent messages when security events occur. Also, help desk or service desk personnel need to be trained to recognize security incidents while working with end users and troubleshooting problems.

•   Incident declaration   Some personnel are granted roles that can formally declare a security incident. They are usually trained to recognize various types of incidents and follow procedures to notify others of an incident. Incident declaration formally triggers the performance of incident response procedures and communications.

•   Incident commander   Some personnel coordinate various activities as an incident unfolds and is managed. For this role, organizations typically select domain experts and other personnel with technical skills and backgrounds, who can direct other personnel as an incident is examined, contained, and resolved. In severe and prolonged incidents, incident commanders will take shifts.

•   Internal communications   These roles are designated to communicate information about an incident to personnel inside the organization, to keep other internal parties informed on the proceedings of the incident and its response.

•   External communications   These personnel are authorized to communicate with outside parties, including law enforcement, regulators, customers, partners, suppliers, shareholders, and the public. Typically, the matter of external communications is shared, with one or more people who must approve any external communications and those who do the actual communicating.

•   Legal counsel   Inside or outside counselors are generally responsible for interpreting applicable laws, regulations, and legal agreements, and they advise other incident response personnel of steps that should (or should not) be taken. In many cases, incident investigations are protected by attorney–client privilege, which requires that legal counsel be involved in the main proceedings of the incident.

•   Scribe   One or more scribes maintain records of all the proceedings. This includes but is not limited to actions taken by all incident response personnel, decisions, communications, and the location of records such as retained logs and artifacts from forensic analysis.

•   Forensic analysis   Many security events require one or more people with expertise in computer and/or network forensics who seek to determine the cause of an incident and methods that can be used to contain and eradicate it. Because some security incidents may result in subsequent legal proceedings, forensic analysts employ evidence preservation techniques and establish a chain of custody to ensure that evidence is not altered.

•   Containment, eradication, remediation, and recovery   These personnel take measures to halt an incident’s progress and recover affected systems to their pre-incident states. While containment, eradication, remediation, and recovery are four distinct steps in incident response, they are often performed by the same personnel.

•   Business continuity and emergency operations   A significant incident may result in considerable downtime or other business disruption, as one or more critical systems may be affected by an incident and taken out of service. An organization may need to invoke business continuity and/or emergency operations to continue critical business operations.

Incident Response Tools and Techniques

The detection of most security incidents, including malware and intrusions, requires the use of tools. Without these tools, organizations may be unaware of any incident in progress and may not learn of the incident until months or years later, if ever. Some tools are used to examine and analyze an incident that has been identified. They help security personnel understand events in one or more systems and/or networks. Other tools are sometimes used to eradicate and recover from an incident. Finally, tools can be used to chronicle all the events of an incident for later analysis during post-incident review and beyond. Incident response tools include the following:

•   Logging   Events on individual systems and network devices often provide direct or indirect indications of intrusions and other incidents. Logs stored in a central server make this capability more powerful, as events from different systems and devices can appear together, providing a more comprehensive view of events.

•   Log analysis and correlation   A SIEM provides log analysis and correlation to help security personnel realize when unwanted events are occurring or have occurred in the past.

•   Alerting   A SIEM or other log processing system can be configured to produce alerts when specific incidents occur, proactively notifying security personnel that something requires attention.

•   Threat hunting   Specialized tools are available to facilitate proactive threat hunting.

•   Threat intelligence   Many organizations subscribe to one or more cyber-threat intelligence feeds that help make personnel aware of actionable threats, enabling them to confirm that protective and detective measures are in place. Some threat intel feeds are meant to be fed directly into a SIEM, which will correlate threats with identified vulnerabilities to direct personnel to improve defenses. Other threat intel feeds are intended to be human-readable. This functionality is often packaged in a threat intelligence platform (TIP).

•   Malware prevention   Antivirus and advanced antimalware solutions on mobile devices, laptops, and servers detect the presence of malware and can often block or disrupt its activities. Malware detection and prevention capabilities can also be provided by firewalls, IPSs, web filters, and spam/phishing filters.

•   Network intrusion prevention   IPSs analyze the details and contents of network traffic that passes through them, detecting—and often blocking—an initial intrusion or the command-and-control (C&C) traffic generated by malware that has successfully compromised a system. A typical IPS is configured to block specific traffic automatically and produce alerts when this occurs, but it will permit certain traffic. Network intrusion detection will alert personnel of suspected attacks, without doing anything to stop them.

•   Web content filter   Many organizations employ systems that provide protection from the hazards of users browsing malicious and fraudulent web sites. Web content filters can be used to block access to known malicious sites as well as sites associated with various types of inappropriate content. For example, an organization can block users’ from accessing sites that focus on pornography, weapons, hate crimes, or online gambling. Some web content filters can examine the contents of traffic and can block malware from reaching end-user devices.

•   File integrity monitoring (FIM)   FIM systems periodically scan file systems on servers and workstations and report any changes. Although changes may result from periodic maintenance, they can also be indicators of compromise. A typical FIM system sends alerts to a SIEM to notify SOC analysts of a potential intrusion.

•   File activity monitoring (FAM)   FAM systems monitor directories and files on servers or workstations to detect unusual activities that may indicate compromise. A typical FAM system sends alerts to a SIEM, where SOC analysts will be watching for alerts.

•   Forensic analysis   These tools are used to study the events that have occurred on a system, examine the contents of file systems and memory, and analyze malware to understand its structure and actions. Their use requires forensic skills and experience, as they usually don’t reveal what happened, but instead show detailed information to a forensic examiner, who determines which elements to examine to uncover the relevant chain of events. Forensic analysis is used to examine a malware attack and chronicle the events of an employee accused of misbehavior.

•   Video surveillance   This is needed for incidents involving human activity—usually the comings and goings of personnel and intruders and any items they are carrying with them.

•   Recordkeeping   Decisions, steps undertaken, and communications need to be recorded so that incident responders can understand the activities that have taken place during incident response and provide a backward look during post-incident review.

Incident Monitoring by MSSPs

Organizations may outsource security monitoring to a managed security services provider (MSSP). Because security incidents may proceed rapidly, some organizations prefer to have an outside expert organization perform around-the-clock security monitoring of its critical systems to provide expert detection and rapid notification of suspected and confirmed incidents. Some MSSPs may be able to perform additional steps of incident response, including analysis and containment of an incident, on their customers’ behalf.

Organizations that choose to outsource security monitoring do so for several reasons, including the following:

•   Domain expertise   Personnel at an MSSP have security monitoring and incident detection expertise.

•   Dedicated personnel   The staff at an MSSP have only one job: monitoring customers’ systems to identify and respond to security incidents. Unlike an organization’s security staff, the personnel at an MSSP are not distracted by other activities or projects, other than the continuous improvement of event monitoring.

•   Staffing shortage   It is difficult for many organizations to identify, recruit, and retain qualified information security personnel. Outsourcing security monitoring relieves organizations of the burden of staffing their security monitoring function.

•   Cost control   The fees charged by MSSPs may be less than the salaries, benefits, tools, workspaces, and other costs required for in-house staff, mainly because of economies of scale: MSSP personnel typically perform security monitoring for numerous organizations.

Threat Hunting

The practice of threat hunting is used proactively to look for signs of intrusions. Rather than passively monitoring systems, threat hunters use tools to hunt for indicators of compromise (IOCs). The objective of threat hunting is the earliest possible detection of intrusions. When an intrusion is detected early, its impact on the organization may be low, particularly if an attack is detected prior to the intruder achieving her attack objective. Threat hunting is often carried out by organizations with mature event monitoring programs. In other words, organizations considering threat hunting should do so only after achieving a moderate to high level of maturity in their monitoring tools and practices.

Incident Response Retainers

An incident response retainer (IRR) is a legal agreement between an organization and a security professional services firm (sometimes the same MSSP used to detect incidents) that contracts to assist the organization in the event of a security incident. The agreement may include a service level agreement (SLA) that commits the security firm to respond quickly to an organization’s call for assistance. The IRR agreement may consist of prepaid services, hourly rates for incident response, and other provisions that define roles and responsibilities.

Depending upon the nature of a security incident, the security firm may send forensic experts to the client’s location to perform forensics, or, if the incident does not require onsite work, the client organization may send malware samples, incident logs, or other digital information to the security firm, where analysis can be performed remotely. In some cases, the organization experiencing an incident may need a security firm to act as an incident commander who may fulfill the role of managing the organization’s activities in response to the incident.

External Legal Counsel

Some organizations retain outside legal counsel through a retainer agreement. External legal advisors can provide expertise in the legal aspects of security incident response. Outside counsel can advise an organization on the interpretation of laws regarding cybersecurity and privacy, and it may offer counsel regarding contracts with other organizations as well. An external legal counsel may also be used to assist with legal activities and logistics related to incident response.

Cyber-insurance Companies and Incident Response

Although organizations have been able to purchase cyber-insurance policies for decades, it is only in the last few years that cyber-insurance companies have become intimately involved in organizations’ security practices and incident response. This involvement has deepened in recent years following a plague of ransomware attacks and large insurance payouts. As a result, cyber-insurance companies are doing the following:

•   Becoming keenly aware of the specific risk factors leading to costly incidents

•   Thoroughly vetting organizations’ security programs and capabilities, using lengthy questionnaires and requests for specific artifacts such as security policies and even detailed configuration information

•   Creating policies with more detailed terms, conditions, and exclusions

•   Charging organizations higher premiums with limitations in benefits if an organization is deemed to have substandard security practices and safeguards in place, or denying them coverage at any price

•   Becoming deeply involved in security incident response, sometimes by directing one of a short list of security professional services firms to perform computer and network forensics

It is becoming increasingly difficult to obtain cyber-insurance as insurance companies are becoming more stringent on requirements such as multifactor authentication and antimalware. It is imperative that an organization be aware of the fine print of its cyber-security policy; otherwise, the organization may find the policy is worthless when it’s time to file a claim.

Incident Investigation and Evaluation

Any response to a security incident consists of several phases, from detection, to closure, to post-incident review. The phases of security incident response are part of a model. As such, security managers realize that certain types of incidents don’t require all of the steps included in the model. A stolen laptop computer may require virtually no eradication activities, for example. And a violation of security policy, such as a user sharing login credentials, will pivot into an internal investigation that may result in disciplinary action.

Some incidents may require additional phases. For instance, a security incident involving the theft of a large volume of information will require a series of post-incident proceedings that may represent greater efforts and costs than the initial incident response. Regardless of the seriousness of the incident, successful incident response requires considerable planning, and this involves allocating roles and responsibilities and using multiple tools and techniques.

Incident Detection

The detection phase marks the start of an organization’s awareness of a security incident. In many cases, some time elapses between the beginning of an actual incident and the moment that the organization is aware of it; this period is known as dwell time. The ability to detect an intrusion or incident requires event visibility, which is typically achieved through event log collection and analysis tools (usually a SIEM system), together with other tools that monitor and detect activities in networks, servers, and endpoints. An organization can be made aware of an incident in a number of ways, including but not limited to the following:

•   Reporting by an employee   An organization’s personnel can be aware of certain types of incidents, especially misbehavior by other employees.

•   Reporting by a MSSP or SOC analyst   Personnel monitoring the organization’s networks and systems are likely to detect suspicious activities and initiate an investigation and response.

•   Reporting by a customer or client   An organization’s customers or clients may have noticed phenomena related to a breach and may report it to the organization.

•   Social media   Clients, customers, and other parties may report observations about a security incident via social media, particularly if they have no other means of notifying the organization.

•   Notification from law enforcement or regulator   In the case of information theft, outside organizations and agencies may become aware through higher rates of fraud. Law enforcement investigations reveal the source of the intrusion.

•   Notification from a security researcher   Security researchers sometimes discover vulnerabilities or signs of intrusion in other organizations’ networks.

•   Unknown persons   Occasionally, someone not associated with the organization will notify the organization of a security problem. For example, a passer-by may notice discarded assets tossed aside by someone who stole them.

•   IT personnel or end users   A security incident may initially appear as a malfunction or error in a system or application. Only through analysis is the malfunction determined to be caused by an intruder. For this reason, IT service desk personnel need to be trained in the art of detecting security issues when users call for help.

Incident Initiation

When an organization realizes that a security incident has occurred or is occurring, an incident responder will make an incident declaration, signaling the initiation phase. An organization’s security incident response plan should include a procedure for initiating an incident. This generally consists of notifying key personnel, including the security manager and the IT manager (whose actual titles may vary), and personnel on the incident response team. Incident response personnel may then initiate and join an emergency communications conference bridge or assemble in a war room. The group will select an incident commander, who will coordinate the use of resources and internal communications to enable the team to work effectively to manage the incident.

Incident Analysis

In the analysis phase of security incident response, response team members evaluate and rank available information to reveal the nature and criticality of the incident. This phase may include the use of forensic examination techniques that permit the examiner to determine how an incident was able to occur.

Incident Ranking and Rating

The types and severities of security incidents vary significantly; a relatively minor incident such as the loss of a laptop computer with encrypted contents would be considered far less serious than the theft and exploitation of a large database containing sensitive customer information, for example. Accordingly, an organization’s incident response plans should include steps to determine the scope and severity of an incident. This will help the organization determine the amount and types of resources that may be required, and it may determine whether executive management is informed of an incident. Chapter 7 includes a detailed explanation of incident ranking, including the different responses based upon rank.

Forensic Investigations

After a security incident has occurred, the organization may determine that an investigation is needed to determine the incident’s cause and effects. A forensic investigator gathers, studies, and retains information that may be needed in a court of law should the incident result in legal proceedings. Because the information collected in an investigation may later be used in a legal proceeding, a forensic investigator must understand the requirements regarding the chain of custody and other evidence protection activities that ensure that evidence can be used in court.

Chain of Custody  The key to an effective and successful forensic investigation is the establishment of a sound chain of custody. A chain of custody documents, in precise detail, how and when evidence is protected against tampering through every step of the investigation. Any irregularities in the information acquisition and analysis process will likely be looked at unfavorably in legal proceedings, possibly resulting in the organization failing to convince judicial authorities that the event occurred as described.

Chain of custody is driven primarily by the prospect of future legal proceedings for reasons that could include the following:

•   Disciplinary actions against employees, if insiders perpetrated the incident

•   Prosecution of perpetrators

•   Lawsuits brought by affected parties, particularly employees or customers

•   Investigations by regulators

Several major considerations determine the effectiveness of a forensic investigation:

•   Identification   This includes a description of the evidence acquired and the tools and techniques used to acquire it. Evidence may include digital information acquired from computers, network devices, and mobile devices, as well as interviews of involved people.

•   Preservation   Several tools and techniques are used to retain evidence. Preservation will include detailed records establishing the chain of custody, which may be presented and tested in legal proceedings.

•   Analysis   This description of the examination of the evidence gathered may include a reconstruction of events that are the subject of the investigation.

•   Presentation   This formal document describes the entire investigation, evidence gathered, tools used, and findings that express the examiner’s opinion of the events that occurred (or did not occur).

Forensic Techniques and Considerations  Computer and network forensics require several specialized techniques that ensure the integrity of the entire forensic investigation and a sound chain of evidence. Some of these techniques are listed here:

•   Data acquisition   Data must be acquired for forensic analysis. Subject data may reside on a computer’s hard drive, SSD, or RAM; in mobile device memory; in an application’s audit log; or on a network device. Several tools are available for forensic data acquisition, including media copiers, which acquire a copy of a computer’s hard drive, live memory, USB memory stick, or removable media such as an external hard drive, SSD, or CD/DVD-ROM.

•   Data extraction   If data is being acquired from a running system or a third party, a forensics analyst must use a secure method to acquire the data and demonstrate the integrity of the process used to do so. This shows the data’s source and proves that data was not altered during the extraction process.

•   Data protection   Once data is extracted, the forensic investigator must take particular steps to ensure its integrity. Computers used for forensic analysis must be physically locked to prevent unauthorized access, and they must not be connected to any network that would allow for the introduction of malware or other agents that could alter acquired data and influence the investigation’s outcome.

•   Analysis and transformation   Often, tools are required to analyze acquired data and search for specific clues. Also, data must frequently be transformed from its native state into a state that is human- or tool-readable; in many cases, computers store information in a binary format that is not easily read and interpreted by humans. For example, the NTUSER.DAT file used in Windows is a binary representation of the HKEY_LOCAL_USER branch of the system’s registry. This file cannot be directly read but requires tools to transform it into a human-readable form.

Most organizations do not have the luxury of owning computer forensics tools and having expert(s) on staff. Instead, when an incident requiring forensics occurs, a outside forensic investigator is brought in to conduct the forensics portion of the investigation. The forensic investigator will bring her own systems for acquiring live memory and hard drive/SSD images and tools for examining the data she obtains.

Organizations that want to have one or more forensic investigators available can purchase a retainer, an agreement that provides access to a pool of investigators and includes an SLA on their remote or onsite availability. Without a retainer, the costs to hire an investigator may be higher, and the organization may have to wait longer for an investigator to become available.

Some law firms also have in-house or retained forensics experts to assist in investigations. The outside law firm can operate under attorney–client privilege, which would also protect the information obtained by the forensic investigator and her final report.

Privacy Breaches

A breach of privacy is a unique type of security incident. In a privacy breach, an attacker may steal or compromise sensitive or private data about employees, customers, or other persons. The steps taken during incident response will be largely the same as those for breaches of other types of information. There are, however, two differences to keep in mind:

•   Incident handlers must handle privacy data according to the organization’s security and privacy policies.

•   The organization may be required to notify affected people during or soon after the incident.

Organizations that store or process information within the scope of privacy laws should include a security incident categorization that covers privacy incidents. Security incident plans or playbooks should include specific information that directs incident responders to perform all necessary steps, including notifications and disclosures.

Incidents Involving a Service Provider

With many organizations outsourcing one or more principal business applications to external service providers, organizations need to develop plans that include the procedure to follow when an incident or breach occurs in a service provider’s environment.

An organization that provides software as a service (SaaS) will likely detect an incident such as a malware attack or an intrusion when it occurs. The legal agreement between the organization and the SaaS provider should stipulate the circumstances in which the SaaS provider will notify affected customers. For the most part, the SaaS provider will perform most or all phases of security incident response, but that does not mean that the customer organization has nothing to do. A breach in a SaaS organization is still a breach, and the customer organization must have an incident response plan that considers such circumstances.

Organizations will have to rely mainly on the SaaS provider’s incident response to proceed and close the incident. However, the customer organization will need to be informed along the way, as it will need to pursue damage control, including notification of affected parties. Organizations are fully accountable when a breach occurs in a service provider’s organization. The organization selected the service provider and is accountable for all outcomes, including breaches. Chapter 6 explores the topic of third-party risk management in detail.

Incident Containment Methods

Incident containment includes the steps taken to prevent the incident from spreading further. Containment requires knowledge of the particulars of the incident and is most successful after the incident is examined and its techniques identified in the assessment phase. Containment is distinct from eradication, which is the removal of threats or threat actors from the environment. When containment has been completed, the threat still exists, but it cannot further proceed because containment measures have been taken.

Many cyberattacks can be contained by curtailing their network communications. If the attacker’s communication connections have been severed to prevent reestablishing or resuming communications, often the attack can be considered to be contained. Based upon the nature of the intrusion, containment may involve network changes in a firewall, IPS, or edge router to black-hole communications from the attacker’s network. Indeed, one of the main functions of an IPS is to block communications with known domains and IP address ranges known to be malicious. But for an attack originating from a malicious network not yet identified by an IPS, the organization can quickly implement a rule to block the IP address, range, or entire country’s range of IP networks, as appropriate.

Many forms of malware, including ransomware, utilize C&C communications from the computer they have attacked, to servers controlled by the malware operator. Well-managed IPS systems block C&C traffic from known adversaries and can recognize new, unclassified commands and proactively block traffic. However, security incident responders also realize that some forms of malware are not completely incapacitated when their C&C traffic is disrupted; they still may be able to operate independently, and may even continue to explore an organization’s network and even infect additional systems. This is another reason why isolating affected systems is so important. Similarly, if the malware’s C&C is DNS-based, incident responders may be able to block C&C traffic effectively by preventing DNS lookups to the domains identified as malicious.

When an attack has been identified, and once the organization has collected available information about the attack, the attack can be effectively contained by severing most or all network communications from the target system. This may, however, also impair incident responders from carrying out subsequent eradication and restoration steps if they cannot communicate with the system.

Other techniques are available in the containment phase. For instance, if the attacker can compromise systems through privilege escalation, locking the affected user or system account may prevent the attacker from successfully compromising additional systems. Also, if ransomware actively encrypts files on a network share, blocks authentication on the network share, or removes the network share altogether, removing affected systems from the network effectively contains the attack.

Incident Response Communications

Security incident response, in its details, is far from straightforward: while timely communication with specific parties is essential, organizations must take care not to over-communicate the details of an incident. Sometimes, the organization should limit communications about the existence of an incident only to authorized parties, rather than to the entire organization.

The incident response team should also consider using out-of-band communications if normal communications channels are suspected to be compromised. For instance, if the team believes that corporate e-mail and/or instant messaging is compromised, an entirely different system should be used for communication until the incident has been closed.

Crisis Management and Communications

Many organizations employ crisis management and/or crisis communications personnel and procedures. Both exist to improve responses to various business emergencies, including business interruptions of every kind. These capabilities should be incorporated into security incident response plans if they exist.

The crisis management process is used by an organization to respond to various business emergencies. One could liken crisis management to a general mobilization plan for business leaders and others to come together to respond quickly and effectively to disruptive events. Given that disasters and security incidents fall into the category of disruptive events, a security incident response plan, business continuity plan, and disaster recovery plan should utilize the capabilities in crisis management.

Why would an organization develop a similar, parallel capability instead of using what it already has? Crisis management does not exist to take over or control business continuity, disaster recovery, or security incident response. Rather, crisis management can provide templates and techniques for communications and escalation. Crisis management should help simplify the overall effort of responding to all kinds of business emergencies.

Crisis communications is a subset of the overall public relations function used to inform internal and external parties of the proceedings of business emergencies. A crisis communications person or team often prepares for a variety of business emergencies through prewritten press releases and prepared remarks that can be tailored for each event. Crisis communications often establishes relationships with internal and external parties such as investor relations, public safety, and news media. Policy related to crisis management and crisis communications should define the personnel authorized to communicate with external parties. But even then, an organization’s top executives may often be required to approve individual external communications.

Communications in the Incident Response Plan

Communications procedures, including identifying the specific parties to be involved in incident communications, should be sufficiently detailed so that incident responders will know precisely who to inform, what to say (and not say), and how often to communicate. Personnel doing the communicating, as well as personnel receiving communication, need to understand the serious and sensitive nature of incident communications and limit communications to the fewest possible personnel.

Limiting Communications to Few Authorized Persons

Few security incidents should be discussed organization-wide. Rather, communications about an incident should involve the fewest possible numbers of personnel. Each of those persons needs to understand explicitly any obligations regarding the need to keep the lid on news and details about a security incident.

Regulatory Requirements

Internal secrecy must be balanced with regulatory requirements for reporting security incidents to regulators and affected parties. Organizations must have a detailed understanding of regulatory requirements and proceed accordingly. However, security leaders and incident responders must determine how to describe incidents without providing details that could enable other attackers to understand specific weaknesses that could be exploited in further attacks.

Law Enforcement Proceedings

Organizations sometimes choose to involve local, regional, or national law enforcement when an incident occurs. Law enforcement organizations can be outstanding business partners in these situations, sometimes making cyber-incident experts available to help the organization understand what happened. It is a good practice to determine the key points of contact for various agencies with which your organization is most likely to interact during an incident. This helps ensure that lines of communications are already established, which can shorten the time for an agency to engage with the organization.

Often, a law enforcement organization will request that the organization refrain from publicly disclosing details about the incident, sometimes requiring that the organization say nothing to the public. This is understandable, particularly if the law enforcement agency is attempting to identify the perpetrator(s) in the incident to apprehend and charge them with a crime. In these cases, organizations must keep detailed records so that all members of the incident response team know what information is known about the incident, what has been communicated with law enforcement, and what has been communicated publicly.

Shaping Public Opinion

Experienced cybersecurity professionals often recognize good and bad examples of organizations’ handling security breaches. Better organizations quickly acknowledge a security incident and provide useful information to affected parties and the public. Other organizations handle these matters poorly, either with outright denial, whitewashing, or by minimizing the scope or impact of an incident, disclosing it gradually when forced.

Organizations need to be keenly aware of how their announcements and updates of a security incident will be interpreted. For instance, “There is no evidence of actual data exfiltration,” is often code for “We don’t have logging turned on, so if the attacker stole data, we have no way of knowing one way or the other.” Such a statement can be damning and difficult to undo.

Incident Response Metrics and Reporting

Incident response recordkeeping is critical to the success of the incident response function. Proceedings of individual incidents must be recorded to facilitate activities such as the post-incident review (aka after-action review) and to permit the creation of accurate metrics and reporting. Access to such information must be limited to few authorized personnel.

Recordkeeping

Typical incident response plans often direct that all proceedings of incident response be recorded, so that post-incident activities can be informed by the steps taken during the incident. This recordkeeping should include e-mails, notifications, decisions, artifacts, reports, and virtually everything connected with the incident.

A standard, consistent methodology for recording incidents facilitates future research by making specific types of information easier to find. For instance, if MITRE ATT&CK is used to analyze malware, a folder called “Mitre” containing this information could be created for each incident.

Organizations must identify a secure, reliable data storage system for storing information about each incident. Access should be granted to the fewest numbers of personnel possible, as some of this information is highly sensitive and could help future attackers by revealing the organization’s architecture and defenses. The chosen repository should support the chain of custody or a separate storage technique used when a chain of custody is needed.

Organizations that utilize ticketing systems often prefer to record the proceedings of a security incident in the ticketing system. Although this may be a favored solution, many ticketing systems’ contents are viewable by numerous personnel. If a ticketing system is used, it should have a way of marking tickets containing incident information as private or restricted, so that only the fewest number of authorized personnel can view notes and artifacts. When access to those tickets cannot be restricted or controlled, a different repository should be selected.

In addition to developing repositories to contain details about each incident, organizations also need to produce and maintain an incident log, which serves as a master index that contains all security incidents that have occurred in the past. The log may be a simple worksheet or database containing information such as the following:

•   Incident number

•   Incident date

•   Incident name

•   Short description

•   Incident context and severity

•   URL or other pointer to the repository containing incident details

Access to the incident log should be restricted to few personnel on a need-to-know basis.

Metrics

An organization’s security incident response program can be managed and improved only to the extent that key metrics are established to measure the program’s performance. Metrics that can be developed and reported include the following:

•   Number of incidents of each incident severity and type

•   Dwell time (time from the start of the incident to the time the organization became aware of the incident)

•   Time required to contain the incident

•   Time required to resolve and close each incident

•   Number of times incident response SLAs were not met

•   Improvements identified and implemented based on tabletop exercises and lessons learned from actual incidents

•   Number or percentage of employees receiving security awareness training, as well as any correlation between this and the number of incidents

•   Number of records compromised

•   Number of external people affected and notified

•   Total cost and effort required to resolve each incident

Reporting

Like any management report, the information security manager must identify target audiences and tailor reporting for those audiences based on the types of information of interest to them. Reports may include metrics, key risk indicators (KRIs), and key performance indicators (KPIs) that help management better understand whether the incident response program is effective at detecting and responding to incidents.

For instance, security incident reporting for a board of directors may contain a list of significant incidents (if any), as well as metrics showing the trends of incidents over time. This reporting should inform the audience of basic facts, including:

•   Whether the numbers of incidents are increasing or decreasing over time

•   Whether the effort and cost of incident response is increasing or decreasing over time

•   Whether any significant incidents have occurred, including any requiring regulator or public disclosure

•   What measures are planned to improve detection and response

Security leaders need to be able to explain trends to senior executives. For instance, an increase in the number of security incidents does not necessarily mean that defenses are deteriorating; instead, the number of attacks may be increasing or the ability to detect attacks is improving.

Incident Eradication, and Recovery

In security incident response, the threat agent, whatever or whomever it is or was, is contained so that it can advance no further. Next, the incident response team needs to understand what must be done to remove or eradicate the threat, enabling the organization to recover the system to its pre-incident state.

Incident Eradication

Eradication is the complete removal of the agent(s) that caused harm in an incident. To remove threat agents successfully, the security incident response team must be confident in the containment steps performed earlier. Depending on the nature of the incident, this may involve the removal of physical subjects from a work center or information processing center or the removal of malware from one or more affected systems.

Modern malware and intrusion techniques can be difficult to identify and even more difficult to remove. Malware can have characteristics or employ techniques that make it more resilient, including the following:

•   Hiding within legitimate processes

•   Fileless malware

•   Antiforensics techniques such as encryption, steganography, file wiping, and trail obfuscation

•   Hiding data in memory, slack space, bad blocks, hidden partitions, or the registry

•   Hiding “below” the operating system in the master boot record, in a virtual machine hypervisor, or the system’s Basic Input/Output System (BIOS) or unified extensible firmware interface (UEFI)

The personnel who examine infected systems must have up-to-date skills and experience to identify and remove malware and other attack artifacts.

While targeted eradication can be effective, it is often time-consuming. However, as confidence in complete eradication is not always high, incident responders may take an opposite approach by completely rebuilding the asset from scratch using techniques such as the following:

•   Resetting the system or device to its factory-installed state

•   Performing a bare-metal restore from a known-clean pre-incident image or backup

•   Replacing storage media with factory new media

To succeed, incident responders must be confident and be able to confirm that their eradication results in the complete removal of the malware.

Incident Recovery

The recovery phase of security incident response focuses on restoring affected systems and assets to their pre-incident state. Recovery is performed after eradication is completed; this means that any malware or other tools used by the intruder have been removed. The state of a system entering the recovery phase is described as free of all tools, files, and agents used by the intruder. There are two basic approaches to recovery:

•   Restoration of damaged files   In this approach, incident responders have a high degree of certainty that all artifacts used by the intruder have been removed from the system. While this is a valid approach, it does come with some risk, as it may be difficult to determine positively that all components used by the intruder are, in fact, removed.

•   Bare-metal restore   In this approach, all information is removed from the system and recovered from backup. Typically, this involves reformatting main storage. Incident responders need to be aware of advanced techniques attackers use, including persistence in the computer’s BIOS, in UEFI, or hidden main storage partitions. Further, if systems being restored are virtual machines, personnel must determine that new virtual machine images are free of infection.

In some situations, a single operation such as bare-metal restore may function as both eradication and recovery. However, incident responders should not necessarily prefer such a measure to save time; instead, eradication and recovery measures should be chosen based on their effectiveness. Malware cannot be permitted to persist in any circumstance.

Incident Remediation

I stated that recovery is the action of returning a system or asset to its pre-incident state, but you must understand a slight, but critical, nuance: we don’t want to restore the system to its exact pre-incident state, but to a state where the system functions as before the incident, but with one or more immediate safeguards to prevent recurrence of the same or similar attack. This is where recovery leads to remediation. Incident responders understand that the intruder may not be satisfied that he was eradicated from target systems. If any of the same vulnerabilities still exist, the intruder may attempt to re-establish a foothold to resume the intrusion in support of its original objective.

A critical step in incident response is remediation of any vulnerabilities exploited during the incident. This includes but is not limited to technical vulnerabilities that may have permitted malware exploits to work; it also includes any supporting technologies, business processes, or personnel training that may have helped to prevent the incident from occurring if they had been in place before the incident. For instance, if an end user’s system was successfully attacked with ransomware because that system’s endpoint detection and response (EDR) solution was not installed or functioning correctly, remediation of the system will include steps to ensure that the EDR is working correctly.

A key part of the investigation into the security incident must include an identification and detailed analysis of the factors or vulnerabilities that led to the incident’s occurrence. The key question that incident responders and investigators should ask is what weakness(s) permitted the attack or intrusion to succeed, and what should be done to the system to prevent the same or similar attack from succeeding in the future? In this context, remediation is more about fixing whatever was broken that permitted the attack or intrusion, rather than re-engineering overall defenses. The latter is generally addressed in a post-incident review that includes recommendations for long-term improvements.

A broader issue of learning from the incident is addressed later, in the section “Post-incident Review.”

Post-incident Review Practices

After the affected systems and devices have been eradicated of their attack artifacts and recovered to normal use, incident response moves into a post-incident phase. Incident responders and other key security and IT personnel will close the active portion of incident response and begin discussions that will hopefully lead to the generation of ideas to improve defenses and response.

Closure

After an incident has been identified, its causes eradicated, and any affected systems remediated and recovered, the incident can be closed. Mainly this is a “back to business as usual” declaration. Some activities are necessary for full closure:

•   Archival of forensic evidence   All information and records obtained through forensic analysis must be archived. The chain of custody must continue, however, should any legal proceedings occur in the future.

•   Archival of communications records   Copies of internal communications and notifications sent to outside parties need to be preserved.

•   Notification to internal personnel and outside authorities   All personnel and outside authorities who have been notified of the incident need to be informed that the incident has been closed.

•   Report issuance   Formal reports are produced for internal and external audiences that describe the incident and all of the steps of detection, response, eradication, remediation, and recovery.

The preceding information should be packaged and stored in a protected system with strict access controls. These technical details require protection because they could be used to exploit the organization in the future.

Post-incident Review

When all incident response proceedings have concluded, the organization should consider reviewing the incident that has taken place. A post-incident review should include a frank, open discussion that identifies what went well during the incident response and what could have been handled or performed better. A typical post-incident review should cover the following:

•   Incident awareness   Determine whether the organization realized quickly enough that an incident was occurring.

•   Internal communications   Determine whether internal communications were well organized, the right personnel were involved, and the right information was shared with the appropriate parties.

•   External communications   Determine whether external communications were well organized, including communications with regulators, law enforcement, customers, insurance companies, and the public.

•   Response procedures   Determine whether incident response personnel acted quickly, decisively, and correctly.

•   Knowledge and training   Determine whether incident responders had sufficient experience to perform their tasks effectively.

•   Resilience   The organization examines its environment, including both technology and business processes, to discover opportunities to improve the organization’s resilience. This can help the organization better defend itself in the future through the reduction in incident probability and reduced impact.

Security organizations should always operate with a culture of continuous improvement. In this regard, reviewing every aspect of a recent security incident should seek to identify improvements that will enable the organization to be better prepared when another incident occurs.

Some organizations bring in an expert third party to facilitate post-incident review to minimize emotional response from incident response team members. A third-party facilitator can help the organization avoid any tendency to identify scapegoats, to focus instead on the response itself and potential improvements to detective, preventive, and response controls and procedures.

Chapter Review

Security incident management, disaster recovery planning, and business continuity planning all support a central objective: resilience and rapid recovery when disruptive events occur.

As a result of a security incident event, the confidentiality, integrity, or availability of information or information systems has been or is in danger of being compromised. Although important, the condition of information systems is a secondary concern. Human safety is always the top priority when any disaster event has occurred.

The phases of incident response are planning, detection, initiation, analysis, containment, eradication, recovery, remediation, closure, and post-incident review. Planning consists of the development of incident response policies, roles and responsibilities, procedures, as well as testing and training.

Security incident response requires incident detection capabilities that enable an organization to be aware of an incident as it occurs. Without incident detection capabilities, an organization may not know about an intrusion for many weeks or months, if ever. A primary capability in incident response is event visibility, which is usually provided through a security information and event management (SIEM) system.

Many organizations outsource security event monitoring to a third-party managed security services provider. Organizations also often outsource incident response to security professional services firms by purchasing an incident response retainer, a prepaid arrangement. Remember that outsourcing the activity does not mean that the organization transfers the risk or responsibility of the incident response program or its impact on the business.

With the proliferation of outsourcing to cloud-based service providers, many security incidents now occur on systems managed by a third-party provider. This requires additional planning and coordination on the part of the organization, so that incident response involving a third party is effective. The organization may need to incorporate the third party’s incident response plan into its existing plan.

Business continuity planning and disaster recovery planning work together to ensure the survival of an organization during and after a natural or human-made disaster.

Notes

•   Developing custom playbooks that address specific types of security incidents will ensure a more rapid and effective response to a security incident. High-velocity incidents such as data wipers and ransomware require a rapid, almost automatic response.

•   Organizations must be careful to understand all of the terms and exclusions in any cyber-incident insurance policy to ensure that no exclusions would result in denial of benefits after an incident.

•   With so many organizations using cloud-based services, organizations must understand, in detail, their roles and responsibilities and that of each cloud service provider. This is necessary for the organization to build effective incident response should an incident occur at a cloud-based service provider.

•   Threat hunting and cyber-threat intelligence can help an organization more effectively anticipate and detect an incident as it unfolds. This helps reduce potentially damaging effects through prevention.

•   Many organizations outsource the forensic examination and analysis portion of security incident response, because personnel with these skills are difficult to find and the tools required are expensive.

•   When responding to a security incident, organizations should consider establishing attorney–client privilege and chain of custody early on, in case disciplinary or legal proceedings may follow.

Questions

1.   The types of incident response plan testing are:

A.   Document review, walk-through, and simulation

B.   Document review and simulation

C.   Document review, walk-through, simulation, parallel test, and cutover test

D.   Document review, walk-through, and cutover test

2.   The length of time between incident occurrence and incident detection is known as:

A.   Dwell time

B.   Lag time

C.   Lead time

D.   Propagation

3.   The purpose of attorney–client privilege during an investigation is:

A.   To improve the results of the investigation

B.   To obtain better forensic examination services

C.   To protect investigation proceedings from a discovery order

D.   To improve the integrity of investigation proceedings

4.   The purpose of chain of custody procedures is:

A.   To prove the ownership of investigation data

B.   To determine the cause of an incident

C.   To prove the integrity of investigation data

D.   To determine who is responsible for an incident

5.   An organization has developed its first-ever business continuity plan. Which of the following is the best first choice to test of the continuity plan that the business should perform?

A.   Walk-through

B.   Simulation

C.   Parallel test

D.   Cutover test

6.   An organization is experiencing a ransomware attack that is damaging critical data. What is the best course of action?

A.   Security incident response

B.   Security incident response followed by business continuity plan

C.   Concurrent security incident response and business continuity plan

D.   Business continuity plan

7.   An organization has just experienced a major earthquake at its operations center. Which of the following should be the organization’s top priority?

A.   Ensure that an automatic failure to the recovery site will occur as personnel may be slow to respond.

B.   Ensure that visitors and personnel know how to evacuate the premises and are aware of the location of sheltering areas.

C.   Ensure that data replication to a recovery site has been working properly.

D.   Ensure that backup media will be available at the recovery site.

8.   The purpose of a SIEM is:

A.   To centrally log event data

B.   To correlate events and generate alerts

C.   To track remediation of known vulnerabilities

D.   To scan systems and devices for new vulnerabilities

9.   An organization lacks personnel and tools to conduct forensic analysis. What is the best way for the organization to acquire this capability?

A.   Purchase advanced antimalware tools.

B.   Purchase a SIEM.

C.   Purchase an incident response retainer.

D.   Hire a full-time computer forensics specialist.

10.   An organization wants to protect itself from the effects of a ransomware attack. What is the best data protection approach?

A.   Periodically scan data for malware.

B.   Replicate data to a cloud-based storage provider.

C.   Replicate data to a secondary storage system.

D.   Back up data to offline media.

11.   Security personnel are conducting forensic analysis concerning the malicious wrongdoing of a former employee. How should the proceedings of the forensic analysis be protected?

A.   Backup to write-once media

B.   Double locked

C.   Chain of custody

D.   Role-based access control

12.   An incident responder has declared a security incident, prompting the mobilization by other incident responders and notification to senior management. Later, the responders determined that no security incident was taking place. What is the best course of action?

A.   Train the incident responder who declared the incident.

B.   Discipline the incident responder who declared the incident.

C.   Stand down and cease incident response activities.

D.   Continue with incident response until its conclusion.

13.   An organization has detected a ransomware attack that has destroyed information on several end-user workstations and is now destroying information on a central file server. Incident responders have taken the file server offline. What action should the organization take next?

A.   Inform the organization that the file server is unavailable.

B.   Stop incident response procedures and activate business continuity and disaster recovery plans.

C.   Wait until the security incident is over, and then activate business continuity and disaster recovery plans.

D.   Activate business continuity and disaster recovery plans to be performed concurrently.

14.   An organization currently stores its backup media in a cabinet next to the computers being backed up. A consultant advised that the organization should store backup media at an offsite storage facility. What risk did the consultant most likely have in mind when making this recommendation?

A.   A disaster that damages computer systems can also damage backup media.

B.   Backup media rotation may result in loss of data backed up several weeks in the past.

C.   Corruption of online data will require rapid data recovery from off-site storage.

D.   Physical controls at the data processing site are insufficient.

15.   An organization with a cyber-insurance policy detected an active ransomware attack. What should be the organization’s top priority?

A.   Contain and close the incident, and then notify the cyber-insurance company.

B.   Immediately notify the cyber-insurance company of the attack.

C.   Notify the cyber-insurance company if the organization pays the ransom.

D.   Activate a chain of custody to product the organization from the cyber-insurance company.

Answers

1.   A. The types of security incident response plan testing are document review, walk-through, and simulation. Parallel and cutover tests are not part of security incident response planning or testing and are used for disaster recovery planning.

2.   A. Dwell time refers to the period between the occurrence of a security incident and the organization’s awareness of the incident.

3.   C. The purpose of attorney–client privilege is the protection of correspondence and exhibits, including those in an investigation. If an organization that has experienced a security incident believes it may be defending itself in a lawsuit, the organization can choose to protect its investigation (including actions performed by a third-party firm) and its proceedings so that the organization will not be required to turn over that information during the lawsuit.

4.   C. The purpose of chain of custody procedures is to demonstrate the integrity of the investigation—namely, that no information has been altered, including the contents of any computer memory and hard drives.

5.   A. The best choice of tests for a first-time business continuity plan is a document review or a walk-through. Because this is a first-time plan, none of the other tests is the best first choice.

6.   C. If a ransomware incident has damaged an organization’s critical data, it should invoke its business continuity plan alongside its security incident response plan. This may help the organization restore services to its customers more quickly.

7.   B. Human safety is always the top priority when any disaster event has occurred. Although important, the condition of information systems is a secondary concern.

8.   B. A SIEM is a central event log processing system that correlates events among various devices. It produces alerts that may represent intrusions and other types of security incidents.

9.   C. An organization lacking personnel and tools to conduct computer forensics should purchase an incident response retainer. With a retainer, forensics experts are available on-call to respond to an incident. Although an organization can consider hiring one or more people with these skills, a job search can take several months, and people with these skills command high salaries.

10.   D. The best approach for protecting data from a high-velocity attack such as ransomware is to back up the data to offline media that end users cannot access. Replicating data to another storage system may only serve to replicate damaged data to the secondary storage system, making recovery more difficult or expensive.

11.   C. The results from a forensic investigation, particularly in cases in which legal proceedings are possible, should be protected through a chain of custody. In this example, the organization may believe that the former employee is considering filing a lawsuit.

12.   C. If a security incident is declared and personnel realize that no incident is actually taking place, incident response activities may cease. An after-action review may be warranted to identify any improvements in declaration procedures to reduce the likelihood of false positives in the future.

13.   D. The organization should immediately activate business continuity and disaster recovery plans, so that the organization can quickly resume critical business operations and recover the affected server as soon as possible.

14.   A. The primary reason for employing offsite backup media storage is to mitigate the effects of a disaster that could otherwise destroy computer systems and their backup media.

15.   B. The organization should notify the cyber-insurance company right away. Often, cyber-insurance companies will assist their policyholders only if they are notified of an attack immediately.