Today, threat actors are increasingly successful at utilizing automation to execute their attacks. More often than not, their success stems from collaboration with other skilled actors on the Dark Web, leveraging each other’s shared knowledge and toolkits. This collaboration over tactics, techniques, and procedures (TTPs) , as well as an overall increased investment in time and effort to achieve goals, has become an inherent part of attack planning due to defenders improving their security response. Defenders need to take a page out of the attacker’s book and start collaborating with one another as well.
Collaborating Towards a Common Goal
“This is an arms race. Attackers collaborate to achieve their goals. We need to do the same but better and faster than they can.” – Fortune 500 CISO
There are many examples where collaboration on threat intelligence, vulnerability disclosure, product security defects, and other areas has seen benefits for everyone involved. In some cases, there may be some ad hoc sharing across organizations and in other cases facilitated by CERTs, and industry organizations such as FIRST. However, the majority of organizations continue to invest in best-in-class security technologies that are often complex, distributed, and disparate, hoping that each of those technologies fill a gap in their defensive posture.
The problem with this patchwork approach is that it introduces an enormous burden on either the vendors selling those technologies, and more likely, the organizations themselves to operationalize those set of technologies in an effective and coordinated manner. Many of the problems exacerbated with such environments are a result of different system defensive roles those technologies play, different operational teams managing or using them, and different organizational requirements driving a very heterogenous set of capabilities all being deployed to increase security.
Can we do better?
One area that remains a challenge is security response is Course of Action. Recently, I had the pleasure to co-present on Collaborative Course of Action Operations (CACAO) at FIRST CTI Conference with Bret Jordan, Symantec. CACAO is a proposal that was developed by multiple vendors and interested parties for many months to help define the requirements, high-level system design, and approach to collaboration on Course of Action.
What is CACAO?
A proposed standard that defines structured and machine-readable cybersecurity response playbooks encompassing:
- Creation of playbooks
- Distribution of playbooks across systems
- Monitoring playbook effectiveness and results
It includes documenting and describing the steps needed to prevent, mitigate, remediate, and monitor responses to a threat, an attack, or an incident.
Playbook example scenario
A system (windows desktop) is identified as being infected by “Fictitious Fuzzy PandaX” malware by the endpoint agent running on the system. A playbook is employed to remediate the situation, outlining steps typically performed by both the desktop and network security teams in a coordinated manner:
- Quarantine system to a sandbox VLAN
- Delete run at start reg keys and triggers
- Reboot into SafeMode
- Kill process 3 then 1 then 2
- Delete temp files
- Delete compromised files from the system
- Delete other Reg keys
- Reboot system in to safe mode
- Verify processes do not restart
- Patch AV system
- Run updated AV scan
- Patch OS
- Run additional on-demand special AV scanners
- Reboot system to normal mode
- Move system out of sandbox VLAN in to a restricted watch VLAN
Now that we have an understanding of a CACAO playbook, let’s review the key steps of CACAO use?
Contextualizing these steps with an organization’s security infrastructure can be difficult to visualize – the figure below shows a high-level model of the interactions and components.
In order to effectively incorporate CACAO, organizations need to understand how CACAO describes some of the important elements of its architecture.
CACAO Definitions
Actor Roles
Just as most security organizations are made up of multiple roles and functions, CACAO embodies that philosophy to represent their separate roles in the operations using CACAO playbooks. Three primary roles will work with CACAO playbooks and the technologies that it encompasses:
- Security Analyst: Senior role performing analysis of all available threat intelligence, malware research, and active threats that may be relevant to their environment to determine a set of recommended steps to both detect and respond to threats. Security analysts are aware of the capabilities of the organization to respond and have knowledge of the security infrastructure deployed on both network, servers, and endpoints, as well as the services running on those systems
- SecOps Project Admin: Senior role that oversees and manages the security operations of the network. This role may work closely with the Security Analyst to determine response playbooks to proactively manage risk in the enterprise environment. They may either define CACAO Playbooks themselves or review/refine CACAO Playbooks defined by the Security Analyst.
- Incident Responder: Focused on responding to an active threat to the enterprise where they have limited time to respond and most of their actions are focused on mitigation and remediation. Any outcomes and results of the incident may be fed back into the other two teams involved to enhance future responses that reduce the risk of threat incidents.
Playbook Elements
The following CACAO Playbook elements are defined by the actors during the Definition phase.
- One or more Element Triggers that would initiate a CACAO Playbook being executed
- An Element Trigger may be a:
- network packet
- network session state
- file registry value
- memory state
- user event and associated identity
- time (absolute or interval)
- combination of all the above
- An Element Trigger may be a:
- One or more Element Steps defined within the CACAO Playbook that encapsulates the response to the threats they wish the CACAO Playbook should be responding to
- One or more Element Outputs that are provided as the CACAO Playbook is executed in the enterprise
CACAO Verification
The CACAO Playbook Verification phase represents the ability for an security professional who has created or updated a CACAO Playbook Definition to validate that the project will execute correctly once deployed in an operational environment. The following base verification steps should occur prior to a CACAO Playbook being deployed.
- Verify that all CACAO Playbook Sequence Elements are connected so that the complete sequence will complete when executed
- Verify that all CACAO Playbook Conditional Elements have connections to defined CACAO Playbook Steps
- Verify that each CACAO Playbook Step is well-formed and parses correctly according to the CACAO Playbook JSON schema
More advanced verification may take place, but those advanced verification processes are beyond the current scope.
CACAO Distribution
The CACAO Playbook Distribution phase represents how a CACAO Playbook is deployed to an operational environment after the CACAO Playbook has been Defined and Verified.
Distribution requires the following:
- One Source distribution system (and associated actor) that executes the COA Distribution Application
- One or more COA Execution systems that execute the CACAO Playbook Execution Machine
- One or more COA Distribution protocols, including associated authentication and authorization methods that provides a secure transport of the CACAO Playbook between the COA Distribution Application and the CACAO Playbook Execution Machines
The COA Distribution Application has the following base functional requirements:
- It must support and track distribution of the CACAO Playbook Definition such that it can identify both successful and unsuccessful deployment of the CACAO Playbook.
- It must be able to parse a CACAO Playbook and determine which CACAO Playbook Execution systems are required to have the CACAO Playbook pushed to them
- It must support all COA Distribution protocols required to distribute a CACAO Playbook to all specified systems required to execute that project.
- It must be able to detect and report on errors found as part of the distribution process.
CACAO Execution
The CACAO Playbook Execution Machine executes one or more Elements of the project. The following are base functional requirements:
- It must support at least one COA Distribution protocols to be able to receive CACAO Playbooks
- It must support at least one COA Event Reporting protocols to be able to send CACAO Playbook execution status and events
- It must support the ability to parse received CACAO Playbooks and determine if that project can be executed correctly on the local machine
- A CACAO Playbook Execution Machine can run on any network-connected compute device such as (not limited to): laptop, server, IoT sensor, network switch, router, firewall, IDs, phone.
Related Work
CACAO builds upon many years of experience building security protocols and systems that may be leveraged in some manner as part of the CACAO architecture that encompasses definition, distribution, verification, and execution. The following list is not intended exhaustive, but does include some key, related work.
- STIXv2
Primarily a Cyber Threat Intelligence JSON-based schema that defines a common taxonomy for intelligence associated with threat actors, their TTPS, actions, objectives and many more associated data that builds an understanding of the cyber threat landscape faced by organizations.Relationship to CACAO: STIXv2 introduces a mechanism to associate intelligence (e.g. known threats) and allow organizations to associate one or more CACAO playbooks with recommended actions to take in response to the intelligence. - TAXIIv2
A HTTPS application layer protocol and associated RESTful JSON-based interface for organizations to share STIX intelligence via TAXII either in point-to-point or point-to-multipoint sharing communities.
Relationship to CACAO: TAXIIv2 primarily shares STIXv2 content and if that content includes CACAO Playbook information then organizations will be able to share STIXv2 + CACAO playbooks as a set of information related to their threat landscape. - NetConf
A protocol defined to install, manipulate, and delete the configuration of network devices, primarily defined in XML.Relationship to CACAO: CACAO Playbooks would be able to configure network devices in response to specific threats using NetConf and their associated mitigations or investigative steps as defined in the playbooks. - IODEF
An XML exchange format defined to represent incidents and their associated meta-data.Relationship to CACAO: CACAO Playbooks could be referenced by IODEF incident content similar to STIXv2 referencing recommended response to particular incident occurrences. - RID
A protocol to enable exchange of IODEF incident data primarily focused on XML-based IODEF exchange.Relationship to CACAO: Similar to TAXIIv2 where IODEF incidents are exchanged via RID, if those IODEF incident were to reference CACAO Playbooks then RID could be used to distribute both contents provided RID supports non-XML content. - I2NSF
I2NSF defines a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual network security functions, enabling clients to specify rulesets.Relationship to CACAO: CACAO Playbooks would be able to configure network devices in response to specific threats using I2NSF associated protocols and provide threat mitigations or investigative steps as defined in the playbooks.
CACAO is an exciting opportunity for the cybersecurity industry to take a standards-based approach on threat response. One of the easiest ways to stay ahead of our adversaries is through information sharing, starting with communicating with a common language.
We welcome organizations (vendors and consumers) alike to get more involved in developing a standard that works for the significant problems we have. Thank you to Bret Jordan (Symantec) and Jyoti Verma (Cisco) as my co-authors of IETF CACAO draft.
