idnits 2.17.1 draft-jordan-cacao-introduction-00.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 (September 12, 2018) is 2051 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: March 16, 2019 LookingGlass Cyber 6 J. Verma 7 Cisco Systems 8 September 12, 2018 10 Collaborative Automated Course of Action Operations (CACAO) for Cyber 11 Security 12 draft-jordan-cacao-introduction-00 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) Project. 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 March 16, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6. Deliverables . . . . . . . . . . . . . . . . . . . . . . . . 12 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 64 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 set of manual or automated actions 76 applicable to a given system or human processes. 78 COA Project: A COA Project is the instantiation of a sequence of COA 79 actions that can be executed on a system or set of systems to protect 80 it against Cyber threats and attacks. 82 COA Project 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 2. Introduction 90 Threat Actors and Intrusion Sets are constantly advancing at an 91 increasing rate relative to cyber defense. Further, cyber defenders 92 typically have to manually identify and process prevention, 93 mitigation, and remediation steps in order to protect their systems 94 and networks and address and contain problems identified during and 95 after an incident response. 97 Due to the increase and sophistication of cyber attacks from Threat 98 Actors and Intrusion Sets the need for a secure mechanism that would 99 enable system and network operators to respond to incidents in 100 machine relevant time has raised significantly. While some attacks 101 may be well known to certain security experts and cyber researchers 102 they are often not documented in a way that would enable automated 103 mitigation or remediation. A documented way of describing 104 prevention, mitigation, and remediation actions is critical for cyber 105 defenders to respond more quickly and reduce the exposure from an 106 attack. 108 In a similar manner, this will allow organizations to prevalidate the 109 course of actions options and potentially simulate the course of 110 actions and understand their implications in terms of potential 111 overall cost, revenue loss, user experience, risk of churn, risks in 112 general, and liabilities. Indeed certain COAs might lead to radical 113 mitigations in the system which might lead to more or less acceptable 114 collateral damages to answer a certain cyber threat. Like at war, 115 'officers' responsible to engage or trigger the execution of a COA 116 could be offered a chance to understand their options first in 117 selecting the most appropriate COA. 119 While many attempts have been made over the years in the IETF and 120 other SDOs to address certain elements of this problem space, there 121 is currently no consolidated and standardized language or means that 122 would allow cyber actions to be automatically coordinated, sequenced, 123 processed and shared to enable cyber defenders to respond in machine 124 relevant time. Some efforts such as BPMN have traditionally focused 125 on higher-level non-cyber constructs for process definition, and 126 other efforts like OpenC2 have focused purely on atomic actions, but 127 none have focused on the overlay processes required for this to be 128 used in a broader cyber security response use case. 130 To enable and assist cyber defense, a solution needs to be created to 131 securely document, share, and automate the actions needed to prevent, 132 mitigate, and remediate threats. This effort will focus on providing 133 an information model, data serialization, and transport for defining, 134 sharing, and processing Collaborative Automated Course of Action 135 Operations (CACAO). 137 Each collaborative course of action will consist of a sequence of 138 cyber defense action that can be coordinated and deployed with 139 verified responses across a set of heterogeneous cyber security 140 systems. The primary focus will be on the definition of the higher 141 level sequence of actions (perhaps a tree or graph) and where 142 possible we will leverage existing efforts that _may_ define the 143 atomic actions to be included in a process or sequence. 145 A key use of collaborative courses of action is to enable more senior 146 cyber defenders to document and share detailed step by step actions 147 and solutions for a given threat that can be deployed en mass across 148 heterogenous system and network solutions. It also enables less 149 experienced or junior personnel to have greater confidence in their 150 efforts to defend their networks based on shared collaborative COA 151 Projects defined by other organizations and other experts in the 152 field of cyber security. These suggested steps, that may be executed 153 automatically, provided by the senior personnel can also help guide 154 the junior personnel in the correct ways to handle a variety of the 155 security response without requiring senior personnel being involved. 157 This effort is intended to define a way for chaining atomic security 158 actions together. The atomic actions themselves could be formed from 159 a variety of languages such as STIX COA; OpenC2; Cisco IOS; Juniper 160 JunOS....etc. 162 This effort will primarily focus on defining a semantic 163 representation and information model to allow the construction of an 164 Collaborative Automated Course Of Action Operations (CACAO). Our 165 secondary focus will be on defining a serialization and transport 166 protocol to enable these collaborative courses of action to be used 167 between systems. 169 3. Examples 171 The following 2 simplified examples explain collaborative COA 172 Projects that are written in pseudo programmatic terms to explain how 173 the project contains both human and machine defined actions that are 174 executed in response to a threat. For each project, the initial 175 trigger event is defined and then followed by a set of project steps 176 that can be sequential, conditional-based-flow steps, or a 177 combination of both. 179 Example 1: Infected Host Mitigation Project In this example, it is 180 described how a collaborative COA Project defines how an organization 181 may respond to threat detection on a host within their internal 182 network after a specific type of threat has been detected on the 183 host. The project defines both machine and human steps to describe 184 the mitigation response. 186 BEGIN-PROJECT 188 Project-Name: InfectedHostMitigation1 Project-Trigger-Event: 190 o Indicator indicator-8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a 191 command and control server based on CIDR 192.0.2.x that has been 192 communicated to and from the host 198.51.100.12. 194 o A trigger event may be defined in STIX2 196 o A trigger defines an entry point into the project steps as 197 follows. 199 BEGIN-STEPS 201 Project-Step: 203 o Id: 1 205 o Type: Human 207 * Question: Ask the user whether they wish to review the 208 mitigation procedures before proceeding? 210 * Answer-Y-or-N 212 + If Y: Proceed to Id: 2 214 + If N: Proceed to Id: 3 216 Project-Step: 218 o Id: 2 220 o Type: Human 222 * Operation: Display mitigation procedures. 224 Project-Step: 226 o Id:3 228 o Type: Machine 230 * Operation: Vlan-Move 232 * Variable: "HostVLANID ="infected-host.vlan 234 * Target: $$infected-host 236 * Destination: Quarantine VLAN ID 238 Project-Step: 240 o Id:4 241 o Type: Machine 243 * Operation: Host-Image 245 * Target: $$infected-host 247 * ImageName: Windows-Good-Image1 249 Project-Step: 251 o Id:5 253 o Type: Machine 255 * Operation: Vlan-Move 257 * Target: $$infected-host 259 * Destination: $$HostVLANID 261 END-STEPS 263 END-PROJECT 265 Example 2: Find and Remove Malware Project In this example, it is 266 described how a Collaborative Courses of Action Project defines how 267 an organization may find malware and then if found can remove the 268 malware from an infected host. The project defines both a more 269 complicated sequence of machine instructions as identified by the 270 MACHINE-SEQUENCE operation in Project-Step-Id{4}. 272 BEGIN-PROJECT 274 Project-Name: FindRemoveMalware1 Project-Trigger-Event: 276 o Indicator indicator-8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f defines a 277 malware hash $$inserthash that is known to identify a specific 278 malware file if found on a host system 280 o A trigger event may be defined in STIX2 282 o A trigger defines an entry point into the project steps as 283 follows. 285 BEGIN-STEPS 287 Project-Step: 289 o Id: 1 291 o Type: Human 293 * Question: Ask the user whether they wish to review the 294 mitigation procedures before proceeding? 296 * Answer-Y-or-N 298 + If Y: Proceed to Id: 2 300 + If N: Proceed to Id: 3 302 Project-Step: 304 o Id: 2 306 o Type: Human 308 * Operation: Display mitigation procedures. 310 Project-Step: 312 o Id:3 314 o Type: Machine 316 * Operation: Vlan-Move 318 * Variable: "HostVLANID ="infected-host.vlan 320 * Target: $$infected-host 322 * Destination: Quarantine VLAN ID 324 Project-Step: 326 o Id:4 328 o Type: Machine-Sequence { 330 * Delete run at start reg keys and triggers 332 * Reboot into SafeMode 334 * Kill process 3 then 1 then 2 336 * Delete temp files 337 * Delete compromised files from the system 339 * Delete other Reg keys 341 * Reboot system in to safe mode 343 * Verify processes do not restart 345 * Patch AV system 347 * Run updated AV scan 349 * Patch OS 351 * Run additional on-demand special AV scanners 353 * Reboot system to normal mode } 355 * Target: $$infected-host 357 Project-Step: 359 o Id:5 361 o Type: Machine 363 * Operation: Vlan-Move 365 * Target: $$infected-host 367 * Destination: $$HostVLANID 369 END-STEPS 371 END-PROJECTS 373 4. Requirements 375 Below is a list of high level requirements that this effort needs to 376 address. 378 o Multiple Actions: The solution needs to support the ability to 379 describe one or more actions that can be processed in a batch 380 manner or as-a-group. 382 o Data Protection, Integrity and Authentication (Rules for data in 383 motion and at rest): All requests and responses must be 384 confidential and therefore a secure protocol should be used to 385 convey these messages such as TLS (but not limited to). The COA 386 Projects and actions must be able to be encrypted (and optionally 387 signed) to ensure integrity and that they are only accessible by 388 authenticated and authorized users. 390 o Globally Unique Identifiers: All transactions (requests, 391 responses, and notifications) need to be able to be tracked, 392 monitored, and recorded for security and operational reasons, 393 including the ability to backout failed actions. This means 394 responses and notifications need a way to be tied back to the 395 original request. Globally unique identifiers apply to both the 396 COA Project and the COA Actions within the project. All 397 transactions tracked, monitored and recorded will be restricted to 398 the same management zone as the systems initiating the 399 transactions and operating on the results. All systems operating 400 in that management zone will support a common and agreed set of 401 privacy associated with those transactions such that no concerns 402 over loss of privacy or unexpected data exposure occurs. 404 o Reporting: Provide the ability to gather single and batch reports 405 of events for responses. All report events must have a timestamp, 406 identifier of original request or rule causing event, and option 407 for a full dump of matching data (network, endpoint config....etc) 408 to be included in the event record. The report could be either 409 synchronously requested or be an asynchronous event (syslog) with 410 periodic updates. 412 o Sequences of Atomic Actions: The ability to define an ordered list 413 of atomic actions that must be executed as a combined set rather 414 than as a sequence. 416 o Projects & Project Templates: These should support actions for 417 machine automation, human actions / intervention, and high level 418 conceptual actions. 420 o Customization: Provide the option to include custom actions in a 421 batch or set of atomic actions. 423 o Conditional Logic: This solution needs the ability to include 424 action sequences that can support conditional logic, logical and 425 comparative operators, and behavioral logic. 427 o Project Testing: Ability to support what-if deployments where a 428 defined COA Projects can be verified before deploying to a real 429 system or environment, and perhaps be able to identify all the 430 organizations that have tested it and verified it. 432 o Auditability: The solution needs the ability to provide full 433 confirmation (tracking and logging) of each COA and each action at 434 every transaction state. 436 o Digital Signature Chain / Attribution with Identified Signed 437 Topic: The solution needs the ability to track multiple digital 438 signatures to show a chain of trust where it identifies the 439 specific Signed Topic that is being signed. This solution should 440 also support multiple independent organizations signing and 441 verifying the correctness, accuracy, and validity of the COA 442 Project or individual action where the Signed Topic being signed 443 by that independent entity is specified. 445 o Input: One or more technical indicators, prioritization 446 indicators, and rule names (optional). 448 o Transport Methods: This solution needs to support the ability for 449 clients to send COAs directly to an end device (request/response) 450 and also to a communications channel (publish/subscribe). 452 o Versioning: The solution needs to support both incremental 453 versioning and semantic versioning, along with assertions that the 454 COA works with certain products. This will enable support of 455 multiple versions of a COA across products so that not all systems 456 are required to be the same version to implement COA Projects. 457 Newer COA Projects will provide information that allows consumers 458 to relate the new version to prior versions. 460 o Transactions: Needs the ability for systems to have the option to 461 support both atomic and non-atomic transactions. 463 o System Targeting: The solution needs the ability to identify the 464 type, version, patch level of one or more systems that this COA is 465 applicable for. 467 o Project Versioning: Need ability to version (and track) COA 468 Projects and Templates 470 o Data Markings: Need ability to support data marking at a COA 471 Project level such as the Traffic Light Protocol (TLP) for the 472 project. 474 o Command and Control Management Separation (Definition vs Execution 475 Environment): A COA Project (and the contained atomic COA actions) 476 may be defined in one system by one or more authors, but the COA 477 project may be executed in an operational environment where the 478 systems and users of those systems have different authentication 479 and authorizations for the COA. In order for the COA Project to 480 execute correctly it must have authorization in the operational 481 environment where it is executed. Therefore the credentials of 482 the authors should not be relied upon to execute correctly in the 483 execution environment. Also, the security environment executing 484 the COA Project will likely be different from where the COA 485 project was defined. 487 o Integration: Ensure that COA Projects can be used in and work with 488 existing threat intelligence data models, for example STIX. 490 o Flexibility: Allow the COA Project to benefit and leverage 491 existing capabilities available in 'the system' such as atomic 492 ways to exchange security commands 'a la openc2', or read from 493 available security capabilities in a standard way 'a la i2nsf' to 494 understand what it can actually do or to allow conditional COA 495 sequences 497 5. Architecture 499 A Collaborative Course of Action workflow will consist of several 500 components, including at least: 502 +----------+ +----------+ +----------+ +----------+ 503 | Define | --> | Verify | --> | Deliver | --> | Execute | 504 | COA Proj | <-- | COA Proj | | COA Proj | | COA Proj | 505 +----------+ +----------+ +----------+ +----------+ 506 ^ ^ ^ ^ 507 | | | | 508 | +--------------------------+ | 509 <-------- | Monitoring and Reporting | --------> 510 +--------------------------+ 512 o Define: Where a COA Project is defined based on various inputs 513 both automated and manually derived. 515 o Verify: Where a COA Project is reviewed for accuracy, correctness, 516 and is properly defined to execute correctly in a target 517 environment without making any changes to the target environment. 519 o Deliver: Where a COA Project is distributed to the systems that 520 will execute the COA Project. Distribution includes checking that 521 the COA Project has been deployed correctly and has followed the 522 rules defined within the project for atomic transactions. 524 o Execute: Where a COA Project is evaluated by one or more security 525 infrastructure systems and execution events are communicated to 526 the COA Project monitoring step. It can run either in full 527 execution or in verification mode. 529 o Monitoring: Where a COA Project execution is monitored and metrics 530 are determined on the COA Project to enable further refinement or 531 improvement to the COA Project definition. 533 6. Deliverables 535 This effort will need to produce and deliver the following documents: 537 1. An overview and architecture document 539 2. A COA Project data model in JSON / CBOR 541 3. Define how COA Projects will be distributed between each system 542 within the process including leveraging existing transport 543 mechanisms and any new APIs/Protocols required. 545 7. IANA Considerations 547 This memo includes no request to IANA. 549 8. Security Considerations 551 The solution described by this document provides a mechanism to 552 define a series of actions that can be applied to a network or host 553 system to prevent, mitigate, or remediate some threat. Discussion is 554 needed about how to protect such a mechanism and the information it 555 is managing from unauthorized access or disclosure. 557 In a principle of "who guards the guards" ("quis custodiet Ipsos 558 custodes" Juvenal, Satire VI, lines 347-348) it is essential to armor 559 the COA service against itself and to consider a COA-SELF project for 560 consistency and coherency where the target system of the COA is the 561 COA service itself. 563 A breach in the COA service would break the integrity of an entire 564 target system, potentially at extra large scale. 566 9. Privacy Considerations 568 Discussion is also needed about privacy considerations around how the 569 endpoint devices and systems are identified and to ensure that any 570 commands are encoded in a safe way and if the COA Project needs to 571 collect private data it is still compliant to privacy regulations and 572 offers all the mechanisms to guarantee compliance to such frameworks 573 such as auditability, security, encryption, right to be forgotten, 574 consents, etc. 576 Contributors 578 o Allen Hadden 579 IBM 580 ahadden@us.ibm.com 582 o David Waltermire 583 NIST 584 david.waltermire@nist.gov 586 o Efrain Ortiz 587 Symantec 588 efrain_ortiz@symantec.com 590 o Jason Keirstead 591 IBM 592 jason.keirstead@ca.ibm.com 594 o Jason Webb 595 LookingGlass Cyber 596 jwebb@lookingglasscyber.com 598 o Kyle Mackenzie 599 JPMC 600 Mackenzie.kyle@jpmorgan.com 602 o Subodh Kumar 603 JPMC 604 subodh.kumar@jpmorgan.com 606 o Swaroop Pradhan 607 JPMC 608 swaroop.s.pradhan@jpmorgan.com 610 o Vivek Jain 611 JPMC 612 vivek.jain@jpmchase.com 614 Authors' Addresses 615 Bret Jordan 616 Symantec Corporation 617 350 Ellis Street 618 Mountain View CA 94043 619 USA 621 Email: bret_jordan@symantec.com 623 Allan Thomson 624 LookingGlass Cyber 625 10740 Parkridge Blvd, Suite 200 626 Reston VA 20191 627 USA 629 Email: athomson@lookingglasscyber.com 631 Jyoti Verma 632 Cisco Systems 633 170 West Tasman Dr. 634 San Jose CA 95134 635 USA 637 Email: jyoverma@cisco.com