idnits 2.17.1 draft-waltermire-sacm-use-cases-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 16, 2012) is 4300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IF-MAP' is mentioned on line 222, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-nea-pt-eap-02 == Outdated reference: A later version (-08) exists of draft-ietf-nea-pt-tls-05 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Waltermire, Ed. 3 Internet-Draft NIST 4 Intended status: Informational July 16, 2012 5 Expires: January 17, 2013 7 Analysis of Security Automation and Continuous Monitoring (SACM) Use 8 Cases 9 draft-waltermire-sacm-use-cases-01 11 Abstract 13 This document identifies foundational use cases, derived functional 14 capabilities and requirements, architectural components, and the 15 supporting standards needed to define an interoperable, automation 16 infrastructure required to support timely, accurate and actionable 17 situational awareness over an organization's IT systems. Automation 18 tools implementing a continuous monitoring approach will utilize this 19 infrastructure together with existing and emerging event, incident 20 and network management standards to provide visibility into the state 21 of assets, user activities and network behavior. Stakeholders will 22 be able to use these tools to aggregate and analyze relevant security 23 and operational data to understand the organizations security 24 posture, quantify business risk, and make informed decisions that 25 support organizational objectives while protecting critical 26 information. Organizations will be able to use these tools to 27 augment and automate information sharing activities to collaborate 28 with partners to identify and mitigate threats. Other automation 29 tools will be able to integrate with these capabilities to enforce 30 policies based on human decisions to harden systems, prevent misuse 31 and reduce the overall attack surface. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 17, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. UC1: Assessment and Enforcement of Acceptable State . . . 4 72 3.2. UC2: Behavioral Monitoring and Enforcement . . . . . . . . 5 73 3.3. UC3: Security Control Verification and Monitoring . . . . 6 74 3.4. UC4: Secure Exchange of Risk and Compliance Information . 6 75 3.5. UC5: Automated Forensics Investigation . . . . . . . . . . 7 76 4. Functional Capabilities . . . . . . . . . . . . . . . . . . . 10 77 4.1. Functional Capability 1 . . . . . . . . . . . . . . . . . 10 78 4.2. Functional Capability n . . . . . . . . . . . . . . . . . 10 79 5. Functional Components . . . . . . . . . . . . . . . . . . . . 10 80 6. Data Exchange Models and Communications Protocols . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 87 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 This document addresses foundational use cases in security 93 automation. Portions of these use cases may be considered when 94 establishing a charter for the Security Automation and Continuous 95 Monitoring (SACM) working group within the IETF. This working group 96 will address a portion of the standards needed to define an 97 interoperable, automation infrastructure required to support timely, 98 accurate and actionable situational awareness over an organization's 99 IT systems. This document enumerates use cases and break down 100 related concepts that cross many IT security information domains. 102 Sections [...] of this document focus on: 104 Defining the key concepts and terminology used within the document 105 providing a common frame of reference; 107 Identifying foundational use cases that represent classes of 108 stakeholders, goals, and usage scenarios; 110 A set of derived functional capabilities and associated 111 requirements that are needed to support the use cases; 113 A break down of architectural components that address one or more 114 functional capabilities that can be used in various combinations 115 to support the use cases; and 117 An inventory of existing, emerging, and needed data exchange 118 models and communications protocols that are required to support 119 interoperability between architectural components. 121 The standards identified in this document provide a foundation for 122 creating interoperable automation tools and continuous monitoring 123 solutions that provide visibility into the state of assets, user 124 activities, and network behavior. Stakeholders will be able to use 125 these tools to aggregate and analyze relevant security and 126 operational data to understand the organizations security posture, 127 quantify business risk, and make informed decisions that support 128 organizational objectives while protecting critical information. 129 Organizations will be able to use these tools to augment and automate 130 information sharing activities to collaborate with partners to 131 identify and mitigate threats. Other automation tools will be able 132 to integrate with these capabilities to enforce policies based on 133 human decisions to harden systems, prevent misuse and reduce the 134 overall attack surface. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. Key Concepts 144 Define/reference the major concepts included in this document. 146 3. Use Cases 148 Describe use cases, one per sub-section. 150 Things to consider including (but not limited to): 152 o Usage scenarios (e.g. Security Control Verification, Endpoint 153 Enforcement, Incident Detection, Forensic Investigation, etc.) 155 o Information Domains (e.g. configuration, vulnerability, digital 156 events, etc.) 158 o Characteristics of the information used (e.g. real-time/periodic, 159 static/dynamic, etc.) 161 3.1. UC1: Assessment and Enforcement of Acceptable State 163 Controlling access to networks and services based on the assessment 164 and analysis of host and/or network state based on machine 165 processable content. 167 Possible "things" that are being measured: 169 o Asset information (e.g., Asset identification, ARF, ASR) 171 o System configuration (e.g., SCAP) 173 o System vulnerabilities (e.g., SCAP) 175 o System weaknesses 177 o Semi-automated human interrogation methods to assess non- 178 automatable, technical controls (e.g., OCIL) 180 Possible desired outcomes to address: 182 o User/system is allowed access to network resources 184 o User/system is denied access to network resources 186 * Potential mitigation actions are taken 188 The Network Endpoint Assessment (NEA) protocols (PA-TNC [RFC5792], 189 PB-TNC [RFC5793], PT-TLS [I-D.ietf-nea-pt-tls], and PT-EAP 190 [I-D.ietf-nea-pt-eap]) may be used to query and transport the things 191 to be measured, as well as providing for manual or automated 192 remediation and mitigation. SCAP content (XCCDF, OVAL, OCIL, etc.) 193 may be transported over the NEA protocols to indicate which things 194 are to be measured and send the results of the measurements. And 195 enforcement may be implemented with RADIUS [RFC2865] or DIAMETER 196 [RFC3588]. 198 3.2. UC2: Behavioral Monitoring and Enforcement 200 Controlling access to networks and services based on the detection 201 and analysis of host and/or user behavior using automatable 202 information from various sources. 204 Possible "things" that are being measured: 206 o System configuration 208 o System vulnerabilities 210 o Network events 212 o User/host behavior 214 Possible desired outcomes to address: 216 o Change in state is recorded and reported 218 o User/system activity is recorded and reported 220 o User/system access is terminated or altered 222 The Trusted Computing Group's [IF-MAP] protocol provides a standard 223 way to rapidly share events and updates related to user/device 224 behavior and network events, enabling logging or swift response such 225 as reduced or terminated access. 227 Possible other things to address: 229 o Discuss how this could potentially be related to the IP Flow 230 Information Export (ipfix) working group. Basically leveraging 231 Netflow to detect network behavior. This information could be 232 received from what the MILE WG is doing with incident response. 233 (see UC5 and UC4) 235 o Relevant processes, technologies and techniques. 237 3.3. UC3: Security Control Verification and Monitoring 239 Continuous assessment of the implementation and effectiveness of 240 security controls based on machine processable content. 242 Possible "things" that are being measured: 244 o Compliance to organizationally defined/required controls 246 * System configuration 248 * System vulnerabilities 250 * Network events 252 * Semi-automated human interrogation methods to assess non- 253 technical controls 255 o Deviations from expected state 257 Possible desired outcomes to address: 259 o Compliance or non-compliance is recorded and reported 261 This use case extends UC1 to ensure that changes to the things 262 measured in UC1 are rapidly detected, reported, and optionally 263 responded to with manual or automated remediation and mitigation. 265 Possible other things to address: 267 o Relevant processes, technologies and techniques. 269 3.4. UC4: Secure Exchange of Risk and Compliance Information 271 Sharing security and/or operationally relevant information within and 272 across trust boundaries using secure, automated communication 273 channels and formats. 275 Possible "things" that are being measured: 277 o ??? 279 Possible desired outcomes to address: 281 o Combining results from UC1-UC3, a report to an organizational 282 authority is generated, including relevant data pertaining to the 283 user activities, potentially along with the aggregated data from 284 other user activities. 286 o Aggregate/roll-up reporting of organizational, security-oriented 287 information in response to pre-arranged and ad hoc, automated data 288 requests. 290 o Potential sharing of risk and/or threat behavioral information 291 with partners as well as reference data and content like USGCB, 292 NVD, IAVM, and machine-readable US-CERT alerts 294 o Outcome of UC4 informs back through UC1-UC3, such as updates to 295 digitial policies, adjusted configurations, new patch data, etc. 297 Possible other things to address: 299 o Indicate the relationship of this use case to UC3 and UC5. This 300 use case supports requests for and reporting of information 301 generated by UC3 and UC5. 303 o Be sure to incorporate Incident/Security Event Exchange (UC5). 305 o Document how this use case supports methods to combine data sets 306 to generate reports that would be shared between parties. This is 307 a touch point with the MILE GRC-Exchange work. Establish the use 308 cases for the exchange. In the following sections, discuss 309 additional work that may be needed to tie these pieces together 311 o Discuss the use of content repositories in support of information 312 exchange. 314 o Relevant processes, technologies and techniques. 316 3.5. UC5: Automated Forensics Investigation 318 Remote and/or local collection of organizational, network, and/or 319 host information to generate situational awareness that will serve as 320 an input to enhance incident detection, investigation, and response 321 activities. 323 Possible "things" that are being measured: 325 o Scope and impact of security incident 327 * Coverage of situational awareness for the assets monitored 328 (trending as improvements are made and new data sources are 329 added for each of the above use cases) 331 * Time to detect compliance and security issues/problems from 332 increased capabilities to automate continuous monitoring 334 * Time to resolve issues/problems detected from continuous 335 monitoring solutions and improvements (trending) to demonstrate 336 prevention capability improvements 338 * Number of low, medium, and high level threats to assets 339 (considering the criticality of those assets) using the 340 combined situational awareness, continuous monitoring, and 341 feeds of known vulnerability information, static and over time. 343 * Variations in behavior to enhance detection capabilities 344 through increased situational awareness gained from UC1, UC2, 345 and UC3 347 * Impact of security incidents trending against improvements in 348 situational awareness capabilities 350 * Time to detect, quarantine, and remediate incidents, trending 351 over time for each measurement, correlated to improvements in 352 situational awareness and continuous monitoring. 354 * Impact of security incidents measured by time, monetary impact, 355 reputation and other factors. The trending of these 356 measurements as improvements are made to situational awareness 357 and continuous monitoring is a critical key performace 358 indicator for the security program. 360 Possible desired outcomes to address: 362 o Identify the need for additional data collection from UC1-UC3 363 based on gaps in information currently collected 365 o Can be informed by UC4, such as shared risk/threat information 367 o Intersect data and analysis provided from UC1, UC2, and UC3 with 368 threat and vulnerability information to enable detection of 369 incidents via event information related to the described 370 intersection. 372 o Alteration to acceptable system state requirements necessary for 373 UC1-UC2 375 o Identify the need for additional or altered controls to be 376 addressed by UC3 378 o Identify the appropriate techniques and data sources necessary to 379 build situational awareness and continuous monitoring solutions 380 using standards to provide improved prevention and detection 381 capabilities. This step does not perform the analysis, but 382 provides the data and techniques to obtain the data to enable the 383 necessary analysis capabilities. 385 Possible other things to address: 387 o Relevant processes, technologies and techniques. 389 o Determine standard inputs to create situational awareness, leaving 390 analysis out-of-scope to enable innovation. The relevant 391 techniques will be addressed in UC1-UC4. 393 o Determine existing sets of processes, technologies, and techniques 394 that may be leveraged specific to increased awareness of incidents 395 and current threats through sharing indicators of compromise. 396 Examples include, but are not limited to: 398 * RFC5070, Incident Object Description Exchange Format (IODEF) 400 * RFC6545, Real-time Inter-network Defense (RID) 402 * RFC6546, Transport of Real-time Inter-network Defense over 403 HTTP/TLS 405 * Extensions to IODEF such as: 407 + RFC5901, Extension to IODEF-Document Class for Reporting 408 Phishing 410 + RFC5941, Sharing Transaction Fraud Data 412 + IODEF-extension to support structured cyber security 413 information: 415 - http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ 417 + Forensics extension 418 + Etc. 420 4. Functional Capabilities 422 Decompose the functional capabilities needed to support the use 423 cases, one per sub-section. Cross reference the use case 424 dependencies where they exist. 426 Things to consider including (but not limited to): 428 o Information Views/Reports (e.g. security posture, compliance, 429 control effectiveness) 431 o Data Collection (e.g. configuration state, software inventory, 432 user and network behavior) 434 o Reference Information Formats (e.g. control catalogs, 435 configuration baselines, malware characteristics, vulnerability 436 data) 438 4.1. Functional Capability 1 440 Describe the first capability. 442 4.2. Functional Capability n 444 Describe the n capability. 446 5. Functional Components 448 Describe the abstract functional components needed to provide the 449 capabilities described in the previous section. Describe any 450 relationships between the components and how they can be composed to 451 address functional capabilities. (this might be better defined in the 452 previous section.) 454 Things to consider including (but not limited to): 456 o Topologies 458 o Federation Strategy 460 6. Data Exchange Models and Communications Protocols 462 Document where existing work exists, what is currently defined by 463 SDOs, and any gaps that should be addressed. Point to existing 464 event, incident and network management standards when available. 465 Describe emerging efforts that may be used for the creation of new 466 standards. For gaps provide insight into what would be a good fit 467 for SACM or another IETF working groups. 469 This will help us to identify what is needed for SACM to be 470 successful. This section will help determine which of the 471 specifications can be normatively referenced and what needs to be 472 addressed in the IETF. This should help us determine any protocol or 473 guidance documentation we will need to generate to support the 474 described use cases. 476 Things to address: 478 For IETF related efforts, discuss work in NEA and MILE working 479 groups. Address SNMP, NetConf and other efforts as needed. 481 Reference any Security Automation work that is applicable. 483 7. IANA Considerations 485 This memo includes no request to IANA. 487 All drafts are required to have an IANA considerations section (see 488 RFC 5226 [RFC5226] for a guide). If the draft does not require IANA 489 to do anything, the section contains an explicit statement that this 490 is the case (as above). If there are no requirements for IANA, the 491 section will be removed during conversion into an RFC by the RFC 492 Editor. 494 8. Security Considerations 496 All drafts are required to have a security considerations section. 497 See RFC 3552 [RFC3552] for a guide. 499 9. Acknowledgements 501 The author would like to thank Kathleen Moriarty and Stephen Hanna 502 for contributing text to this document. The author would also like 503 to acknowledge the members of the SACM mailing list for thier keen 504 and insightful feedback on the concepts and text within this 505 document. 507 10. References 509 10.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 10.2. Informative References 516 [I-D.ietf-nea-pt-eap] 517 Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 518 (PT) Protocol For EAP Tunnel Methods", 519 draft-ietf-nea-pt-eap-02 (work in progress), May 2012. 521 [I-D.ietf-nea-pt-tls] 522 Sangster, P., Cam-Winget, N., and J. Salowey, "PT-TLS: A 523 TCP-based Posture Transport (PT) Protocol", 524 draft-ietf-nea-pt-tls-05 (work in progress), May 2012. 526 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 527 "Remote Authentication Dial In User Service (RADIUS)", 528 RFC 2865, June 2000. 530 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 531 Text on Security Considerations", BCP 72, RFC 3552, 532 July 2003. 534 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 535 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 537 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 538 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 539 May 2008. 541 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 542 (PA) Protocol Compatible with Trusted Network Connect 543 (TNC)", RFC 5792, March 2010. 545 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 546 A Posture Broker (PB) Protocol Compatible with Trusted 547 Network Connect (TNC)", RFC 5793, March 2010. 549 Appendix A. Additional Stuff 551 This becomes an Appendix if needed. 553 Author's Address 555 David Waltermire (editor) 556 National Institute of Standards and Technology 557 100 Bureau Drive 558 Gaithersburg, Maryland 20877 559 USA 561 Phone: 562 Email: david.waltermire@nist.gov