IETF B. Jordan
Internet-Draft Symantec Corporation
Intended status: Informational A. Thomson
Expires: March 16, 2019 LookingGlass Cyber
J. Verma
Cisco Systems
September 12, 2018
Collaborative Automated Course of Action Operations (CACAO) for Cyber
Security
draft-jordan-cacao-introduction-00
Abstract
This document describes the need for defining a standardized language
and associated protocols to capture and automate a collection of
coordinated cyber security actions and responses. This collection of
actions is called a Course of Action (COA) Project.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Jordan, et al. Expires March 16, 2019 [Page 1]
Internet-Draft CACAO September 2018
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Deliverables . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Definitions
System: A system is an heterogeneous set of any IT capabilities
including hardware, software, endpoints (including IoT), networks,
data centers and platforms with no assumptions on deployment form
factor (physical, virtual, microservices), deployment scenario,
geographic distribution, or dispersion.
COA: A Course of Action is a set of manual or automated actions
applicable to a given system or human processes.
COA Project: A COA Project is the instantiation of a sequence of COA
actions that can be executed on a system or set of systems to protect
it against Cyber threats and attacks.
COA Project Template: A set of high level COA actions defined by an
organization on how they might respond generically to a specific
threat scenario without the specific details of the threat included.
Example: high level steps for mitigating or remediating malware in
general.
2. Introduction
Threat Actors and Intrusion Sets are constantly advancing at an
increasing rate relative to cyber defense. Further, cyber defenders
typically have to manually identify and process prevention,
mitigation, and remediation steps in order to protect their systems
and networks and address and contain problems identified during and
after an incident response.
Jordan, et al. Expires March 16, 2019 [Page 2]
Internet-Draft CACAO September 2018
Due to the increase and sophistication of cyber attacks from Threat
Actors and Intrusion Sets the need for a secure mechanism that would
enable system and network operators to respond to incidents in
machine relevant time has raised significantly. While some attacks
may be well known to certain security experts and cyber researchers
they are often not documented in a way that would enable automated
mitigation or remediation. A documented way of describing
prevention, mitigation, and remediation actions is critical for cyber
defenders to respond more quickly and reduce the exposure from an
attack.
In a similar manner, this will allow organizations to prevalidate the
course of actions options and potentially simulate the course of
actions and understand their implications in terms of potential
overall cost, revenue loss, user experience, risk of churn, risks in
general, and liabilities. Indeed certain COAs might lead to radical
mitigations in the system which might lead to more or less acceptable
collateral damages to answer a certain cyber threat. Like at war,
'officers' responsible to engage or trigger the execution of a COA
could be offered a chance to understand their options first in
selecting the most appropriate COA.
While many attempts have been made over the years in the IETF and
other SDOs to address certain elements of this problem space, there
is currently no consolidated and standardized language or means that
would allow cyber actions to be automatically coordinated, sequenced,
processed and shared to enable cyber defenders to respond in machine
relevant time. Some efforts such as BPMN have traditionally focused
on higher-level non-cyber constructs for process definition, and
other efforts like OpenC2 have focused purely on atomic actions, but
none have focused on the overlay processes required for this to be
used in a broader cyber security response use case.
To enable and assist cyber defense, a solution needs to be created to
securely document, share, and automate the actions needed to prevent,
mitigate, and remediate threats. This effort will focus on providing
an information model, data serialization, and transport for defining,
sharing, and processing Collaborative Automated Course of Action
Operations (CACAO).
Each collaborative course of action will consist of a sequence of
cyber defense action that can be coordinated and deployed with
verified responses across a set of heterogeneous cyber security
systems. The primary focus will be on the definition of the higher
level sequence of actions (perhaps a tree or graph) and where
possible we will leverage existing efforts that _may_ define the
atomic actions to be included in a process or sequence.
Jordan, et al. Expires March 16, 2019 [Page 3]
Internet-Draft CACAO September 2018
A key use of collaborative courses of action is to enable more senior
cyber defenders to document and share detailed step by step actions
and solutions for a given threat that can be deployed en mass across
heterogenous system and network solutions. It also enables less
experienced or junior personnel to have greater confidence in their
efforts to defend their networks based on shared collaborative COA
Projects defined by other organizations and other experts in the
field of cyber security. These suggested steps, that may be executed
automatically, provided by the senior personnel can also help guide
the junior personnel in the correct ways to handle a variety of the
security response without requiring senior personnel being involved.
This effort is intended to define a way for chaining atomic security
actions together. The atomic actions themselves could be formed from
a variety of languages such as STIX COA; OpenC2; Cisco IOS; Juniper
JunOS....etc.
This effort will primarily focus on defining a semantic
representation and information model to allow the construction of an
Collaborative Automated Course Of Action Operations (CACAO). Our
secondary focus will be on defining a serialization and transport
protocol to enable these collaborative courses of action to be used
between systems.
3. Examples
The following 2 simplified examples explain collaborative COA
Projects that are written in pseudo programmatic terms to explain how
the project contains both human and machine defined actions that are
executed in response to a threat. For each project, the initial
trigger event is defined and then followed by a set of project steps
that can be sequential, conditional-based-flow steps, or a
combination of both.
Example 1: Infected Host Mitigation Project In this example, it is
described how a collaborative COA Project defines how an organization
may respond to threat detection on a host within their internal
network after a specific type of threat has been detected on the
host. The project defines both machine and human steps to describe
the mitigation response.
BEGIN-PROJECT
Project-Name: InfectedHostMitigation1 Project-Trigger-Event:
o Indicator indicator-8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a
command and control server based on CIDR 192.0.2.x that has been
communicated to and from the host 198.51.100.12.
Jordan, et al. Expires March 16, 2019 [Page 4]
Internet-Draft CACAO September 2018
o A trigger event may be defined in STIX2
o A trigger defines an entry point into the project steps as
follows.
BEGIN-STEPS
Project-Step:
o Id: 1
o Type: Human
* Question: Ask the user whether they wish to review the
mitigation procedures before proceeding?
* Answer-Y-or-N
+ If Y: Proceed to Id: 2
+ If N: Proceed to Id: 3
Project-Step:
o Id: 2
o Type: Human
* Operation: Display mitigation procedures.
Project-Step:
o Id:3
o Type: Machine
* Operation: Vlan-Move
* Variable: "HostVLANID ="infected-host.vlan
* Target: $$infected-host
* Destination: Quarantine VLAN ID
Project-Step:
o Id:4
Jordan, et al. Expires March 16, 2019 [Page 5]
Internet-Draft CACAO September 2018
o Type: Machine
* Operation: Host-Image
* Target: $$infected-host
* ImageName: Windows-Good-Image1
Project-Step:
o Id:5
o Type: Machine
* Operation: Vlan-Move
* Target: $$infected-host
* Destination: $$HostVLANID
END-STEPS
END-PROJECT
Example 2: Find and Remove Malware Project In this example, it is
described how a Collaborative Courses of Action Project defines how
an organization may find malware and then if found can remove the
malware from an infected host. The project defines both a more
complicated sequence of machine instructions as identified by the
MACHINE-SEQUENCE operation in Project-Step-Id{4}.
BEGIN-PROJECT
Project-Name: FindRemoveMalware1 Project-Trigger-Event:
o Indicator indicator-8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a
malware hash $$inserthash that is known to identify a specific
malware file if found on a host system
o A trigger event may be defined in STIX2
o A trigger defines an entry point into the project steps as
follows.
BEGIN-STEPS
Project-Step:
Jordan, et al. Expires March 16, 2019 [Page 6]
Internet-Draft CACAO September 2018
o Id: 1
o Type: Human
* Question: Ask the user whether they wish to review the
mitigation procedures before proceeding?
* Answer-Y-or-N
+ If Y: Proceed to Id: 2
+ If N: Proceed to Id: 3
Project-Step:
o Id: 2
o Type: Human
* Operation: Display mitigation procedures.
Project-Step:
o Id:3
o Type: Machine
* Operation: Vlan-Move
* Variable: "HostVLANID ="infected-host.vlan
* Target: $$infected-host
* Destination: Quarantine VLAN ID
Project-Step:
o Id:4
o Type: Machine-Sequence {
* Delete run at start reg keys and triggers
* Reboot into SafeMode
* Kill process 3 then 1 then 2
* Delete temp files
Jordan, et al. Expires March 16, 2019 [Page 7]
Internet-Draft CACAO September 2018
* 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 }
* Target: $$infected-host
Project-Step:
o Id:5
o Type: Machine
* Operation: Vlan-Move
* Target: $$infected-host
* Destination: $$HostVLANID
END-STEPS
END-PROJECTS
4. Requirements
Below is a list of high level requirements that this effort needs to
address.
o Multiple Actions: The solution needs to support the ability to
describe one or more actions that can be processed in a batch
manner or as-a-group.
o Data Protection, Integrity and Authentication (Rules for data in
motion and at rest): All requests and responses must be
confidential and therefore a secure protocol should be used to
Jordan, et al. Expires March 16, 2019 [Page 8]
Internet-Draft CACAO September 2018
convey these messages such as TLS (but not limited to). The COA
Projects and actions must be able to be encrypted (and optionally
signed) to ensure integrity and that they are only accessible by
authenticated and authorized users.
o Globally Unique Identifiers: All transactions (requests,
responses, and notifications) need to be able to be tracked,
monitored, and recorded for security and operational reasons,
including the ability to backout failed actions. This means
responses and notifications need a way to be tied back to the
original request. Globally unique identifiers apply to both the
COA Project and the COA Actions within the project. All
transactions tracked, monitored and recorded will be restricted to
the same management zone as the systems initiating the
transactions and operating on the results. All systems operating
in that management zone will support a common and agreed set of
privacy associated with those transactions such that no concerns
over loss of privacy or unexpected data exposure occurs.
o Reporting: Provide the ability to gather single and batch reports
of events for responses. All report events must have a timestamp,
identifier of original request or rule causing event, and option
for a full dump of matching data (network, endpoint config....etc)
to be included in the event record. The report could be either
synchronously requested or be an asynchronous event (syslog) with
periodic updates.
o Sequences of Atomic Actions: The ability to define an ordered list
of atomic actions that must be executed as a combined set rather
than as a sequence.
o Projects & Project Templates: These should support actions for
machine automation, human actions / intervention, and high level
conceptual actions.
o Customization: Provide the option to include custom actions in a
batch or set of atomic actions.
o Conditional Logic: This solution needs the ability to include
action sequences that can support conditional logic, logical and
comparative operators, and behavioral logic.
o Project Testing: Ability to support what-if deployments where a
defined COA Projects can be verified before deploying to a real
system or environment, and perhaps be able to identify all the
organizations that have tested it and verified it.
Jordan, et al. Expires March 16, 2019 [Page 9]
Internet-Draft CACAO September 2018
o Auditability: The solution needs the ability to provide full
confirmation (tracking and logging) of each COA and each action at
every transaction state.
o Digital Signature Chain / Attribution with Identified Signed
Topic: The solution needs the ability to track multiple digital
signatures to show a chain of trust where it identifies the
specific Signed Topic that is being signed. This solution should
also support multiple independent organizations signing and
verifying the correctness, accuracy, and validity of the COA
Project or individual action where the Signed Topic being signed
by that independent entity is specified.
o Input: One or more technical indicators, prioritization
indicators, and rule names (optional).
o Transport Methods: This solution needs to support the ability for
clients to send COAs directly to an end device (request/response)
and also to a communications channel (publish/subscribe).
o Versioning: The solution needs to support both incremental
versioning and semantic versioning, along with assertions that the
COA works with certain products. This will enable support of
multiple versions of a COA across products so that not all systems
are required to be the same version to implement COA Projects.
Newer COA Projects will provide information that allows consumers
to relate the new version to prior versions.
o Transactions: Needs the ability for systems to have the option to
support both atomic and non-atomic transactions.
o System Targeting: The solution needs the ability to identify the
type, version, patch level of one or more systems that this COA is
applicable for.
o Project Versioning: Need ability to version (and track) COA
Projects and Templates
o Data Markings: Need ability to support data marking at a COA
Project level such as the Traffic Light Protocol (TLP) for the
project.
o Command and Control Management Separation (Definition vs Execution
Environment): A COA Project (and the contained atomic COA actions)
may be defined in one system by one or more authors, but the COA
project may be executed in an operational environment where the
systems and users of those systems have different authentication
and authorizations for the COA. In order for the COA Project to
Jordan, et al. Expires March 16, 2019 [Page 10]
Internet-Draft CACAO September 2018
execute correctly it must have authorization in the operational
environment where it is executed. Therefore the credentials of
the authors should not be relied upon to execute correctly in the
execution environment. Also, the security environment executing
the COA Project will likely be different from where the COA
project was defined.
o Integration: Ensure that COA Projects can be used in and work with
existing threat intelligence data models, for example STIX.
o Flexibility: Allow the COA Project to benefit and leverage
existing capabilities available in 'the system' such as atomic
ways to exchange security commands 'a la openc2', or read from
available security capabilities in a standard way 'a la i2nsf' to
understand what it can actually do or to allow conditional COA
sequences
5. Architecture
A Collaborative Course of Action workflow will consist of several
components, including at least:
+----------+ +----------+ +----------+ +----------+
| Define | --> | Verify | --> | Deliver | --> | Execute |
| COA Proj | <-- | COA Proj | | COA Proj | | COA Proj |
+----------+ +----------+ +----------+ +----------+
^ ^ ^ ^
| | | |
| +--------------------------+ |
<-------- | Monitoring and Reporting | -------->
+--------------------------+
o Define: Where a COA Project is defined based on various inputs
both automated and manually derived.
o Verify: Where a COA Project is reviewed for accuracy, correctness,
and is properly defined to execute correctly in a target
environment without making any changes to the target environment.
o Deliver: Where a COA Project is distributed to the systems that
will execute the COA Project. Distribution includes checking that
the COA Project has been deployed correctly and has followed the
rules defined within the project for atomic transactions.
Jordan, et al. Expires March 16, 2019 [Page 11]
Internet-Draft CACAO September 2018
o Execute: Where a COA Project is evaluated by one or more security
infrastructure systems and execution events are communicated to
the COA Project monitoring step. It can run either in full
execution or in verification mode.
o Monitoring: Where a COA Project execution is monitored and metrics
are determined on the COA Project to enable further refinement or
improvement to the COA Project definition.
6. Deliverables
This effort will need to produce and deliver the following documents:
1. An overview and architecture document
2. A COA Project data model in JSON / CBOR
3. Define how COA Projects will be distributed between each system
within the process including leveraging existing transport
mechanisms and any new APIs/Protocols required.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
The solution described by this document provides a mechanism to
define a series of actions that can be applied to a network or host
system to prevent, mitigate, or remediate some threat. Discussion is
needed about how to protect such a mechanism and the information it
is managing from unauthorized access or disclosure.
In a principle of "who guards the guards" ("quis custodiet Ipsos
custodes" Juvenal, Satire VI, lines 347-348) it is essential to armor
the COA service against itself and to consider a COA-SELF project for
consistency and coherency where the target system of the COA is the
COA service itself.
A breach in the COA service would break the integrity of an entire
target system, potentially at extra large scale.
9. Privacy Considerations
Discussion is also needed about privacy considerations around how the
endpoint devices and systems are identified and to ensure that any
commands are encoded in a safe way and if the COA Project needs to
collect private data it is still compliant to privacy regulations and
Jordan, et al. Expires March 16, 2019 [Page 12]
Internet-Draft CACAO September 2018
offers all the mechanisms to guarantee compliance to such frameworks
such as auditability, security, encryption, right to be forgotten,
consents, etc.
Contributors
o Allen Hadden
IBM
ahadden@us.ibm.com
o David Waltermire
NIST
david.waltermire@nist.gov
o Efrain Ortiz
Symantec
efrain_ortiz@symantec.com
o Jason Keirstead
IBM
jason.keirstead@ca.ibm.com
o Jason Webb
LookingGlass Cyber
jwebb@lookingglasscyber.com
o Kyle Mackenzie
JPMC
Mackenzie.kyle@jpmorgan.com
o Subodh Kumar
JPMC
subodh.kumar@jpmorgan.com
o Swaroop Pradhan
JPMC
swaroop.s.pradhan@jpmorgan.com
o Vivek Jain
JPMC
vivek.jain@jpmchase.com
Authors' Addresses
Jordan, et al. Expires March 16, 2019 [Page 13]
Internet-Draft CACAO September 2018
Bret Jordan
Symantec Corporation
350 Ellis Street
Mountain View CA 94043
USA
Email: bret_jordan@symantec.com
Allan Thomson
LookingGlass Cyber
10740 Parkridge Blvd, Suite 200
Reston VA 20191
USA
Email: athomson@lookingglasscyber.com
Jyoti Verma
Cisco Systems
170 West Tasman Dr.
San Jose CA 95134
USA
Email: jyoverma@cisco.com
Jordan, et al. Expires March 16, 2019 [Page 14]