This document describes an automated enterprise vulnerability assessment scenario aligned with the SACM Use Cases. The scenario 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.
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 Implementation Examples for examples of solutions that support this scenario).
Vulnerability discovery, disclosure, publication, and prioritization is out of scope. However, given the importance of prioritization in an enterprise's vulnerability assessment process, it is discussed in Priority.
Information on how the scenario aligns with SACM and other existing work is discussed in SACM Usage Scenarios through Alignment with Other Existing Works.
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 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 capabilities
An enterprise IT department's ability to manage endpoint identity, endpoint information, and associated metadata on an ongoing basis.
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 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.
A number of assumptions must be stated in order to further clarify the position and scope of this document.
The document assumes that:
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.
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 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 capabilities are expected to be performed on an ongoing basis, resulting in routine, or even event-driven, collection of basic endpoint information.
See Data Attribute Table for information-specific details.
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. The enterprise is responsible for determining the sources of vulnerability description information as well as which vulnerability description information is converted into vulnerability detection data.
See Data Attribute Table for information-specific details.
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:
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:
In many cases, the endpoint information needed to determine an endpoint's vulnerability status will have been previously collected 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 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 Data Attribute Table for information-specific details.
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 Table for information-specific details.
This memo includes no request to IANA.
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" RFC 7632. As a result, the security considerations for RFC 7632 apply to this document. Furthermore, the data collected as part of the vulnerability assessment may provide attackers with useful information such as what software an enterprise is running on their endpoints. As a result, organizations should consider properly protecting this information.
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.
The SWID Message and Attributes for PA-TNC standard I-D.ietf-sacm-nea-swid-patnc defines collection and validation of software identities using the ISO Software Identification Tag Standard. Using this standard, the identity of all installed software including the endpoint operating system, could be collected and used for later assessment.
The OVAL Definitions Model I-D.haynes-sacm-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 I-D.rothenberg-sacm-oval-sys-char-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 Common Vulnerability Reporting Framework (CVRF) is an XML-based language that attempts to standardize the creation of vulnerability description information. Using CVRF, the enterprise could create automated tools based on the standardized schema which would obtain the needed and relevant information useful for later assessments and assessment results.
Within the SACM Architecture, the assessment task would be handled by the Evaluator component. If previously collected data is used, it would be obtained from a Data Store 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.
The SWID Message and Attributes for PA-TNC standard defines collection and validation of software identities using the ISO Software Identification Tag Standard. Using this standard, all installed software including 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 attributes that demonstrate compliance with enterprise policy. Endpoints can be required to provide posture attributes, which may include identification attributes to enable persistent communications.
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 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.
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. The assessment prioritization involves prioritization of the vulnerability 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 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 mitigation 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, a vulnerability that is easily exploitable and which can 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 in context. This information can be used in both of the priority types discussed above. In other cases, enterprise administrators may need to prioritize based only on what they know about their enterprise and the description provided in the vulnerability description information.
Examples of data attributes specific to priority of assessments and/or remedies include (but not limited to) the following:
The SACM "Endpoint Security Posture Assessment: Enterprise Use Cases" document (RFC 7632) defines multiple usage scenarios that are meant to provide examples of implementing the use cases and building block capabilities. Below is a brief summary of some of these usage scenarios and how this document aligns and/or adds additional value to the identified usage scenarios.
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.ietfI-D.ietf-sacm-requirements, SACM Charter charter-ietf-sacm-01, and SACM Use Cases (RFC 7632) documents and represent work that may be necessary to support the tasks or goals of SACM going forward.
This sub-step aligns with the Endpoint Discovery, Endpoint Characterization, and Endpoint Target Identification building block capabilities. The alignment is due to the fact that the purpose of this sub-step is to discover, identify, and characterize all endpoints on an enterprise network.
This sub-step aligns with the Data Publication building block capability because this section involves storage of endpoint attributes within an enterprise Repository. This sub-step also aligns with the Endpoint Characterization and Endpoint Target Identification building block capabilities because it further characterizes the endpoint through automated and possibly manual means. There is direct alignment with the Endpoint Component Inventory, Posture Attribute Identification, and Posture Attribute Value Collection building block capabilities since the purpose of this sub-step is to perform an initial inventory of the endpoint and collect basic attributes and their values. Last, there is alignment with the Collection Guidance Acquisition building block capabilities as the inventory and collection of endpoint attributes would be directed by some type of enterprise or third-party guidance.
This step aligns with the Data Publication and Data Retrieval building block capabilities because this section details storage of vulnerability description information within an enterprise Repository and later retrieval of the same.
This sub-step aligns with the Data Retrieval, Data Query, and Posture Attribute Value Query building block capabilities because, in this sub-step, the process is attempting to determine the vulnerability status of the endpoint using the data that has previously been collected.
This sub-step aligns with the Data 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 the vulnerability description information (guidance) drives the collection of additional endpoint attributes.
This sub-step aligns with the Endpoint Characterization (both manual and automated) and Endpoint Target Identification building block capabilities because it could further characterize the endpoint through automated and possibly manual means. There is direct alignment with the Endpoint Component Inventory, Posture Attribute Identification, and Posture Attribute Value Collection building block capabilities since the purpose of this sub-step is to perform additional and more specific component inventories and collections of endpoint attributes and their values.
This step aligns with the Data Publication and Data Retrieval building block capabilities because this section details storage of vulnerability assessment results within an enterprise Repository and later retrieval of the same.
The Center for Internet Security's Critical Security Controls critical-controls includes security controls for a number of usage scenarios, some of which are covered in this document. This section documents the alignment between the Center's controls and the relevant elements of the scenario.
"CSC 4: Continuous Vulnerability Assessment and Remediation," which is described by the Center for Internet Security as "Continuously acquire, assess, and take action on new information in order to identify vulnerabilities, remediate, and minimize the window of opportunity for attackers." The scenario described in this document is aligned with CSC 4 in multiple ways:
CSC 4.1 applies to this scenario in that it calls for running regular, automated scanning to deliver prioritized lists of vulnerabilities with which to respond. The scenario described in this document is intended to be executed on a continuous basis, and the priorities of both vulnerability description information and the remedy of vulnerabilities are discussed in the Priority section earlier in this document.
This scenario assumes that the enterprise already has a source for vulnerability description information as described in CSC 4.4.
Both CSC 4.2 and 4.7 are made possible by writing information to a 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 some of the important ways in which prioritization would impact the endpoint assessment process in the Priority section. As such, the Priority section aligns with CSC 4.8, which deals with vulnerability priority. Vulnerability priority in this scenario is discussed in terms of the vulnerability description information priority during receipt, as well as the vulnerability 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 with mitigations and patching, is out of scope for this work. 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" to collect 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 directly aligns with the scenario described in this document with the exception of applying patches to endpoints.
This scenario is also aligned with, and describes a process for, collecting and maintaining hardware and software inventories, which are covered by the Center for Internet Security CSC 1 "Inventory of Authorized and Unauthorized Devices" and CSC 2 "Inventory of Authorized and Unauthorized Software." This scenario documents a process that is specific to collecting and maintaining hardware and software data attributes for vulnerability assessment purposes, but the collection of the hardware attributes and software inventory documented in the Endpoint Data Collection section that follows can also be used for the purpose of implementing authorized and unauthorized hardware and software 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 endpoint data collection and vulnerability management.
The Endpoint Data Collection section does not have coverage for the specific details described in CSC 1 and 2 as they are different processes and would be out-of-scope of this scenario, but the section does provide the data necessary to support the controls.
The Endpoint Identification and Endpoint Data Collection sections within this scenario align with CSC 1.1 and 1.4 by identifying enterprise endpoints and collecting their hardware and network attributes. The Endpoint Data Collection section aligns with and supports CSC 2.3 by defining a software inventory process and a method of obtaining operating system and file system attributes. The rest of the items from CSC 1 and 2 deal with implementation details and would be out-of-scope for this document.
It is not sufficient to perform a single assessment when vulnerability description information is published without any further checking. Doing so does not address the possibility that the reported vulnerability might be introduced to the enterprise environment after the initial assessment completes. For example, new endpoints can be introduced to the environment which have old software or are not up-to-date with patches. Another example is where unauthorized or obsolete software is installed on an existing endpoint by enterprise users after vulnerability description information and initial 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 to guide enterprise assessments until sometime after the initial receipt.
The scenario above describes a single assessment of endpoints. However, it does not make any assumptions as to when this assessment occurs relative to the original receipt of the vulnerability description data that led to this assessment. The assessment could immediately follow the ingestion of the vulnerability description information, could be delayed, or the assessment might represent a reassessment of some vulnerability description information against which endpoints had previously been assessed. Moreover, the scenario incorporates long-term storage of collected data, vulnerability description information, and assessment results in order to facilitate meaningful and ongoing reassessment.
The following table maps all major data attributes against each major process where they are used.
Vulnerability Description Data | Endpoint Identification and Initial Data Collection | Endpoint Applicability and Assessment | Assessment Results | |
Endpoint | ||||
Collection date/time | X | X | ||
Endpoint Type | X | X | ||
Hardware Version/Firmware | X | X | X | |
Operating System | X | X | X | |
Operating System Attributes (e.g., version, service pack, level, edition, etc.) | X | X | X | |
Installed Software Name | X | X | X | X |
Installed Software Attributes (e.g., version, patch level, install path, etc.) | X | X | X | X |
Open Ports/Services | X | X | X | |
Operating System Optional Component Inventory | X | X | X | |
Location | X | X | ||
Purpose | X | X | ||
Criticality | X | X | ||
File System Attributes (e.g., versions, size, write date, modified date, checksum, etc.) | X | X | ||
Shared Libraries | X | X | ||
Other Software Configuration Information | X | X | ||
External Vulnerability Description Data | ||||
Ingest Date | X | X | ||
Date of Release | X | X | ||
Version | X | X | ||
External Vulnerability ID | X | X | X | |
Severity Score | X | |||
Assessment Results | ||||
Date of Assessment | X | X | ||
Date of Collection | X | X | X | |
Endpoint Identification and/or Locally Assigned ID | X | X | X | |
Vulnerable Software Product(s) | X | X | X | X |
Endpoint Vulnerability Status | X | X | ||
Vulnerability Description | X | X | ||
Vulnerability Remediation | X | X |
Table 1: Vulnerability Assessment Attributes
Christopher Coffin
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730 USA
Email: ccoffin@…
Brant Cheikes
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730 USA
Email: bcheikes@…
Charles Schmidt
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730 USA
Email: cmschmidt@…
Daniel Haynes
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730 USA
Email: dhaynes@…
Jessica Fitzgerald-McKay
Department of Defense
9800 Savage Road
Ft. Meade, Maryland USA
Email: jmfitz2@…
David Waltermire
National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, Maryland 20877 USA
Email: david.waltermire@…
The content of this page was last updated on 2017-05-22. It was migrated from the old Trac wiki on 2023-01-30.