Maksim Kabakou - Fotolia
IR plans: The difference between disaster and recovery
What goes into a good incident response plan, and what steps should security professionals take to ensure they are appropriately prepared for the almost inevitable attack, and secure buy-in from organisational leadership?
The inevitability of an organisation being hit by a cyber attack has shot up in recent years, illustrated with frequent news reports of major businesses becoming victims of ransomware, data loss, and critical system downtime. It only takes one catastrophic blow to halt operations and cause significant financial, reputational, and legal repercussions.
An incident response policy provides guidelines to ensure a consistent and effective approach to the management of such breaches and ensures that the organisation complies with relevant laws and regulations.
Planning should consider the wide variety of potential incidents, such as environmental disasters, public transport strikes, and cyber security attacks. Understanding and assigning categories and priorities to events is essential to prevent a significant incident from going unnoticed because attention is diverted towards a relatively small issue elsewhere. This requires all relevant stakeholders to be involved – the information security, IT, compliance, public relations, and HR teams for example, as well as employees, and sometimes external security experts.
Frameworks, such as those from organisations including NIST and ITIL, can be used to help guide the creation of an incident response plan. Often, these consider the following steps.
- Detection and response: Identifying the initial incident and alerting the relevant teams requires the right monitoring for the systems in question, and an alert mechanism that will notify the right people. Including incident analysis will help with correct prioritisation of the event moving forward. When forming detection patterns, the entire end-to-end process should be considered, rather than isolated assets and specific technical exploits. Where possible, threat intelligence should be used to understand the most likely method of attack organisations are likely to experience.
- Mitigation: Once confirmed, the incident needs to be contained or eradicated to the best of the organisation’s ability. Ultimately this step is about stopping the spread of the after-effects of the incident.
- Reporting and notification: Clear steps for escalation and communication of the incident are required. Reports need to identify the internal and external parties to inform including senior management, corporate communications, employees and customers, as well as authorities (such as the police or fire department) and regulatory bodies. It is important to know under what circumstances each of these should be contacted, by who, and in what timeframe.
- Recovery and remediation: A successful mitigation and control of the initial event is followed by a focus on recovery, and a return to normal (or as close to normal as possible). The organisation needs to rebuild systems and applications that have been damaged, as well as validate the security of its new set up, and implement any necessary changes to prevent the event recurring. Ongoing issues need to be identified, monitored, and remediated.
- Lessons learned: A full review of the whole event and the actions taken includes noting what worked and what was less successful. It should also consider future preventions, carefully weighed up after the strain of dealing with the attack. Detailed and unambiguous documentation for everyone requiring visibility is important to prevent further damage, as well as for future reference.
Understanding priorities
Building out an incident response plan requires that priorities are outlined and agreed. After the non-negotiable safety of people, careful balancing may be needed. For example, securing of the incident scene, proper gathering of forensic evidence, and ongoing investigation are key, but can also delay the reinstating of business-as-usual (BAU) processes. Ensuring each activity is given the right weighting and that this is clearly laid out before an incident occurs ensures no key elements are reduced to spur-of-the-moment decisions during a crisis.
Testing the plan
A plan has little value if there is no proof that it is effective, running the risk that it crumbles at the first hurdle in the face of an emergency.
Testing the incident response plan is therefore one of the biggest keys to success. This identifies problem areas and ensures everyone knows their responsibilities; it also helps to iron out small but significant issues such as synchronising system clocks so that event logs match up for ease of investigation. In addition, it can highlight any gaps in employee training. Using a range of testing methods, from desktop scenarios to full simulations, helps to gauge the level of preparedness at different levels of the business.
Leadership buy-in
Proving the value of preparing for an event that may never happen means obtaining leadership buy-in and funding is often viewed as one of the toughest challenges of incident response planning.
Knowing the organisation’s assets, their value, and the impact in the event of their loss is a good place to start. It’s important to quantify potential costs, demonstrate that one incident may be all it takes to realise this loss, and flag that once an incident is underway, it is too late to start a plan to combat its ill effects.
Read more on this topic
- A ransomware incident response plan may be the difference between surviving an attack and shuttering operations. Read key planning steps, and download a free template to get started.
- The NCSC has added a level to its CIR programme to enable more cyber attack victims to take advantage of the service, which offers access to assured incident response specialists.
- The high-rolling city of Las Vegas experiences unique cyber security challenges rarely seen elsewhere. CIO Mike Sherwood reveals how he turned to Darktrace to help address incidents quicker and with confidence.
Illustrating the inevitable chaos of a security incident is often more effective than describing it. Engaging leadership teams in war-gaming scenarios is one option. Using a fictitious event and guiding them through a ‘mock’ incident response can help to increase understanding of the response process, the potential for significant loss, and the consequences of having no proper plan in place.
Flagging legislative and compliance obligations is also useful. Outlining directives that require the organisation to report an incident and its response, such as the NIS2 or DORA regulations in the European Union, can help to unlock funding from the board and C-Suite by highlighting the risk of even greater fines for non-compliance. These pieces of legislation can also provide a good basic framework of requirements for components such as ongoing testing or risk management.
Security culture
Incident identification may not always come from monitoring software – sometimes it can be an anomaly noticed by an employee. It is key to have organisation-wide mechanisms for the reporting of suspicious activities or mistakes, along with robust and engaging cyber security training, and a culture in which users know how (and why) to report an incident without fear of personal repercussions.
A combined approach
Building a robust risk and security programme offers preventative protection against threat actors infiltrating an organisation’s systems. But this should be combined with an in-depth and considered incident response plan - knowing what to do in the event of a successful breach or significant security incident can be the difference between full operational collapse and a successful recovery.
The Computer Weekly Security Think Tank on incident response
- Mike Gillespie, Advent IM: Incident response planning is vulnerable to legacy thinking.
- Sam Lascelles, PA Consulting: Use existing structures to build your incident response plan.
- Jack Chapman, Egress: Incident response planning requires constant testing.
