Incident Response Planning and Preparation

Why every organisation needs an incident response plan and what to include in your IR plan

Incident response planning has always been an important part of mature cyber security programs, but its significance has become much clearer in recent years, with more and more businesses acknowledging the inevitability of data breaches.

Security experts agree that no matter how sophisticated an organisation’s threat prevention and detection technologies are, advanced threats can and will still get through, and attacks will still occur. The wisest course of action, then, is to have a well-defined plan in place for when they do.

What is a cyber incident?

The National Institute of Standards and Technology (NIST) defines an incident as "an occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits... "

Why having an Incident Response (IR) plan is important

Having a plan and preparing in advance for cyber incidents helps organisations respond quickly, efficiently and in a streamlined manner when an attack is detected. Being purposeful and proactive when an incident occurs can reduce stress for all stakeholders and make the recovery process smoother than it would be with a purely reactive approach.

A concrete IR plan facilitates systematic and consistent incident handling
It minimises response and recovery time, and limits the damage a cyberattack causes
A well-defined plan also reduces stress for the IR team and helps business executives make better decisions during a crisis situation
It spells out the value and business need for better attack preparedness and helps get decision makers on board
With response steps laid out clearly in a plan, businesses can address the legal issues arising out of the incident with more clarity and confidence
Having an IR plan is also often required by government security policies and regulations

Existing IR Frameworks

A number of organisations use popular incident response frameworks like the SANS Institute's 6-step IR process, or the National Institute of Standards and Technology’s (NIST) 4-step framework, to guide their IR plan and process. The SANS Framework includes the following six steps: Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned. NIST’s framework is similar, except that it clubs together Containment, Eradication and Recovery in a single step.

Some larger organisations have their own IR processes and internal frameworks and policies. Others use one of the existing frameworks as a base and add to it based on their specific business needs.

Ultimately, creating an internal IR plan (whether it is based on an existing framework or is specific to an organisation), implementing it, and continually improving it – all contribute to effective incident handling.

The IR plan can't be a wishlist - it needs to be logically constructed and actionable

While creating a plan, organisations must take into account what they can realistically do during an attack and align the response steps to their existing processes and technology. Being too focused on a particular framework sometimes prevents organisations from properly assessing their own internal capabilities before constructing a plan.

To fill any internal gaps, they must get help from managed security providers, incident response services, and local law enforcement - the plan must include contact details for all entities that can provide support during the response process.

Verizon’s last Incident Preparedness and Response Report, based on three years (2016-2018) of IR plan assessments, found that while most (79 percent) organisations surveyed had IR plans in place, “fewer than half (48 percent) had a logically constructed, efficient IR Plan”. Only 16 percent of the plans fully specified (evidence) collection and analysis procedures, 57 percent did not fully provide third-party contact procedures, and 38 percent cited no legal or regulatory requirements for cyber security, incident response or data breach notification.

The following section lists some of the components that organisations with mature IR plans typically include. Bear in mind that different organisations’ IR plans can vary significantly based on factors like compliance requirements, industry, financial capacity, resources available, and business needs.

Components of an Incident Response plan

Planning and Preparation

Introduction, mission and goals - An effective plan must include the IR mission and how it ties in with the organization’s larger mission. The purpose of the document must be clearly explained for the IT and business teams to understand its criticality and value.
Roles and responsibilities - Roles and responsibilities should specify what each member of the IR team will be responsible for when an incident occurs. The team itself should be cross-functional, meaning it must include not just security analysts and technical responders, but also, at the least, a communication specialist to communicate with different stakeholders including leadership, the IT and networking teams, the media, and law enforcement; business executives for high-level decision making; a legal team; and third-party vendors or managed security providers for security expertise not available internally.
Communication processes - A communication tree should specify how and what kind of information about the incident is to be shared internally and externally, and at what stages of the response lifecycle.
Breach notification list and process – The plan must clearly define the process to notify affected customers, partners and third parties, in addition to informing law enforcement, as determined by the compliance standards applicable to the organisation.
Emergency contacts – Everyone in the IR team should know whom to contact if internal resources aren’t enough (which they often aren’t) to handle an incident. These could be government agencies, cyber security service providers, consultants, vendors or legal counsel.
Documentation and Reporting – A process must be laid out for documenting each step of the detection, investigation, response and recovery stages.
Evaluation metrics to measure incident response effectiveness
Inventory of critical assets to be tracked and monitored
Plan reviews - An IR plan can only be truly effective if it is periodically reviewed, tested, improved and updated to include steps for addressing new threats and attack vectors and incorporating lessons learned from past incidents. This review process must also be a part of the plan.
Table-top exercise schedule – Additionally, the IRP should include a schedule / frequency to conduct red-team or table-top exercises to sharpen the skills of the team, identify and fill gaps, and improve attack preparedness.
Regulatory requirements for response processes and incident notifications.
Incident classification – The IR plan must contain a list of incident types, and playbooks for how each type of incident is to be handled. There will be different sets of steps to be followed, for instance, for a ransomware attack, a DDoS attack, and a supply chain attack.
Tools to be used at different stages of incident response

Detection and Investigation

Detection - Threat detection tools and technologies to cover both endpoints and networks, and detection processes, including alert handling, triage and escalation procedures.
Event assessment - The means to be used to assign event status to alerts and incident status to events. Not all events that are detected will need deeper investigation and a proper incident response process to resolve. The criteria to assign incident status to an event must be clearly defined in the IR plan. Different organisations may have different methods to make this assessment
Investigation and severity assignment - Once identified, the incident will need to be investigated using standardised workflows and playbooks for different kinds of incidents. This may include looking for the initial access point, systems affected, users compromised, and determining the end goal of the attacker. Investigation, along with the previous step, will also determine the severity of the incident.
Preservation - The response plan must also include all the steps to be taken to collect and preserve artifacts and logs related to the incident while maintaining the integrity of the data. These may potentially be used as evidence by law enforcement, and for deeper forensic investigation at a later time if necessary.

Containment and eradication

Containment - Containment steps form the core of the incident response process and must be described clearly for different kinds of incidents. Depending on the urgency and importance of a threat, containment may begin immediately after detection and happen alongside investigation. It usually refers to the immediate actions that can be taken to block the attacker’s access and stop the threat from spreading or causing more damage.
Eradication - After containment comes eradication, which includes all the steps to completely remove the infected files or malware from affected systems and bring the systems back to a sanitized state.
Recovery steps - These are the steps to be taken to return affected devices and apps to a pre-compromise state and resuming business operations if the incident caused disruption to operations. The recovery process may also include doing a final vulnerability scan to confirm all threats have been removed.

Post-recovery steps

Finally, the IR plan should lay out post-recovery steps focused on reviewing the effectiveness of the plan and lessons learned after an incident. This must be a formal exercise and the lessons learned from each incident should be documented and incorporated in the plan in the form of updated procedures.

---------------------------

Conclusion

While this is by no means an exhaustive list of everything to be included in an IR Plan, it does touch upon the key areas that are important to consider (but not necessarily include) when creating a plan. To reiterate a point we made earlier, there is, as there should be, considerable variation in different organisations’ IR plans. Different companies have different levels of risk tolerance and are vulnerable to different kinds of threats based on their business models, industry verticals and a host of other factors. Their plans, therefore, must also address their specific needs.

In future posts about incident response, we will talk about Security Orchestration, Automation and Response (SOAR), and Incident Response in the context of Managed Detection and Response (MDR).