SACM Vulnerability Assessment Scenario
draft-coffin-sacm-vuln-scenario-00

Abstract

This document provides a core narrative that walks through an automated enterprise vulnerability assessment scenario. It is aligned with the SACM "Endpoint Security Posture Assessment: Enterprise Use Cases" [RFC7632]. It begins with an enterprise ingesting a vulnerability report and ends at the point of identifying affected endpoints. Processes that specifically overlap between this scenario and RFC 7632 will be noted where applicable. Specifically, the relationship between this document and the RFC 7632 use case building block capabilities and the usage scenarios will be covered.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 20, 2016.

Copyright Notice

Copyright (c) 2015 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
• 2. Assumptions
• 3. Endpoint Identification and Initial (Pre-Assessment) Data Collection
• 3.1. Identification
• 3.2. Processing Artifacts
• 3.3. Endpoint Data Collection
• 4. Vulnerability Reports
• 5. Endpoint Applicability and Assessment
• 5.1. Applicability
• 5.2. Secondary Assessment
• 6. Assessment Reports
• 7. IANA Considerations
• 8. Security Considerations
• 9. Informative References
• Appendix A. Continuous Vulnerability Assessment
• Appendix B. Priority
• Appendix C. Data Attribute Table and Definitions
• C.1. Table
• C.2. Definitions
• Appendix D. Alignment with Other Existing Works
• D.1. Critical Security Controls
• D.1.1. Continuous Vulnerability Assessment
• D.1.2. Hardware and Software Inventories
• Appendix E. SACM Usage Scenarios
• Appendix F. SACM Requirements and Charter - Future Work
• Authors' Addresses

1. Scope

The purpose of this document is to describe a detailed scenario for vulnerability assessment, and identify aspects of this scenario that could be used in the development of an information model. This includes classes of data, major roles, and a high-level description of role interactions. Additionally, this scenario can also inform engineering work on protocol and data model development. The focus of the document is entirely intra-organizational and covers enterprise handling of vulnerability reports. The document does not attempt to cover the security disclosure itself and any prior activities of the security researcher or discloser, nor does it attempt to cover the specific activities of the vendor whose software is the focus of a vulnerability report.

For the purposes of this document, the term "vulnerability report" is intended to mean: "A publication intended to alert enterprise IT resources to the existence of a flaw or flaws in software, hardware, and/or firmware, which could potentially have an impact on enterprise functionality and/or security." For the purpose of this scenario, such a report also includes information that can be used to determine (to some level of accuracy, although possibly not conclusively) whether or not the flaw is present within an enterprise, when compared to information about the state of the enterprise's endpoints.

This document makes no attempt to provide a definition of a normalized data format for vulnerability reports. Also, it does not attempt to define procedures by which a vulnerability discoverer coordinates the release of a report with other parties.

2. Assumptions

A number of assumptions must be stated in order to further clarify the position and scope of this document.

• The document begins with the assumption that the enterprise has received a vulnerability report, and that the report data has already been processed into a format that the enterprise's security software tools can understand and use. In particular, this document:
  • Does not discuss how the enterprise identifies a potentially relevant vulnerability report.
  • Does not discuss how the enterprise collects that report.
  • Does not discuss how the enterprise assesses the authenticity of the report.
  • Does not discuss parsing of the report into a usable format.

• The document assumes that the enterprise has a means of identifying enterprise endpoints. This could mean identifying endpoints as they join the network, actively scanning for connected endpoints, passive scanning of network traffic to identify connected endpoints, or some other method of accounting for the presence of all endpoints in the enterprise.
• The document assumes that the enterprise has a means of extracting relevant infomation about enterprise endpoints. Moreover, this extracted information is expressed in a format that is compatible with the information extracted from the vulnerability report. The document:
  • Does not specify how relevant information is identified.
  • Does not specify the mechanics of how relevant information is extracted from the data sources (such as the endpoint itself).
  • Does not specify how extracted endpoint information and vulnerability alert information are normalized to be compatible.

  Note that having a means of extracting relevant information about enterprise endpoints is within the scope of the SACM Endpoint Security Posture Assessment process. In the case of this document, this sub-process is assumed to be existent.

• The document assumes that all information described in the steps below is available in the vulnerability report and serves as the basis of this assessment. Likewise, the document assumes that the enterprise can provide all relevant information about any endpoint needed to perform the described analysis. The authors recognize that this will not always be the case, but these assumptions are taken in order to show the breadth of data utilization in this scenario. Less complete information may require variations to the described steps.
• The document assumes that the enterprise has a policy by which assessment of endpoints based on vulnerability reports are prioritized. The document:
  • Does not specify how prioritization occurs.
  • Does not specify how prioritization impacts assessment behaviors.

• The document assumes that the enterprise has a mechanism for long-term storage of vulnerability reports and endpoint assessment results.
• This document assumes that the enterprise has a procedure for reassessment of endpoints at some point after initial assessment. The document:
  • Does not specify how a reassessment would impact individual assessment behaviors. (I.e., it is agnostic as to whether the assessment procedure is the same regardless of whether this is the first or a subsequent assessment for a given vulnerability report.)
  • Does not provide guidance or specifics on reassessment intervals.

3. Endpoint Identification and Initial (Pre-Assessment) Data Collection

The first step in this scenario involves identifying endpoints and collecting basic system information from them. This occurs prior to the receipt of any specific vulnerability report and is part of the regular, ongoing monitoring of endpoints within an enterprise. This process is not meant to report on, or gather data for any specific vulnerabilities. The information gathered during this step could be applied in many enterprise automation efforts. Specifically, in addition to vulnerability management, it could be used by configuration and license management tasks. All of the information collected during this step is stored in a central location such as a CMDB.

This activity involves the following sub-steps:

3.1. Identification

Prior to any other steps, the identification of endpoints must occur. This involves locating (at least virtually) and distinguishing between endpoints on the network in a way that allows each endpoint to be recognized in future interactions and selected for specific treatment. This not only allows later steps to determine the scope of what systems need to be assessed, but also allows for the unique identification of each endpoint. Unique endpoint IDs are used to allow for systems to be tracked over time and also allow for proper counts of assets during inventories and other similar collections. Endpoint identity can be established by collecting certain system properties that allow persistent tracking of the endpoints. Examples include, but are not limited to, IP address, MAC address, FQDNs, pre-provisioned identifiers such as GUIDs or copies of serial numbers, certificates, hardware identity values, or similar.

This sub-step aligns with the Endpoint Discovery, Endpoint Characterization (automated collection data only), 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.

3.2. Processing Artifacts

Processing artifacts, such as the date and time the collection was performed, should be collected and stored. This timestamp is extremely important when performing later assessments, as it is needed for data freshness computations. The organization may develop rules for stale data and when a new data collection is required. This metadata is also helpful in correlating information across multiple data collections. This includes correlating both pre-assessment data and secondary assessment data (sections 4.3 Endpoint Data Collection and 6.2 Secondary Assessment).

3.3. Endpoint Data Collection

The enterprise should perform ongoing collection of basic endpoint information such as operating system and version information, and an installed software inventory. This information is collected for general system monitoring as well as its potential use in activities such as vulnerability assessment.

Some basic information to collect from endpoints in this pre-vulnerability report and pre-assessment process could include:

• Endpoint type - e.g., standard computer, printer, router, mobile device, tablet, etc.
• Hardware version/firmware
• Operating system - Windows, Linux, OSX, Android
• Operating system attributes - e.g., version, patch level, service pack level, internationalized or localized version, etc.
• Installed software inventory - important for later assessments. Would include the software names and versions (and possibly other high-level attributes). Could be used to quickly determine endpoint applicability in later vulnerability reports.
• Open ports/running services
• Operating system optional component inventory - some OS' have optional components that can be installed which may not show up as separate pieces of software (e.g., web and ftp servers, demo web pages, shared libraries, etc.). Note that this could also occur within third-party applications as well.

In addition to the above, the possibility should be left open for enterprises to define their own custom queries to gather enterprise-specific system attributes that are deemed of interest to regular enterprise operations.

Human-assigned endpoint attributes are yet another type of data item that could be collected here. This would include any attributes that cannot be collected programmatically. The attributes could be manually entered into a CMDB by a human after the initial data collection occurs. The attributes could help with system categorization and may have influence on later prioritizations. The human-assigned attributes could include:

• Location - physical location, department, room, etc.
• Role - The function that the endpoint serves within the enterprise (end user system, database server, public web server, etc.)
• Criticality - enterprise defined rating (possibly a score) that helps determine the criticality of the endpoint. If this endpoint is attacked or lost, what is the impact to the overall enterprise?

This sub-step aligns with the Data Publication building block capability because this section involves storage of endpoint attributes within an enterprise CMDB. This sub-step also aligns with the Endpoint Characterization (both manual and automated) 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.

4. Vulnerability Reports

The next step in the Vulnerability Assessment scenario begins after a vulnerability report has been received and processed into a form that can be used in the assessment of the enterprise. As a part of the enterprise process for managing vulnerability reports, the enterprise should store all received and processed vulnerability reports in a CMDB. These stored vulnerability reports can be used and compared with later vulnerability reports for the purpose of duplicate detection and in some cases guidance on how to handle similar issues.

All vulnerability reports should be assigned an internal tracking ID by the enterprise as a first step. Incoming vulnerability reports might not have a global identifier when they are received, and might never have one assigned.

High-level vulnerability report metadata to store would include:

• Ingest Date - the date that the report was received by the enterprise.
• Date of Report Release (i.e., publication or disclosure date) - Some older reports may be ingested long after publication. This can be useful when reviewing historical enterprise information to (potentially) identify the period when a particular endpoint was first vulnerable. Sometimes this information will help to differentiate between similar vulnerability reports.
• Report Version - the version or iteration of the report according to the report author, if applicable.
• External Report ID(s) (if applicable) - any external or third-party IDs assigned to the report should be tracked. There could be multiple IDs in some cases (e.g., vendor bug id, global ID, discoverer's local ID, third-party vulnerability database ID, etc.).
• Severity Score (if available) - these may be useful for later mitigation prioritization.

In addition to the described metadata, all vulnerability reports would be stored with the information extracted from them that is to be used in the applicability and assessment process.

This step aligns with the Data Publication and Data Retrieval building block capabilities because this section details storage of vulnerability reports within an enterprise CMDB and later retrieval of the same.

5. Endpoint Applicability and Assessment

When a new vulnerability report is received by the enterprise, applicable enterprise endpoints must be identified and assessed. Endpoints are first examined using pre-assessment data. If this is not sufficient to determine endpoint applicability, a secondary data collection for additional data and attributes may be performed to determine status with regard to the vulnerability report.

5.1. Applicability

The applicability of an endpoint and its vulnerability status can, in many cases, be determined entirely by the existence of a particular version of installed software on the endpoint. This data would already have been collected in the pre-assessment data collection. If the applicability and vulnerability status of an endpoint can be determined entirely by the pre-collected data attribute set, no further data collection is required.

Other cases may require specific data (i.e., file system attributes, specific configuration parameters, etc.) to be collected for the assessment of a particular vulnerability report. In these cases, a secondary, targeted vulnerability assessment is required. Administrators may want to evaluate applicability to the vulnerability report iteratively. Specifically, the process would compare against pre-collected data first (easy to do and the data is stored in a CMDB), and then if needed, query endpoints that are not already excluded from applicability for additional required data. (I.e., A "fast-fail" model). To do this, the criteria for determining applicability must be separable, so that some conclusions can be drawn based on the possession of partial data.

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.

5.2. Secondary Assessment

If the applicability and vulnerability status of an endpoint cannot be determined by the pre-assessment data collection, a secondary and targeted assessment of the endpoint will be required. A secondary assessment may also be required in the case that data on-hand (either from pre-assessment or from prior secondary assessments) is stale or out-of-date.

The following data types and attributes are examples of what might be required in the case of a secondary and targeted assessment:

• Specific files and attributes - i.e., file name, versions, size, write date, modified date, checksum, etc. Some vulnerabilities may only be distinguishable through the presence or absence of specific files.
• Shared libraries - Some vulnerabilities will affect many products across multiple vendors. In these cases the vulnerability may apply to a shared library. Under these circumstances, product versions may be less helpful than looking for the presence of one or more specific files and their attributes.
• Other software configuration information (if applicable) - such as Microsoft Windows registry queries, text configuration files and their parameters, and the installation paths. Sometimes vulnerabilities only affect certain software configurations and in some cases these are not the default configurations. Certain configuration attributes can be used to determine the current configuration state.

Note that the secondary assessment described here does not need to be a pull assessment that is initiated by the server. The secondary assessment could also be part of a push to the server when the endpoint detects a change to a vulnerability assessment baseline.

This sub-step aligns with the Data Publication building block capability because this section details storage of endpoint attributes within an enterprise CMDB. The sub-step also aligns with the Collection Guidance Acquisition building block capability since the vulnerability report (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.

6. Assessment Reports

An assessment report presents the results of an assessment, along with sufficient context so a human or machine can make the appropriate response. This context might include a description of the issue provided by the vulnerability report, the endpoint attributes that indicate applicability, or other information needed to respond to the report determination. Data in this step is stored for auditing and forensic purposes.

The following details are important to track in an assessment report. Note that information may be "included" by providing pointers to other records stored in a CMDB.

• Date of assessment - The date that the assessment was performed. To understand when the data was compared against the vulnerability report and what conclusions were drawn.
• Data collection/attribute age - The age of the data used in the assessment to make the endpoint status determination.
• Endpoint ID - The endpoint itself must be identified for tracking results over time.
• Vulnerability report ID - Allows linkage to the correct vulnerability report. The ID could be internally or externally defined (or both).
• Vulnerable software product(s) - Identifies the software products on the endpoint that resulted in the endpoint being declared applicable. Since some vulnerability reports identify vulnerabilities in multiple products, this will help identify the specific product (or products) found to be vulnerable in the endpoint assessment.
• Endpoint vulnerability status - The endpoint status based on the vulnerability report. Does the vulnerability exist on the endpoint?
• Vulnerability description - Not needed for automated assessment but probably should be included for human review. The reason for inclusion is to support the human user understanding of the vulnerability assessment report within the application front-end or interface.

This step aligns with the Data Publication and Data Retrieval building block capabilities because this section details storage of vulnerability assessment reports within an enterprise CMDB and later retrieval of the same.

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] . It is for informational purposes only. As a result, there are no specific security considerations.

9. Informative References

Appendix A. Continuous Vulnerability Assessment

It is not sufficient to perform a single assessment when a vulnerability report 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 such an assessment completes. For example, new endpoints can be introduced to the environment which have old software or are not up-to-date with patches. This is especially true of BYOD environments. Another example is where unauthorized or obsolete software is installed on an existing endpoint by enterprise users after a vulnerability report and initial assessment has taken place. Moreover, enterprises might not wish to, or be able to, assess all vulnerability reports 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 report that led to this assessment. The assessment could immediately follow ingest of the report, could be delayed, or the assessment might represent a reassessment of some report against which endpoints had previously been assessed. Moreover, the scenario incorporates long-term storage of collected data, vulnerability reports, and assessment results in order to facilitate meaningful ongoing reassessment.

Appendix B. Priority

Priorities associated with both the reports 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 report scenario as they separable issues with their own sets of requirements.

Priority in regard to vulnerability reports, can be viewed in a couple of different ways within an enterprise. The assessment prioritization involves prioritization of the vulnerability report assessment process. This determines which vulnerability reports are assessed, and in what order they are 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 reports 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 report.

Examples of data attributes specific to priority of assessments and/or remedies include (but not limited to) the following:

• Enterprise-defined role of the device, criticality of the device, exposure of the device, etc.
• Severity attributes - A rating or score that attempts to provide the level of severity or criticality associated with a given vulnerability.

Appendix C. Data Attribute Table and Definitions

C.1. Table

The following table maps all major data attributes against each major process where they are used.