Upgrading Cybersecurity with Incident Response Playbooks
In this article, we’ll explain the concept of an incident response playbook and the role it plays in an incident response plan and outline how you can create one. We’ll also touch on common use cases for incident response playbooks and provide examples of automated security playbooks. Read on to learn about incident response playbooks and how they can help you achieve a higher level of cybersecurity.
Both of these have the following steps in common. The incident response plan should define:
Preparation—what should be done before an incident occurs
Identification—how to identify a real security incident
Containment—immediate steps to stop the incident and prevent further damage
Eradication—ensuring the root cause of the attack is removed from your systems
Recovery—recovering affected systems and bringing them back online
Lessons learned—learning from an actual incident to respond better to future incidents
What is an incident response playbook
You must keep your incident response plan simple, to ensure staff can understand it and take the required actions under the extreme pressure of an actual cyberattack. To simplify the plan and ensure staff can take action quickly, many teams add incident security playbooks for specific incident scenarios.
A playbook can take two forms:
Manual incident response process—traditionally, a playbook was a printed guide that provides step-by-step instructions for an incident response team in a specific situation. Who is in charge, who to call, and what to do.
Automated incident response process—today there are technology solutions that can help automate security playbooks. A security solution that integrates with the relevant systems—such as email servers, endpoints, or firewalls—can run a script that executes the playbook automatically. So that when an incident occurs, a complete response can be executed immediately with no human intervention.
A manual playbook is a list of steps, which can easily be converted to an automated process or script. This is why incident response playbooks are a bridge between a traditional manual incident response process to an automated process.
How to create an incident response playbook
An incident response playbook is made up of the following building blocks:
Initiating condition—an event that signifies an actual or suspected security incident, which should trigger the incident response process.
Mandatory steps—these are the practical steps you must go through in order to contain the incident. They can include analysis and triage, locking down or quarantining systems, resetting passwords, setting firewall rules, and notifying affected parties.
Best practices—activities that can be performed in addition to the mandatory steps. These can be guidelines for carrying out the process more effectively, or additional measures that can help contain and eradicate the incident more comprehensively.
End state—the desired goal of the playbook, given the initiating condition. When this state is met, the playbook process stops.
To create a playbook:
Start by identifying an initiating condition and end state, which can be identified clearly and unequivocally, using existing data or security tools.
List out all the possible steps you envision an incident response team may perform in order to identify and investigate the incident and bring it to closure.
Separate the practical steps into “mandatory steps” and “best practices” which are nice to have but optional.
Create a core process using only the mandatory steps.
Group the best practices and identify where they can fit in as part of the core process.
For reference, list regulatory requirements or standards that the playbook should comply with.
Common scenarios for incident response playbooks
Here are a few scenarios for which you should consider building an incident response playbook, whether manual or automatic:
A malware infection
A ransomware attack
A phishing attack
Distributed Denial of Service (DDoS)
Escalation of privileges
Examples of Automated Security Playbooks
Here is how an automated security system can carry out an automated playbook to respond to specific incidents.
Anomalous Login Attempt
Initiating condition: A security system identifies a login attempt that violates a rule or appears to be anomalous, based on behavioral analysis
Mandatory steps: User account disabled and alert sent to security staff
Best practices: Check access and usage patterns by the same user in the past three months
Initiating condition: Active trojan identified on a host in the local network.
Mandatory steps: Isolate the host from the network and quarantine it. Attempt to remove the threat via automated scan.
Best practices: Perform a manual test to ensure the system does not have additional malware, and check for similar malware elsewhere on the same subnet.
Endpoint Protection—Prevention, Detection and Protection with Cynet 360