Incident Response Planning: it’s not optional!

Understanding and developing an Incident Response plan is critical for an effective resolution to security breaches

An effective IR plan is the best way to ensure an incident is handled quickly. To use an old military term ‘prior preparation prevents poor performance’ - if a plan is made ahead of time, when an incident occurs, you can react quickly, saving time and money. This is borne out in the Ponemon Institute’s 2020 Cost of a Data Breach Report which highlighted the average cost of a breach for organizations with a regularly-tested IR plan was USD 3.29 million, compared to USD 5.29 million for organizations that did not.

Understanding what to do when an incident occurs and who to talk to is critical for an effective response. So, how best to set up an IR plan?

1. Gap assessment

Ensure all the appropriate questions have been asked and the information to identify systems, services, business owners, etc. has been reviewed. If an IR plan is already in place, the gap assessment will establish if the plan is fit for purpose, identify gaps and benchmark results. This is something we manage for our clients with our Cybersecurity Advisory Service.

2. Design IR plan

This is based on the evidence gathered from the gap assessment. The business requirements drive the mission statement and objectives for the IR plan, as they would for a Disaster Recovery plan, and the IR plan should have similar executive ownership.

 An Incident Response plan creator – or creators – designing a plan, either on a computer, or creating a board of ideas. Image caption: The Incident Response plan is driven by business requirements and gathered data.

3. Write IR plan

Write the IR plan in line with business objectives, with an overarching methodology for incident response. Two key ones are:

NIST (Computer Security Incident Handling Guide SP 800-61)	SANS Incident Handling Framework
Preparation	Preparation
Detection & Analysis	Identification
Containment, Eradication & Recovery	Containment
	Eradication
	Recovery
Post-Incident Activity	Lessons Learnt

Table 1: IR Frameworks

These frameworks are broken down differently but ultimately deal with incidents in the same procedural fashion. The vast majority of the elements for an IR plan will be defined in the preparation phase:

• Team structure
  • Breakdown of the team responsible for day-to-day incident handling processes, including external teams.
• Roles and responsibilities
  • Must be very clearly stated so all members of the team are aware of where they fit into the overall plan and what’s expected.
• Definitions
  • States what an incident is, when the organization will trigger a major incident, as well as the other key terms associated with the IR plan.
• Priority matrix
  • What constitutes a low to critical incident? Broken down into specific areas, e.g. users, criticality, device, attack type and systems affected. Scoring is conducted against each area, helping calculate the incident’s severity.
• Incident workflows
  • Define activities to be undertaken by each team during an incident. Align the workflow against a general IR plan, with bespoke elements added in the form of runbooks for specific threats. Details the escalation paths and breakout to external procedures.
• Escalations
  • Define escalation paths against set criteria. There are many reasons for escalation, such as additional skills or external assistance required and these should all be detailed so that staff working the incident know who to call on when required.
• Communication
  
  • Ensures team members are aware of how they should be communicating. If the organization’s network has been compromised, a separate communications channel should be invoked i.e. not email! Other elements of the communication plan should align with the Traffic Light Protocol so the incident can be classified accordingly and only authorized staff are briefed.
• Evidence controls
  • All evidence should be stored and processed as if it were to go to court. Any security information and event management systems (SIEMs) used should be designed with this in mind, and any additional information captured must follow the correct chain of evidence as defined.
• Key documentation
  
  • This includes all other information pertinent to the IR plan:
    • Organizational chart
    • Critical assets, data and services list
    • Network diagrams
    • Data flow diagrams
    • Ingress/egress points
    • Business Continuity Plan
    • Disaster Recovery Plan
    • IR playbooks for common attack types
    • Chain of custody form
    • Incident questionnaire
    • Contact information for law enforcement
    • On-call/handover roster
    • Compliance/regulatory body requirements
    • Standard Operating Procedures

Future elements of the plan will follow a similar workflow, but more granular, so to assist analysts with their investigations and offer guidance. Example:

Step No.	Actions
Step 3	Does the mitigation strategy involve disconnecting operational resources?  YES – Work with the affected area department head, or designee to determine risk to the business. NO – Go to Step 5.
Step 4	Did the decision-maker approve of disconnecting or shutting down the resource? YES – Go to Step 5. NO – Use alternative containment strategy: •  Live response activities •  Firewall filters •  Kill suspicious services •   Apply patches
Step 5	Secure critical information, before shutting the system down including: • Volatile memory data • Packet capture • Live collection of relevant artefacts

Table 2: Workflow Charts

The IR plan should detail the actions which must be conducted on resolution of an incident, such as analysis, lessons learned, and reporting. Further details on this can be found in my earlier blog, The Calm After the Storm.  

Your incident response plan must be tested and reviewed to ensure all team members are responding appropriately.

Testing is critical

Most critically: test your plan. Why do all this work if your team isn’t aware of how to respond in an emergency?

We test fire evacuation plans and incident response shouldn’t be any different. Ideally, the tests would be hosted by external organizations that create test scenarios and review the plan to ensure all team members are responding appropriately. This external team can then identify any gaps and provide additional assistance and training where required. Our Digital Forensics and Incident Response Service can support you in this, providing you with a prioritized, actionable security roadmap to optimize your existing controls and determine if new ones are needed.

There are free resources available to create your IR plan, but it is a very specialist area. It’s critical to review the organizations that are out there to guarantee your IR plan is effective and aligned to your business needs. If you don’t currently have an incident response plan in place, don’t delay – your future self will appreciate it.