idnits 2.17.1 draft-ietf-sacm-use-cases-02.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 (October 14, 2013) is 3841 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 490, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Automation and Continuous Monitoring WG D. Waltermire 3 Internet-Draft NIST 4 Intended status: Informational D. Harrington 5 Expires: April 17, 2014 Effective Software 6 October 14, 2013 8 Endpoint Security Posture Assessment - Enterprise Use Cases 9 draft-ietf-sacm-use-cases-02 11 Abstract 13 This memo documents a sampling of use cases for securely aggregating 14 configuration and operational data and assessing that data to 15 determine an organization's security posture. From these operational 16 use cases, we can derive common functional capabilities and 17 requirements to guide development of vendor-neutral, interoperable 18 standards for aggregating and assessing data relevant to security 19 posture. 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 http://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 April 17, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 (http://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 3 57 2.1. Definition and Publication of Automatable Configuration 58 Guides . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Automated Checklist Verification . . . . . . . . . . . . 5 60 2.3. Organizational Software Policy Compliance . . . . . . . . 6 61 2.4. Detection of Posture Deviations . . . . . . . . . . . . . 6 62 2.5. Search for Signs of Infection . . . . . . . . . . . . . . 6 63 2.6. Remediation and Mitigation . . . . . . . . . . . . . . . 7 64 2.7. Endpoint Information Analysis and Reporting . . . . . . . 7 65 2.8. Others... . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 7 71 6.2. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 8 72 6.3. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 73 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 9 74 6.4. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 9 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 7.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Our goal with this document is to improve our agreement on which 83 problems we're trying to solve. We need to start with short, simple 84 problem statements and discuss those by email and in person. Once we 85 agree on which problems we're trying to solve, we can move on to 86 propose various solutions and decide which ones to use. 88 This document describes example use cases for endpoint posture 89 assessment for enterprises. It provides a sampling of use cases for 90 securely aggregating configuration and operational data and assessing 91 that data to determine the security posture of individual endpoints, 92 and, in the aggregate, the security posture of an enterprise. 94 These use cases cross many IT security information domains. From 95 these operational use cases, we can derive common concepts, common 96 information expressions, functional capabilities and requirements to 97 guide development of vendor-neutral, interoperable standards for 98 aggregating and assessing data relevant to security posture. 100 Using this standard data, tools can analyze the state of endpoints, 101 user activities and behaviour, and assess the security posture of an 102 organization. Common expression of information should enable 103 interoperability between tools (whether customized, commercial, or 104 freely available), and the ability to automate portions of security 105 processes to gain efficiency, react to new threats in a timely 106 manner, and free up security personnel to work on more advanced 107 problems. 109 The goal is to enable organizations to make informed decisions that 110 support organizational objectives, to enforce policies for hardening 111 systems, to prevent network misuse, to quantify business risk, and to 112 collaborate with partners to identify and mitigate threats. 114 It is expected that use cases for enterprises and for service 115 providers will largely overlap, but there are additional 116 complications for service providers, especially in handling 117 information that crosses administrative domains. 119 The output of endpoint posture assessment is expected to feed into 120 additional processes, such as policy-based enforcement of acceptable 121 state, verification and monitoring of security controls, and 122 compliance to regulatory requirements. 124 2. Endpoint Posture Assessment 126 Endpoint posture assessment involves orchestrating and performing 127 data collection and analysis pertaining to the posture of a given 128 endpoint. Typically, endpoint posture information is gathered and 129 then published to appropriate data repositories to make collected 130 information available for further analysis supporting organizational 131 security processes. 133 Endpoint posture assessment typically includes: 135 o Collecting the posture of a given endpoint; 137 o Making that posture available to the enterprise for further 138 analysis and action; and 140 o Performing analysis to assess that the endpoint's posture is in 141 compliance with enterprise standards and policy. 143 As part of these activities it is often necessary to identify and 144 acquire any supporting content that is needed to drive data 145 collection and analysis. 147 The following is a typical workflow scenario for assessing endpoint 148 posture: 150 1. Define a target endpoint to be assessed 152 2. Select policies applicable to the target, and identify what 153 posture attributes need to be collected for assessment. 155 3. Verify the identity of the target being assessed 157 4. Collect posture attributes from the target 159 5. Communicate target identity and collected attributes to external 160 system for evaluation 162 6. Evaluator compares collected posture attributes from the target 163 with expected values as expressed in policies 165 The following subsections detail specific use cases for data 166 collection, analysis, and related operations pertaining to the 167 publication and use of supporting content. 169 2.1. Definition and Publication of Automatable Configuration Guides 171 A network device vendor manufactures a number of enterprise grade 172 routers and other network devices. They also develop and maintain an 173 operating system for these devices that enables end-user 174 organizations to configure a number of security and operational 175 settings for these devices. As part of their customer support 176 activities, they publish a number of secure configuration guides that 177 provide minimum security guidelines for configuring their devices. 179 Each guide they produce applies to a specific model of device and 180 version of the operating system and provides a number of specialized 181 configurations depending on the devices intended function and what 182 add-on hardware modules and software licenses are installed on the 183 device. To enable their customers to assess the security posture of 184 their devices to ensure that all appropriate minimal security 185 settings are enabled, they publish an automatable configuration 186 checklist using a popular data format that defines what settings to 187 check using a network management protocol and appropriate values for 188 each setting. They publish these guides to a public content 189 repository that customers can query to retrieve applicable guides for 190 their deployed enterprise network infrastructure endpoints. 192 Guides could also come from sources other than a device vendor, such 193 as industry groups or regulatory authorities, or enterprises could 194 develop their own checklists. 196 QUESTION: This use case applies equally to vendors representing other 197 endpoint types. Should this be generalized to capture this notion? 199 QUESTION: Is providing traceability to functional capabilities 200 useful? If so, we need to replicate this for the other use cases. 202 2.2. Automated Checklist Verification 204 A financial services company operates a heterogeneous IT environment. 205 In support of their risk management program, they utilize vendor 206 provided automatable security configuration checklists for each 207 operating system and application used within their IT environment. 208 Multiple checklists are used from different vendors to insure 209 adequate coverage of all IT assets. 211 To identify what checklists are needed, they use automation to gather 212 an inventory of the software versions utilized by all IT assets in 213 the enterprise. This data gathering will involve querying existing 214 data stores of previously collected endpoint software inventory 215 posture data and actively collecting data from reachable endpoints as 216 needed utilizing network and systems management protocols. 217 Previously collected data may be provided by periodic data 218 collection, network connection-driven data collection, or ongoing 219 event-driven monitoring of endpoint posture changes. 221 Using the gathered software inventory data and associated asset 222 management data indicating the organizational defined functions of 223 each endpoint, they locate and query each vendors content repository 224 for the appropriate checklists. These checklists are cached locally 225 to reduce the need to download the checklist multiple times. 227 Driven by the setting data provided in the checklist, a combination 228 of existing configuration data stores and data collection methods are 229 used to gather the appropriate posture information from each 230 endpoint. Specific data is gathered based on the defined enterprise 231 function and software inventory of each endpoint. The data 232 collection paths used to collect software inventory posture will be 233 used again for this purpose. Once the data is gathered, the actual 234 state is evaluated against the expected state criteria in each 235 applicable checklist. Deficiencies are identified and reported to 236 the appropriate endpoint operators for remedy. 238 Checklists could also come from sources other than the application or 239 OS vendor, such as industry groups or regulatory authorities, or 240 enterprises could develop their own checklists. 242 2.3. Organizational Software Policy Compliance 244 Example Corporation, in support of compliance requirements, has 245 identified a number of secure baselines for different endpoint types 246 that exist across their enterprise IT environment. Determining which 247 baseline applies to a given endpoint is based on the organizationally 248 defined function of the device. 250 Each baseline, defined using an automatable standardized data format, 251 identifies the expected hardware, software and patch inventory, and 252 software configuration item values for each endpoint type. As part 253 of their compliance activities, they require that all endpoints 254 connecting to their network meet the appropriate baselines. Each 255 endpoint is checked to make sure it complies with the appropriate 256 baseline whenever it connects to the network and at least once a day 257 thereafter. These daily compliance checks assess the posture of each 258 endpoint and report on its compliance with the appropriate baseline. 260 [TODO: Need to speak to how the baselines are identified for a given 261 endpoint connecting to the network.] 263 2.4. Detection of Posture Deviations 265 Example corporation has established secure configuration baselines 266 for each different type of endpoint within their enterprise 267 including: network infrastructure, mobile, client, and server 268 computing platforms. These baselines define an approved list of 269 hardware, software (i.e., operating system, applications, and 270 patches), and associated required configurations. When an endpoint 271 connects to the network, the appropriate baseline configuration is 272 communicated to the endpoint based on its location in the network, 273 the expected function of the device, and other asset management data. 274 It is checked for compliance with the baseline indicating any 275 deviations to the device's operators. Once the baseline has been 276 established, the endpoint is monitored for any change events 277 pertaining to the baseline on an ongoing basis. When a change occurs 278 to posture defined in the baseline, updated posture information is 279 exchanged allowing operators to be notified and/or automated action 280 to be taken. 282 2.5. Search for Signs of Infection 284 TODO 286 2.6. Remediation and Mitigation 288 TODO 290 2.7. Endpoint Information Analysis and Reporting 292 TODO 294 2.8. Others... 296 Additional use cases will be identified as we work through other 297 domains. 299 3. IANA Considerations 301 This memo includes no request to IANA. 303 4. Security Considerations 305 This memo documents, for Informational purposes, use cases for 306 security automation. While it is about security, it does not affect 307 security. 309 5. Acknowledgements 311 The National Institute of Standards and Technology (NIST) and/or the 312 MITRE Corporation have developed specifications under the general 313 term "Security Automation" including languages, protocols, 314 enumerations, and metrics. 316 The authors would like to recognize and thank Adam Montville for his 317 work on early edits of this draft. Additionally, the authors would 318 like to thank Kathleen Moriarty and Stephen Hanna for contributing 319 text to this document. The authors would also like to acknowledge 320 the members of the SACM mailing list for their keen and insightful 321 feedback on the concepts and text within this document. 323 6. Change Log 325 6.1. -00- to -01- 327 Changed title 329 removed section 4, expecting it will be moved into the requirements 330 document. 332 removed the list of proposed caabilities from section 3.1 333 Added empty sections for Search for Signs of Infection, Remediation 334 and Mitigation, and Endpoint Information Analysis and Reporting. 336 Removed Requirements Language section and rfc2119 reference. 338 Removed unused references (which ended up being all references). 340 6.2. -00- to -01- 342 o Work on this revision has been focused on document content 343 relating primarily to use of asset management data and functions. 345 o Made significant updates to section 3 including: 347 * Reworked introductory text. 349 * Replaced the single example with multiple use cases that focus 350 on more discrete uses of asset management data to support 351 hardware and software inventory, and configuration management 352 use cases. 354 * For one of the use cases, added mapping to functional 355 capabilities used. If popular, this will be added to the other 356 use cases as well. 358 * Additional use cases will be added in the next revision 359 capturing additional discussion from the list. 361 o Made significant updates to section 4 including: 363 * Renamed the section heading from "Use Cases" to "Functional 364 Capabilities" since use cases are covered in section 3. This 365 section now extrapolates specific functions that are needed to 366 support the use cases. 368 * Started work to flatten the section, moving select subsections 369 up from under asset management. 371 * Removed the subsections for: Asset Discovery, Endpoint 372 Components and Asset Composition, Asset Resources, and Asset 373 Life Cycle. 375 * Renamed the subsection "Asset Representation Reconciliation" to 376 "Deconfliction of Asset Identities". 378 * Expanded the subsections for: Asset Identification, Asset 379 Characterization, and Deconfliction of Asset Identities. 381 * Added a new subsection for Asset Targeting. 383 * Moved remaining sections to "Other Unedited Content" for future 384 updating. 386 6.3. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 388 o Transitioned from individual I/D to WG I/D based on WG consensus 389 call. 391 o Fixed a number of spelling errors. Thank you Erik! 393 o Added keywords to the front matter. 395 o Removed the terminology section from the draft. Terms have been 396 moved to: draft-dbh-sacm-terminology-00 398 o Removed requirements to be moved into a new I/D. 400 o Extracted the functionality from the examples and made the 401 examples less prominent. 403 o Renamed "Functional Capabilities and Requirements" section to "Use 404 Cases". 406 * Reorganized the "Asset Management" sub-section. Added new text 407 throughout. 409 + Renamed a few sub-section headings. 411 + Added text to the "Asset Characterization" sub-section. 413 o Renamed "Security Configuration Management" to "Endpoint 414 Configuration Management". Not sure if the "security" distinction 415 is important. 417 * Added new sections, partially integrated existing content. 419 * Additional text is needed in all of the sub-sections. 421 o Changed "Security Change Management" to "Endpoint Posture Change 422 Management". Added new skeletal outline sections for future 423 updates. 425 6.4. -04- to -05- 426 o Are we including user activities and behavior in the scope of this 427 work? That seems to be layer 8 stuff, appropriate to an IDS/IPS 428 application, not Internet stuff. 430 o I removed the references to what the WG will do because this 431 belongs in the charter, not the (potentially long-lived) use cases 432 document. I removed mention of charter objectives because the 433 charter may go through multiple iterations over time; there is a 434 website for hosting the charter; this document is not the correct 435 place for that discussion. 437 o I moved the discussion of NIST specifications to the 438 acknowledgements section. 440 o Removed the portion of the introduction that describes the 441 chapters; we have a table of concepts, and the existing text 442 seemed redundant. 444 o Removed marketing claims, to focus on technical concepts and 445 technical analysis, that would enable subsequent engineering 446 effort. 448 o Removed (commented out in XML) UC2 and UC3, and eliminated some 449 text that referred to these use cases. 451 o Modified IANA and Security Consideration sections. 453 o Moved Terms to the front, so we can use them in the subsequent 454 text. 456 o Removed the "Key Concepts" section, since the concepts of ORM and 457 IRM were not otherwise mentioned in the document. This would seem 458 more appropriate to the arch doc rather than use cases. 460 o Removed role=editor from David Waltermire's info, since there are 461 three editors on the document. The editor is most important when 462 one person writes the document that represents the work of 463 multiple people. When there are three editors, this role marking 464 isn't necessary. 466 o Modified text to describe that this was specific to enterprises, 467 and that it was expected to overlap with service provider use 468 cases, and described the context of this scoped work within a 469 larger context of policy enforcement, and verification. 471 o The document had asset management, but the charter mentioned 472 asset, change, configuration, and vulnerability management, so I 473 added sections for each of those categories. 475 o Added text to Introduction explaining goal of the document. 477 o Added sections on various example use cases for asset management, 478 config management, change management, and vulnerability 479 management. 481 7. References 483 7.1. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 7.2. Informative References 490 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 491 "Remote Authentication Dial In User Service (RADIUS)", RFC 492 2865, June 2000. 494 Authors' Addresses 496 David Waltermire 497 National Institute of Standards and Technology 498 100 Bureau Drive 499 Gaithersburg, Maryland 20877 500 USA 502 Email: david.waltermire@nist.gov 504 David Harrington 505 Effective Software 506 50 Harding Rd 507 Portsmouth, NH 03801 508 USA 510 Email: ietfdbh@comcast.net