Playbooks planning overview
This section maps SOAR features to a step-by-step playbook design process.
Creating a playbook involves a set of incident types, phases, tasks, fields, workflows, scripts and rules to respond to an incident through intelligence, automation, and orchestration. Before you create a playbook, you need to understand your organization’s policies for responding to events.
- NIST Special Publication 800-61R2 (August 2012), Computer Security Incident Handling Guide
- Verizon’s VERIS Framework, Vocabulary for Event Recording and Incident Sharing
- Department of Defense CJCSM 6510.01B (18DEC14), Cyber Incident Handling Program
Before you start, familiarize yourself with the various tools and capabilities of the SOAR Platform as described in SOAR playbook toolkit. Afterward, use the provided configuration procedures to create your playbook.
SOAR playbooks planning approach
- Categorize your events. Use the Incident Type feature to organize your events into categories.
- Map your response progression. Use the Phases features.
- Define your manual intervention responses. Use the Tasks feature.
- Design the “look and feel,” including how you choose to organize your data. Use the Incident Layouts, Fields, and Data Tables features.
- Define your decision-making process. Use the Playbooks and Scripts features. For those use cases not covered by Playbooks, use Rules, Workflows, and Scripts instead.
- Automate information gathering and decision making. Use Threat Services and Functions features, and deploy apps appropriate for your environment.
- Test your playbook. Use the Simulations feature.
SOAR for MSSPs add-on and playbooks
The SOAR for MSSPs add-on is a feature that you use to manage multiple SOAR child organizations from a single configuration organization. Each child organization can be assigned to a different group, division, or company to meet their incident response requirements.
- Without the MSSP add-on, you create playbooks, rules, and workflows within each SOAR organization for that organization. With the MSSP add-on, you create those components in the configuration organization, which is then pushed to every child organization.
- When you create playbooks, be careful to not use names or other information that cannot be shared with every child organization. All playbooks are pushed at to all child organizations. Additionally, if you delete any input field in a sub-playbook or remove a sub-playbook from a playbook then push the configuration, any running instances of that playbook are canceled.
- When you create a rules and workflows-based playbook, design a “global playbook” that meets your service requirements. Then, add any rules, workflows, scripts, or other objects to meet the customer-specific requirements of each child organization.
For more information, see the MSSP Add-On Configuration Guide.