SACM C. Coffin Internet-Draft B. Cheikes Intended status: Informational C. Schmidt Expires:December 10, 2016January 8, 2017 D. Haynes The MITRE Corporation J. Fitzgerald-McKay Department of Defense D. Waltermire National Institute of Standards and TechnologyJune 8,July 7, 2016 SACM Vulnerability Assessment Scenariodraft-ietf-sacm-vuln-scenario-00draft-ietf-sacm-vuln-scenario-01 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 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 onDecember 10, 2016.January 8, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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.Scope . . . .Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Vulnerability Assessment Pre-requisites . . . . . . . . . . . 4 4.1. Endpoint Management Capability . . . . . . . . . . . . . 4 4.2. Vulnerability Description Information . . . . . . . . . . 5 5. Endpoint Vulnerability Assessment Capability . . . . . . . . 5 6. Vulnerability Assessment Results . . . . . . . . . . . . . .67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . .78 A.1. ChangesSince Adopted as a WG I-D -00in Revision -01 . . . . . . . . . .7 A.2. Changes in Revision draft-coffin-sacm-vuln-scenario-01.8 Appendix B. Continuous Vulnerability Assessment. . . . . . 8 A.2. Changes Since Adopted as a WG I-D -00 . .10 Appendix C. Priority. . . . . . . . 9 A.3. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 9 Appendix B. Implementation Examples . . . . . . . . . . . . . .10 Appendix D.11 B.1. Endpoint DataAttribute TableCollection . . . . . . . . . . . . . . . . 11D.1. TableB.2. Vulnerability Description Information . . . . . . . . . . 12 B.3. Secondary Assessment . . . . . . . . . . . . . . . .11 Appendix E. Alignment with Other Existing Works. . 12 B.4. Assessment Results . . . . . .14 E.1. Critical Security Controls. . . . . . . . . . . . . 12 Appendix C. Priority . .14 E.1.1. Continuous Vulnerability Assessment. . . . . . . . .14 E.1.2. Hardware and Software Inventories. . . . . . . . . .16. 13 AppendixF.D. SACM Usage Scenarios . . . . . . . . . . . . . . . .1614 AppendixG.E. SACM Requirements and Charter - Future Work . . . .1815 AppendixH.F. SACM Use Case Alignment . . . . . . . . . . . . . .18 H.1.16 F.1. Endpoint Identification . . . . . . . . . . . . . . . . .18 H.2.16 F.2. Endpoint Data Collection . . . . . . . . . . . . . . . .19 H.3.16 F.3. Vulnerability Description Information . . . . . . . . . .19 H.4.17 F.4. Applicability . . . . . . . . . . . . . . . . . . . . . .19 H.5.17 F.5. Secondary Assessment . . . . . . . . . . . . . . . . . .19 H.6.17 F.6. Assessment Results . . . . . . . . . . . . . . . . . . .2017 AppendixI. Implementation Examples . . . . . . .G. Alignment with Other Existing Works . . . . . . .20 I.1. Endpoint Data Collection. 17 G.1. Critical Security Controls . . . . . . . . . . . . . . .20 I.2.17 G.1.1. Continuous VulnerabilityDescription Information . . . .Assessment . . . . . .20 I.3. Secondary Assessment. . . 18 G.1.2. Hardware and Software Inventories . . . . . . . . . . 19 Appendix H. Continuous Vulnerability Assessment . . . . .21 I.4. Assessment Results. . . 19 Appendix I. Data Attribute Table . . . . . . . . . . . . . . . .2120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .2223 1.ScopeIntroduction This document describes a detailed, enterprise-specific vulnerability assessment scenario from which information model elements can be discovered.Such elements may include classes of data, major roles, and role interactions.This scenario also informs protocol and data model development in support of vulnerability assessment, as part of overall postureassessment.assessment (see Appendix B for examples of solutions that support this scenario). Vulnerability discovery, disclosure, publication, andpublicationprioritization is out of scope. However, given the importance of prioritization in an enterprise's vulnerability assessment process, it is discussed in Appendix C. Information on how the scenario aligns with SACM and other existing work is discussed in Appendix D through Appendix G. 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. Endpoint management capability: An enterprise IT capability managing 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 assessment: The process of determining whether a set of endpoints is vulnerable according to the information contained in the vulnerability description information.Supplemental collection: The task of collecting specific endpoint information from the target endpoint, that is not available from the endpoint management capability, in order to make a determination about that endpoint (vulnerability status, identification, etc.).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 vulnerability detection data that the enterprise's security software tools can understand and use. o The enterprise has a means of identifying enterprise endpointsalthough assertionsthrough 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. 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 initialassessment.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 An endpoint management capability is assumed to be in place within the enterprise, and is expected to collect a minimum set of attributes from the endpoints undermanagement,management via Collection Tasks and to establish an endpoint's identity within the scope of that domain. Endpoint identity can be established by collecting certainattributes (as part ofidentifying attributes, collectively known as theminimum set of attributes)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 stored, with appropriate metadata (i.e. timestamp), in a centrallocation.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 expected to be performed on an ongoing basis, resulting in routine, or evenevent- driven,event-driven, collection of basic endpoint information. See"Data Attribute Tables and Definitions"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"Data Attribute Tables and Definitions"Appendix I for information-specific details. 5. Endpoint Vulnerability Assessment Capability 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 isexamined.examined by the vulnerability management capability through Evaluation Tasks. o If the data possessed by the endpoint management capability is insufficient,thena 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 asupplemental collectionCollection Task will benecessary.triggered to collect it from the target endpoint. Of course, an implementation of an endpoint management capability may prefer to enable operators to performsupplementalthis 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).SupplementalThe collection of additional endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by the vulnerability assessment capability.Under certain deployment scenarios, once the necessary detection information is known, theOver time, some new pieces of informationbeyondthatwhich is available in theare needed during common types of assessments might be identified. An endpoint management capability can bepushedreconfigured to have this information delivered automatically. This avoids the need to trigger additional Collection Tasks to gather this information during assessments, streamlining thevulnerabilityassessmentcapabilityprocess. 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 endpointwhenever thatmanagement capability to no longer collect this informationchanges. See "Data Attribute Tablesto reduce network andDefinitions"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"Data Attribute Tables and Definitions"Appendix I for information-specific details. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations This document provides a core narrative that walks through an automated enterprise vulnerability assessment scenario and is aligned with SACM "Endpoint Security Posture Assessment: Enterprise Use Cases" [RFC7632]. As a result, the security considerations for [RFC7632] apply to this document. Furthermore, the data collected as part of the vulnerabilitydescription informationassessment may provide attackers with useful information such as what software an enterprise is running on their endpoints. As a result, organizations should consider properlyprotect the vulnerability description data it ingests.protecting this information. 9. Informative References [charter-ietf-sacm-01] Security Automation and Continuous Monitoring, "Charter, Version 1.0",July 2013.October 2015, <https://datatracker.ietf.org/doc/charter-ietf-sacm/>. [critical-controls]Council on CyberSecurity,Center for Internet Security, "Critical Security Controls, Version5.1". [draft-hansbury-sacm-oval-info-model-mapping-01]6.0", <https://www.cisecurity.org/critical- controls.cfm>. [cvrf] Industry Consortium for Advancement of Security on the Internet, "Common Vulnerability and Reporting Framework", May 2012, <http://www.icasi.org/cvrf/>. [draft-hansbury-sacm-oval-info-model-mapping-02] Security Automation and Continuous Monitoring, "OVAL and the SACM Information Model",November 2015.March 2016, <https://datatracker.ietf.org/doc/draft-hansbury-sacm- oval-info-model-mapping>. [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. [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. [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 2016. [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015, <http://www.rfc-editor.org/info/rfc7632>. Appendix A. Change Log A.1. 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. GitHub issue #19 (https://github.com/sacmwg/vulnerability-scenario/ issues/18). GitHub issue #20 (https://github.com/sacmwg/ 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 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 how to carry out a vulnerability assessment. GitHub issue #13 (https://github.com/sacmwg/vulnerability-scenario/issues/13). Changed "targeted collection" to "supplemental collection". GitHub issue #14 (https://github.com/sacmwg/vulnerability-scenario/ issues/14). Clarified that the ability for an enterprise to convert vulnerability description information and process it into a format usable by security tools is the same as the converting vulnerability description information into vulnerability detection data. GitHub issue #15 (https://github.com/sacmwg/vulnerability-scenario/ 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.2.A.3. 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 sections. Added an example to vulnerability description data in the scope section. Added a sentence to clarify vulnerability description data definition in the scope section. Added data repository example for long-term storage scope item. Added sentence to direct reader to examples of basic system information in endpoint identification section. Split the examples of information to collect in the pre-assessment collection section into a basic and advanced list. Added examples of data stored in the repository in the Assessment Results section. Added sentence for human-assigned attributes in the Future Work section. Replaced "vulnerability report" to "vulnerability description data" because the term report was causing confusion. Similarly, replaced "assessment report" with "assessment results". Replaced "Configuration Management Database (CMDB)" with "Repository" which is SACM's term for a data store. Replaced endpoint "Role" with "Purpose" because "Role" is already defined in SACM. Also, removed "Function" because it too is already defined in SACM. Clarified that the document does not try to define a normalized data format for vulnerability description data although it does not preclude the creation of such a format. Included additional examples of software configuration information. Clarified the section around endpoint identification to make it clear designation attributes used to correlate and identify endpoints are both persistent and unique. Furthermore, text was added to explain how the persistency of attributes may vary. This was based on knowledge gained from the Endpoint ID Design Team. Updated the Security Considerations section to mention those described in [RFC7632]. Removed text around Bring Your Own Device (BYOD). While important, BYOD just adds complexity to this initial draft. BYOD should be addressed in a later revision. Merged the list of "basic endpoint information" and the list of "human-assigned endpoint attributes" as both represent data we want to collect about an endpoint. Whether or not that data is natively available on the endpoint for collection or assigned by a human, computed, or derived from other data which may or may not be available on the endpoint for collection seems arbitrary. With this scenario, we primarily care about expressing information needs rather than how the information is collected or from where. Appendix B.Continuous Vulnerability Assessment It is not sufficient to perform a single assessment when vulnerability description information is published without any further checking. Doing so does not addressImplementation Examples B.1. Endpoint Data Collection Within thepossibility thatSACM Architecture, thereported vulnerability mightInternal and External Collector components could beintroducedused totheallow enterprises to collect posture attributes that demonstrate compliance with enterpriseenvironment after the initial assessment completes. For example, new endpointspolicy. Endpoints can beintroducedrequired tothe environmentprovide posture attributes, whichhave old software or are not up-to-date with patches. Another example is where unauthorized or obsoletemay include identification attributes to enable persistent communications. The SWID Message and Attributes for PA-TNC standard [I-D.coffin-sacm-nea-swid-patnc] defines collection and validation of softwareisidentities using the ISO Software Identification Tag Standard. Using this standard, the identity of all installedon an existingsoftware including the endpointby enterprise users after vulnerability description informationoperating system, could be collected andinitial assessment has taken place. Moreover, enterprises might not wish to, orused for later assessment. The OVAL Definitions Model [I-D.haynes-sacm-oval-definitions-model] provides a data model that can beable to, assess all vulnerability description information immediately when they come in. Conflicts with other critical activities or limited resources might mean that some alerts, especially those that the enterprise deemsused to specify what posture attributes to collect as"low priority", are notwell as their expected values which can be used toguide enterprise assessments until sometime after the initial receipt.drive an assessment. Thescenario above describes a single assessment of endpoints. However, it does not make any assumptions asOVAL System Characteristics Model [I-D.rothenberg-sacm-oval-sys-char-model] can be used towhen this assessment occurs relativecapture information about an endpoint. The model is specifically suited tothe original receipt of the vulnerability description dataexpressing OS information, endpoint identification information (such as IP and MAC addresses), and other endpoint metadata. B.2. Vulnerability Description Information The Common Vulnerability Reporting Framework (CVRF) [cvrf] is an XML- based language thatledattempts tothis assessment. The assessment could immediately followstandardize theingestioncreation ofthevulnerability descriptioninformation,information. Using CVRF, the enterprise couldbe delayed, orcreate automated tools based on theassessment might represent a reassessment of some vulnerability description information againststandardized schema whichendpoints had previously been assessed. Moreover,would obtain thescenario incorporates long-term storage of collected data, vulnerability description information,needed andassessment results in order to facilitate meaningfulrelevant information useful for later assessments andongoing reassessment. Appendix C. Priority Priorities associated withassessment results. B.3. Secondary Assessment Within the SACM Architecture, thevulnerability description information,assessmentresults, and any remedy is important, buttask would be handled by the Evaluator component. If previously collected data istreated asused, it would be obtained from aseparate challenge and, as such, has not been integrated intoData Store component. Within thedescription of this scenario. Nevertheless, it is important to point out and describe the use of priorities inSACM Architecture, theoverall vulnerability assessment scenario as a separate issue with its own sets of requirements. Priority in regardInternal and External Collector components could be used tovulnerability description information,allow enterprises to collect posture attributes that demonstrate compliance with enterprise policy. Endpoints can beviewed in a couple of different ways within an enterprise.required to provide posture attributes, which may include identification attributes to enable persistent communications. Theassessment prioritization involves prioritizationSWID Message and Attributes for PA-TNC standard defines collection and validation of software identities using thevulnerability description information assessment process. This determines what vulnerability description information is assessed, and in what order it is assessed in. For instance, a vulnerability affecting anISO Software Identification Tag Standard. Using this standard, all installed software including the endpoint operating systemor application used throughout the enterprise would likelycould beprioritized higher thancollected and stored for later assessment. The OVAL Definitions Model provides avulnerability in an application which isdata model that can be usedonly on a few, low-criticality endpoints. The prioritization of remedies relatestothe enterprise remediation and mitigation process based on the discovered vulnerabilities. Once an assessment has been performed and applicable endpoints identified, enterprise vulnerability managers must determine wherespecify what posture attributes tofocuscollect as well as theirefforts to apply appropriate remedies. For example, a vulnerability that is easily exploitable andexpected values which canallow arbitrary code execution mightberemedied before a vulnerability that is more difficultused toexploit or which just degrades performance. Some vulnerability description information include severities and/or otherdrive an assessment. The OVAL System Characteristics Model can be used to capture informationthat places the vulnerability in context. Thisabout an endpoint. The model is specifically suited to expressing OS information, endpoint identification information (such as IP and MAC addresses), and other endpoint metadata. The SACM Internal and External Attribute Collector components can be usedin both of the priority types discussed above. In other cases,to allow enterprises to collect posture attributes that demonstrate compliance with enterpriseadministratorspolicy. Endpoints can be required to provide posture attributes, which mayneedinclude identification attributes toprioritize based only on what they know about their enterprise and the description provided in the vulnerability description information. Examples ofenable persistent communications. B.4. Assessment Results The OVAL Results Model [I-D.cokus-sacm-oval-results-model] provides a dataattributes specificmodel topriority of assessments and/ or remedies include (but not limited to) the following: o Enterprise - defined purpose ofencode thedevice, criticalityresults of thedevice, exposure ofassessment, 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 thedevice, etc. o Severity attributes - A rating or scoreOVAL Results Model. Note thatattempts to providethelevel of severity or criticality associated with a given vulnerability. o Cyber threat intelligence - information such as tactics, techniques, and procedures of threat actors, indicatorsuse ofcompromise, incidents, coursesthe OVAL Results Model for sharing results is not recommended per section 7.3 ofaction, etc. that helptheenterprise understand relevant threatsOVAL andhow to detect, mitigate, or respondthe SACM Information Model [draft-hansbury-sacm-oval-info-model-mapping-02]. Within the SACM Architecture, the generation of the assessment results would occur in the Report Generator component. Those results might then be moved tothem. Appendix D.a DataAttribute Table D.1. TableStore 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 separate challenge and, as such, has not been integrated into the description of this scenario. Nevertheless, it is important to point out and describe the use of priorities in the overall vulnerability assessment scenario as a separate issue with its own sets of requirements. Priority in regard to vulnerability description information, can be viewed in a couple of different ways within an enterprise. Thefollowing table maps all major data attributes against each major process where they are used. +--------------+------------+--------------+-------------+----------+ | | vulnerabil | Endpoint Ide | Endpoint Ap | Assessme | | | ity descri | ntification | plicability | nt | | | ption data |assessment prioritization involves prioritization of the vulnerability description information assessment process. This determines what vulnerability description information is assessed, andInitial |in what order it is assessed in. For instance, a vulnerability affecting an operating system or application used throughout the enterprise would likely be prioritized higher than a vulnerability in an application which is used only on a few, low-criticality endpoints. The prioritization of remedies relates to the enterprise remediation and| Results | | | | (Pre- | Assessment | | | | | Assessment) | | | | | | Data | | | | | | Collection | | | +--------------+------------+--------------+-------------+----------+ | *Endpoint* | | | | | +--------------+------------+--------------+-------------+----------+ | Collection | | X | X | | | date/time | | | | | +--------------+------------+--------------+-------------+----------+ | Endpoint | | X | X | | | type | | | | | +--------------+------------+--------------+-------------+----------+ | Hardware ver | X | X | X | | | sion/firmwar | | | | | | e | | | | | +--------------+------------+--------------+-------------+----------+ | Operating | X | X | X | | | system | | | | | +--------------+------------+--------------+-------------+----------+ | Operating | X | X | X | | | system | | | | | | attributes | | | | | | (e.g., | | | | | | version, | | | | | | service pack | | | | | | level, | | | | | | edition, | | | | | | etc.) | | | | | +--------------+------------+--------------+-------------+----------+ | Installed | X | X | X | X | | software | | | | | | name | | | | | +--------------+------------+--------------+-------------+----------+ | Installed | X | X | X | X | | software | | | | | | attributes | | | | | | (e.g., | | | | | | version, | | | | | | patch level, | | | | | | install | | | | | | path, etc.) | | | | | +--------------+------------+--------------+-------------+----------+ | Open ports/s | X | X | X | | | ervices | | | | | +--------------+------------+--------------+-------------+----------+ | Operating | X | X | X | | | system | | | | | | optional | | | | | | component | | | | | | inventory | | | | | +--------------+------------+--------------+-------------+----------+ | Location | | X | | X | +--------------+------------+--------------+-------------+----------+ | Purpose | | X | | X | +--------------+------------+--------------+-------------+----------+ | Criticality | | X | | X | +--------------+------------+--------------+-------------+----------+ | File system | X | | X | | | attributes | | | | | | (e.g., | | | | | | versions, | | | | | | size, write | | | | | | date, | | | | | | modified | | | | | | date, | | | | | | checksum, | | | | | | etc.) | | | | | +--------------+------------+--------------+-------------+----------+ | Shared | X | | X | | | libraries | | | | | +--------------+------------+--------------+-------------+----------+ | Other | X | | X | | | software con | | | | | | figuration | | | | | | information | | | | | +--------------+------------+--------------+-------------+----------+ | *External vu | | | | | | lnerability | | | | | | description | | | | | | data* | | | | | +--------------+------------+--------------+-------------+----------+ | Ingest Date | X | | X | | +--------------+------------+--------------+-------------+----------+ | Date of | X | | X | | | Release | | | | | +--------------+------------+--------------+-------------+----------+ | Version | X | | X | | +--------------+------------+--------------+-------------+----------+ | External | X | | X | X | | vuln ID | | | | | +--------------+------------+--------------+-------------+----------+ | Severity | | | | X | | Score | | | | | +--------------+------------+--------------+-------------+----------+ | *Assessment | | | | | | Results* | | | | | +--------------+------------+--------------+-------------+----------+ | Date of | | | X | X | | assessment | | | | | +--------------+------------+--------------+-------------+----------+ | Date of data | | X | X | X | | collection | | | | | +--------------+------------+--------------+-------------+----------+ | Endpoint ide | | X | X | X | | ntification | | | | | | and/or | | | | | | locally | | | | | | assigned ID | | | | | +--------------+------------+--------------+-------------+----------+ | Vulnerable | X | X | X | X | | software | | | | | | product(s) | | | | | +--------------+------------+--------------+-------------+----------+ | Endpoint vul | | | X | X | | nerability | | | | | | status | | | | | +--------------+------------+--------------+-------------+----------+ | Vulnerabilit | X | | | X | | y | | | | | | description | | | | | +--------------+------------+--------------+-------------+----------+ | Vulnerabilit | X | | | X | | y | | | | | | rememdiation | | | | | +--------------+------------+--------------+-------------+----------+ Table 1: Vulnerability Assessment Attributes Appendix E. Alignment with Other Existing Works E.1. Critical Security Controls The Council on CyberSecurity's Critical Security Controls [critical-controls] includes security controls formitigation process based on the discovered vulnerabilities. Once an assessment has been performed and applicable endpoints identified, enterprise vulnerability managers must determine where to focus their efforts to apply appropriate remedies. For example, anumber of use scenarios, some ofvulnerability that is easily exploitable and whichare coveredcan allow arbitrary code execution might be remedied before a vulnerability that is more difficult to exploit or which just degrades performance. Some vulnerability description information include severities and/or other information that places the vulnerability inthis document.context. Thissection documents the alignment betweeninformation can be used in both of theCouncil's controlspriority types discussed above. In other cases, enterprise administrators may need to prioritize based only on what they know about their enterprise and therelevant elementsdescription provided in the vulnerability description information. Examples of data attributes specific to priority of assessments and/ or remedies include (but not limited to) thescenario. E.1.1. Continuous Vulnerability Assessment "CSC 4: Continuous Vulnerability Assessment and Remediation," which is described byfollowing: o Enterprise - defined purpose of theCouncil on CyberSecurity as "Continuously acquire, assess, and take action on new information in orderdevice, criticality of the device, exposure of the device, etc. o Severity attributes - A rating or score that attempts toidentify vulnerabilities, remediate, and minimizeprovide thewindowlevel ofopportunity for attackers."severity or criticality associated with a given vulnerability. o Cyber threat intelligence - information such as tactics, techniques, and procedures of threat actors, indicators of compromise, incidents, courses of action, etc. that help the enterprise understand relevant threats and how to detect, mitigate, or respond to them. Appendix D. SACM Usage Scenarios Thescenario described in thisSACM "Endpoint Security Posture Assessment: Enterprise Use Cases" documentis aligned with CSC 4 in([RFC7632]) defines multipleways: CSC 4-1 applies to this scenario inusage scenarios thatit calls for running regular, automated scanningare meant todeliver prioritized listsprovide examples ofvulnerabilities with which to respond. The scenario described in this documentimplementing the use cases and building block capabilities. Below isintended to be executed onacontinuous basis, and the prioritiesbrief summary ofboth vulnerability description information and the remedysome ofvulnerabilities are discussed in the Priority section earlier inthese usage scenarios and how thisdocument. This scenario assumes thatdocument aligns and/or adds additional value to the identified usage scenarios. o Automated Checklist Verification (2.2.2) - "An enterprisealready hasoperates asourceheterogeneous IT environment. They utilize vendor-provided automatable security configuration checklists forvulnerability description information as described in CSC 4-4. Both CSC 4-2each operating system and4-7application used within their IT environment. Multiple checklists aremade possible by writing informationused from different vendors toa Repository since this makes previously collected data available for later analysis. While this scenario does not go into the details of how prioritization would be calculated or applied, it does touch on someensure adequate coverage ofthe important ways in which prioritization would impact the endpoint assessment processall IT assets." The usage scenario, as defined in thePriority section. As such,RFC, is targeted at thePriority section aligns with CSC 4-10, which deals with vulnerability priority. Vulnerability priority in this scenariochecklist level and can be interpreted as being specific to endpoint configuration. There isdiscussed in termsmention ofthepatch assessment and vulnerabilitydescription information priority during receipt, as well asmitigation, but thevulnerability priority with regards to remedies. The describedusage scenariodoes not addresscould be expanded upon by including vulnerability verification. Replacing thedetailsidea ofapplyingaremedy based on assessment results. As such, CSC 4-5, 4-8, and 4-9, which all deal with mitigations and patching, are out of scope for this work. Similarly, CSC 4-3 prescribes performing scanschecklist inauthenticated mode and CSC 4-6 prescribes monitoring logs. Thisthe SACM usage scenariodoes not get intowith vulnerability would allow themeans by which data is collected, focusing on "what"usage scenario tocollect rather than "how", and as such does not have corresponding sections, although the procedures described are not incompatible with either of these controls. The CSC 4 System Entity Relationship diagram and numbered steps directlyalign almost exactly with the scenario described in thisdocument with the exceptiondocument. Instead ofstep 7 (patch response). Steps 1 -6 in CSC 4 describe the overall process for vulnerability management starting with obtainingcollecting automatable security configuration checklists, the enterprise would collect automatable vulnerability description information available from thesource in Step 1,vendor as described or possibly from other interested third-parties. o Detection of Posture Deviations (2.2.3) - "An enterprise has established secure configuration baselines for each different type of endpoint within their IT environment. When an endpoint connects toproducing assessment resultsthe network, the appropriate baseline configuration is communicated to the endpoint. Once the baseline has been established, the endpoint is monitored for any change events pertaining to the baseline on an ongoing basis. When a change occurs to posture defined inStep 6. E.1.2. Hardware and Software Inventories This scenariothe baseline, updated posture information isalso aligned with, and describes a process for, collecting and maintaining hardware and software inventories, which are covered byexchanged. When theCouncil on CyberSecurity CSC 1 "Inventory of Authorized and Unauthorized Devices" and CSC 2 "Inventory of Authorized and Unauthorized Software." This scenario documentsendpoint detects aprocess thatposture change, an alert is generated identifying the specificto collecting and maintaining hardware and software data attributes for vulnerability assessment purposes, butchanges in posture." This usage scenario would support thecollectionconcept of endpoints signaling or alerting thehardware attributes and software inventory documentedenterprise to changes in theEndpoint Data Collection sectionposture relates to endpoint vulnerabilities in the same way thatfollows can also be usedit would for configurations. Replacing thepurposeidea ofimplementing authorized and unauthorized hardware and software management processes (e.g., scanning tools looking for unauthorized software). Moreover, the ability to accurately identify endpoints and, toalesser degree, applications is integral to effective endpointchecklist with vulnerability description datacollectionallows the SACM usage scenario andvulnerability management. The Endpoint Data Collection section does not have coverage forthespecific detailsscenario described inCSC 1 and 2 as they are different processes and would be out-of-scope ofthisscenario, butdocument to align in their objectives. o Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra (2.2.5) - "An isolated arctic IT environment that is separated from thesection does providemain university network. The only network communications are via an intermittent, low-speed, high-latency, high-cost satellite link. Remote network admins will need to show continued compliance with the security policies of thedata necessary to supportuniversity, thecontrols. The Endpoint Identificationgovernment, andEndpoint Data Collection sections within thisthe provider of the satellite network, as well as keep current on vulnerability testing." This SACM usage scenarioalign with CSC 1-1 and 1-4 by identifying enterprise endpoints and collecting their hardwaredescribes vulnerability assessment andnetwork attributes. The Endpoint Data Collection sectionaligns well with the vulnerability scenario described in this document. The endpoint assets are identified andsupports CSC 2-3 and 2-4 by definingassociated data is published in asoftware inventory processRepository. Vulnerability description information is collected and saved in amethod of obtaining operating system and file system attributes.Repository as it is released. Therest ofvulnerability description information is queued for later assessment, then theitems from CSC 1 and 2 deal with implementation detailsassessment results andwould be out-of-scope forvulnerability description information are stored after assessment. The only real difference in thisdocument. CSC 2-9 describesSACM usage scenario is theusetiming ofa software ID tag in XML format. SWID tags (https://en.wikipedia.org/wiki/ISO/IEC_19770) would also be a possible implementation fortheEndpoint Data Collection sectionassessments. The scenario describedinwithin thisscenario.document would have no problems adjusting to the timing of this SACM usage scenario or anything similar. AppendixF.E. SACMUsage ScenariosRequirements and Charter - Future Work In the course authoring this document, some additional considerations for possible future work were noted. The following points were taken from the SACM Requirements [I-D.ietf-sacm-requirements], SACM Charter [charter-ietf-sacm-01], and SACM"Endpoint Security Posture Assessment: EnterpriseUseCases" documentCases ([RFC7632])defines multiple usage scenariosdocuments and represent work thatare meant to provide examplesmay be necessary to support the tasks or goals ofimplementingSACM going forward. o The SACM requirements mentions "Result Reporting" with applications but no detail around what theuse cases and building block capabilities. Belowassessment results data set should include. In the case of vulnerability assessment results, context is important and details beyond just abrief summaryPass or Fail result are needed in order to take action. A good example ofsomethis might be the Priority ofthese usage scenariosthe vulnerability itself and how many systems it affects within the enterprise. With thisdocument aligns and/or adds additional valuein mind, it might be worthwhile tothe identified usage scenarios. o Automated Checklist Verification (2.2.2) - "An enterprise operatesinvestigate aheterogeneous IT environment. They utilize vendor-provided automatable security configuration checklistsminimum data set or schema foreach operating system and application used within their IT environment. Multiple checklists are used from different vendors to ensure adequate coverage of all IT assets."assessment results. Theusage scenario,concern here is with vulnerability description data, but this could apply to other enterprise processes asdefinedwell. o The "Human-assigned endpoint attributes" mentioned previously in this scenario are touched on in theRFC, is targeted atSACM use cases, but thechecklist leveltopic could probably be explored in much more depth. Enterprise policy andcanbehaviors could beinterpretedgreatly influenced by endpoint attributes such asbeing specific tolocations, how the endpointconfiguration. Thereismention of patch assessmentused, andvulnerability mitigation, butcriticality. When and how these data attributes are collected, as well as what theusage scenario couldminimum or common set might look like, would beexpanded upon by including vulnerability verification. Replacinggood topics for future related SACM work. In addition, theideastorage ofa checklistthese attributes could be central (stored in a data repository) or they could be assigned and stored on the endpoints themselves. Appendix F. SACMusage scenarioUse Case Alignment F.1. Endpoint Identification This sub-step aligns withvulnerability would allowtheusage scenarioEndpoint Discovery, Endpoint Characterization, and Endpoint Target Identification building block capabilities. The alignment is due toalign almost exactly with the scenario described in this document. Instead of collecting automatable security configuration checklists,theenterprise would collect automatable vulnerability description information available fromfact that thevendor as described or possibly from other interested third-parties. o Detectionpurpose ofPosture Deviations (2.2.3) - "Anthis sub-step is to discover, identify, and characterize all endpoints on an enterprisehas established secure configuration baselines for each different typenetwork. F.2. Endpoint Data Collection This sub-step aligns with the Data Publication building block capability because this section involves storage of endpoint attributes withintheir IT environment. Whenanendpoint connects to the network, the appropriate baseline configuration is communicated to the endpoint. Onceenterprise Repository. This sub-step also aligns with thebaseline has been established,Endpoint Characterization and Endpoint Target Identification building block capabilities because it further characterizes the endpoint through automated and possibly manual means. There ismonitored for any change events pertaining todirect alignment with thebaseline on an ongoing basis. When a change occurs to posture defined inEndpoint Component Inventory, Posture Attribute Identification, and Posture Attribute Value Collection building block capabilities since thebaseline, updated posture informationpurpose of this sub-step isexchanged. Whento perform an initial inventory of the endpointdetects a posture change, an alertand collect basic attributes and their values. Last, there isgenerated identifyingalignment with thespecific changes in posture." This usage scenario would supportCollection Guidance Acquisition building block capabilities as theconceptinventory and collection ofendpoints signaling or alerting the enterprise to changes in the posture relates toendpointvulnerabilities in the same way that itattributes wouldfor configurations. Replacing the ideabe directed by some type ofa checklistenterprise or third-party guidance. F.3. Vulnerability Description Information This step aligns with the Data Publication and Data Retrieval building block capabilities because this section details storage of vulnerability descriptiondata allows the SACM usage scenarioinformation within an enterprise Repository and later retrieval of thescenario describedsame. F.4. Applicability This sub-step aligns with the Data Retrieval, Data Query, and Posture Attribute Value Query building block capabilities because, in thisdocument to align in their objectives. o Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra (2.2.5) - "An isolated arctic IT environment that is separated fromsub-step, themain university network. The only network communications are via an intermittent, low-speed, high-latency, high-cost satellite link. Remote network admins will needprocess is attempting toshow continued compliance withdetermine thesecurity policiesvulnerability status of theuniversity,endpoint using thegovernment, anddata that has previously been collected. F.5. Secondary Assessment This sub-step aligns with theproviderData Publication building block capability because this section details storage of endpoint attributes within an enterprise Repository. The sub-step also aligns with the Collection Guidance Acquisition building block capability since thesatellite network, as well as keep current on vulnerability testing." This SACM usage scenario describesvulnerabilityassessment anddescription information (guidance) drives the collection of additional endpoint attributes. This sub-step alignswellwith thevulnerability scenario described in this document. The endpoint assets are identifiedEndpoint Characterization (both manual andassociated data is published in a Repository. Vulnerability description information is collectedautomated) andsaved in a Repository asEndpoint Target Identification building block capabilities because itis released. The vulnerability description information is queued for later assessment, thencould further characterize theassessment resultsendpoint through automated andvulnerability description information are stored after assessment. The only real difference in this SACM usage scenariopossibly manual means. There is direct alignment with thetiming of the assessments. The scenario described within this document would have no problems adjusting to the timing of this SACM usage scenario or anything similar. Appendix G. SACM RequirementsEndpoint Component Inventory, Posture Attribute Identification, andCharter - Future Work InPosture Attribute Value Collection building block capabilities since thecourse authoringpurpose of thisdocument, somesub-step is to perform additionalconsiderations for possible future work were noted. The following points were taken from the SACM Requirements [I-D.ietf-sacm-requirements], SACM Charter [charter-ietf-sacm-01],andSACM Use Cases ([RFC7632]) documentsmore specific component inventories andrepresent work that may be necessary to support the tasks or goalscollections ofSACM going forward. o The SACM requirements mentions "Result Reporting"endpoint attributes and their values. F.6. Assessment Results This step aligns withapplications but no detail around what the assessment results data set should include. InthecaseData Publication and Data Retrieval building block capabilities because this section details storage of vulnerabilityassessment results, context is importantassessment results within an enterprise Repository anddetails beyond justlater retrieval of the same. Appendix G. Alignment with Other Existing Works G.1. Critical Security Controls The Center for Internet Security's Critical Security Controls [critical-controls] includes security controls for aPass or Fail resultnumber of usage scenarios, some of which areneededcovered inorder to take action. A good example ofthismight bedocument. This section documents thePriorityalignment between the Center's controls and the relevant elements of thevulnerability itselfscenario. G.1.1. Continuous Vulnerability Assessment "CSC 4: Continuous Vulnerability Assessment andhow many systems it affects withinRemediation," which is described by theenterprise. With thisCenter for Internet Security as "Continuously acquire, assess, and take action on new information inmind, it might be worthwhileorder toinvestigate a minimum data set or schemaidentify vulnerabilities, remediate, and minimize the window of opportunity forassessment results.attackers." Theconcern herescenario described in this document is aligned withvulnerability description data, butCSC 4 in multiple ways: CSC 4.1 applies to thiscould applyscenario in that it calls for running regular, automated scanning toother enterprise processes as well. odeliver prioritized lists of vulnerabilities with which to respond. The"Human-assigned endpoint attributes" mentioned previouslyscenario described in thisscenario are toucheddocument is intended to be executed onina continuous basis, and theSACM use cases, butpriorities of both vulnerability description information and thetopic could probably be exploredremedy of vulnerabilities are discussed inmuch more depth. Enterprise policy and behaviors could be greatly influenced by endpoint attributes suchthe Priority section earlier in this document. This scenario assumes that the enterprise already has a source for vulnerability description information aslocations, how the endpoint is used, and criticality. Whendescribed in CSC 4.4. Both CSC 4.2 andhow these data attributes4.7 arecollected, as well as what the minimum or common set might look like, would be good topicsmade possible by writing information to a Repository since this makes previously collected data available forfuture related SACM work. In addition,later analysis. While this scenario does not go into thestoragedetails ofthese attributes couldhow prioritization would becentral (stored in a data repository)calculated orthey could be assigned and storedapplied, it does touch on some of theendpoints themselves. Appendix H. SACM Use Case Alignment H.1. Endpoint Identification This sub-step aligns withimportant ways in which prioritization would impact theEndpoint Discovery, Endpoint Characterization, and Endpoint Target Identification building block capabilities. The alignment is due toendpoint assessment process in thefact thatPriority section. As such, thepurpose of this sub-step is to discover, identify, and characterize all endpoints on an enterprise network. H.2. Endpoint Data Collection This sub-stepPriority section aligns withthe Data Publication building block capability becauseCSC 4.8, which deals with vulnerability priority. Vulnerability priority in thissection involves storagescenario is discussed in terms ofendpoint attributes within an enterprise Repository. This sub-step also aligns withtheEndpoint Characterization and Endpoint Target Identification building block capabilities because it further characterizesvulnerability description information priority during receipt, as well as theendpoint through automated and possibly manual means. There is direct alignmentvulnerability priority with regards to remedies. The described scenario does not address the details of applying a remedy based on assessment results. As such, CSC 4.5 which deals withthe Endpoint Component Inventory, Posture Attribute Identification,mitigations andPosture Attribute Value Collection building block capabilities since the purposepatching, is out of scope for thissub-stepwork. Similarly, CSC 4.3 prescribes performing scans in authenticated mode and CSC 4.6 prescribes monitoring logs. This scenario does not get into the means by which data is collected, focusing on "what" toperform an initial inventory of the endpoint andcollectbasic attributesrather than "how", andtheir values. Last, there is alignment with the Collection Guidance Acquisition building block capabilitiesas such does not have corresponding sections, although theinventory and collection of endpoint attributes would be directed by some typeprocedures described are not incompatible with either ofenterprise or third-party guidance. H.3. Vulnerability Description Information This stepthese controls. The CSC 4 System Entity Relationship diagram directly aligns with theData Publication and Data Retrieval building block capabilities becausescenario described in thissection details storagedocument with the exception ofvulnerability description information within an enterprise Repositoryapplying patches to endpoints. G.1.2. Hardware andlater retrieval of the same. H.4. ApplicabilitySoftware Inventories Thissub-step aligns with the Data Retrieval, Data Query,scenario is also aligned with, andPosture Attribute Value Query building block capabilities because, in this sub-step, thedescribes a processis attempting to determinefor, collecting and maintaining hardware and software inventories, which are covered by thevulnerability statusCenter for Internet Security CSC 1 "Inventory ofthe endpoint using the data that has previously been collected. H.5. Secondary Assessment This sub-step aligns with the Data Publication building block capability because this section details storageAuthorized and Unauthorized Devices" and CSC 2 "Inventory ofendpointAuthorized and Unauthorized Software." This scenario documents a process that is specific to collecting and maintaining hardware and software data attributeswithin an enterprise Repository. The sub-step also aligns with the Collection Guidance Acquisition building block capability since thefor vulnerabilitydescription information (guidance) drivesassessment purposes, but the collection ofadditional endpoint attributes. This sub-step aligns withthe hardware attributes and software inventory documented in the EndpointCharacterization (both manualData Collection section that follows can also be used for the purpose of implementing authorized andautomated)unauthorized hardware andEndpoint Target Identification building block capabilities because it could further characterizesoftware management processes (e.g., scanning tools looking for unauthorized software). Moreover, the ability to accurately identify endpoints and, to a lesser degree, applications is integral to effective endpointthrough automateddata collection andpossibly manual means. There is direct alignment with thevulnerability management. The EndpointComponent Inventory, Posture Attribute Identification, and Posture Attribute ValueData Collectionbuilding block capabilities sincesection does not have coverage for thepurposespecific details described in CSC 1 and 2 as they are different processes and would be out-of-scope of thissub-step isscenario, but the section does provide the data necessary toperform additionalsupport the controls. The Endpoint Identification andmore specific component inventoriesEndpoint Data Collection sections within this scenario align with CSC 1.1 andcollections of endpoint attributes1.4 by identifying enterprise endpoints and collecting theirvalues. H.6. Assessment Results This step aligns with the Data Publicationhardware and network attributes. The Endpoint DataRetrieval building block capabilities because thisCollection sectiondetails storage of vulnerability assessment results within an enterprise Repositoryaligns with and supports CSC 2.3 by defining a software inventory process andlater retrievala method of obtaining operating system and file system attributes. The rest of thesame.items from CSC 1 and 2 deal with implementation details and would be out-of-scope for this document. AppendixI. Implementation Examples I.1. Endpoint Data Collection WithinH. Continuous Vulnerability Assessment It is not sufficient to perform a single assessment when vulnerability description information is published without any further checking. Doing so does not address theSACM Architecture,possibility that theInternal and External Collector components couldreported vulnerability might beused to allow enterprisesintroduced tocollect posture attributes that demonstrate compliance withthe enterprisepolicy. Endpointsenvironment after the initial assessment completes. For example, new endpoints can berequiredintroduced toprovide posture attributes,the environment whichmay include identification attributes to enable persistent communications. The SWID Message and Attributes for PA-TNC standard defines collection and validation ofhave old softwareidentities using the ISO Software Identification Tag Standard. Using this standard, the identity of all installedor are not up-to-date with patches. Another example is where unauthorized or obsolete softwareincluding theis installed on an existing endpointoperating system, could be collectedby enterprise users after vulnerability description information andused for later assessment. The OVAL Definitions Model provides a data model that can be used to specify what posture attributes to collect as well as their expected values which caninitial assessment has taken place. Moreover, enterprises might not wish to, or be able to, assess all vulnerability description information immediately when they come in. Conflicts with other critical activities or limited resources might mean that some alerts, especially those that the enterprise deems as "low priority", are not used todrive an assessment.guide enterprise assessments until sometime after the initial receipt. TheOVAL System Characteristics Model can be usedscenario above describes a single assessment of endpoints. However, it does not make any assumptions as tocapture information about an endpoint. The model is specifically suitedwhen this assessment occurs relative toexpressing OS information, endpoint identification information (such as IP and MAC addresses), and other endpoint metadata. I.2. Vulnerability Description Information The Common Vulnerability Reporting Framework (CVRF) is an XML-based languagethe original receipt of the vulnerability description data thatattemptsled tostandardizethis assessment. The assessment could immediately follow thecreationingestion of the vulnerability descriptioninformation. Using CVRF, the enterpriseinformation, couldcreate automated tools based onbe delayed, or thestandardized schemaassessment might represent a reassessment of some vulnerability description information against whichwould obtainendpoints had previously been assessed. Moreover, theneeded and relevant information useful for later assessmentsscenario incorporates long-term storage of collected data, vulnerability description information, and assessmentresults. I.3. Secondary Assessment Within the SACM Architecture, the assessment task would be handled by the Evaluator component. If pre-assessment data is used, this would be stored onresults in order to facilitate meaningful andobtained from aongoing reassessment. Appendix I. DataStore component. Within the SACM Architecture, the Internal and External Collector components could be used to allow enterprises to collect posture attributes that demonstrate compliance with enterprise policy. Endpoints can be required to provide posture attributes, which may include identification attributes to enable persistent communications.Attribute Table TheSWID Messagefollowing table maps all major data attributes against each major process where they are used. +--------------+------------+-------------+-------------+-----------+ | | vulnerabil | Endpoint Id | Endpoint Ap | Assessmen | | | ity descri | entificatio | plicability | t Results | | | ption data | n andAttributes for PA-TNC standard defines collection| andvalidation of| | | | | Initial | Assessment | | | | | Data | | | | | | Collection | | | +--------------+------------+-------------+-------------+-----------+ | *Endpoint* | | | | | +--------------+------------+-------------+-------------+-----------+ | Collection | | X | X | | | date/time | | | | | +--------------+------------+-------------+-------------+-----------+ | Endpoint | | X | X | | | type | | | | | +--------------+------------+-------------+-------------+-----------+ | Hardware ver | X | X | X | | | sion/firmwar | | | | | | e | | | | | +--------------+------------+-------------+-------------+-----------+ | Operating | X | X | X | | | system | | | | | +--------------+------------+-------------+-------------+-----------+ | Operating | X | X | X | | | system | | | | | | attributes | | | | | | (e.g., | | | | | | version, | | | | | | service pack | | | | | | level, | | | | | | edition, | | | | | | etc.) | | | | | +--------------+------------+-------------+-------------+-----------+ | Installed | X | X | X | X | | softwareidentities using the ISO Software Identification Tag Standard. Using this standard, all installed| | | | | | name | | | | | +--------------+------------+-------------+-------------+-----------+ | Installed | X | X | X | X | | softwareincluding the endpoint operating system could be collected and stored for later assessment. The OVAL Definitions Model provides a data model that can be used to specify what posture attributes to collect as well as their expected values which can be used to drive an assessment. The OVAL System Characteristics Model can be used to capture information about an endpoint. The model is specifically suited to expressing OS information, endpoint identification information (such as IP and MAC addresses), and other endpoint metadata. The SACM Internal and External Attribute Collector components can be used to allow enterprises to collect posture| | | | | | attributesthat demonstrate compliance with enterprise policy. Endpoints can be required to provide posture attributes, which may include identification| | | | | | (e.g., | | | | | | version, | | | | | | patch level, | | | | | | install | | | | | | path, etc.) | | | | | +--------------+------------+-------------+-------------+-----------+ | Open ports/s | X | X | X | | | ervices | | | | | +--------------+------------+-------------+-------------+-----------+ | Operating | X | X | X | | | system | | | | | | optional | | | | | | component | | | | | | inventory | | | | | +--------------+------------+-------------+-------------+-----------+ | Location | | X | | X | +--------------+------------+-------------+-------------+-----------+ | Purpose | | X | | X | +--------------+------------+-------------+-------------+-----------+ | Criticality | | X | | X | +--------------+------------+-------------+-------------+-----------+ | File system | X | | X | | | attributesto enable persistent communications. I.4. Assessment Results The 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| | | | | | (e.g., | | | | | | versions, | | | | | | size, write | | | | | | date, | | | | | | modified | | | | | | date, | | | | | | checksum, | | | | | | etc.) | | | | | +--------------+------------+-------------+-------------+-----------+ | Shared | X | | X | | | libraries | | | | | +--------------+------------+-------------+-------------+-----------+ | Other | X | | X | | | software con | | | | | | figuration | | | | | | information | | | | | +--------------+------------+-------------+-------------+-----------+ | *External vu | | | | | | lnerability | | | | | | description | | | | | | data* | | | | | +--------------+------------+-------------+-------------+-----------+ | Ingest Date | X | | X | | +--------------+------------+-------------+-------------+-----------+ | Date ofthe OVAL and the SACM Information Model [draft-hansbury-sacm-oval-info-model-mapping-01]. Within the SACM Architecture, the generation| X | | X | | | Release | | | | | +--------------+------------+-------------+-------------+-----------+ | Version | X | | X | | +--------------+------------+-------------+-------------+-----------+ | External | X | | X | X | | vuln ID | | | | | +--------------+------------+-------------+-------------+-----------+ | Severity | | | | X | | Score | | | | | +--------------+------------+-------------+-------------+-----------+ | *Assessment | | | | | | Results* | | | | | +--------------+------------+-------------+-------------+-----------+ | Date ofthe| | | X | X | | assessmentresults 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.| | | | | +--------------+------------+-------------+-------------+-----------+ | Date of data | | X | X | X | | collection | | | | | +--------------+------------+-------------+-------------+-----------+ | Endpoint ide | | X | X | X | | ntification | | | | | | and/or | | | | | | locally | | | | | | assigned ID | | | | | +--------------+------------+-------------+-------------+-----------+ | Vulnerable | X | X | X | X | | software | | | | | | product(s) | | | | | +--------------+------------+-------------+-------------+-----------+ | Endpoint vul | | | X | X | | nerability | | | | | | status | | | | | +--------------+------------+-------------+-------------+-----------+ | Vulnerabilit | X | | | X | | y | | | | | | description | | | | | +--------------+------------+-------------+-------------+-----------+ | Vulnerabilit | X | | | X | | y | | | | | | remediation | | | | | +--------------+------------+-------------+-------------+-----------+ Table 1: Vulnerability Assessment Attributes Authors' Addresses Christopher Coffin The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: ccoffin@mitre.org Brant Cheikes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: bcheikes@mitre.org Charles Schmidt The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: cmschmidt@mitre.org Daniel Haynes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: dhaynes@mitre.org Jessica Fitzgerald-McKay Department of Defense 9800 Savage Road Ft. Meade, Maryland USA Email: jmfitz2@nsa.gov David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20877 USA Email: david.waltermire@nist.gov