Incident response is
|“||[t]he documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of a malicious cyber attack against an organization's IT system(s).||”|
|“||[t]he activities that address the short-term, direct effects of an incident and may also support short-term recovery.||”|
|“||[t]he actions taken to protect and restore the normal operational conditions of an information system and the information stored in it when a cybersecurity incident occurs.||”|
The concept of incident response existed long before industrial control systems (ICS) or computers. The idea is based on preparing for and responding to unforeseen, negative events that may affect a business or organization. The cause of an incident may be unintentional, as in the case of a storm or flood, or intentional, as in the case of an intruder or vandal that breaks into a facility and steals or damages equipment or supplies. Regardless of the cause, it always has been a good practice to prepare for and appropriately respond to negative events affecting the organization. For years, industry has created contingency plans for events that have negative impacts on critical equipment or operations. For example, most asset owners have preventative maintenance programs, emergency backup power, and standby equipment. Only recently, however, incidents related directly to cyber threats have faced asset owners.
Effective practices for incident response include:
- preparation of incident responses for those types of incidents to which the firm is most likely to be subject, e.g., loss of customer PII, data corruption, DDoS attack, network intrusion, customer account intrusion or malware infection;
- incorporation of current threat intelligence to identify the most common incident types and attack vectors;
- containment and mitigation strategies for multiple incident types;
- eradication and recovery plans for systems and data;
- investigation and damage assessment processes;
- preparation of communication/notification plans for outreach to relevant stakeholders, e.g., customers, regulators, law enforcement, intelligence agencies, industry information-sharing bodies;
- involvement in industrywide, and firm-specific simulation exercises as appropriate to the role and scale of a firm's business; and
- implementation of measures to maintain client confidence, including:
Computer security incident response has become an important component of information technology (IT) programs. Security-related threats have become not only more numerous and diverse but also more damaging and disruptive. New types of security-related incidents emerge frequently. Preventative activities based on the results of risk assessments can lower the number of incidents, but not all incidents can be prevented. An incident response capability is therefore necessary for rapidly detecting incidents, minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring computing services.
To that end, NIST Special Publication 800-61 provides guidelines for development and initiation of an incident handling program, particularly for analyzing incident-related data and determining the appropriate response to each incident. The guidelines can be followed independently of particular hardware platforms, operating systems, protocols, or applications. As part of the authorization process the system security plan will have documented all of the “IR” or Incident Response family of controls.
As represented in Figure 1: incident response is a continually improving process.
Figure 1: Incident response life cycle
One of the most important parts of incident response is also the most often omitted — learning and improving. Each incident response team should evolve to reflect new threats, improved technology, and lessons learned. Many organizations have found that holding a “lessons learned” meeting with all involved parties after a major incident, and periodically after lesser incidents, is extremely helpful in improving security measures and the incident handling process itself. This meeting provides a chance to achieve closure with respect to an incident by reviewing what occurred, what was done to intervene, and how well intervention worked.