idnits 2.17.1 draft-ietf-sacm-vuln-scenario-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 (September 9, 2016) is 2757 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-coffin-sacm-nea-swid-patnc-01 == Outdated reference: A later version (-18) exists of draft-ietf-sacm-requirements-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM C. Coffin 3 Internet-Draft B. Cheikes 4 Intended status: Informational C. Schmidt 5 Expires: March 13, 2017 D. Haynes 6 The MITRE Corporation 7 J. Fitzgerald-McKay 8 Department of Defense 9 D. Waltermire 10 National Institute of Standards and Technology 11 September 9, 2016 13 SACM Vulnerability Assessment Scenario 14 draft-ietf-sacm-vuln-scenario-02 16 Abstract 18 This document describes an automated enterprise vulnerability 19 assessment scenario aligned with the SACM Use Cases. The scenario 20 assumes the existence of endpoint management capabilities and begins 21 with an enterprise ingesting vulnerability description information. 22 Endpoints are assessed against the vulnerability description 23 information based on a combination of examining known endpoint 24 characterization information and collected endpoint information. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 13, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Vulnerability Assessment Pre-requisites . . . . . . . . . . . 4 64 4.1. Endpoint Management Capabilities . . . . . . . . . . . . 5 65 4.2. Vulnerability Description Information . . . . . . . . . . 5 66 5. Endpoint Vulnerability Assessment Capabilities . . . . . . . 5 67 6. Vulnerability Assessment Results . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 9. Informative References . . . . . . . . . . . . . . . . . . . 7 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 72 A.1. Changes in Revision -02 . . . . . . . . . . . . . . . . . 8 73 A.2. Changes in Revision -01 . . . . . . . . . . . . . . . . . 9 74 A.3. Changes Since Adopted as a WG I-D -00 . . . . . . . . . . 9 75 A.4. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 10 76 Appendix B. Implementation Examples . . . . . . . . . . . . . . 11 77 B.1. Endpoint Data Collection . . . . . . . . . . . . . . . . 11 78 B.2. Vulnerability Description Information . . . . . . . . . . 12 79 B.3. Secondary Assessment . . . . . . . . . . . . . . . . . . 12 80 B.4. Assessment Results . . . . . . . . . . . . . . . . . . . 13 81 Appendix C. Priority . . . . . . . . . . . . . . . . . . . . . . 13 82 Appendix D. SACM Usage Scenarios . . . . . . . . . . . . . . . . 14 83 Appendix E. SACM Requirements and Charter - Future Work . . . . 16 84 Appendix F. SACM Use Case Alignment . . . . . . . . . . . . . . 16 85 F.1. Endpoint Identification . . . . . . . . . . . . . . . . . 16 86 F.2. Endpoint Data Collection . . . . . . . . . . . . . . . . 16 87 F.3. Vulnerability Description Information . . . . . . . . . . 17 88 F.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 17 89 F.5. Secondary Assessment . . . . . . . . . . . . . . . . . . 17 90 F.6. Assessment Results . . . . . . . . . . . . . . . . . . . 18 91 Appendix G. Alignment with Other Existing Works . . . . . . . . 18 92 G.1. Critical Security Controls . . . . . . . . . . . . . . . 18 93 G.1.1. Continuous Vulnerability Assessment . . . . . . . . . 18 94 G.1.2. Hardware and Software Inventories . . . . . . . . . . 19 95 Appendix H. Continuous Vulnerability Assessment . . . . . . . . 20 96 Appendix I. Data Attribute Table . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 This document describes a detailed, enterprise-specific vulnerability 102 assessment scenario from which information model elements can be 103 discovered. This scenario also informs protocol and data model 104 development in support of vulnerability assessment, as part of 105 overall posture assessment (see Appendix B for examples of solutions 106 that support this scenario). 108 Vulnerability discovery, disclosure, publication, and prioritization 109 is out of scope. However, given the importance of prioritization in 110 an enterprise's vulnerability assessment process, it is discussed in 111 Appendix C. 113 Information on how the scenario aligns with SACM and other existing 114 work is discussed in Appendix D through Appendix G. 116 2. Terminology 118 Vulnerability description information: Information pertaining to the 119 existence of a flaw or flaws in software, hardware, and/or 120 firmware, which could potentially have an adverse impact on 121 enterprise IT functionality and/or security. Vulnerability 122 description information should contain enough information to 123 support vulnerability detection. 125 Vulnerability detection data: A type of guidance extracted or 126 derived from vulnerability description information that 127 describes the specific mechanisms of vulnerability detection 128 that is used by an enterprise's vulnerability management 129 capabilities to determine if a vulnerability is present on an 130 endpoint. 132 Endpoint management capabilities: An enterprise IT department's 133 ability to manage endpoint identity, endpoint information, and 134 associated metadata on an ongoing basis. 136 Vulnerability management capabilities: An enterprise IT department's 137 ability to manage endpoint vulnerabilities and associated 138 metadata on an ongoing basis by ingesting vulnerability 139 description information and vulnerability detection data, and 140 performing vulnerability assessments. 142 Vulnerability assessment capabilities: An enterprise IT department's 143 ability to determine whether a set of endpoints is vulnerable 144 according to the information contained in the vulnerability 145 description information. 147 3. Assumptions 149 A number of assumptions must be stated in order to further clarify 150 the position and scope of this document. 152 The document assumes that: 154 o The enterprise has received vulnerability description information, 155 and that the information has already been processed into 156 vulnerability detection data that the enterprise's security 157 software tools can understand and use. 159 o The enterprise has a means of identifying enterprise endpoints 160 through the execution of Target Endpoint Discovery Tasks although 161 assertions about some details of this capability are made. 163 o The enterprise has a means of extracting relevant information 164 about enterprise endpoints in a form that is compatible with the 165 vulnerability description data. 167 o All information described in this scenario is available in the 168 vulnerability description data and serves as the basis of 169 assessments. 171 o The enterprise can provide all relevant information about any 172 endpoint needed to perform the described assessment. 174 o The enterprise has a mechanism for long-term storage of 175 vulnerability description information, vulnerability detection 176 data, and vulnerability assessment results. 178 o The enterprise has a procedure for reassessment of endpoints at 179 some point after initial assessment (see Appendix H for more 180 information). 182 4. Vulnerability Assessment Pre-requisites 184 In order to successfully support the vulnerability assessment 185 scenario, an enterprise needs to have the following capabilities 186 deployed on their network and information readily available. 188 4.1. Endpoint Management Capabilities 190 Endpoint management capabilities are assumed to be in place within 191 the enterprise, and are expected to collect a minimum set of 192 attributes from the endpoints under management via Collection Tasks 193 and to establish an endpoint's identity within the scope of that 194 domain. Endpoint identity can be established by collecting certain 195 identifying attributes, collectively known as the Target Endpoint 196 Identifier, that allow for unique and persistent tracking of 197 endpoints on the enterprise network. Examples include, but are not 198 limited to, IP address, MAC address, Fully Qualified Domain Names 199 (FQDNs), pre-provisioned identifiers such as Globally Unique 200 Identifiers (GUIDs) or copies of serial numbers, certificates, 201 hardware identity values, or similar attributes. To simplify the 202 identification of an endpoint, a Target Endpoint Label may be created 203 and assigned to refer to the Target Endpoint Identifier. All of the 204 information collected by the endpoint management capabilities is 205 stored, with appropriate metadata (i.e. timestamp), in a central 206 location and used to build up a Target Endpoint Characterization 207 Record and Target Endpoint Profile via a Target Endpoint 208 Characterization Task. The endpoint management capabilities are 209 expected to be performed on an ongoing basis, resulting in routine, 210 or even event-driven, collection of basic endpoint information. 212 See Appendix I for information-specific details. 214 4.2. Vulnerability Description Information 216 Vulnerability description information is expected to be periodically 217 received by the enterprise. Upon receipt, the vulnerability 218 description information is expected to be assigned a unique tracking 219 identifier, stored in a repository (with appropriate metadata) in raw 220 form, and transformed into a machine-readable vulnerability detection 221 data with unique tracking identifier understood by the components 222 described by this scenario. This transformed form can be referred to 223 as the vulnerability detection data. At some point, receipt and 224 processing of vulnerability description data is expected to trigger 225 the vulnerability assessment. 227 See Appendix I for information-specific details. 229 5. Endpoint Vulnerability Assessment Capabilities 231 When new vulnerability description information is received by the 232 enterprise, affected endpoints are identified and assessed. The 233 vulnerability is said to apply to an endpoint if the endpoint 234 satisfies the conditions expressed in the vulnerability detection 235 data. 237 A vulnerability assessment (i.e. vulnerability detection) is 238 performed in two steps: 240 o Endpoint information collected by the endpoint management 241 capabilities is examined by the vulnerability management 242 capabilities through Evaluation Tasks. 244 o If the data possessed by the endpoint management capabilities is 245 insufficient, a Collection Task is triggered and the necessary 246 data is collected from the target endpoint. 248 Vulnerability detection relies on the examination of different 249 endpoint information depending on the nature of a specific 250 vulnerability. Common endpoint information used to detect a 251 vulnerability includes: 253 o A specific software version is installed on the endpoint 255 o File system attributes 257 o Specific state attributes 259 In many cases, the endpoint information needed to determine an 260 endpoint's vulnerability status will have been previously collected 261 by the endpoint management capabilities and available in a 262 Repository. However, in other cases, the necessary endpoint 263 information will not be readily available in a Repository and a 264 Collection Task will be triggered to collect it from the target 265 endpoint. Of course, some implementations of endpoint management 266 capabilities may prefer to enable operators to perform this 267 collection under certain circumstances, even when sufficient 268 information can be provided by the endpoint management capabilities 269 (e.g. there may be freshness requirements for information). 271 The collection of additional endpoint information for the purpose of 272 vulnerability assessment does not necessarily need to be a pull by 273 the vulnerability assessment capabilities. Over time, some new 274 pieces of information that are needed during common types of 275 assessments might be identified. Endpoint management capabilities 276 can be reconfigured to have this information delivered automatically. 277 This avoids the need to trigger additional Collection Tasks to gather 278 this information during assessments, streamlining the assessment 279 process. Likewise, it might be observed that certain information 280 delivered by endpoint management capabilities is rarely used. In 281 this case, it might be useful to re-configure the endpoint management 282 capabilities to no longer collect this information to reduce network 283 and processing overhead. Instead, a new Collection Task can be 284 triggered to gather this data on the rare occasions when it is 285 needed. 287 See Appendix I for information-specific details. 289 6. Vulnerability Assessment Results 291 Vulnerability assessment results present evaluation results along 292 with sufficient context, so that appropriate action can be taken. 293 Vulnerability assessment results are ideally stored for later use. 295 See Appendix I for information-specific details. 297 7. IANA Considerations 299 This memo includes no request to IANA. 301 8. Security Considerations 303 This document provides a core narrative that walks through an 304 automated enterprise vulnerability assessment scenario and is aligned 305 with SACM "Endpoint Security Posture Assessment: Enterprise Use 306 Cases" [RFC7632]. As a result, the security considerations for 307 [RFC7632] apply to this document. Furthermore, the data collected as 308 part of the vulnerability assessment may provide attackers with 309 useful information such as what software an enterprise is running on 310 their endpoints. As a result, organizations should consider properly 311 protecting this information. 313 9. Informative References 315 [charter-ietf-sacm-01] 316 Security Automation and Continuous Monitoring, "Charter, 317 Version 1.0", October 2015, 318 . 320 [critical-controls] 321 Center for Internet Security, "Critical Security Controls, 322 Version 6.0", . 325 [cvrf] Industry Consortium for Advancement of Security on the 326 Internet, "Common Vulnerability and Reporting Framework", 327 May 2012, . 329 [I-D.coffin-sacm-nea-swid-patnc] 330 Coffin, C., Haynes, D., Schmidt, C., and J. Fitzgerald- 331 McKay, "SWID Message and Attributes for PA-TNC", draft- 332 coffin-sacm-nea-swid-patnc-01 (work in progress), June 333 2016. 335 [I-D.cokus-sacm-oval-results-model] 336 Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez, 337 "OVAL(R) Results Model", draft-cokus-sacm-oval-results- 338 model-01 (work in progress), September 2016. 340 [I-D.hansbury-sacm-oval-info-model-mapping] 341 mhansbury@mitre.org, m., Haynes, D., and J. Gonzalez, 342 "OVAL and the SACM Information Model", draft-hansbury- 343 sacm-oval-info-model-mapping-03 (work in progress), 344 September 2016. 346 [I-D.haynes-sacm-oval-definitions-model] 347 Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez, 348 "OVAL(R) Definitions Model", draft-haynes-sacm-oval- 349 definitions-model-01 (work in progress), September 2016. 351 [I-D.ietf-sacm-requirements] 352 Cam-Winget, N. and L. Lorenzin, "Security Automation and 353 Continuous Monitoring (SACM) Requirements", draft-ietf- 354 sacm-requirements-13 (work in progress), March 2016. 356 [I-D.rothenberg-sacm-oval-sys-char-model] 357 Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez, 358 "OVAL(R) System Characteristics Model", draft-rothenberg- 359 sacm-oval-sys-char-model-01 (work in progress), September 360 2016. 362 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 363 Posture Assessment: Enterprise Use Cases", RFC 7632, 364 DOI 10.17487/RFC7632, September 2015, 365 . 367 Appendix A. Change Log 369 A.1. Changes in Revision -02 371 Changed "capability" in the context of endpoint management, 372 vulnerability management, and vulnerability assessments to 373 "capabilities" to avoid confusion with the term "capability" in the 374 terminology draft. 376 Made a few other minor editorial and clarification changes. 378 A.2. Changes in Revision -01 380 Clarified how the endpoint management capability can reconfigured 381 over time to adapt to the needs of an enterprise. GitHub issue #12 382 (https://github.com/sacmwg/vulnerability-scenario/issues/12). 384 Included references to the various appendices in the document. 385 GitHub issue #18 (https://github.com/sacmwg/vulnerability-scenario/ 386 issues/18). 388 Fixed typos and other minor editorial changes in the document. 389 GitHub issue #19 (https://github.com/sacmwg/vulnerability-scenario/ 390 issues/18). GitHub issue #20 (https://github.com/sacmwg/ 391 vulnerability-scenario/issues/20). GitHub issue #22 392 (https://github.com/sacmwg/vulnerability-scenario/issues/22). 394 Updated references to the Critical Controls to Version 6.0. GitHub 395 issue #23 (https://github.com/sacmwg/vulnerability-scenario/ 396 issues/23). 398 Aligned the scenario with SACM Tasks. GitHub issue #25 399 (https://github.com/sacmwg/vulnerability-scenario/issues/25). 401 A.3. Changes Since Adopted as a WG I-D -00 403 Made various organizational and editorial changes as proposed by Adam 404 Montville. GitHub issue #4 (https://github.com/sacmwg/vulnerability- 405 scenario/issues/4). 407 Removed the TODO from the Security Considerations section 408 (https://github.com/sacmwg/vulnerability-scenario/issues/8). 410 Clarified the definition of "vulnerability detection data" to explain 411 how it was guidance and provided instructions for security tools on 412 how to carry out a vulnerability assessment. GitHub issue #13 413 (https://github.com/sacmwg/vulnerability-scenario/issues/13). 415 Changed "targeted collection" to "supplemental collection". GitHub 416 issue #14 (https://github.com/sacmwg/vulnerability-scenario/ 417 issues/14). 419 Clarified that the ability for an enterprise to convert vulnerability 420 description information and process it into a format usable by 421 security tools is the same as the converting vulnerability 422 description information into vulnerability detection data. GitHub 423 issue #15 (https://github.com/sacmwg/vulnerability-scenario/ 424 issues/15). 426 Determine if we need to remove references to the long-term storage of 427 data in repositories. GitHub issue #16 (https://github.com/sacmwg/ 428 vulnerability-scenario/issues/16). 430 Moved the information needs captured in Appendix D.2 into the 431 Information Model. GitHub issue #17 (https://github.com/sacmwg/ 432 vulnerability-scenario/issues/17). 434 A.4. Changes in Revision draft-coffin-sacm-vuln-scenario-01 436 Clarification of the vulnerability description data IDs in sections 4 437 and 6. 439 Added "vulnerability remediation" to the Assessment Results and Data 440 Attribute Table and Definitions sections. 442 Added Implementation Examples to Endpoint Identification and Initial 443 (Pre-Assessment) Data Collection, Vulnerability Description Data, 444 Endpoint Applicability and Assessment, and Assessment Results 445 sections. 447 Added an example to vulnerability description data in the scope 448 section. 450 Added a sentence to clarify vulnerability description data definition 451 in the scope section. 453 Added data repository example for long-term storage scope item. 455 Added sentence to direct reader to examples of basic system 456 information in endpoint identification section. 458 Split the examples of information to collect in the pre-assessment 459 collection section into a basic and advanced list. 461 Added examples of data stored in the repository in the Assessment 462 Results section. 464 Added sentence for human-assigned attributes in the Future Work 465 section. 467 Replaced "vulnerability report" to "vulnerability description data" 468 because the term report was causing confusion. Similarly, replaced 469 "assessment report" with "assessment results". 471 Replaced "Configuration Management Database (CMDB)" with "Repository" 472 which is SACM's term for a data store. 474 Replaced endpoint "Role" with "Purpose" because "Role" is already 475 defined in SACM. Also, removed "Function" because it too is already 476 defined in SACM. 478 Clarified that the document does not try to define a normalized data 479 format for vulnerability description data although it does not 480 preclude the creation of such a format. 482 Included additional examples of software configuration information. 484 Clarified the section around endpoint identification to make it clear 485 designation attributes used to correlate and identify endpoints are 486 both persistent and unique. Furthermore, text was added to explain 487 how the persistency of attributes may vary. This was based on 488 knowledge gained from the Endpoint ID Design Team. 490 Updated the Security Considerations section to mention those 491 described in [RFC7632]. 493 Removed text around Bring Your Own Device (BYOD). While important, 494 BYOD just adds complexity to this initial draft. BYOD should be 495 addressed in a later revision. 497 Merged the list of "basic endpoint information" and the list of 498 "human-assigned endpoint attributes" as both represent data we want 499 to collect about an endpoint. Whether or not that data is natively 500 available on the endpoint for collection or assigned by a human, 501 computed, or derived from other data which may or may not be 502 available on the endpoint for collection seems arbitrary. With this 503 scenario, we primarily care about expressing information needs rather 504 than how the information is collected or from where. 506 Appendix B. Implementation Examples 508 B.1. Endpoint Data Collection 510 Within the SACM Architecture, the Internal and External Collector 511 components could be used to allow enterprises to collect posture 512 attributes that demonstrate compliance with enterprise policy. 513 Endpoints can be required to provide posture attributes, which may 514 include identification attributes to enable persistent 515 communications. 517 The SWID Message and Attributes for PA-TNC standard 518 [I-D.coffin-sacm-nea-swid-patnc] defines collection and validation of 519 software identities using the ISO Software Identification Tag 520 Standard. Using this standard, the identity of all installed 521 software including the endpoint operating system, could be collected 522 and used for later assessment. 524 The OVAL Definitions Model [I-D.haynes-sacm-oval-definitions-model] 525 provides a data model that can be used to specify what posture 526 attributes to collect as well as their expected values which can be 527 used to drive an assessment. 529 The OVAL System Characteristics Model 530 [I-D.rothenberg-sacm-oval-sys-char-model] can be used to capture 531 information about an endpoint. The model is specifically suited to 532 expressing OS information, endpoint identification information (such 533 as IP and MAC addresses), and other endpoint metadata. 535 B.2. Vulnerability Description Information 537 The Common Vulnerability Reporting Framework (CVRF) [cvrf] is an XML- 538 based language that attempts to standardize the creation of 539 vulnerability description information. Using CVRF, the enterprise 540 could create automated tools based on the standardized schema which 541 would obtain the needed and relevant information useful for later 542 assessments and assessment results. 544 B.3. Secondary Assessment 546 Within the SACM Architecture, the assessment task would be handled by 547 the Evaluator component. If previously collected data is used, it 548 would be obtained from a Data Store component. 550 Within the SACM Architecture, the Internal and External Collector 551 components could be used to allow enterprises to collect posture 552 attributes that demonstrate compliance with enterprise policy. 553 Endpoints can be required to provide posture attributes, which may 554 include identification attributes to enable persistent 555 communications. 557 The SWID Message and Attributes for PA-TNC standard defines 558 collection and validation of software identities using the ISO 559 Software Identification Tag Standard. Using this standard, all 560 installed software including the endpoint operating system could be 561 collected and stored for later assessment. 563 The OVAL Definitions Model provides a data model that can be used to 564 specify what posture attributes to collect as well as their expected 565 values which can be used to drive an assessment. 567 The OVAL System Characteristics Model can be used to capture 568 information about an endpoint. The model is specifically suited to 569 expressing OS information, endpoint identification information (such 570 as IP and MAC addresses), and other endpoint metadata. 572 The SACM Internal and External Attribute Collector components can be 573 used to allow enterprises to collect posture attributes that 574 demonstrate compliance with enterprise policy. Endpoints can be 575 required to provide posture attributes, which may include 576 identification attributes to enable persistent communications. 578 B.4. Assessment Results 580 The OVAL Results Model [I-D.cokus-sacm-oval-results-model] provides a 581 data model to encode the results of the assessment, which could then 582 be stored in a Repository and later accessed. The assessment results 583 described in this scenario could be stored and later accessed using 584 the OVAL Results Model. Note that the use of the OVAL Results Model 585 for sharing results is not recommended per section 7.3 of the OVAL 586 and the SACM Information Model 587 [I-D.hansbury-sacm-oval-info-model-mapping]. 589 Within the SACM Architecture, the generation of the assessment 590 results would occur in the Report Generator component. Those results 591 might then be moved to a Data Store component for later sharing and 592 retrieval as defined by SACM. 594 Appendix C. Priority 596 Priorities associated with the vulnerability description information, 597 assessment results, and any remedy is important, but is treated as a 598 separate challenge and, as such, has not been integrated into the 599 description of this scenario. Nevertheless, it is important to point 600 out and describe the use of priorities in the overall vulnerability 601 assessment scenario as a separate issue with its own sets of 602 requirements. 604 Priority in regard to vulnerability description information, can be 605 viewed in a couple of different ways within an enterprise. The 606 assessment prioritization involves prioritization of the 607 vulnerability description information assessment process. This 608 determines what vulnerability description information is assessed, 609 and in what order it is assessed in. For instance, a vulnerability 610 affecting an operating system or application used throughout the 611 enterprise would likely be prioritized higher than a vulnerability in 612 an application which is used only on a few, low-criticality 613 endpoints. 615 The prioritization of remedies relates to the enterprise remediation 616 and mitigation process based on the discovered vulnerabilities. Once 617 an assessment has been performed and applicable endpoints identified, 618 enterprise vulnerability managers must determine where to focus their 619 efforts to apply appropriate remedies. For example, a vulnerability 620 that is easily exploitable and which can allow arbitrary code 621 execution might be remedied before a vulnerability that is more 622 difficult to exploit or which just degrades performance. 624 Some vulnerability description information include severities and/or 625 other information that places the vulnerability in context. This 626 information can be used in both of the priority types discussed 627 above. In other cases, enterprise administrators may need to 628 prioritize based only on what they know about their enterprise and 629 the description provided in the vulnerability description 630 information. 632 Examples of data attributes specific to priority of assessments and/ 633 or remedies include (but not limited to) the following: 635 o Enterprise - defined purpose of the device, criticality of the 636 device, exposure of the device, etc. 638 o Severity attributes - A rating or score that attempts to provide 639 the level of severity or criticality associated with a given 640 vulnerability. 642 o Cyber threat intelligence - information such as tactics, 643 techniques, and procedures of threat actors, indicators of 644 compromise, incidents, courses of action, etc. that help the 645 enterprise understand relevant threats and how to detect, 646 mitigate, or respond to them. 648 Appendix D. SACM Usage Scenarios 650 The SACM "Endpoint Security Posture Assessment: Enterprise Use Cases" 651 document ([RFC7632]) defines multiple usage scenarios that are meant 652 to provide examples of implementing the use cases and building block 653 capabilities. Below is a brief summary of some of these usage 654 scenarios and how this document aligns and/or adds additional value 655 to the identified usage scenarios. 657 o Automated Checklist Verification (2.2.2) - "An enterprise operates 658 a heterogeneous IT environment. They utilize vendor-provided 659 automatable security configuration checklists for each operating 660 system and application used within their IT environment. Multiple 661 checklists are used from different vendors to ensure adequate 662 coverage of all IT assets." The usage scenario, as defined in the 663 RFC, is targeted at the checklist level and can be interpreted as 664 being specific to endpoint configuration. There is mention of 665 patch assessment and vulnerability mitigation, but the usage 666 scenario could be expanded upon by including vulnerability 667 verification. Replacing the idea of a checklist in the SACM usage 668 scenario with vulnerability would allow the usage scenario to 669 align almost exactly with the scenario described in this document. 670 Instead of collecting automatable security configuration 671 checklists, the enterprise would collect automatable vulnerability 672 description information available from the vendor as described or 673 possibly from other interested third-parties. 675 o Detection of Posture Deviations (2.2.3) - "An enterprise has 676 established secure configuration baselines for each different type 677 of endpoint within their IT environment. When an endpoint 678 connects to the network, the appropriate baseline configuration is 679 communicated to the endpoint. Once the baseline has been 680 established, the endpoint is monitored for any change events 681 pertaining to the baseline on an ongoing basis. When a change 682 occurs to posture defined in the baseline, updated posture 683 information is exchanged. When the endpoint detects a posture 684 change, an alert is generated identifying the specific changes in 685 posture." This usage scenario would support the concept of 686 endpoints signaling or alerting the enterprise to changes in the 687 posture relates to endpoint vulnerabilities in the same way that 688 it would for configurations. Replacing the idea of a checklist 689 with vulnerability description data allows the SACM usage scenario 690 and the scenario described in this document to align in their 691 objectives. 693 o Asynchronous Compliance/Vulnerability Assessment at Ice Station 694 Zebra (2.2.5) - "An isolated arctic IT environment that is 695 separated from the main university network. The only network 696 communications are via an intermittent, low-speed, high-latency, 697 high-cost satellite link. Remote network admins will need to show 698 continued compliance with the security policies of the university, 699 the government, and the provider of the satellite network, as well 700 as keep current on vulnerability testing." This SACM usage 701 scenario describes vulnerability assessment and aligns well with 702 the vulnerability scenario described in this document. The 703 endpoint assets are identified and associated data is published in 704 a Repository. Vulnerability description information is collected 705 and saved in a Repository as it is released. The vulnerability 706 description information is queued for later assessment, then the 707 assessment results and vulnerability description information are 708 stored after assessment. The only real difference in this SACM 709 usage scenario is the timing of the assessments. The scenario 710 described within this document would have no problems adjusting to 711 the timing of this SACM usage scenario or anything similar. 713 Appendix E. SACM Requirements and Charter - Future Work 715 In the course authoring this document, some additional considerations 716 for possible future work were noted. The following points were taken 717 from the SACM Requirements [I-D.ietf-sacm-requirements], SACM Charter 718 [charter-ietf-sacm-01], and SACM Use Cases ([RFC7632]) documents and 719 represent work that may be necessary to support the tasks or goals of 720 SACM going forward. 722 o The SACM requirements mentions "Result Reporting" with 723 applications but no detail around what the assessment results data 724 set should include. In the case of vulnerability assessment 725 results, context is important and details beyond just a Pass or 726 Fail result are needed in order to take action. A good example of 727 this might be the Priority of the vulnerability itself and how 728 many systems it affects within the enterprise. With this in mind, 729 it might be worthwhile to investigate a minimum data set or schema 730 for assessment results. The concern here is with vulnerability 731 description data, but this could apply to other enterprise 732 processes as well. 734 o The "Human-assigned endpoint attributes" mentioned previously in 735 this scenario are touched on in the SACM use cases, but the topic 736 could probably be explored in much more depth. Enterprise policy 737 and behaviors could be greatly influenced by endpoint attributes 738 such as locations, how the endpoint is used, and criticality. 739 When and how these data attributes are collected, as well as what 740 the minimum or common set might look like, would be good topics 741 for future related SACM work. In addition, the storage of these 742 attributes could be central (stored in a data repository) or they 743 could be assigned and stored on the endpoints themselves. 745 Appendix F. SACM Use Case Alignment 747 F.1. Endpoint Identification 749 This sub-step aligns with the Endpoint Discovery, Endpoint 750 Characterization, and Endpoint Target Identification building block 751 capabilities. The alignment is due to the fact that the purpose of 752 this sub-step is to discover, identify, and characterize all 753 endpoints on an enterprise network. 755 F.2. Endpoint Data Collection 757 This sub-step aligns with the Data Publication building block 758 capability because this section involves storage of endpoint 759 attributes within an enterprise Repository. This sub-step also 760 aligns with the Endpoint Characterization and Endpoint Target 761 Identification building block capabilities because it further 762 characterizes the endpoint through automated and possibly manual 763 means. There is direct alignment with the Endpoint Component 764 Inventory, Posture Attribute Identification, and Posture Attribute 765 Value Collection building block capabilities since the purpose of 766 this sub-step is to perform an initial inventory of the endpoint and 767 collect basic attributes and their values. Last, there is alignment 768 with the Collection Guidance Acquisition building block capabilities 769 as the inventory and collection of endpoint attributes would be 770 directed by some type of enterprise or third-party guidance. 772 F.3. Vulnerability Description Information 774 This step aligns with the Data Publication and Data Retrieval 775 building block capabilities because this section details storage of 776 vulnerability description information within an enterprise Repository 777 and later retrieval of the same. 779 F.4. Applicability 781 This sub-step aligns with the Data Retrieval, Data Query, and Posture 782 Attribute Value Query building block capabilities because, in this 783 sub-step, the process is attempting to determine the vulnerability 784 status of the endpoint using the data that has previously been 785 collected. 787 F.5. Secondary Assessment 789 This sub-step aligns with the Data Publication building block 790 capability because this section details storage of endpoint 791 attributes within an enterprise Repository. The sub-step also aligns 792 with the Collection Guidance Acquisition building block capability 793 since the vulnerability description information (guidance) drives the 794 collection of additional endpoint attributes. 796 This sub-step aligns with the Endpoint Characterization (both manual 797 and automated) and Endpoint Target Identification building block 798 capabilities because it could further characterize the endpoint 799 through automated and possibly manual means. There is direct 800 alignment with the Endpoint Component Inventory, Posture Attribute 801 Identification, and Posture Attribute Value Collection building block 802 capabilities since the purpose of this sub-step is to perform 803 additional and more specific component inventories and collections of 804 endpoint attributes and their values. 806 F.6. Assessment Results 808 This step aligns with the Data Publication and Data Retrieval 809 building block capabilities because this section details storage of 810 vulnerability assessment results within an enterprise Repository and 811 later retrieval of the same. 813 Appendix G. Alignment with Other Existing Works 815 G.1. Critical Security Controls 817 The Center for Internet Security's Critical Security Controls 818 [critical-controls] includes security controls for a number of usage 819 scenarios, some of which are covered in this document. This section 820 documents the alignment between the Center's controls and the 821 relevant elements of the scenario. 823 G.1.1. Continuous Vulnerability Assessment 825 "CSC 4: Continuous Vulnerability Assessment and Remediation," which 826 is described by the Center for Internet Security as "Continuously 827 acquire, assess, and take action on new information in order to 828 identify vulnerabilities, remediate, and minimize the window of 829 opportunity for attackers." The scenario described in this document 830 is aligned with CSC 4 in multiple ways: 832 CSC 4.1 applies to this scenario in that it calls for running 833 regular, automated scanning to deliver prioritized lists of 834 vulnerabilities with which to respond. The scenario described in 835 this document is intended to be executed on a continuous basis, and 836 the priorities of both vulnerability description information and the 837 remedy of vulnerabilities are discussed in the Priority section 838 earlier in this document. 840 This scenario assumes that the enterprise already has a source for 841 vulnerability description information as described in CSC 4.4. 843 Both CSC 4.2 and 4.7 are made possible by writing information to a 844 Repository since this makes previously collected data available for 845 later analysis. 847 While this scenario does not go into the details of how 848 prioritization would be calculated or applied, it does touch on some 849 of the important ways in which prioritization would impact the 850 endpoint assessment process in the Priority section. As such, the 851 Priority section aligns with CSC 4.8, which deals with vulnerability 852 priority. Vulnerability priority in this scenario is discussed in 853 terms of the vulnerability description information priority during 854 receipt, as well as the vulnerability priority with regards to 855 remedies. 857 The described scenario does not address the details of applying a 858 remedy based on assessment results. As such, CSC 4.5 which deals 859 with mitigations and patching, is out of scope for this work. 860 Similarly, CSC 4.3 prescribes performing scans in authenticated mode 861 and CSC 4.6 prescribes monitoring logs. This scenario does not get 862 into the means by which data is collected, focusing on "what" to 863 collect rather than "how", and as such does not have corresponding 864 sections, although the procedures described are not incompatible with 865 either of these controls. 867 The CSC 4 System Entity Relationship diagram directly aligns with the 868 scenario described in this document with the exception of applying 869 patches to endpoints. 871 G.1.2. Hardware and Software Inventories 873 This scenario is also aligned with, and describes a process for, 874 collecting and maintaining hardware and software inventories, which 875 are covered by the Center for Internet Security CSC 1 "Inventory of 876 Authorized and Unauthorized Devices" and CSC 2 "Inventory of 877 Authorized and Unauthorized Software." This scenario documents a 878 process that is specific to collecting and maintaining hardware and 879 software data attributes for vulnerability assessment purposes, but 880 the collection of the hardware attributes and software inventory 881 documented in the Endpoint Data Collection section that follows can 882 also be used for the purpose of implementing authorized and 883 unauthorized hardware and software management processes (e.g., 884 scanning tools looking for unauthorized software). Moreover, the 885 ability to accurately identify endpoints and, to a lesser degree, 886 applications is integral to effective endpoint data collection and 887 vulnerability management. 889 The Endpoint Data Collection section does not have coverage for the 890 specific details described in CSC 1 and 2 as they are different 891 processes and would be out-of-scope of this scenario, but the section 892 does provide the data necessary to support the controls. 894 The Endpoint Identification and Endpoint Data Collection sections 895 within this scenario align with CSC 1.1 and 1.4 by identifying 896 enterprise endpoints and collecting their hardware and network 897 attributes. The Endpoint Data Collection section aligns with and 898 supports CSC 2.3 by defining a software inventory process and a 899 method of obtaining operating system and file system attributes. The 900 rest of the items from CSC 1 and 2 deal with implementation details 901 and would be out-of-scope for this document. 903 Appendix H. Continuous Vulnerability Assessment 905 It is not sufficient to perform a single assessment when 906 vulnerability description information is published without any 907 further checking. Doing so does not address the possibility that the 908 reported vulnerability might be introduced to the enterprise 909 environment after the initial assessment completes. For example, new 910 endpoints can be introduced to the environment which have old 911 software or are not up-to-date with patches. Another example is 912 where unauthorized or obsolete software is installed on an existing 913 endpoint by enterprise users after vulnerability description 914 information and initial assessment has taken place. Moreover, 915 enterprises might not wish to, or be able to, assess all 916 vulnerability description information immediately when they come in. 917 Conflicts with other critical activities or limited resources might 918 mean that some alerts, especially those that the enterprise deems as 919 "low priority", are not used to guide enterprise assessments until 920 sometime after the initial receipt. 922 The scenario above describes a single assessment of endpoints. 923 However, it does not make any assumptions as to when this assessment 924 occurs relative to the original receipt of the vulnerability 925 description data that led to this assessment. The assessment could 926 immediately follow the ingestion of the vulnerability description 927 information, could be delayed, or the assessment might represent a 928 reassessment of some vulnerability description information against 929 which endpoints had previously been assessed. Moreover, the scenario 930 incorporates long-term storage of collected data, vulnerability 931 description information, and assessment results in order to 932 facilitate meaningful and ongoing reassessment. 934 Appendix I. Data Attribute Table 936 The following table maps all major data attributes against each major 937 process where they are used. 939 +--------------+------------+-------------+-------------+-----------+ 940 | | vulnerabil | Endpoint Id | Endpoint Ap | Assessmen | 941 | | ity descri | entificatio | plicability | t Results | 942 | | ption data | n and | and | | 943 | | | Initial | Assessment | | 944 | | | Data | | | 945 | | | Collection | | | 946 +--------------+------------+-------------+-------------+-----------+ 947 | *Endpoint* | | | | | 948 +--------------+------------+-------------+-------------+-----------+ 949 | Collection | | X | X | | 950 | date/time | | | | | 951 +--------------+------------+-------------+-------------+-----------+ 952 | Endpoint | | X | X | | 953 | type | | | | | 954 +--------------+------------+-------------+-------------+-----------+ 955 | Hardware ver | X | X | X | | 956 | sion/firmwar | | | | | 957 | e | | | | | 958 +--------------+------------+-------------+-------------+-----------+ 959 | Operating | X | X | X | | 960 | system | | | | | 961 +--------------+------------+-------------+-------------+-----------+ 962 | Operating | X | X | X | | 963 | system | | | | | 964 | attributes | | | | | 965 | (e.g., | | | | | 966 | version, | | | | | 967 | service pack | | | | | 968 | level, | | | | | 969 | edition, | | | | | 970 | etc.) | | | | | 971 +--------------+------------+-------------+-------------+-----------+ 972 | Installed | X | X | X | X | 973 | software | | | | | 974 | name | | | | | 975 +--------------+------------+-------------+-------------+-----------+ 976 | Installed | X | X | X | X | 977 | software | | | | | 978 | attributes | | | | | 979 | (e.g., | | | | | 980 | version, | | | | | 981 | patch level, | | | | | 982 | install | | | | | 983 | path, etc.) | | | | | 984 +--------------+------------+-------------+-------------+-----------+ 985 | Open ports/s | X | X | X | | 986 | ervices | | | | | 987 +--------------+------------+-------------+-------------+-----------+ 988 | Operating | X | X | X | | 989 | system | | | | | 990 | optional | | | | | 991 | component | | | | | 992 | inventory | | | | | 993 +--------------+------------+-------------+-------------+-----------+ 994 | Location | | X | | X | 995 +--------------+------------+-------------+-------------+-----------+ 996 | Purpose | | X | | X | 997 +--------------+------------+-------------+-------------+-----------+ 998 | Criticality | | X | | X | 999 +--------------+------------+-------------+-------------+-----------+ 1000 | File system | X | | X | | 1001 | attributes | | | | | 1002 | (e.g., | | | | | 1003 | versions, | | | | | 1004 | size, write | | | | | 1005 | date, | | | | | 1006 | modified | | | | | 1007 | date, | | | | | 1008 | checksum, | | | | | 1009 | etc.) | | | | | 1010 +--------------+------------+-------------+-------------+-----------+ 1011 | Shared | X | | X | | 1012 | libraries | | | | | 1013 +--------------+------------+-------------+-------------+-----------+ 1014 | Other | X | | X | | 1015 | software con | | | | | 1016 | figuration | | | | | 1017 | information | | | | | 1018 +--------------+------------+-------------+-------------+-----------+ 1019 | *External vu | | | | | 1020 | lnerability | | | | | 1021 | description | | | | | 1022 | data* | | | | | 1023 +--------------+------------+-------------+-------------+-----------+ 1024 | Ingest Date | X | | X | | 1025 +--------------+------------+-------------+-------------+-----------+ 1026 | Date of | X | | X | | 1027 | Release | | | | | 1028 +--------------+------------+-------------+-------------+-----------+ 1029 | Version | X | | X | | 1030 +--------------+------------+-------------+-------------+-----------+ 1031 | External | X | | X | X | 1032 | vuln ID | | | | | 1033 +--------------+------------+-------------+-------------+-----------+ 1034 | Severity | | | | X | 1035 | Score | | | | | 1036 +--------------+------------+-------------+-------------+-----------+ 1037 | *Assessment | | | | | 1038 | Results* | | | | | 1039 +--------------+------------+-------------+-------------+-----------+ 1040 | Date of | | | X | X | 1041 | assessment | | | | | 1042 +--------------+------------+-------------+-------------+-----------+ 1043 | Date of data | | X | X | X | 1044 | collection | | | | | 1045 +--------------+------------+-------------+-------------+-----------+ 1046 | Endpoint ide | | X | X | X | 1047 | ntification | | | | | 1048 | and/or | | | | | 1049 | locally | | | | | 1050 | assigned ID | | | | | 1051 +--------------+------------+-------------+-------------+-----------+ 1052 | Vulnerable | X | X | X | X | 1053 | software | | | | | 1054 | product(s) | | | | | 1055 +--------------+------------+-------------+-------------+-----------+ 1056 | Endpoint vul | | | X | X | 1057 | nerability | | | | | 1058 | status | | | | | 1059 +--------------+------------+-------------+-------------+-----------+ 1060 | Vulnerabilit | X | | | X | 1061 | y | | | | | 1062 | description | | | | | 1063 +--------------+------------+-------------+-------------+-----------+ 1064 | Vulnerabilit | X | | | X | 1065 | y | | | | | 1066 | remediation | | | | | 1067 +--------------+------------+-------------+-------------+-----------+ 1069 Table 1: Vulnerability Assessment Attributes 1071 Authors' Addresses 1073 Christopher Coffin 1074 The MITRE Corporation 1075 202 Burlington Road 1076 Bedford, MA 01730 1077 USA 1079 Email: ccoffin@mitre.org 1081 Brant Cheikes 1082 The MITRE Corporation 1083 202 Burlington Road 1084 Bedford, MA 01730 1085 USA 1087 Email: bcheikes@mitre.org 1088 Charles Schmidt 1089 The MITRE Corporation 1090 202 Burlington Road 1091 Bedford, MA 01730 1092 USA 1094 Email: cmschmidt@mitre.org 1096 Daniel Haynes 1097 The MITRE Corporation 1098 202 Burlington Road 1099 Bedford, MA 01730 1100 USA 1102 Email: dhaynes@mitre.org 1104 Jessica Fitzgerald-McKay 1105 Department of Defense 1106 9800 Savage Road 1107 Ft. Meade, Maryland 1108 USA 1110 Email: jmfitz2@nsa.gov 1112 David Waltermire 1113 National Institute of Standards and Technology 1114 100 Bureau Drive 1115 Gaithersburg, Maryland 20877 1116 USA 1118 Email: david.waltermire@nist.gov