What is an incident response plan
An incident response plan is a documented, systematic process that defines how your organization should deal with a cybersecurity incident. There are two common frameworks you can use to create an incident response plan, the 6-Step SANS Incident Response Process and the 7-Step NIST Incident Response Process.
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
- Data theft
- 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
Cynet 360 is a security solution that includes a complete Endpoint Protection Platform (EPP), including Next-Generation Antivirus (NGAV), device firewall, advanced EDR security capabilities and automated incident response. The Cynet solution goes beyond endpoint protection, offering network analytics, UEBA and deception technology.
Cynet’s platform includes:
- NGAV—blocks malware, exploits, LOLBins, Macros, malicious scripts, and other known and unknown malicious payloads.
- Zero-day protection—uses User and Entity Behavior Analytics (UEBA) to detect suspicious activity and block unknown threats.
- Monitoring and control—asset management, endpoint vulnerability assessments and application control, with auditing, logging and monitoring.
- Response orchestration—automated playbooks and remote manual action for remediating endpoints, networks and user accounts affected by an attack.
- Deception technology—lures attackers to a supposedly vulnerable honeypot, mitigating damage and gathering useful intelligence about attack techniques.
- Network analytics—identifying lateral movement, suspicious connections and unusual logins.
Learn more about the Cynet 360 security platform.