Cydarm playbook library
This article provides examples of playbooks which you can install into your Cydarm instance.
Overview
Playbooks are a great way to embed your operational processes within Cydarm.
A set of sample playbooks for you to use can be downloaded here: Cydarm playbooks
Playbook details
Checklists
These are checklist-style playbooks using the ATC format, with a linear progression between steps.
| Name | Description |
| Advanced Persistent Threat (P01) | An Advanced, Persistent Threat (APT) is a threat group that has significant technical and operational capability, typically is well funded, and is prepared expend significant time and effort to achieve its objectives. They will have clearly defined objectives and strategies. They could be foreign intelligence, state affiliated groups tasked by foreign states, or sophisticated organised crime groups. |
| High Risk, Actively Exploited Vulnerability (P02) | A playbook for when there is a high risk (eg Remote, unauthenticated, code execution) vulnerability, there is actual, or imminent, exploitation activity, and it is possible that the affected software/systems exist inside our environment |
| Phishing email (P03) | Respond to credential harvesting email campaigns. |
| Public facing application exploited (P04) | This playbook is for when a public facing application has been exploited by a threat actor. |
| Vulnerability Management Assurance (P05) | Assess identified vulnerabilities and determine action in line with organisational Vulnerability Management Policy. |
| Risk Assessment (P06) | Assess the severity of the incident, in line with Risk Management Framework principles. |
| Lessons Learnt (P07) | It is important to capture lessons learnt after an incident has concluded, to capture learnings and feed these back into processes and control improvements. |
| SMS Phishing (P08) | Instructions on how to respond to SMS phishing reports from users. Typically these will be targeted towards personal accounts of users, such as internet banking, toll providers or utilities. |
| Potential data breach (P09) | If an incident potentially involves the loss of, or unauthorised access to personal information, then it must be assessed to determine if it is an eligible data breach under the Australian Privacy Act 1988 (Cth). |
| Threat Intel Report Workflow (P10) | Process for assessing, reviewing and actioning Cyber Threat Intelligence reports. |
| Investigate suspicious inbox rule (P11) | Investigate potentially suspicious inbox rules created on user mailboxes. |
| CPS234 Cyber Security Incident Notification (P12) | The Australian Prudential Regulatory Authority (APRA) regulates financial services organisations in Australia. Prudential Standard CPS 234 Section 35 dictates requirements to notify APRA in the event of a cyber security incident that meets certain criteria. |
| Investigate suspicious login alert (P14) | Investigate various suspicious login alerts generated by identity systems and applications. The objective is to determine whether it is a false positive or benign event, or a true positive security event that requires further action. |
| Compromised user account (P15) | Investigate various suspicious login alerts generated by identity systems and applications. The objective is to determine whether it is a false positive or benign event, or a true positive security event that requires further action. |
| AI Data Leak and Unauthorised AI Tool Usage (P20) | Respond to incidents where internal users (staff or contractors) upload corporate or personal information to external, public generative AI tools (such as public ChatGPT, Gemini, Claude.ai, Copilot consumer tiers, or similar) without authorisation. |
| Internal AI Infrastructure Compromise (P21) | Respond to security incidents where an organisation's private, hosted AI framework has been breached or manipulated by an attacker. This covers managed LLM platforms such as Azure AI Foundry and AWS Bedrock, as well as self-hosted model-serving infrastructure and the applications, agents and data pipelines built on top of them. |
CACAO
These playbooks are in OASIS CACAO format and use dependencies, parallels, and conditional branching to more strictly specify the order of actions.
| Name | Description |
|
Account and Identity Reconnaissance Alerts (CACAO-1) |
Investigate account and identity reconnaissance-related alerts to determine if they are false positives or actual security incidents. |
|
Authentication and Access Alerts (CACAO-2) |
Investigate authentication and access-related alerts to determine if they are false positives or actual security incidents. |
|
Threat Response - Generic SOP (CACAO-3) |
Generic SOP for threat response where no playbook currently exists. |
|
Threat Modelling Engagement (CACAO-4) |
Process for conducting a Threat Modelling engagement. |
|
Threat Hunting - Zero Day (CACAO-5) |
Triggered from joint action advisories on active/evolving threats, Cyber Threat Intelligence, social media, the internet, and 3rd-party advisories. |
|
Vulnerability Management (CACAO-6) |
Assess identified vulnerabilities and determine action per the Department's Vulnerability Assessment Process, Patching/Vulnerability Management Standard, and Risk Management Framework. Covers vendor advisories, open-source vuln intel, pen testing, red team, bug bounties, responsible disclosure, etc. |
|
Zero day vulnerability (CACAO-7) |
For a high-risk vulnerability (e.g. remote unauthenticated code execution) - zero-day or with unapplied patches/mitigations - where exploitation is actual or imminent and affected software/systems may exist in the environment (e.g. Log4J, Citrix Netscaler, Exchange ProxyShell). |
|
Threat intel report distribution (CACAO-8) |
Triage threat intelligence reports, extract actionable intel and distribute to relevant audiences. |
|
Analyst Review of Account Alert (CACAO-9) |
Triage a monitored-account alert: extract alert and account details, have an analyst review for false positives, and escalate to the SOC when indicators of infrastructure compromise are found. |
|
Calculate IOC Risk Score (CACAO-10) |
Evaluate an IOC by identifying affected hosts, collecting local enrichment, and computing mission and vulnerability risk scores, then attaching the results back to the case. |
|
Create Submitter Behavior Profile (CACAO-11) |
Build and finalize a behavioral profile for a STIX submitter, recording true/false-positive history and publishing the profile object to a TAXII feed. |
|
Curate Incoming STIX Messages (CACAO-12) |
Review incoming STIX submissions against behavior analytics, mark false positives, update submitter profiles, and publish validated objects to the TIP/TAXII server. |
|
CVE Patch Testing (CACAO-13) |
Identify assets needing a patch from vulnerability scans, stand up test machines, and coordinate SOC/NOC review and execution of a matching mitigation strategy. |
|
Domain IOC Response Ex1 (CACAO-14) |
Respond to a domain IOC: run a reputation check, apply analyst judgement, and block or whitelist the domain with business justification before closing the case. |
|
ICS Asset Integrity Check (CACAO-15) |
Determine the required integrity checks for an ICS asset by type, run them via operator-approved response, and escalate if any checks fail. |
|
ICS Asset Mitigation (CACAO-16) |
Mitigate a compromised ICS asset by quarantining, re-imaging via config management, or migrating operations to a hot spare under operator approval. |
|
ICS Asset Recovery (CACAO-17) |
Restore an ICS asset using stored restoration workflows, verify functionality, notify the operator, and document the incident and recovery in the daily digest. |
|
Monitor Threat Feed Ingest (CACAO-18) |
Poll the TIP for new records each interval, compare record counts against a failure threshold, and raise a ticket for threat intel/NOC if a feed failure is suspected. |
|
Parse Email (CACAO-19) |
Parse a reported email for IP IOCs, enrich them from local sources, determine which IPs were affected, and generate response tickets and events. |
|
Patch Systems for CVE (CACAO-20) |
Deploy patches per policy across affected systems, verify rollout via vulnerability scan, and update configuration management to confirm the CVE is addressed. |
|
Process ICS Alert (CACAO-21) |
Handle a SIEM alert from the ICS network: gather alert data, identify the related asset, and route an actionable alert to an operator while logging to the daily digest. |
|
Process Incoming CVE (CACAO-22) |
Extract CVE data and severity, check whether the affected software exists and is already addressed, set priority, and create tickets to remediate or update config management. |
|
Process Internal FW Alert (CACAO-23) |
Process a firewall alert on internal traffic, collect supporting system data when thresholds are met, and flag the system for monitoring or COA review. |
|
Process Internal IDS Alert (CACAO-24) |
Process an IDS alert on internal traffic, collect supporting system data when thresholds are met, and flag the system for monitoring or COA review. |
|
Process Service Heartbeat Failure (CACAO-25) |
Investigate a SIEM heartbeat alert by pinging and connecting to the server, verifying service availability, and migrating to a hot spare or marking a false positive. |
|
Rebuild Server (CACAO-26) |
Rebuild a failed server via config management, modify and restore network access, verify service availability, and escalate to SOC/service owner on failure. |
|
Reinstall Service (CACAO-27) |
Reinstall a failed service via config management after service-owner approval, verify restoration, and escalate to SOC/service owner if it fails. |
|
Remediate Systems (CACAO-28) |
Review remediation, obtain SOC approval, remove quarantine and restore systems (manually if needed), and raise a ticket when restoration fails. |
|
Removable Media Alert (CACAO-29) |
Triage a removable-media SIEM alert by extracting the username and checking directory group membership to confirm whether the user is permitted such media. |
|
Remove False Positive STIX Object (CACAO-30) |
Delete a confirmed false-positive STIX object from the TIP, update the submitter profile, and flag it for re-baselining when a threshold is met. |
|
Response to Domain IOC Ex2 (CACAO-31) |
Respond to a domain IOC by checking proxy logs and visit counts, tagging the repository, contacting the IT group, and updating/closing the case. |
|
Response to Domain IOC Ex3 (CACAO-32) |
Automated domain-IOC handling: check SIEM visits and firewall whitelist, push the domain to a consolidated block list via Python, and notify the SOC by digest email. |
|
Response to Domain IOC Ex4 (CACAO-33) |
Respond to a URL/domain container: check SIEM prevalence and FW block list, let analysts choose to act, block on the firewall, and send an end-of-day digest. |
|
Response to Email IOC Ex1 (CACAO-34) |
Respond to an email IOC by checking matching emails, filtering the sender against block/spam lists based on IOC score, and documenting actions in the case. |
|
Response to Email IOC Ex2 (CACAO-35) |
Respond to an email IOC via analyst inspection and orchestrator investigation, adding the sender to the content filter if not already present, then closing the case. |
|
Response to Email IOC Ex3 (CACAO-36) |
Automated email-IOC handling: extract the sender, check the mail-server blacklist and local sightings, add to blacklist/digest, and hand a ticket to an analyst. |
|
Response to File Hash Ex1 (CACAO-37) |
Respond to a file-hash IOC with a reputation check and analyst inspection, then create an alert rule and update the case with business justification. |
|
Response to File Hash IOC Ex3 (CACAO-38) |
Automated file-hash handling: check local allow/block lists, submit to VirusTotal, add to the blacklist/digest, and hand a draft ticket to an analyst. |
|
Response to File Hash IOC Ex4 (CACAO-39) |
Respond to a file-hash IOC by querying FW/network tools for prevalence, identifying affected systems/users from logs, blocking the hash, and notifying server/endpoint teams. |
|
Response to IP IOC Ex1 (CACAO-40) |
Respond to an IP IOC with a reputation check and analyst judgement, querying local data sources and blocking the IP with business justification before closing. |
|
Response to IP IOC Ex3 (CACAO-41) |
Automated IP-IOC handling: check firewall allow/block lists and agency assignments, push to a consolidated block list at SOC-designated times, and notify by digest. |
|
Review Submitted IDS Rules (CACAO-42) |
Route a submitted IDS rule for SOC analyst review and, once approved, upload the new rule to the IDS before closing the ticket. |
|
Rogue System Detected (CACAO-43) |
Respond to a rogue-system SIEM alert by confirming quarantine, raising a high-priority SOC ticket, and blocking or excepting the MAC on the NAC based on review. |
|
Select Heartbeat Failure (CACAO-44) |
Triage a service heartbeat failure: investigate, select a COA, restart the service, and notify the SOC and service owner of server/service status. |
|
Share Event Information (CACAO-45) |
Extract event data, IOCs, and COAs from a case, obtain threat-intel approval, format into a STIX bundle, and publish to the TAXII server. |
|
Suspicious Email Submission Triage (CACAO-46) |
Triage a submitted suspicious email: extract URLs and attachments, compare against allow/block lists, detonate files, and build a consolidated IOC list. |
|
System COA Alert Review (CACAO-47) |
Gather system and alert information for a COA review ticket, have the SOC select IOCs for blocking and execute additional tasks, then share information per policy. |
|
Threat Enrichment (CACAO-48) |
Enrich a domain IOC via reputation lookups and local searches across domains, endpoints, and users, format results as JSON, and ticket them to an analyst. |
|
Verify CVE Patch Testing (CACAO-49) |
Wait for automated patch tests to complete, update SOC/NOC tickets with results, and have both teams review the risk and patch policy. |
Installation instructions
- You will need to have playbook editor permission group attached to your account to install playbooks on your stack.
- Log into Cydarm and go to the Playbooks tab.
- Click on the Upload Playbook or Action button.

- For CACAO branching playbooks, simply select one or more files ending in .cacao.json and click upload.
- For ATC branching playbooks:
- Go to the location where you unzipped the files, and go into the Actions directory. Select all files and click upload.

- Again, click on the Upload Playbook or Action button.
- Go to the Playbooks directory in the unzipped file contents. Select all files and click upload.

- Go to the location where you unzipped the files, and go into the Actions directory. Select all files and click upload.
The playbooks have now been installed to your stack.
Troubleshooting
- If a playbook or action file already exists with the same name, you will receive an error:

This might mean that you've already uploaded some of the actions or playbooks - If a playbook contains actions that are not present on your system, you will receive an error:

Check to make sure you have uploaded all action files first.
For more detailed technical information please refer to our Cydarm API documentation.