How to Build an Incident Response Playbook from Scratch

Just under half of small and medium-sized businesses say a $100,000 cybersecurity incident could lead to bankruptcy. But what makes this fact particularly concerning is that attacks against SMBs typically cost between $120,000 and $1.24 million to recover from. The implications here are obvious and sobering, to say the least.

Fortunately, the best solution is simply to be prepared. Specifically, having ready-and-tested incident response playbooks to buttress your recovery effort makes all the difference.

This is why we’re here today. We aim to provide SMB leaders with practical advice, clear direction, and expert insight for building bulletproof IR playbooks. Rather than one-size-fits-all guidance, this piece is geared toward small organizations with fewer resources and expertise at their disposal.

‍

Why an Incident Response Playbook Is Important

Let’s think of a cyber incident response playbook in terms of handling a fire. Guided by a sound playbook, your team would already know their roles, emergency exits, extinguisher locations, and protocols to contain the blaze. Oppositely, no playbook, to use a pun, leads to everyone running like their hair’s on fire.

One point of confusion to clear up before going further is the difference between an incident response policy, plan, and playbook.

Incident Response Policy vs. Incident Response Plan vs. Incident Response Playbook

·       A policy broadly defines the organization’s overall expectations and responsibilities for handling security incidents.

·       The incident response plan turns those expectations into a structured outline for managing an incident from detection through recovery.

·       Playbooks provide step-by-step instructions for responding to specific types of incidents, such as ransomware, phishing, DDoS, or insider threats.

Therefore, IR playbooks are important because they offer incident-specific guidelines to follow rather than broad-stroke ideas.

The Key Elements of an Incident Response Playbook

Given enough time and effort, virtually any network connected to the Internet can be infiltrated. Knowing this, forward-looking leaders don’t mope but choose to prioritize putting the right people, processes, and technology in place beforehand.

For this section, we’ll highlight the core elements to consider when building your IR playbooks.

Incident Detection and Reporting

Most blogs will tell you that incident detection and reporting start with SIEMs, EDRs, and SOARs. However, for a lot of small business leaders, this jargon makes their eyes glaze over. While these solutions certainly have their role, more often than not, at smaller organizations it’s the average employee who’ll be the first to notice something isn't right.

Build your playbooks around realistic incident detection and reporting mechanisms rather than purely relying on technology signals. For example, hyper-focus on employee cyber awareness so that suspicious emails and invoices are flagged before being processed. Also work closely with your bank’s fraud department so that you’re quickly notified of atypical activity.

What’s more, SMBs typically don’t take full advantage of existing detection capabilities built into the tools they already use. Microsoft 365, for instance, is chock-full with security features that can help with early detection.

Your goal isn’t to build the playbook that a Fortune 500 company would write, it’s to build the one that works for the business you run today.

Threat Triage and Classification

The purpose of triage and classification is to readily determine whether an alert is benign, suspicious, or a confirmed incident.

Traditionally, at larger organizations, they’d have a small army of L1 and L2 analysts who spend their entire working day scoring the torrents of alerts that stream in from a SIEM. More recently, low-level threat triage and classification are being handled by AI with a human in-the-loop for critical decisions.

This shift is beneficial for SMBs because it means the laborious, expensive part that traditionally required humans can now be automated. What AI can’t replace, however, is the decision at the end of the flag. An automated tool can tell you something looks off, but your playbook tells your team what happens next.

Roles and Responsibilities

During an incident, unclear ownership creates delay, unclear authority creates hesitation, and inconsistent communication creates avoidable damage. Whereas a large company might hire dedicated employees or a third-party firm to fill these positions, SMBs typically can’t. Instead, you can boil responsibilities down to four core roles:

·       Leadership provides oversight, funding, and executive decision-making throughout the response.

·       Incident handlers investigate, contain, and help recover from security incidents.

·       Public affairs / media relations coordinate all communications and media engagement when needed.

·       Legal ensures the response accounts for relevant laws, regulations, privacy requirements, and contractual obligations.

Containment Procedures

Containment is the first critical pillar in the incident handling portion of IR. Alongside eradication and recovery, it forms the bridge between an organization being under active attack and getting back to business.

Here we should note that the best playbooks make an important distinction between isolation and containment. While the two are closely related, they serve different purposes.

Red Canary writes, “think of isolation as an automated function that is set to execute based on a specific trigger. This allows for minimizing potential damage to an endpoint without compromising the overall network operations.”

Meanwhile, containment “involves more manual processes, where network operations or other situated personnel take actions such as changing VLAN communication or disabling user accounts to stop the spread of malware or other malicious activity.”

Eradication and Recovery

Once the incident is contained and better understood, the next step is to discover and eradicate the root cause of the issues. Sometimes this is simple and straightforward; other times it’s not.

Take Maersk as a fine example of the latter. After stealing domain admin credentials from an aging server that was set for an upgrade, a group called NotPetya was able to target the shipping giant with a devastatingly quick and wide-sweeping ransomware attack that saw some 55,000 devices infected within just seven minutes.

While this alone would be enough to induce a mirage for any stakeholders involved, to make matters worse, all 150 of Maersk’s domain controllers were also impacted. These were the very servers the security team needed to attempt their recovery effort.

But here’s the kicker, the company’s recovery strategy was comprehensive enough that they could’ve recovered most of the impacted infrastructure using healthy backups. The problem was they didn't account for all their mission critical domain controllers being impacted.

Because of this, eradication and recovery were exorbitantly complex, requiring a complete infrastructure teardown and rebuilding that cost an estimated $10 billion.

Maersk’s experience represents an extreme version of what can happen when eradication and recovery become more complicated than expected. For an SMB, the stakes may be smaller, but the mechanics are largely the same.

Post-Incident Analysis

After an incident, the natural impulse for some people is to point the finger at the person who clicked the link, missed the alert, failed to apply the patch, etc. This approach is counterproductive as it never makes the business safer.

Cybersecurity experts agree that a post-incident analysis should be a blameless undertaking. Instead of pointing out individual errors, it’s better when the goal is to uncover systemic and process failures through a review that “reconstructs a precise timeline of the attack and the response, identifies the root causes of the breach and any failures in the defensive controls, and produces a prioritized set of concrete action items.”

NIST provides a deeper dive into best practices of post-incident analysis here.

When Is an Incident Response Playbook Useful?

Throughout the monumental business and technology transformation that coincided with the Internet boom of the 1990s to early 2000s, organizations were, by and large, focused on breach prevention. Nowadays, given the state of our modern threat landscape, mature organizations are less focused on the idea of 100% prevention and more so on the reality that breaches will occur.

Planning for effective incident response and resilience is therefore the best way forward. The idea is not the total elimination of all risks, but shrinking the damage when risk becomes real.

Any SMB with a small or nonexistent IT security team has the most to gain from well-planned IR playbooks. This is because, when done right, IR playbooks turn panic into a predictable sequence of steps by removing emotions and pre-authorizing important decisions.