idnits 2.17.1 draft-jordan-cacao-introduction-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 08, 2019) is 1869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF B. Jordan 3 Internet-Draft Symantec Corporation 4 Intended status: Informational A. Thomson 5 Expires: September 9, 2019 LookingGlass Cyber 6 J. Verma 7 Cisco Systems 8 March 08, 2019 10 Collaborative Automated Course of Action Operations (CACAO) for Cyber 11 Security 12 draft-jordan-cacao-introduction-01 14 Abstract 16 This document describes the need for defining a standardized language 17 and associated protocols to capture and automate a collection of 18 coordinated cyber security actions and responses. This collection of 19 actions is called a Course of Action (COA) Playbook. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 9, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6. Deliverables . . . . . . . . . . . . . . . . . . . . . . . . 12 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 64 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 67 1. Definitions 69 System: A system is an heterogeneous set of any IT capabilities 70 including hardware, software, endpoints (including IoT), networks, 71 data centers and platforms with no assumptions on deployment form 72 factor (physical, virtual, microservices), deployment scenario, 73 geographic distribution, or dispersion. 75 COA: A Course of Action is a manual or automated action applicable to 76 a given system or human process. 78 COA Playbook: A COA Playbook is the instantiation of a sequence of 79 COAs that can be executed on a system or set of systems to protect it 80 against Cyber threats and attacks. 82 COA Playbook Template: A set of high level COA actions defined by an 83 organization on how they might respond generically to a specific 84 threat scenario without the specific details of the threat included. 85 Example: high level steps for mitigating or remediating malware in 86 general. 88 CACAO: A Collaborative Automated Course of Action Operation 89 represents a COA Playbook that can be coordinated and deployed with 90 verified responses across a set of heterogeneous cyber security 91 systems. 93 2. Introduction 95 To defend against threat actors and their tactics, techniques, and 96 procedures, organizations need to identify, create, and document 97 prevention, mitigation, and remediation steps. These steps when 98 grouped together into a course of action (COA) Playbook are used to 99 protect systems, networks, data, and users. The problem is, once 100 these steps have been created there is no standardized and structured 101 way to document them, verify they were correctly executed, or easily 102 share them across organizational boundaries and technology stacks. 104 A COA Playbook with automated steps would enable system and network 105 operators to respond to incidents in machine relevant time. 107 While some attacks may be well known to certain security experts and 108 cyber researchers they are often not documented in a way that would 109 enable automated mitigation or remediation. A documented way of 110 describing prevention, mitigation, and remediation actions is 111 critical for cyber defenders to respond more quickly and reduce the 112 exposure from an attack. 114 In a similar manner, this will allow organizations to prevalidate the 115 course of actions and potentially simulate the course of actions and 116 understand their implications in terms of potential overall cost, 117 revenue loss, user experience, risk of churn, risks in general, and 118 liabilities. Indeed certain COAs might lead to radical mitigations 119 in the system which might lead to more or less acceptable collateral 120 damages to answer a certain cyber threat. Like at war, 'officers' 121 responsible to engage or trigger the execution of a COA could be 122 offered a chance to understand their options first in selecting the 123 most appropriate COA. 125 While many attempts have been made over the years in the IETF and 126 other SDOs to address certain elements of this problem space, there 127 is currently no consolidated and standardized language or means that 128 would allow cyber actions to be automatically coordinated, sequenced, 129 processed and shared to enable cyber defenders to respond in machine 130 relevant time. Some efforts such as BPMN have traditionally focused 131 on higher-level non-cyber constructs for process definition, and 132 other efforts like OpenC2 have focused purely on atomic actions, but 133 none have focused on the overlay processes required for this to be 134 used in a broader cyber security response use case. 136 To enable and assist cyber defense, a solution needs to be created to 137 securely document, share, and automate the actions needed to prevent, 138 mitigate, and remediate threats. This effort will focus on providing 139 an information model, data serialization, and transport for defining, 140 sharing, and processing Collaborative Automated Course of Action 141 Operations (CACAO). 143 Every COA Playbook will consist of a sequence of cyber defense 144 actions that can be coordinated and deployed with verified responses 145 across a set of heterogeneous cyber security systems. The primary 146 focus will be on the definition of the higher level sequence of 147 actions (perhaps a tree or graph) and where possible we will leverage 148 existing efforts that _may_ define the atomic actions to be included 149 in a process or sequence. 151 A key use of CACAO is to enable more senior cyber defenders to 152 document and share detailed step by step actions and solutions for a 153 given threat that can be deployed en mass across heterogenous system 154 and network solutions. It also enables less experienced or junior 155 personnel to have greater confidence in their efforts to defend their 156 networks based on shared COA Playbooks defined by other organizations 157 and other experts in the field of cyber security. These suggested 158 steps, that may be executed automatically, provided by the senior 159 personnel can also help guide the junior personnel in the correct 160 ways to handle a variety of the security response without requiring 161 senior personnel being involved. 163 This effort is intended to define a way for chaining atomic security 164 actions together. The atomic actions themselves could be formed from 165 a variety of languages such as STIX COA; OpenC2; Cisco IOS; Juniper 166 JunOS....etc. 168 This effort will primarily focus on defining a semantic 169 representation and information model to allow the construction of a 170 COA Playbook. Our secondary focus will be on defining a 171 serialization and transport protocol to enable COA Playbooks to be 172 used between systems. 174 3. Examples 176 The following 2 simplified examples explain CACAOs that are written 177 in pseudo programmatic terms to explain how the COA Playbook contains 178 both human and machine defined actions that are executed in response 179 to a threat. For each COA Playbook, the initial trigger event is 180 defined and then followed by a set of COAs that can be sequential, 181 conditional-based-flow, or a combination of both. 183 Example 1: Infected Host Mitigation COA Playbook This example defines 184 the COA Playbook for an organization to respond to threat detection 185 on a host within their internal network after a specific type of 186 threat has been detected on the host. The playbook defines both 187 machine and human steps to describe the mitigation response. 189 BEGIN-PLAYBOOK 191 Playbook-Name: InfectedHostMitigation1 193 Playbook-Trigger-Event: 195 o Indicator indicator-8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a 196 command and control server based on CIDR 192.0.2.x that has been 197 communicated to and from the host 198.51.100.12. 199 o A trigger event may be defined in STIX2 201 o A trigger defines an entry point into the playbook steps as 202 follows. 204 BEGIN-COAs 206 COA: 208 o Id: 1 210 o Type: Human 212 * Question: Ask the user whether they wish to review the 213 mitigation procedures before proceeding? 215 * Answer-Y-or-N 217 + If Y: Proceed to Id: 2 219 + If N: Proceed to Id: 3 221 COA: 223 o Id: 2 225 o Type: Human 227 * Operation: Display mitigation procedures. 229 COA: 231 o Id:3 233 o Type: Machine 235 * Operation: Vlan-Move 236 * Variable: "HostVLANID ="infected-host.vlan 238 * Target: $$infected-host 240 * Destination: Quarantine VLAN ID 242 COA: 244 o Id:4 246 o Type: Machine 248 * Operation: Host-Image 250 * Target: $$infected-host 252 * ImageName: Windows-Good-Image1 254 COA: 256 o Id:5 258 o Type: Machine 260 * Operation: Vlan-Move 262 * Target: $$infected-host 264 * Destination: $$HostVLANID 266 END-COAs 268 END-PLAYBOOK 270 Example 2: Find and Remove Malware COA Playbook This example 271 describes a COA Playbook for an organization to find malware and then 272 if found to remove the malware from an infected host. The playbook 273 defines a more complicated sequence of machine instructions as 274 identified by the MACHINE-SEQUENCE operation in COA-Id{4}. 276 BEGIN-PLAYBOOK 278 Playbook-Name: FindRemoveMalware1 280 Playbook-Trigger-Event: 282 o Indicator indicator-8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a 283 malware hash $$inserthash that is known to identify a specific 284 malware file if found on a host system 286 o A trigger event may be defined in STIX2 288 o A trigger defines an entry point into the playbook steps as 289 follows. 291 BEGIN-COAs 293 COA: 295 o Id: 1 297 o Type: Human 299 * Question: Ask the user whether they wish to review the 300 mitigation procedures before proceeding? 302 * Answer-Y-or-N 304 + If Y: Proceed to Id: 2 306 + If N: Proceed to Id: 3 308 COA: 310 o Id: 2 312 o Type: Human 314 * Operation: Display mitigation procedures. 316 COA: 318 o Id:3 320 o Type: Machine 322 * Operation: Vlan-Move 324 * Variable: "HostVLANID ="infected-host.vlan 326 * Target: $$infected-host 328 * Destination: Quarantine VLAN ID 330 COA: 332 o Id:4 334 o Type: Machine-Sequence { 336 * Delete run at start reg keys and triggers 338 * Reboot into SafeMode 340 * Kill process 3 then 1 then 2 342 * Delete temp files 344 * Delete compromised files from the system 346 * Delete other Reg keys 348 * Reboot system in to safe mode 350 * Verify processes do not restart 352 * Patch AV system 354 * Run updated AV scan 356 * Patch OS 358 * Run additional on-demand special AV scanners 360 * Reboot system to normal mode } 362 * Target: $$infected-host 364 COA: 366 o Id:5 368 o Type: Machine 370 * Operation: Vlan-Move 372 * Target: $$infected-host 374 * Destination: $$HostVLANID 376 END-COAs 377 END-PLAYBOOK 379 4. Requirements 381 Below is a list of high level requirements that this effort needs to 382 address. 384 o Multiple Actions: The solution needs to support the ability to 385 describe one or more actions that can be processed in a batch 386 manner or as-a-group. 388 o Data Protection, Integrity and Authentication (Rules for data in 389 motion and at rest): All requests and responses must be 390 confidential and therefore a secure protocol should be used to 391 convey these messages such as TLS (but not limited to). The COA 392 Playbooks and actions must be able to be encrypted (and optionally 393 signed) to ensure integrity and that they are only accessible by 394 authenticated and authorized users. 396 o Globally Unique Identifiers: All transactions (requests, 397 responses, and notifications) need to be able to be tracked, 398 monitored, and recorded for security and operational reasons, 399 including the ability to backout failed actions. This means 400 responses and notifications need a way to be tied back to the 401 original request. Globally unique identifiers apply to both the 402 COA Playbook and the COAs within the playbook. All transactions 403 tracked, monitored and recorded will be restricted to the same 404 management zone as the systems initiating the transactions and 405 operating on the results. All systems operating in that 406 management zone will support a common and agreed set of privacy 407 associated with those transactions such that no concerns over loss 408 of privacy or unexpected data exposure occurs. 410 o Reporting: Provide the ability to gather single and batch reports 411 of events for responses. All report events must have a timestamp, 412 identifier of original request or rule causing event, and option 413 for a full dump of matching data (network, endpoint config....etc) 414 to be included in the event record. The report could be either 415 synchronously requested or be an asynchronous event (syslog) with 416 periodic updates. 418 o Sequences of Atomic Actions: The ability to define an ordered list 419 of atomic actions that must be executed as a combined set rather 420 than as a sequence. 422 o Projects & Project Templates: These should support actions for 423 machine automation, human actions / intervention, and high level 424 conceptual actions. 426 o Customization: Provide the option to include custom actions in a 427 batch or set of atomic actions. 429 o Conditional Logic: This solution needs the ability to include 430 action sequences that can support conditional logic, logical and 431 comparative operators, and behavioral logic. 433 o Project Testing: Ability to support what-if deployments where a 434 defined COA Playbooks can be verified before deploying to a real 435 system or environment, and perhaps be able to identify all the 436 organizations that have tested it and verified it. 438 o Auditability: The solution needs the ability to provide full 439 confirmation (tracking and logging) of each COA at every 440 transaction state. 442 o Digital Signature Chain / Attribution with Identified Signed 443 Topic: The solution needs the ability to track multiple digital 444 signatures to show a chain of trust where it identifies the 445 specific Signed Topic that is being signed. This solution should 446 also support multiple independent organizations signing and 447 verifying the correctness, accuracy, and validity of the COA 448 Playbook or individual COA where the Signed Topic being signed by 449 that independent entity is specified. 451 o Input: One or more technical indicators, prioritization 452 indicators, and rule names (optional). 454 o Transport Methods: This solution needs to support the ability for 455 clients to send COAs directly to an end device (request/response) 456 and also to a communications channel (publish/subscribe). 458 o Versioning: The solution needs to support both incremental 459 versioning and semantic versioning, along with assertions that the 460 COA works with certain products. This will enable support of 461 multiple versions of a COA across products so that not all systems 462 are required to be the same version to implement COA Playbooks. 463 Newer COA Playbooks will provide information that allows consumers 464 to relate the new version to prior versions. 466 o Transactions: Needs the ability for systems to have the option to 467 support both atomic and non-atomic transactions. 469 o System Targeting: The solution needs the ability to identify the 470 type, version, patch level of one or more systems that this COA is 471 applicable for. 473 o Project Versioning: Need ability to version (and track) COA 474 Playbooks and Templates 476 o Data Markings: Need ability to support data marking at a COA 477 Playbook level such as the Traffic Light Protocol (TLP) for the 478 project. 480 o Command and Control Management Separation (Definition vs Execution 481 Environment): A COA Playbook (and the contained atomic COAs) may 482 be defined in one system by one or more authors, but the COA 483 Playbook may be executed in an operational environment where the 484 systems and users of those systems have different authentication 485 and authorizations for the COA. In order for the COA Playbook to 486 execute correctly it must have authorization in the operational 487 environment where it is executed. Therefore the credentials of 488 the authors should not be relied upon to execute correctly in the 489 execution environment. Also, the security environment executing 490 the COA Playbook will likely be different from where the COA 491 Playbook was defined. 493 o Integration: Ensure that COA Playbooks can be used in and work 494 with existing threat intelligence data models, for example STIX. 496 o Flexibility: Allow the COA PLaybook to benefit and leverage 497 existing capabilities available in 'the system' such as atomic 498 ways to exchange security commands 'a la openc2', or read from 499 available security capabilities in a standard way 'a la i2nsf' to 500 understand what it can actually do or to allow conditional COA 501 sequences 503 5. Architecture 505 A Collaborative Course of Action workflow will consist of several 506 components, including at least: 508 +----------+ +----------+ +----------+ +----------+ 509 | Define | --> | Verify | --> | Deliver | --> | Execute | 510 | COA | <-- | COA | | COA | | COA | 511 | Playbook | | Playbook | | Playbook | | Playbook | 512 +----------+ +----------+ +----------+ +----------+ 513 ^ ^ ^ ^ 514 | | | | 515 | +--------------------------+ | 516 <-------- | Monitoring and Reporting | --------> 517 +--------------------------+ 519 o Define: Where a COA Playbook is defined based on various inputs 520 both automated and manually derived. 522 o Verify: Where a COA Playbook is reviewed for accuracy, 523 correctness, and is properly defined to execute correctly in a 524 target environment without making any changes to the target 525 environment. 527 o Deliver: Where a COA Playbook is distributed to the systems that 528 will execute the COA Playbook. Distribution includes checking 529 that the COA Playbook has been deployed correctly and has followed 530 the rules defined within the project for atomic transactions. 532 o Execute: Where a COA Playbook is evaluated by one or more security 533 infrastructure systems and execution events are communicated to 534 the COA Playbook monitoring step. It can run either in full 535 execution or in verification mode. 537 o Monitoring: Where a COA Playbook execution is monitored and 538 metrics are determined on the COA Playbook to enable further 539 refinement or improvement to the COA Playbook definition. 541 6. Deliverables 543 This effort will need to produce and deliver the following documents: 545 1. An overview and architecture document 547 2. A COA Playbook data model in JSON / CBOR 549 3. Define how COA Playbooks will be distributed between each system 550 within the process including leveraging existing transport 551 mechanisms and any new APIs/Protocols required. 553 7. IANA Considerations 555 This memo includes no request to IANA. 557 8. Security Considerations 559 The solution described by this document provides a mechanism to 560 define a series of actions that can be applied to a network or host 561 system to prevent, mitigate, or remediate some threat. Discussion is 562 needed about how to protect such a mechanism and the information it 563 is managing from unauthorized access or disclosure. 565 In a principle of "who guards the guards" ("quis custodiet Ipsos 566 custodes" Juvenal, Satire VI, lines 347-348) it is essential to armor 567 the COA service against itself and to consider a COA-SELF project for 568 consistency and coherency where the target system of the COA is the 569 COA service itself. 571 A breach in the COA service would break the integrity of an entire 572 target system, potentially at extra large scale. 574 9. Privacy Considerations 576 Discussion is also needed about privacy considerations around how the 577 endpoint devices and systems are identified and to ensure that any 578 commands are encoded in a safe way and if the COA Playbook needs to 579 collect private data it is still compliant to privacy regulations and 580 offers all the mechanisms to guarantee compliance to such frameworks 581 such as auditability, security, encryption, right to be forgotten, 582 consents, etc. 584 Contributors 586 o Allen Hadden 587 IBM 588 ahadden@us.ibm.com 590 o David Waltermire 591 NIST 592 david.waltermire@nist.gov 594 o Efrain Ortiz 595 Symantec 596 efrain_ortiz@symantec.com 598 o Jason Keirstead 599 IBM 600 jason.keirstead@ca.ibm.com 602 o Jason Webb 603 LookingGlass Cyber 604 jwebb@lookingglasscyber.com 606 o Kyle Mackenzie 607 JPMC 608 Mackenzie.kyle@jpmorgan.com 610 o Subodh Kumar 611 JPMC 612 subodh.kumar@jpmorgan.com 614 o Swaroop Pradhan 615 JPMC 616 swaroop.s.pradhan@jpmorgan.com 618 o Vivek Jain 619 JPMC 620 vivek.jain@jpmchase.com 622 Authors' Addresses 624 Bret Jordan 625 Symantec Corporation 626 350 Ellis Street 627 Mountain View CA 94043 628 USA 630 Email: bret_jordan@symantec.com 632 Allan Thomson 633 LookingGlass Cyber 634 10740 Parkridge Blvd, Suite 200 635 Reston VA 20191 636 USA 638 Email: athomson@lookingglasscyber.com 640 Jyoti Verma 641 Cisco Systems 642 170 West Tasman Dr. 643 San Jose CA 95134 644 USA 646 Email: jyoverma@cisco.com