--- 1/draft-ietf-sacm-vuln-scenario-01.txt 2016-09-09 08:17:10.258611467 -0700 +++ 2/draft-ietf-sacm-vuln-scenario-02.txt 2016-09-09 08:17:10.422615604 -0700 @@ -1,51 +1,51 @@ SACM C. Coffin Internet-Draft B. Cheikes Intended status: Informational C. Schmidt -Expires: January 8, 2017 D. Haynes +Expires: March 13, 2017 D. Haynes The MITRE Corporation J. Fitzgerald-McKay Department of Defense D. Waltermire National Institute of Standards and Technology - July 7, 2016 + September 9, 2016 SACM Vulnerability Assessment Scenario - draft-ietf-sacm-vuln-scenario-01 + draft-ietf-sacm-vuln-scenario-02 Abstract This document describes an automated enterprise vulnerability assessment scenario aligned with the SACM Use Cases. The scenario - assumes the existence of an endpoint management capability and begins + assumes the existence of endpoint management capabilities and begins with an enterprise ingesting vulnerability description information. Endpoints are assessed against the vulnerability description information based on a combination of examining known endpoint characterization information and collected endpoint information. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 8, 2017. + This Internet-Draft will expire on March 13, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,51 +54,52 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Vulnerability Assessment Pre-requisites . . . . . . . . . . . 4 - 4.1. Endpoint Management Capability . . . . . . . . . . . . . 4 + 4.1. Endpoint Management Capabilities . . . . . . . . . . . . 5 4.2. Vulnerability Description Information . . . . . . . . . . 5 - 5. Endpoint Vulnerability Assessment Capability . . . . . . . . 5 + 5. Endpoint Vulnerability Assessment Capabilities . . . . . . . 5 6. Vulnerability Assessment Results . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 - A.1. Changes in Revision -01 . . . . . . . . . . . . . . . . . 8 - A.2. Changes Since Adopted as a WG I-D -00 . . . . . . . . . . 9 - A.3. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 9 + A.1. Changes in Revision -02 . . . . . . . . . . . . . . . . . 8 + A.2. Changes in Revision -01 . . . . . . . . . . . . . . . . . 9 + A.3. Changes Since Adopted as a WG I-D -00 . . . . . . . . . . 9 + A.4. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 10 Appendix B. Implementation Examples . . . . . . . . . . . . . . 11 B.1. Endpoint Data Collection . . . . . . . . . . . . . . . . 11 B.2. Vulnerability Description Information . . . . . . . . . . 12 B.3. Secondary Assessment . . . . . . . . . . . . . . . . . . 12 - B.4. Assessment Results . . . . . . . . . . . . . . . . . . . 12 + B.4. Assessment Results . . . . . . . . . . . . . . . . . . . 13 Appendix C. Priority . . . . . . . . . . . . . . . . . . . . . . 13 Appendix D. SACM Usage Scenarios . . . . . . . . . . . . . . . . 14 - Appendix E. SACM Requirements and Charter - Future Work . . . . 15 + Appendix E. SACM Requirements and Charter - Future Work . . . . 16 Appendix F. SACM Use Case Alignment . . . . . . . . . . . . . . 16 F.1. Endpoint Identification . . . . . . . . . . . . . . . . . 16 F.2. Endpoint Data Collection . . . . . . . . . . . . . . . . 16 F.3. Vulnerability Description Information . . . . . . . . . . 17 F.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 17 F.5. Secondary Assessment . . . . . . . . . . . . . . . . . . 17 - F.6. Assessment Results . . . . . . . . . . . . . . . . . . . 17 - Appendix G. Alignment with Other Existing Works . . . . . . . . 17 - G.1. Critical Security Controls . . . . . . . . . . . . . . . 17 + F.6. Assessment Results . . . . . . . . . . . . . . . . . . . 18 + Appendix G. Alignment with Other Existing Works . . . . . . . . 18 + G.1. Critical Security Controls . . . . . . . . . . . . . . . 18 G.1.1. Continuous Vulnerability Assessment . . . . . . . . . 18 G.1.2. Hardware and Software Inventories . . . . . . . . . . 19 - Appendix H. Continuous Vulnerability Assessment . . . . . . . . 19 + Appendix H. Continuous Vulnerability Assessment . . . . . . . . 20 Appendix I. Data Attribute Table . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document describes a detailed, enterprise-specific vulnerability assessment scenario from which information model elements can be discovered. This scenario also informs protocol and data model development in support of vulnerability assessment, as part of overall posture assessment (see Appendix B for examples of solutions @@ -114,39 +115,41 @@ 2. Terminology Vulnerability description information: Information pertaining to the existence of a flaw or flaws in software, hardware, and/or firmware, which could potentially have an adverse impact on enterprise IT functionality and/or security. Vulnerability description information should contain enough information to support vulnerability detection. - Vulnerability detection data: A type of guidance extracted from - vulnerability description information that describes the - specific mechanisms of vulnerability detection that is used by - an enterprise's vulnerability management capability to - determine if a vulnerability is present on an endpoint. + Vulnerability detection data: A type of guidance extracted or + derived from vulnerability description information that + describes the specific mechanisms of vulnerability detection + that is used by an enterprise's vulnerability management + capabilities to determine if a vulnerability is present on an + endpoint. - Endpoint management capability: An enterprise IT capability managing - endpoint identity, endpoint information, and associated - metadata on an ongoing basis. + Endpoint management capabilities: An enterprise IT department's + ability to manage endpoint identity, endpoint information, and + associated metadata on an ongoing basis. - Vulnerability management capability: An enterprise IT capability - managing endpoint vulnerabilities and associated metadata on an - ongoing basis by ingesting vulnerability description - information and vulnerability detection data, and performing a - vulnerability assessment. + Vulnerability management capabilities: An enterprise IT department's + ability to manage endpoint vulnerabilities and associated + metadata on an ongoing basis by ingesting vulnerability + description information and vulnerability detection data, and + performing vulnerability assessments. - Vulnerability assessment: The process of determining whether a set - of endpoints is vulnerable according to the information - contained in the vulnerability description information. + Vulnerability assessment capabilities: An enterprise IT department's + ability to determine whether a set of endpoints is vulnerable + according to the information contained in the vulnerability + description information. 3. Assumptions A number of assumptions must be stated in order to further clarify the position and scope of this document. The document assumes that: o The enterprise has received vulnerability description information, and that the information has already been processed into @@ -155,137 +158,138 @@ o The enterprise has a means of identifying enterprise endpoints through the execution of Target Endpoint Discovery Tasks although assertions about some details of this capability are made. o The enterprise has a means of extracting relevant information about enterprise endpoints in a form that is compatible with the vulnerability description data. o All information described in this scenario is available in the - vulnerability description data and serves as the basis of this - assessment. + vulnerability description data and serves as the basis of + assessments. o The enterprise can provide all relevant information about any endpoint needed to perform the described assessment. o The enterprise has a mechanism for long-term storage of vulnerability description information, vulnerability detection data, and vulnerability assessment results. o The enterprise has a procedure for reassessment of endpoints at some point after initial assessment (see Appendix H for more information). 4. Vulnerability Assessment Pre-requisites In order to successfully support the vulnerability assessment scenario, an enterprise needs to have the following capabilities deployed on their network and information readily available. -4.1. Endpoint Management Capability +4.1. Endpoint Management Capabilities - An endpoint management capability is assumed to be in place within - the enterprise, and is expected to collect a minimum set of + Endpoint management capabilities are assumed to be in place within + the enterprise, and are expected to collect a minimum set of attributes from the endpoints under management via Collection Tasks and to establish an endpoint's identity within the scope of that domain. Endpoint identity can be established by collecting certain identifying attributes, collectively known as the Target Endpoint Identifier, that allow for unique and persistent tracking of endpoints on the enterprise network. Examples include, but are not limited to, IP address, MAC address, Fully Qualified Domain Names (FQDNs), pre-provisioned identifiers such as Globally Unique Identifiers (GUIDs) or copies of serial numbers, certificates, hardware identity values, or similar attributes. To simplify the identification of an endpoint, a Target Endpoint Label may be created and assigned to refer to the Target Endpoint Identifier. All of the - information collected by the endpoint management capability is + information collected by the endpoint management capabilities is stored, with appropriate metadata (i.e. timestamp), in a central location and used to build up a Target Endpoint Characterization Record and Target Endpoint Profile via a Target Endpoint - Characterization Task. The endpoint management capability is + Characterization Task. The endpoint management capabilities are expected to be performed on an ongoing basis, resulting in routine, or even event-driven, collection of basic endpoint information. See Appendix I for information-specific details. 4.2. Vulnerability Description Information Vulnerability description information is expected to be periodically received by the enterprise. Upon receipt, the vulnerability description information is expected to be assigned a unique tracking identifier, stored in a repository (with appropriate metadata) in raw form, and transformed into a machine-readable vulnerability detection data with unique tracking identifier understood by the components described by this scenario. This transformed form can be referred to as the vulnerability detection data. At some point, receipt and processing of vulnerability description data is expected to trigger the vulnerability assessment. See Appendix I for information-specific details. -5. Endpoint Vulnerability Assessment Capability +5. Endpoint Vulnerability Assessment Capabilities When new vulnerability description information is received by the enterprise, affected endpoints are identified and assessed. The vulnerability is said to apply to an endpoint if the endpoint satisfies the conditions expressed in the vulnerability detection data. A vulnerability assessment (i.e. vulnerability detection) is performed in two steps: o Endpoint information collected by the endpoint management - capability is examined by the vulnerability management capability - through Evaluation Tasks. + capabilities is examined by the vulnerability management + capabilities through Evaluation Tasks. - o If the data possessed by the endpoint management capability is + o If the data possessed by the endpoint management capabilities is insufficient, a Collection Task is triggered and the necessary data is collected from the target endpoint. Vulnerability detection relies on the examination of different endpoint information depending on the nature of a specific vulnerability. Common endpoint information used to detect a vulnerability includes: o A specific software version is installed on the endpoint o File system attributes o Specific state attributes In many cases, the endpoint information needed to determine an endpoint's vulnerability status will have been previously collected - by the Endpoint Management Capability and available in a Repository. - However, in other cases, the necessary endpoint information will not - be readily available in a Repository and a Collection Task will be - triggered to collect it from the target endpoint. Of course, an - implementation of an endpoint management capability may prefer to - enable operators to perform this collection under certain - circumstances, even when sufficient information can be provided by - the endpoint management capability (e.g. there may be freshness - requirements for information). + by the endpoint management capabilities and available in a + Repository. However, in other cases, the necessary endpoint + information will not be readily available in a Repository and a + Collection Task will be triggered to collect it from the target + endpoint. Of course, some implementations of endpoint management + capabilities may prefer to enable operators to perform this + collection under certain circumstances, even when sufficient + information can be provided by the endpoint management capabilities + (e.g. there may be freshness requirements for information). The collection of additional endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by - the vulnerability assessment capability. Over time, some new pieces - of information that are needed during common types of assessments - might be identified. An endpoint management capability can be - reconfigured to have this information delivered automatically. This - avoids the need to trigger additional Collection Tasks to gather this - information during assessments, streamlining the assessment process. - Likewise, it might be observed that certain information delivered by - an endpoint management capability is rarely used. In this case, it - might be useful to re-configure the endpoint management capability to - no longer collect this information to reduce network and processing - overhead. Instead, a new Collection Task can be triggered to gather - this data on the rare occasions when it is needed. + the vulnerability assessment capabilities. Over time, some new + pieces of information that are needed during common types of + assessments might be identified. Endpoint management capabilities + can be reconfigured to have this information delivered automatically. + This avoids the need to trigger additional Collection Tasks to gather + this information during assessments, streamlining the assessment + process. Likewise, it might be observed that certain information + delivered by endpoint management capabilities is rarely used. In + this case, it might be useful to re-configure the endpoint management + capabilities to no longer collect this information to reduce network + and processing overhead. Instead, a new Collection Task can be + triggered to gather this data on the rare occasions when it is + needed. See Appendix I for information-specific details. 6. Vulnerability Assessment Results Vulnerability assessment results present evaluation results along with sufficient context, so that appropriate action can be taken. Vulnerability assessment results are ideally stored for later use. See Appendix I for information-specific details. @@ -315,61 +319,70 @@ [critical-controls] Center for Internet Security, "Critical Security Controls, Version 6.0", . [cvrf] Industry Consortium for Advancement of Security on the Internet, "Common Vulnerability and Reporting Framework", May 2012, . - [draft-hansbury-sacm-oval-info-model-mapping-02] - Security Automation and Continuous Monitoring, "OVAL and - the SACM Information Model", March 2016, - . - [I-D.coffin-sacm-nea-swid-patnc] Coffin, C., Haynes, D., Schmidt, C., and J. Fitzgerald- McKay, "SWID Message and Attributes for PA-TNC", draft- coffin-sacm-nea-swid-patnc-01 (work in progress), June 2016. [I-D.cokus-sacm-oval-results-model] Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez, "OVAL(R) Results Model", draft-cokus-sacm-oval-results- - model-00 (work in progress), March 2016. + model-01 (work in progress), September 2016. + + [I-D.hansbury-sacm-oval-info-model-mapping] + mhansbury@mitre.org, m., Haynes, D., and J. Gonzalez, + "OVAL and the SACM Information Model", draft-hansbury- + sacm-oval-info-model-mapping-03 (work in progress), + September 2016. [I-D.haynes-sacm-oval-definitions-model] Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez, "OVAL(R) Definitions Model", draft-haynes-sacm-oval- - definitions-model-00 (work in progress), March 2016. + definitions-model-01 (work in progress), September 2016. [I-D.ietf-sacm-requirements] Cam-Winget, N. and L. Lorenzin, "Security Automation and Continuous Monitoring (SACM) Requirements", draft-ietf- sacm-requirements-13 (work in progress), March 2016. [I-D.rothenberg-sacm-oval-sys-char-model] Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez, "OVAL(R) System Characteristics Model", draft-rothenberg- - sacm-oval-sys-char-model-00 (work in progress), March + sacm-oval-sys-char-model-01 (work in progress), September 2016. [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015, . Appendix A. Change Log -A.1. Changes in Revision -01 +A.1. Changes in Revision -02 + + Changed "capability" in the context of endpoint management, + vulnerability management, and vulnerability assessments to + "capabilities" to avoid confusion with the term "capability" in the + terminology draft. + + Made a few other minor editorial and clarification changes. + +A.2. Changes in Revision -01 Clarified how the endpoint management capability can reconfigured over time to adapt to the needs of an enterprise. GitHub issue #12 (https://github.com/sacmwg/vulnerability-scenario/issues/12). Included references to the various appendices in the document. GitHub issue #18 (https://github.com/sacmwg/vulnerability-scenario/ issues/18). Fixed typos and other minor editorial changes in the document. @@ -378,21 +391,21 @@ vulnerability-scenario/issues/20). GitHub issue #22 (https://github.com/sacmwg/vulnerability-scenario/issues/22). Updated references to the Critical Controls to Version 6.0. GitHub issue #23 (https://github.com/sacmwg/vulnerability-scenario/ issues/23). Aligned the scenario with SACM Tasks. GitHub issue #25 (https://github.com/sacmwg/vulnerability-scenario/issues/25). -A.2. Changes Since Adopted as a WG I-D -00 +A.3. Changes Since Adopted as a WG I-D -00 Made various organizational and editorial changes as proposed by Adam Montville. GitHub issue #4 (https://github.com/sacmwg/vulnerability- scenario/issues/4). Removed the TODO from the Security Considerations section (https://github.com/sacmwg/vulnerability-scenario/issues/8). Clarified the definition of "vulnerability detection data" to explain how it was guidance and provided instructions for security tools on @@ -411,21 +424,21 @@ issues/15). Determine if we need to remove references to the long-term storage of data in repositories. GitHub issue #16 (https://github.com/sacmwg/ vulnerability-scenario/issues/16). Moved the information needs captured in Appendix D.2 into the Information Model. GitHub issue #17 (https://github.com/sacmwg/ vulnerability-scenario/issues/17). -A.3. Changes in Revision draft-coffin-sacm-vuln-scenario-01 +A.4. Changes in Revision draft-coffin-sacm-vuln-scenario-01 Clarification of the vulnerability description data IDs in sections 4 and 6. Added "vulnerability remediation" to the Assessment Results and Data Attribute Table and Definitions sections. Added Implementation Examples to Endpoint Identification and Initial (Pre-Assessment) Data Collection, Vulnerability Description Data, Endpoint Applicability and Assessment, and Assessment Results @@ -564,21 +577,21 @@ B.4. Assessment Results The OVAL Results Model [I-D.cokus-sacm-oval-results-model] provides a data model to encode the results of the assessment, which could then be stored in a Repository and later accessed. The assessment results described in this scenario could be stored and later accessed using the OVAL Results Model. Note that the use of the OVAL Results Model for sharing results is not recommended per section 7.3 of the OVAL and the SACM Information Model - [draft-hansbury-sacm-oval-info-model-mapping-02]. + [I-D.hansbury-sacm-oval-info-model-mapping]. Within the SACM Architecture, the generation of the assessment results would occur in the Report Generator component. Those results might then be moved to a Data Store component for later sharing and retrieval as defined by SACM. Appendix C. Priority Priorities associated with the vulnerability description information, assessment results, and any remedy is important, but is treated as a