Incident Response

The actions taken by a utility to prepare for cyberattacks are incident response. This includes creating plans for response, rehearsing the response prior to an attack, continuous monitoring to identify attacks, and the actual response.

Even the most sophisticated defenses can be breached by attackers with sufficient skills and resources. When that happens, the incident will be much worse if the defenders have not planned and rehearsed a strategy for responding. The actions taken by an organization to prepare for and respond to a cyberattack constitute incident response.

Importance

Responding to a cyber incident is a complicated, sensitive process. Even in the best circumstances, the time following an attack will be chaotic as staff struggle to understand what has happened, why it happened, the impact on the business, and the best way to restore business functions. Utilities should prepare their responses in advance; otherwise, the cyberattack will likely last longer and do more damage as utility staff scramble to formulate an ad hoc response. Proactively preparing for an attack through planning, training, and rehearsal will reduce the chaos and the impact of the attack.

Although this incident response building block is written with a utility focus, it applies equally to government agencies, private businesses, nonprofits, and others. Every type of organization can benefit from incident response planning when the inevitable attack materializes.

Intersections With Other Building Blocks

The organizational security policy building block defines some key objectives for the incident response effort and answer some key questions. What are the roles and responsibilities associated with incident response? Which department is responsible for planning the organization’s incident response? Who has the authority to initiate an incident response? What resources are available for incident response? With whom does the organization share data about the attack? The answers to these questions will inform the organization’s incident response plan.

Figure 9. Information passed to the incident response building block

Depending on the organization, it may make sense to include only the highest-level details regarding incident response in the organizational security policy and capture lower-level details in a separate incident response policy, which can then be updated more frequently. At the very least, the organizational security policy should include a statement of commitment from management and a description of the organizational structure that will support incident response.

Processes and Actions

The items below are adapted and abridged from The Computer Security Incident Handling Guide, which expands on each of the elements presented. The Guide recommends creating incident response policy, plan, and procedures documents and lists the elements that should go into each. The policy is the most strategic of the three, while the procedures document is the most tactical. Small utilities or those just beginning to address incident response may combine these into a single document, with sections focusing on policy, planning, and procedures.

In preparation for creating these documents, the utility will need to gather or create the following information:

A list of all applicable laws, regulations, and standards related to incident response and applicable to the utility. Whatever actions are indicated by these laws, regulations, and standards must be included in incident response documents. This will vary between countries. Utilities must include not only laws, regulations, and standards specific to the utility sector but also laws, regulations, and standards that address privacy, consumer protection, and related topics. The regulatory agencies themselves should provide useful information on these topics.
Definition of terms related to incident response, as they will be used in the incident response documents. For instance, a utility may choose to define a cybersecurity “incident” according to its own particular criteria.
A mapping of the utility’s departments and offices to the roles, responsibilities, and levels of authority they will have in incident response. For instance, who within the utility has the authority to disconnect equipment if it is suspected of being compromised?
Prioritization of incidents by potential impact on the utility
A communication plan for incident response that covers communication both internal to the utility and to other organizations (e.g., the media, customers, software vendors, law enforcement, and organizations that track CTI).
Specific checklists, forms, and processes that will be used during incident response (for instance, the procedure for preserving infected hard drives for later forensic analysis).

The utility must identify the tools that it will use to identify cyber incidents, such as IDS, antivirus software, and log analyzers. These will be covered in the technical controls building block.

The incident response documents should cover four phases:

Creating the incident response policy, plan, and procedures document(s); rehearsing the plan and improving it based on lessons learned; collecting all hardware and software (backup drives, forensic tools, printers, etc.) needed to execute the incident response; and determining the best location where incident responders can work.
Detection and Analysis. Monitoring IDS, system logs, and/or antivirus software for indicators of compromise; once a suspected incident is detected, verifying the incident and triggering the response process; correlating the indicators of compromise with other observations about the network, devices, and systems in operation; investigating the cause and potential impacts of the cyber incident to formulate the best response.
Containment, Eradication, and Selecting and executing strategies for containment (activities that stop the cyberattack from spreading to other devices or systems), eradication (the process of removing malware from the system), and recovery (the process of returning the system to normal functioning).
Post-Incident Activity. Gathering lessons learned from the incident, improving the process of incident response, and reviewing data about incidents that help to identify weaknesses in security defenses that may need to be addressed.

Details can be found in Computer Security Incident Handling Guide.

Essential Data

Utilities seeking to create or amend an incident response plan should collect the following information:

A list of all applicable laws, regulations, and standards related to incident response
The phone tree/contract tree that utility employees will use to alert each other when an incident has been declared
A list of outside parties with which the utility will want to communicate during an incident response. These may include media, customers, software vendors, law enforcement agencies, and internet service providers.
Records of software licenses
Locations of backup data and systems and procedures for restoring from backup
Location of equipment and tools that will be used during incident response

Incident Response Terminology
An incident or computer security incident is “a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices” (Cichonski et al. 2012).
The term event is sometimes used interchangeably with incident. However, event is a broader term that encompasses anything that can be observed on the system (e.g., a user sending an email). Events may or may not have a negative impact. Incidents have negative impact (Harris and Maymi 2016).

Additional Resources and References

Harris, Shon, and Fernando Maymi. 2016. CISSP All-in-One Exam Guide 7th ed. New York: McGraw Hill Education.