SACM C. Coffin
Internet-Draft B. Cheikes
Intended status: Informational C. Schmidt
Expires: April 20, 2016 D. Haynes
The MITRE Corporation
J. Fitzgerald-McKay
Department of Defense
D. Waltermire
National Institute of Standards and Technology
October 18, 2015
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.
Coffin, et al. Expires April 20, 2016 [Page 1]
Internet-Draft SACM Vuln Scenario October 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Endpoint Identification and Initial (Pre-Assessment) Data
Collection . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Identification . . . . . . . . . . . . . . . . . . . . . 5
3.2. Processing Artifacts . . . . . . . . . . . . . . . . . . 6
3.3. Endpoint Data Collection . . . . . . . . . . . . . . . . 6
4. Vulnerability Reports . . . . . . . . . . . . . . . . . . . . 8
5. Endpoint Applicability and Assessment . . . . . . . . . . . . 9
5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Secondary Assessment . . . . . . . . . . . . . . . . . . 9
6. Assessment Reports . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Continuous Vulnerability Assessment . . . . . . . . 12
Appendix B. Priority . . . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Data Attribute Table and Definitions . . . . . . . . 14
C.1. Table . . . . . . . . . . . . . . . . . . . . . . . . . . 14
C.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix D. Alignment with Other Existing Works . . . . . . . . 18
D.1. Critical Security Controls . . . . . . . . . . . . . . . 18
D.1.1. Continuous Vulnerability Assessment . . . . . . . . . 18
D.1.2. Hardware and Software Inventories . . . . . . . . . . 19
Appendix E. SACM Usage Scenarios . . . . . . . . . . . . . . . . 20
Appendix F. SACM Requirements and Charter - Future Work . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Coffin, et al. Expires April 20, 2016 [Page 2]
Internet-Draft SACM Vuln Scenario October 2015
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.
o 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.
Coffin, et al. Expires April 20, 2016 [Page 3]
Internet-Draft SACM Vuln Scenario October 2015
* Does not discuss how the enterprise assesses the authenticity
of the report.
* Does not discuss parsing of the report into a usable format.
o 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.
o 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.
o 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.
o 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.
Coffin, et al. Expires April 20, 2016 [Page 4]
Internet-Draft SACM Vuln Scenario October 2015
* Does not specify how prioritization impacts assessment
behaviors.
o The document assumes that the enterprise has a mechanism for long-
term storage of vulnerability reports and endpoint assessment
results.
o 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
Coffin, et al. Expires April 20, 2016 [Page 5]
Internet-Draft SACM Vuln Scenario October 2015
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:
o Endpoint type - e.g., standard computer, printer, router, mobile
device, tablet, etc.
o Hardware version/firmware
o Operating system - Windows, Linux, OSX, Android
o Operating system attributes - e.g., version, patch level, service
pack level, internationalized or localized version, etc.
o 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.
Coffin, et al. Expires April 20, 2016 [Page 6]
Internet-Draft SACM Vuln Scenario October 2015
o Open ports/running services
o 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:
o Location - physical location, department, room, etc.
o Role - The function that the endpoint serves within the enterprise
(end user system, database server, public web server, etc.)
o 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.
Coffin, et al. Expires April 20, 2016 [Page 7]
Internet-Draft SACM Vuln Scenario October 2015
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:
o Ingest Date - the date that the report was received by the
enterprise.
o 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.
o Report Version - the version or iteration of the report according
to the report author, if applicable.
o 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.).
o 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.
Coffin, et al. Expires April 20, 2016 [Page 8]
Internet-Draft SACM Vuln Scenario October 2015
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.
Coffin, et al. Expires April 20, 2016 [Page 9]
Internet-Draft SACM Vuln Scenario October 2015
The following data types and attributes are examples of what might be
required in the case of a secondary and targeted assessment:
o 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.
o 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.
o 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.
Coffin, et al. Expires April 20, 2016 [Page 10]
Internet-Draft SACM Vuln Scenario October 2015
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.
o 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.
o Data collection/attribute age - The age of the data used in the
assessment to make the endpoint status determination.
o Endpoint ID - The endpoint itself must be identified for tracking
results over time.
o Vulnerability report ID - Allows linkage to the correct
vulnerability report. The ID could be internally or externally
defined (or both).
o 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.
o Endpoint vulnerability status - The endpoint status based on the
vulnerability report. Does the vulnerability exist on the
endpoint?
o 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
Coffin, et al. Expires April 20, 2016 [Page 11]
Internet-Draft SACM Vuln Scenario October 2015
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
[charter-ietf-sacm-01]
Security Automation and Continuous Monitoring, "Charter,
Version 1.0", July 2013.
[critical-controls]
Council on CyberSecurity, "Critical Security Controls,
Version 5.1".
[I-D.ietf-sacm-requirements]
Cam-Winget, N. and L. Lorenzin, "Secure Automation and
Continuous Monitoring (SACM) Requirements", draft-ietf-
sacm-requirements-10 (work in progress), October 2015.
[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. 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
Coffin, et al. Expires April 20, 2016 [Page 12]
Internet-Draft SACM Vuln Scenario October 2015
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
Coffin, et al. Expires April 20, 2016 [Page 13]
Internet-Draft SACM Vuln Scenario October 2015
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:
o Enterprise-defined role of the device, criticality of the device,
exposure of the device, etc.
o 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.
+--------------------+--------+------------+------------+-----------+
| | Vuln. | Init. | Assessment | Reporting |
| | Report | Collection | | |
+--------------------+--------+------------+------------+-----------+
| *Endpoint* | | | | |
+--------------------+--------+------------+------------+-----------+
| Collection | | X | X | |
| date/time | | | | |
+--------------------+--------+------------+------------+-----------+
| Endpoint type | | X | X | |
+--------------------+--------+------------+------------+-----------+
| Hardware | X | X | X | |
| version/firmware | | | | |
+--------------------+--------+------------+------------+-----------+
| Operating system | X | X | X | |
+--------------------+--------+------------+------------+-----------+
| Operating system | X | X | X | |
| attributes (e.g., | | | | |
| version, service | | | | |
| pack level, | | | | |
| edition, etc.) | | | | |
+--------------------+--------+------------+------------+-----------+
| Installed software | X | X | X | X |
| name | | | | |
+--------------------+--------+------------+------------+-----------+
| Installed software | X | X | X | X |
| attributes (e.g., | | | | |
| version, patch | | | | |
Coffin, et al. Expires April 20, 2016 [Page 14]
Internet-Draft SACM Vuln Scenario October 2015
| level, install | | | | |
| path, etc.) | | | | |
+--------------------+--------+------------+------------+-----------+
| Open | X | X | X | |
| ports/services | | | | |
+--------------------+--------+------------+------------+-----------+
| Operating system | X | X | X | |
| optional component | | | | |
| inventory | | | | |
+--------------------+--------+------------+------------+-----------+
| Location | | X | | X |
+--------------------+--------+------------+------------+-----------+
| Role | | X | | X |
+--------------------+--------+------------+------------+-----------+
| Criticality | | X | | X |
+--------------------+--------+------------+------------+-----------+
| File system | X | | X | |
| attributes (e.g., | | | | |
| versions, size, | | | | |
| write date, | | | | |
| modified date, | | | | |
| checksum, etc.) | | | | |
+--------------------+--------+------------+------------+-----------+
| Shared libraries | X | | X | |
+--------------------+--------+------------+------------+-----------+
| Other software | X | | X | |
| configuration | | | | |
| information | | | | |
+--------------------+--------+------------+------------+-----------+
| *External | | | | |
| Vulnerability | | | | |
| Report* | | | | |
+--------------------+--------+------------+------------+-----------+
| Ingest Date | X | | X | |
+--------------------+--------+------------+------------+-----------+
| Date of Release | X | | X | |
+--------------------+--------+------------+------------+-----------+
| Report Version | X | | X | |
+--------------------+--------+------------+------------+-----------+
| External Report ID | X | | X | X |
+--------------------+--------+------------+------------+-----------+
| Severity Score | | | | X |
+--------------------+--------+------------+------------+-----------+
| *Assessment | | | | |
| Report* | | | | |
+--------------------+--------+------------+------------+-----------+
| Date of assessment | | | X | X |
+--------------------+--------+------------+------------+-----------+
Coffin, et al. Expires April 20, 2016 [Page 15]
Internet-Draft SACM Vuln Scenario October 2015
| Date of data | | X | X | X |
| collection | | | | |
+--------------------+--------+------------+------------+-----------+
| Endpoint | | X | X | X |
| identification | | | | |
| and/or locally | | | | |
| assigned ID | | | | |
+--------------------+--------+------------+------------+-----------+
| Vulnerable | X | X | X | X |
| software | | | | |
| product(s) | | | | |
+--------------------+--------+------------+------------+-----------+
| Endpoint | | | X | X |
| vulnerability | | | | |
| status | | | | |
+--------------------+--------+------------+------------+-----------+
| Vulnerability | X | | | X |
| description | | | | |
+--------------------+--------+------------+------------+-----------+
Table 1: Vulnerability Assessment Attributes
C.2. Definitions
Endpoint
o Collection date/time - the date and time of data collection
o Endpoint type - the device type of the endpoint (e.g., standard
computer, printer, router, mobile device, tablet, etc.)
o Hardware version/firmware - the hardware or firmware version (if
applicable)
o Operating system - Operating system name
o Operating system attributes - Operating system high-level
attributes (e.g., version, service pack level, edition, etc.).
Would not include configuration details.
o Installed software name - List of all installed software packages
(i.e., software inventory). May or may not include software
installed by the operating system.
o Installed software attributes - Software high-level attributes
(e.g., version, patch level, install path, etc.). Would not
include configuration details.
Coffin, et al. Expires April 20, 2016 [Page 16]
Internet-Draft SACM Vuln Scenario October 2015
o Open ports/services - Listening network ports (TCP and UDP) and
running services
o Operating system optional component inventory - Operating system
specific components and software (when NOT already included in the
general software inventory)
o Location - The physical location of an enterprise endpoint
(department, room, etc.)
o Role - The function that the endpoint serves within the enterprise
(e.g., end user system, database server, public web server, etc.)
o Criticality - An 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?
o File system attributes - Attributes that describe the state of a
file or directory (e.g., versions, size, write date, modified
date, checksum, etc.)
o Shared libraries - libraries that can be used by and installed
with many different software applications. A shared library
vulnerability could affect multiple software applications in the
same way.
o Other software configuration information - operating system or
software application configuration attributes that go beyond that
basic information already captured (Microsoft Windows registry,
text configuration files and their parameters, and the
installation paths.)
External Vulnerability Report
o Ingest Date - the date that the report was received by the
enterprise.
o Date of Release - publication or disclosure date of the
vulnerability report
o Report Version - the version or iteration of the report according
to the report author, if applicable.
o External Report ID - external or third-party IDs assigned to the
report. Could be multiple IDs in some cases (e.g., vendor bug id,
global ID, discoverer's local ID, third-party vulnerability
database ID, etc.).
Coffin, et al. Expires April 20, 2016 [Page 17]
Internet-Draft SACM Vuln Scenario October 2015
o Severity Score - the severity of the report according to the
report author, if applicable.
Assessment Report
o Date of assessment - The date that the assessment was performed
against an endpoint.
o Date of data collection - The age of the data used in the
assessment to make the endpoint status determination.
o Endpoint identification and/or locally assigned ID - The ID
assigned to the enterprise endpoint. Must be assigned for
tracking results over time.
o Vulnerable software product(s) - The vulnerable software products
identified as being installed on the endpoint.
o Endpoint vulnerability status - Overall vulnerability status of
the enterprise endpoint (i.e., Pass or Fail)
o Vulnerability description - A human-consumable description of a
vulnerability. Supports the human user understanding of the
vulnerability assessment report within an application front-end or
user interface.
Appendix D. Alignment with Other Existing Works
D.1. Critical Security Controls
The Council on CyberSecurity's Critical Security Controls
[critical-controls] includes security controls for a number of use
scenarios, some of which are covered in this document. This section
documents the alignment between the Council's controls and the
relevant elements of the scenario.
D.1.1. Continuous Vulnerability Assessment
"CSC 4: Continuous Vulnerability Assessment and Remediation," which
is described by the Council on CyberSecurity 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
Coffin, et al. Expires April 20, 2016 [Page 18]
Internet-Draft SACM Vuln Scenario October 2015
this document is intended to be executed on a continuous basis, and
the priorities of both vulnerability reports 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 reports as described in CSC 4-4.
Both CSC 4-2 and 4-7 are made possible by writing information to a
CMDB 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-10, which deals with vulnerability
priority. Vulnerability priority in this scenario is discussed in
terms of the vulnerability report 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, 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 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 and numbered steps
directly align with the scenario described in this document with the
exception of step 7 (patch response). Steps 1 -6 in CSC 4 describe
the overall process for vulnerability management starting with
obtaining the vulnerability report from the source in Step 1, to
producing an assessment report in step 6.
D.1.2. Hardware and Software Inventories
This scenario is also aligned with, and describes a process for,
collecting and maintaining hardware and software inventories, which
are covered by the Council on CyberSecurity 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
Coffin, et al. Expires April 20, 2016 [Page 19]
Internet-Draft SACM Vuln Scenario October 2015
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 and 2-4 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.
CSC 2-9 describes the use of a software ID tag in XML format. SWID
tags (https://en.wikipedia.org/wiki/ISO/IEC_19770) would also be a
possible implementation for the Endpoint Data Collection section
described in this scenario.
Appendix E. SACM Usage Scenarios
The SACM "Endpoint Security Posture Assessment: Enterprise Use Cases"
document ([RFC7632]) 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.
o Automated Checklist Verification (2.2.2) - "An enterprise operates
a heterogeneous IT environment. They utilize vendor-provided
automatable security configuration checklists for each operating
system and application used within their IT environment. Multiple
checklists are used from different vendors to ensure adequate
coverage of all IT assets." The usage scenario, as defined in the
RFC, is targeted at the checklist level and can be interpreted as
being specific to endpoint configuration. There is mention of
patch assessment and vulnerability mitigation, but the usage
scenario could be expanded upon by including vulnerability
verification. Replacing the idea of a checklist in the SACM usage
scenario with vulnerability would allow the usage scenario to
Coffin, et al. Expires April 20, 2016 [Page 20]
Internet-Draft SACM Vuln Scenario October 2015
align almost exactly with the scenario described in this document.
Instead of collecting automatable security configuration
checklists, the enterprise would collect automatable vulnerability
reports available from the 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 to the 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 in the baseline, updated posture
information is exchanged. When the endpoint detects a posture
change, an alert is generated identifying the specific changes in
posture." This usage scenario would support the concept of
endpoints signaling or alerting the enterprise to changes in the
posture relates to endpoint vulnerabilities in the same way that
it would for configurations. Replacing the idea of a checklist
with a vulnerability report allows the SACM usage scenario and the
scenario described in this document 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 the main 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 the university,
the government, and the provider of the satellite network, as well
as keep current on vulnerability testing." This SACM usage
scenario does describe vulnerability assessment in particular, and
aligns exactly with the scenario described in this document. The
endpoint assets are identified and associated data is published in
a CMDB. Vulnerability reports are collected and saved in a CMDB
as they are released. The reports are queued for later
assessment, then the results and resulting vulnerability reports
are stored after assessment. The only real difference in this
SACM usage scenario is that of the timing 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 F. SACM Requirements 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
Coffin, et al. Expires April 20, 2016 [Page 21]
Internet-Draft SACM Vuln Scenario October 2015
[charter-ietf-sacm-01], and SACM Use Cases ([RFC7632]) documents and
represent work that may be necessary to support the tasks or goals of
SACM going forward.
o The SACM requirements mentions "Result Reporting" with
applications but no detail around what the result data set should
include. In the case of vulnerability assessment reports, context
is important and details beyond just a Pass or Fail result are
needed in order to take action. A good example of this might be
the Priority of the vulnerability itself and how many systems it
affects within the enterprise. With this in mind, it might be
worthwhile to investigate a minimum data set or schema for the
reporting of results. The concern here is with vulnerability
reporting, but this could apply to other enterprise processes as
well.
o The "Human-assigned endpoint attributes" mentioned previously in
this scenario are touched on in the SACM use cases, but the topic
could probably be explored in much more depth. Enterprise policy
and behaviors could be greatly influenced by endpoint attributes
such as locations, functions, and criticality. When and how these
data attributes are collected, as well as what the minimum or
common set might look like, would be good topics for future
related SACM work.
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
Coffin, et al. Expires April 20, 2016 [Page 22]
Internet-Draft SACM Vuln Scenario October 2015
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
Coffin, et al. Expires April 20, 2016 [Page 23]