CACAO playbooks user guide
CACAO (Collaborative Automated Course of Action Operations) playbooks enable you to define, visualise, and execute structured incident response workflows in Cydarm.
Overview
What are CACAO playbooks?
Unlike linear checklists, CACAO playbooks support branching logic, parallel execution, and automated actions to handle complex security scenarios.
CACAO playbooks are visual workflow templates that guide analysts through incident response procedures. They support:
-
Branching Logic: Make decisions based on conditions (if/then/else/switch)
-
Parallel Execution: Run multiple steps simultaneously
-
Automation: Trigger external actions automatically when steps are ready
-
Variable Tracking: Pass data between steps and track inputs/outputs
Key concepts
|
Term |
Description |
|---|---|
|
Playbook |
A reusable workflow template defining steps and their connections |
|
Step |
An individual node in the workflow (action, decision, etc.) |
|
Instance |
A running copy of a playbook attached to a specific case |
|
Variable |
Data that flows through the workflow (IPs, usernames, etc.) |
|
Automation |
External system integration triggered by step execution |
Playbook lifecycle
1. Draft stage
When you create a new playbook, it starts as a draft:
-
Drafts can be edited freely using the visual editor
-
Drafts are saved automatically as you work
-
Drafts cannot be added to cases
-
A "Draft" badge appears in the playbook list
2. Published stage
Publishing makes a playbook available for use:
-
Published playbooks can be added to cases
-
You can create new draft versions to make changes
-
Multiple versions can coexist (one published, multiple drafts)
3. Case instance
When a playbook is added to a case:
-
A new instance is created specific to that case
-
Step statuses are tracked independently
-
Variables are bound to case-specific values
-
Progress is saved and visible to all case participants
Creating a playbook
Step 1: Open the playbook editor
-
Navigate to Playbooks from the main menu
-
Click Create CACAO Playbook
-
The visual editor opens in a new view
Step 2: Start step
Every playbook needs a start step:
-
The editor creates a "Start" node automatically
-
This defines where execution begins
-
Connect subsequent steps from the Start node
Step 3: Add workflow steps
Drag steps from the palette onto the canvas:
|
Step Type |
Icon |
Purpose |
|---|---|---|
|
Action |
Rectangle |
A task for an analyst or automation to complete |
|
If-Condition |
Diamond |
Branch based on a true/false condition |
|
Switch |
Diamond |
Branch based on multiple possible values |
|
Parallel |
Parallel bars |
Execute multiple paths simultaneously |
|
End |
Circle |
Mark the end of a workflow path |
Step 4: Connect steps
-
Click and drag from a step's output connector
-
Drop onto another step's input connector
-
For conditional steps, connect each branch (true/false paths)
Step 5: Configure step properties
Click on any step to configure (noting that each step requires an "Agent" from the Agent Definitions)
-
Name: A descriptive title for the step
-
Description: Detailed instructions for the analyst
-
Condition (for decision steps): The logic to evaluate
-
Commands: Specific actions to perform
-
Variables: Input and output data mappings
Step 6: Save and publish
-
Click Save to preserve your draft
-
When ready, click Publish to make it available
-
The playbook appears in the list without the "Draft" badge
Step types explained
Action steps
Action steps represent work to be done:
Manual actions:
-
Display instructions for the analyst
-
Analyst marks complete when finished
-
Can include checklists, commands, or procedures
Automated actions:
-
Linked to a Triggered Automation
-
Execute automatically when the step becomes ready
-
Results feed back into the workflow
If-condition steps
Create two-way branches based on conditions:
Example: Check if IP is internal
├── True → Skip external lookup
└── False → Perform threat intel lookupCondition syntax:
-
Reference variables: __variable_name__:value
-
Comparisons: ==, !=, >, <
-
Example: __ip_address__:value == '192.168.1.1'
Switch steps
Create multi-way branches:
Example: Route by severity
├── Critical → Escalate immediately
├── High → Assign to senior analyst
├── Medium → Add to queue
└── Low → Auto-close with note
Parallel steps
Execute multiple paths simultaneously:
Example: Gather intel from multiple sources
├── Path 1 → Query VirusTotal
├── Path 2 → Query AbuseIPDB
├── Path 3 → Check internal blocklist
└── All complete → Correlate results
Working with variables
Variable types
|
Type |
Description |
Example |
|---|---|---|
|
String |
Text values |
IP addresses, usernames, file paths |
|
Timestamp |
Date/time values |
Incident start time, deadline |
|
Integer |
Numeric values |
Retry counts, thresholds |
Variable properties
-
Constant: Value is fixed and cannot be changed during execution
-
External: Value must be provided when the playbook is added to a case
Using variables in steps
Reference variables in conditions and commands:
Condition: __source_ip__:value != '0.0.0.0'
Command: Block IP address __source_ip__:value at firewall
Variable bindings
When adding a playbook to a case:
-
External variables prompt for values
-
Enter case-specific data (e.g., the suspicious IP being investigated)
-
Values are stored with the playbook instance
-
Variables can be updated as the workflow progresses
Adding automation to steps
What is step automation?
Automation connects playbook steps to external systems. When a step becomes "ready", Cydarm can automatically:
-
Query threat intelligence APIs
-
Create tickets in external systems
-
Send notifications
-
Execute scripts or commands
-
Update case data
Linking automation to a step
-
Open the playbook in the editor
-
Click on an Action step
-
In the properties panel, find Linked Automation
-
Click Add Automation or Edit Automation
-
Configure the Triggered Automation (see below)
Creating a triggered automation
Triggered Automations define what happens when a step is ready:
-
Navigate to Settings > Triggered Automations
-
Click Create Automation
-
Configure:
-
Name: Descriptive name for the automation
-
Event Type: Select "Playbook Action Ready"
-
Condition: Matches the specific step and playbook version
-
Operation: The action to perform (API call, webhook, etc.)
-
Automation condition format
The condition automatically matches the step:
action.uuid == "<uuid>" && action.version >= "1.0"This ensures the automation only triggers for:
-
The specific step (by UUID)
-
Compatible playbook versions (>= specified version)
Best practices
-
Test in isolation: Verify automations work before linking to playbooks
-
Handle failures: Configure appropriate failure responses
-
Logging: Enable logging to troubleshoot automation issues
Using playbooks in cases
Adding a playbook to a case
-
Open the case in Cydarm
-
Navigate to the Playbooks tab
-
Click Add Playbook
-
Select the playbook from the list (only published playbooks appear)
-
Fill in any required external variables
-
Click Add
Viewing playbook progress
The playbook visualisation shows:
-
Step status: Colour-coded by state (ready, in progress, complete, failed)
-
Current position: Highlighted active steps
-
Assignees: Who is responsible for each step
-
Variable values: Current data flowing through the workflow
Updating step status
Click on a step to update its status:
|
Status |
Meaning |
|---|---|
|
Blocked |
Cannot proceed (dependency issue) |
|
Ready |
Step is available to be worked |
|
In Progress |
Work has started |
|
Success |
Step completed successfully |
|
Failure |
Step failed (may trigger alternate path) |
|
Awaiting Input |
Waiting for external data or decision |
Assigning steps
-
Click on a step in the playbook view
-
Select Assign from the step menu
-
Choose a team member from the list
-
The assignee receives notification of the assignment
Adding tags to steps
Tags help categorise and filter step work:
-
Click on a step
-
Select Add Tag
-
Choose or create a tag
-
Tags appear on the step and in case activity
Managing playbooks
Editing a published playbook
-
Navigate to Playbooks
-
Find the playbook and click Edit
-
A new draft version is created
-
Make your changes in the editor
-
Publish when ready (creates a new version)
Deleting a playbook
-
Navigate to Playbooks
-
Find the playbook and click Delete
-
Confirm the deletion
Note: Deleting a playbook does not affect instances already attached to cases.
Viewing playbook history
Each playbook maintains version history:
-
View previous versions
-
Compare changes between versions
-
Revert to earlier versions if needed
Troubleshooting
1. Playbook not appearing in case add dialog
Cause: The playbook is still in draft status.
Solution: Open the playbook editor and click Publish.
2. Automation not triggering
Possible causes:
-
Automation condition doesn't match the step UUID
-
Version mismatch in condition
-
Automation is disabled
-
Connector or actuator not running
Solutions:
-
Verify the step UUID matches the automation condition
-
Check version compatibility (>= vs ==)
-
Ensure the automation is enabled in Settings
-
Verify actuators are running and connected
3. Step stuck in "Ready" status
Possible causes:
-
No assignee designated
-
Automation failed silently
-
Waiting for manual action
Solutions:
-
Assign the step to an analyst
-
Check automation logs for errors
-
Manually update status if automation failed
4. Variables not resolving
Possible causes:
-
Variable name mismatch
-
Variable not marked as external
-
Value not provided when adding playbook
Solutions:
-
Verify variable names match exactly (case-sensitive)
-
Check variable is marked external in playbook definition
-
Re-add the playbook and provide missing values
Best practices
Playbook design
-
Start simple: Begin with linear workflows, add complexity as needed
-
Use descriptive names: Clear step names help analysts understand the workflow
-
Document thoroughly: Include detailed descriptions and commands in each step
-
Plan for failure: Add error handling paths for critical steps
-
Reuse with sub-playbooks: Create modular playbooks for common procedures
Variable management
-
Name consistently: Use clear, descriptive variable names
-
Mark external appropriately: Only mark variables external if they need case-specific values
-
Use constants: For fixed values that shouldn't change during execution
-
Document variable purpose: Include descriptions for each variable
Automation
-
Test before linking: Verify automations work in isolation
-
Version appropriately: Use >= for forward compatibility
-
Monitor execution: Review automation logs regularly
-
Handle failures gracefully: Configure alternate paths for automation failures
Team collaboration
-
Assign owners: Designate playbook maintainers
-
Review before publishing: Have peers review playbook changes
-
Communicate changes: Notify team when playbooks are updated
-
Gather feedback: Improve playbooks based on analyst experience
FAQs
Q: Can I use the same playbook in multiple cases simultaneously?
A: Yes, each case gets its own independent instance of the playbook.
Q: What happens to running instances when I update a playbook?
A: Existing instances continue using their original version. New instances use the updated version.
Q: Can I duplicate a playbook?
A: Yes, use the duplicate function to create a copy that you can modify.
Q: How do I share playbooks between organisations?
A: Export the playbook as JSON and import it in the target organisation.
Q: Can automation update variables?
A: Yes, automation results can be mapped back to playbook variables.
Q: Is there a limit to playbook complexity?
A: There's no hard limit, but very complex playbooks may impact performance. Consider breaking into sub-playbooks.
Getting help
If you need assistance with CACAO playbooks:
-
Contact your organisation's Cydarm administrator
-
Submit a support ticket through the Cydarm support portal
-
Review the Cydarm knowledge base for additional guides
Last updated: January 2025