Ë
By Jason Wittick • November 21, 2017

Incident Response Plan 101

 

unnamed.png

Cyber-attack has become an inevitable threat. Although not always successful, a near constant onslaught of attacks keep pushing, probing, and penetrating digital defenses. It seems like regardless of a system’s size or how much diligence goes into preparing for or hardening against attack, no-one is safe.

Most attacks, and indeed most breaches are discovered after the fact … meaning security professionals have had to change their perspective from prevention to mitigation if they want to remain effective.

They are no longer concerned with whether or not a system will be attacked and breached, but when those attacks will come … and how to best respond quickly and efficiently. Assuming it has not happened already, does your IT team know what immediate steps to take during an attack or a breach incident? Do they know how to spot or classify and react or respond? If not … do they even know who to ask?

The Problem

It’s surprisingly common to hear that many small to mid-sized businesses have no established Incident Response Plans (IRP) whatsoever. A sobering and puzzling gamble considering that without one, if a breach occurs and intruders have penetrated their systems … responding to an incident would be little more than panic, chaos, and damage control - in that order.

Failing to prepare is preparing to fail, but developing a functional IRP does not have to be a drawn-out, time consuming, or complicated process. Once a plan exists, it must be tested and revised on a regular basis to keep it relevant and ensure it will help personnel to quickly recognize and respond to any type of compromise. Whether it’s an internal leak, a phishing attack, data or information theft, ransomware, or loss / theft of a device … cybercriminals have no bias towards their victims. A well-designed IRP ought to consist of likewise agnostic, adaptable, and simple instructions for dealing with any type of compromise … but response plans are for everyone. If it is too complex, it might not work when you really need it. 

The Solution

So, how do you start? Here are a few key considerations for developing a quality incident response plan:

1 - Identify Risk

To plan for a cyber-attack incident, organizations must first be aware of the different types of data they store and transmit to glean an understanding of why they might be a target for hackers. Next, they must familiarize themselves with known, potential vulnerabilities and evaluate whether they are applicable to their systems. Without knowing the risks, the probability of suffering a breach increases while the ability to quickly identify and recover from a breach decreases by directly inverse proportion.

2 - Build a Team

Everyone needs to know how to report a suspected incident, and to whom. If something unusual happens, do they call a helpdesk? The IT department? Floor manager? Or do they simply tell a coworker? Most successful organizations, just like a military, will rely on a chain of command to manage responsibility and a successful IRP is no different.

One popular IRP strategy is to train and assign an ‘incident manager’ who would be the first person to notify, and who would be specifically equipped to quickly and accurately initiate a response. Every response has to start somewhere, but an informed, focused, and capable team is critical for prompt, effective response.

3 - Define Communication Flow

During an incident, internal and external communication flows are the means by which actors and stakeholders stay informed. Communication flows should include IRP team members, management, a more general employee base, and typically provide facts about an ongoing incident to each distinct audience at an appropriate time.

Building a team and assigning a manager are good places to start developing a sound IRP, but if the inward flow of information about potential incidents is in any way restricted … none of that will matter. Consequently, if the outward flow of information goes unrestricted, misinformation and potentially reputation-damaging inaccuracies will threaten the integrity of an incident target, hinder or even delay response activities.

Well-prepared, timely, and carefully executed communication can be the difference between accolades from the public, the media, and colleagues, or them reading about yet another breach in negative headlines.

4 - Assess the Situation

Just like in a real-life emergency, time is of the essence, but accuracy is also important. A good IRP is adaptable above all else, and planned response mechanisms should begin before an incident has a chance to get out of control. An effective IRP will support teams and process that can accurately recognize emerging issues, inform the correct people to quickly determine source, severity, and ultimately decide on an appropriate, timely response.

Imagine an employee tells their supervisor that they are locked out of their computer and can’t access files, but their supervisor does not know what to do about it. A short time later, several more employees report the same issue and likewise can’t say for sure, but they suspect that maybe something is amiss. By that point, the supervisor would likely bring the issue to their superior, but it might already be too late as more and more workstations are affected. A ransom notice is eventually delivered that if left unpaid promises to destroy everyone’s data.

In a ransomware attack like this one, slow or inaccurate assessment in the first few minutes could be the difference between a massive, tragic compromise ... and a full recovery with subsequent success story.

5 - Draft and Test the IRP

Once an incident response team has been assembled, risks they face have been identified and understood, lines of communication are clearly defined, and everyone is prepared to spot and report suspected incidents … specific response strategies and mechanisms can be designed.

The actual response plans can start as a simple list of if / then statements for each identified risk. After the team has agreed on appropriate, specific response activities for each situation, the resultant plans should each be ‘tested’ or employed against an imagined incident to evaluate their efficacy, identify any gaps, and ensure the plan will function as intended.

6 - Review, Resolve and Reinforce

An IRP is more than just identifying potential or theoretical security events and recovering from them. Whether it’s after an attack or as a result of testing, once an incident has been resolved, as part of the IRP, a structured review process should begin. How did the incident happen? Could it have been prevented? What are the chances of it happening again?

Investigating an incident may lead to more questions than answers, but thorough analysis and proper assessment, investigation activities will help to guide and reinforce security efforts to help prevent future or repeated compromises.

There Will Be Lawyers

In any breach where personal information was compromised, there is a good chance that compliance and data security laws or regulations were either not followed or outright ignored. Ignorance and complacency are not excuses, and even if neither was the case and a breach were a legitimate and unexpected surprise ... response managers and team members need to be equipped with sufficient resources to properly service affected parties. Luckily, building close relationships with lawyers and law enforcement professionals is an easy means to that end.

Lawyers can not only inform management and response teams of potential legal issues, but they can also help to prepare any necessary public announcements. It is always preferable to control announcing incidents and breaches proactively, than to have a media outlet do it on your behalf. Getting to know law enforcement should also be a top priority, as local government within most major cities have established cybercrime divisions to help.

Researching the various legal resources available and, wherever possible, inviting them into your organization will only help to sharpen and improve any remediation when a breach occurs.