SACM Vulnerability Assessment Scenario
draft-ietf-sacm-vuln-scenario-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Chris Coffin , Brant Cheikes , Charles Schmidt , Daniel Haynes , Jessica Fitzgerald-McKay , David Waltermire | ||
| Last updated | 2016-06-09 (Latest revision 2016-06-08) | ||
| Replaces | draft-coffin-sacm-vuln-scenario | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-sacm-vuln-scenario-00
SACM C. Coffin
Internet-Draft B. Cheikes
Intended status: Informational C. Schmidt
Expires: December 10, 2016 D. Haynes
The MITRE Corporation
J. Fitzgerald-McKay
Department of Defense
D. Waltermire
National Institute of Standards and Technology
June 8, 2016
SACM Vulnerability Assessment Scenario
draft-ietf-sacm-vuln-scenario-00
Abstract
This document describes an automated enterprise vulnerability
assessment scenario aligned with the SACM Use Cases. The scenario
assumes the existence of an endpoint management capability and begins
with an enterprise ingesting vulnerability description information.
Endpoints are assessed against the vulnerability description
information based a combination of examining known endpoint
characterization information and collected endpoint information.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Coffin, et al. Expires December 10, 2016 [Page 1]
Internet-Draft SACM Vuln Scenario June 2016
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Vulnerability Assessment Pre-requisites . . . . . . . . . . . 4
4.1. Endpoint Management Capability . . . . . . . . . . . . . 4
4.2. Vulnerability Description Information . . . . . . . . . . 5
5. Endpoint Vulnerability Assessment Capability . . . . . . . . 5
6. Vulnerability Assessment Results . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
A.1. Changes Since Adopted as a WG I-D -00 . . . . . . . . . . 7
A.2. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 8
Appendix B. Continuous Vulnerability Assessment . . . . . . . . 10
Appendix C. Priority . . . . . . . . . . . . . . . . . . . . . . 10
Appendix D. Data Attribute Table . . . . . . . . . . . . . . . . 11
D.1. Table . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix E. Alignment with Other Existing Works . . . . . . . . 14
E.1. Critical Security Controls . . . . . . . . . . . . . . . 14
E.1.1. Continuous Vulnerability Assessment . . . . . . . . . 14
E.1.2. Hardware and Software Inventories . . . . . . . . . . 16
Appendix F. SACM Usage Scenarios . . . . . . . . . . . . . . . . 16
Appendix G. SACM Requirements and Charter - Future Work . . . . 18
Appendix H. SACM Use Case Alignment . . . . . . . . . . . . . . 18
H.1. Endpoint Identification . . . . . . . . . . . . . . . . . 18
H.2. Endpoint Data Collection . . . . . . . . . . . . . . . . 19
H.3. Vulnerability Description Information . . . . . . . . . . 19
H.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 19
H.5. Secondary Assessment . . . . . . . . . . . . . . . . . . 19
H.6. Assessment Results . . . . . . . . . . . . . . . . . . . 20
Appendix I. Implementation Examples . . . . . . . . . . . . . . 20
I.1. Endpoint Data Collection . . . . . . . . . . . . . . . . 20
I.2. Vulnerability Description Information . . . . . . . . . . 20
I.3. Secondary Assessment . . . . . . . . . . . . . . . . . . 21
I.4. Assessment Results . . . . . . . . . . . . . . . . . . . 21
Coffin, et al. Expires December 10, 2016 [Page 2]
Internet-Draft SACM Vuln Scenario June 2016
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Scope
This document describes a detailed, enterprise-specific vulnerability
assessment scenario from which information model elements can be
discovered. Such elements may include classes of data, major roles,
and role interactions. This scenario also informs protocol and data
model development in support of vulnerability assessment, as part of
overall posture assessment. Vulnerability discovery, disclosure, and
publication is out of scope.
2. Terminology
Vulnerability description information: Information pertaining to the
existence of a flaw or flaws in software, hardware, and/or
firmware, which could potentially have an adverse impact on
enterprise IT functionality and/or security. Vulnerability
description information should contain enough information to
support vulnerability detection.
Vulnerability detection data: A type of guidance extracted from
vulnerability description information that describes the
specific mechanisms of vulnerability detection that is used by
an enterprise's vulnerability management capability to
determine if a vulnerability is present on an endpoint.
Endpoint management capability: An enterprise IT capability managing
endpoint identity, endpoint information, and associated
metadata on an ongoing basis.
Vulnerability management capability: An enterprise IT capability
managing endpoint vulnerabilities and associated metadata on an
ongoing basis by ingesting vulnerability description
information and vulnerability detection data, and performing a
vulnerability assessment.
Vulnerability assessment: The process of determining whether a set
of endpoints is vulnerable according to the information
contained in the vulnerability description information.
Supplemental collection: The task of collecting specific endpoint
information from the target endpoint, that is not available
from the endpoint management capability, in order to make a
determination about that endpoint (vulnerability status,
identification, etc.).
Coffin, et al. Expires December 10, 2016 [Page 3]
Internet-Draft SACM Vuln Scenario June 2016
3. Assumptions
A number of assumptions must be stated in order to further clarify
the position and scope of this document.
The document assumes that:
o The enterprise has received vulnerability description information,
and that the information has already been processed into
vulnerability detection data that the enterprise's security
software tools can understand and use.
o The enterprise has a means of identifying enterprise endpoints
although assertions about some details of this capability are
made.
o The enterprise has a means of extracting relevant information
about enterprise endpoints in a form that is compatible with the
vulnerability description data.
o All information described in this scenario is available in the
vulnerability description data and serves as the basis of this
assessment.
o The enterprise can provide all relevant information about any
endpoint needed to perform the described assessment.
o The enterprise has a mechanism for long-term storage of
vulnerability description information, vulnerability detection
data, and vulnerability assessment results.
o The enterprise has a procedure for reassessment of endpoints at
some point after initial assessment.
4. Vulnerability Assessment Pre-requisites
In order to successfully support the vulnerability assessment
scenario, an enterprise needs to have the following capabilities
deployed on their network and information readily available.
4.1. Endpoint Management Capability
An endpoint management capability is assumed to be in place within
the enterprise, and is expected to collect a minimum set of
attributes from the endpoints under management, and to establish an
endpoint's identity within the scope of that domain. Endpoint
identity can be established by collecting certain attributes (as part
of the minimum set of attributes) that allow for unique and
Coffin, et al. Expires December 10, 2016 [Page 4]
Internet-Draft SACM Vuln Scenario June 2016
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. All
of the information collected by the endpoint management capability is
stored, with appropriate metadata (i.e. timestamp), in a central
location. The endpoint management capability is expected to be
performed on an ongoing basis, resulting in routine, or even event-
driven, collection of basic endpoint information.
See "Data Attribute Tables and Definitions" for information-specific
details.
4.2. Vulnerability Description Information
Vulnerability description information is expected to be periodically
received by the enterprise. Upon receipt, the vulnerability
description information is expected to be assigned a unique tracking
identifier, stored in a repository (with appropriate metadata) in raw
form, and transformed into a machine-readable vulnerability detection
data with unique tracking identifier understood by the components
described by this scenario. This transformed form can be referred to
as the vulnerability detection data. At some point, receipt and
processing of vulnerability description data is expected to trigger
the vulnerability assessment.
See "Data Attribute Tables and Definitions" for information-specific
details.
5. Endpoint Vulnerability Assessment Capability
When new vulnerability description information is received by the
enterprise, affected endpoints are identified and assessed. The
vulnerability is said to apply to an endpoint if the endpoint
satisfies the conditions expressed in the vulnerability detection
data.
A vulnerability assessment (i.e. vulnerability detection) is
performed in two steps:
o Endpoint information collected by the endpoint management
capability is examined.
o If the data possessed by the endpoint management capability is
insufficient, then necessary data is collected from the target
endpoint.
Coffin, et al. Expires December 10, 2016 [Page 5]
Internet-Draft SACM Vuln Scenario June 2016
Vulnerability detection relies on the examination of different
endpoint information depending on the nature of a specific
vulnerability. Common endpoint information used to detect a
vulnerability includes:
o A specific software version is installed on the endpoint
o File system attributes
o Specific state attributes
In many cases, the endpoint information needed to determine an
endpoint's vulnerability status will have been previously collected
by the Endpoint Management Capability and available in a Repository.
However, in other cases, the necessary endpoint information will not
be readily available in a Repository and a supplemental collection
will be necessary. Of course, an implementation of an endpoint
management capability may prefer to enable operators to perform
supplemental collection under certain circumstances, even when
sufficient information can be provided by the endpoint management
capability (e.g. there may be freshness requirements for
information).
Supplemental collection of endpoint information for the purpose of
vulnerability assessment does not necessarily need to be a pull by
the vulnerability assessment capability. Under certain deployment
scenarios, once the necessary detection information is known, the
information beyond that which is available in the endpoint management
capability can be pushed to the vulnerability assessment capability
by the endpoint whenever that information changes.
See "Data Attribute Tables and Definitions" for information-specific
details.
6. Vulnerability Assessment Results
Vulnerability assessment results present evaluation results along
with sufficient context, so that appropriate action can be taken.
Vulnerability assessment results are ideally stored for later use.
See "Data Attribute Tables and Definitions" for information-specific
details.
7. IANA Considerations
This memo includes no request to IANA.
Coffin, et al. Expires December 10, 2016 [Page 6]
Internet-Draft SACM Vuln Scenario June 2016
8. Security Considerations
This document provides a core narrative that walks through an
automated enterprise vulnerability assessment scenario and is aligned
with SACM "Endpoint Security Posture Assessment: Enterprise Use
Cases" [RFC7632]. As a result, the security considerations for
[RFC7632] apply to this document. Furthermore, the vulnerability
description information may provide attackers with useful information
such as what software an enterprise is running on their endpoints.
As a result, organizations should properly protect the vulnerability
description data it ingests.
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".
[draft-hansbury-sacm-oval-info-model-mapping-01]
Security Automation and Continuous Monitoring, "OVAL and
the SACM Information Model", November 2015.
[I-D.ietf-sacm-requirements]
Cam-Winget, N. and L. Lorenzin, "Security Automation and
Continuous Monitoring (SACM) Requirements", draft-ietf-
sacm-requirements-13 (work in progress), March 2016.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632,
DOI 10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>.
Appendix A. Change Log
A.1. Changes Since Adopted as a WG I-D -00
Made various organizational and editorial changes as proposed by Adam
Montville. GitHub issue #4 (https://github.com/sacmwg/vulnerability-
scenario/issues/4).
Removed the TODO from the Security Considerations section
(https://github.com/sacmwg/vulnerability-scenario/issues/8).
Coffin, et al. Expires December 10, 2016 [Page 7]
Internet-Draft SACM Vuln Scenario June 2016
Clarified the definition of "vulnerability detection data" to explain
how it was guidance and provided instructions for security tools on
how to carry out a vulnerability assessment. GitHub issue #13
(https://github.com/sacmwg/vulnerability-scenario/issues/13).
Changed "targeted collection" to "supplemental collection". GitHub
issue #14 (https://github.com/sacmwg/vulnerability-scenario/
issues/14).
Clarified that the ability for an enterprise to convert vulnerability
description information and process it into a format usable by
security tools is the same as the converting vulnerability
description information into vulnerability detection data. GitHub
issue #15 (https://github.com/sacmwg/vulnerability-scenario/
issues/15).
Determine if we need to remove references to the long-term storage of
data in repositories. GitHub issue #16 (https://github.com/sacmwg/
vulnerability-scenario/issues/16).
Moved the information needs captured in Appendix D.2 into the
Information Model. GitHub issue #17 (https://github.com/sacmwg/
vulnerability-scenario/issues/17).
A.2. Changes in Revision draft-coffin-sacm-vuln-scenario-01
Clarification of the vulnerability description data IDs in sections 4
and 6.
Added "vulnerability remediation" to the Assessment Results and Data
Attribute Table and Definitions sections.
Added Implementation Examples to Endpoint Identification and Initial
(Pre-Assessment) Data Collection, Vulnerability Description Data,
Endpoint Applicability and Assessment, and Assessment Results
sections.
Added an example to vulnerability description data in the scope
section.
Added a sentence to clarify vulnerability description data definition
in the scope section.
Added data repository example for long-term storage scope item.
Added sentence to direct reader to examples of basic system
information in endpoint identification section.
Coffin, et al. Expires December 10, 2016 [Page 8]
Internet-Draft SACM Vuln Scenario June 2016
Split the examples of information to collect in the pre-assessment
collection section into a basic and advanced list.
Added examples of data stored in the repository in the Assessment
Results section.
Added sentence for human-assigned attributes in the Future Work
section.
Replaced "vulnerability report" to "vulnerability description data"
because the term report was causing confusion. Similarly, replaced
"assessment report" with "assessment results".
Replaced "Configuration Management Database (CMDB)" with "Repository"
which is SACM's term for a data store.
Replaced endpoint "Role" with "Purpose" because "Role" is already
defined in SACM. Also, removed "Function" because it too is already
defined in SACM.
Clarified that the document does not try to define a normalized data
format for vulnerability description data although it does not
preclude the creation of such a format.
Included additional examples of software configuration information.
Clarified the section around endpoint identification to make it clear
designation attributes used to correlate and identify endpoints are
both persistent and unique. Furthermore, text was added to explain
how the persistency of attributes may vary. This was based on
knowledge gained from the Endpoint ID Design Team.
Updated the Security Considerations section to mention those
described in [RFC7632].
Removed text around Bring Your Own Device (BYOD). While important,
BYOD just adds complexity to this initial draft. BYOD should be
addressed in a later revision.
Merged the list of "basic endpoint information" and the list of
"human-assigned endpoint attributes" as both represent data we want
to collect about an endpoint. Whether or not that data is natively
available on the endpoint for collection or assigned by a human,
computed, or derived from other data which may or may not be
available on the endpoint for collection seems arbitrary. With this
scenario, we primarily care about expressing information needs rather
than how the information is collected or from where.
Coffin, et al. Expires December 10, 2016 [Page 9]
Internet-Draft SACM Vuln Scenario June 2016
Appendix B. Continuous Vulnerability Assessment
It is not sufficient to perform a single assessment when
vulnerability description information is published without any
further checking. Doing so does not 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.
Appendix C. Priority
Priorities associated with the vulnerability description information,
assessment results, and any remedy is important, but is treated as a
separate challenge and, as such, has not been integrated into the
description of this scenario. Nevertheless, it is important to point
out and describe the use of priorities in the overall vulnerability
assessment scenario as a separate issue with its own sets of
requirements.
Priority in regard to vulnerability description information, can be
viewed in a couple of different ways within an enterprise. 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
Coffin, et al. Expires December 10, 2016 [Page 10]
Internet-Draft SACM Vuln Scenario June 2016
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:
o Enterprise - defined purpose 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.
o Cyber threat intelligence - information such as tactics,
techniques, and procedures of threat actors, indicators of
compromise, incidents, courses of action, etc. that help the
enterprise understand relevant threats and how to detect,
mitigate, or respond to them.
Appendix D. Data Attribute Table
D.1. Table
The following table maps all major data attributes against each major
process where they are used.
+--------------+------------+--------------+-------------+----------+
| | vulnerabil | Endpoint Ide | Endpoint Ap | Assessme |
| | ity descri | ntification | plicability | nt |
| | ption data | and Initial | and | Results |
Coffin, et al. Expires December 10, 2016 [Page 11]
Internet-Draft SACM Vuln Scenario June 2016
| | | (Pre- | Assessment | |
| | | Assessment) | | |
| | | Data | | |
| | | Collection | | |
+--------------+------------+--------------+-------------+----------+
| *Endpoint* | | | | |
+--------------+------------+--------------+-------------+----------+
| Collection | | X | X | |
| date/time | | | | |
+--------------+------------+--------------+-------------+----------+
| Endpoint | | X | X | |
| type | | | | |
+--------------+------------+--------------+-------------+----------+
| Hardware ver | X | X | X | |
| sion/firmwar | | | | |
| e | | | | |
+--------------+------------+--------------+-------------+----------+
| Operating | X | X | X | |
| system | | | | |
+--------------+------------+--------------+-------------+----------+
| Operating | X | X | X | |
| system | | | | |
| attributes | | | | |
| (e.g., | | | | |
| version, | | | | |
| service pack | | | | |
| level, | | | | |
| edition, | | | | |
| etc.) | | | | |
+--------------+------------+--------------+-------------+----------+
| Installed | X | X | X | X |
| software | | | | |
| name | | | | |
+--------------+------------+--------------+-------------+----------+
| Installed | X | X | X | X |
| software | | | | |
| attributes | | | | |
| (e.g., | | | | |
| version, | | | | |
| patch level, | | | | |
| install | | | | |
| path, etc.) | | | | |
+--------------+------------+--------------+-------------+----------+
| Open ports/s | X | X | X | |
| ervices | | | | |
+--------------+------------+--------------+-------------+----------+
| Operating | X | X | X | |
| system | | | | |
Coffin, et al. Expires December 10, 2016 [Page 12]
Internet-Draft SACM Vuln Scenario June 2016
| optional | | | | |
| component | | | | |
| inventory | | | | |
+--------------+------------+--------------+-------------+----------+
| Location | | X | | X |
+--------------+------------+--------------+-------------+----------+
| Purpose | | X | | X |
+--------------+------------+--------------+-------------+----------+
| Criticality | | X | | X |
+--------------+------------+--------------+-------------+----------+
| File system | X | | X | |
| attributes | | | | |
| (e.g., | | | | |
| versions, | | | | |
| size, write | | | | |
| date, | | | | |
| modified | | | | |
| date, | | | | |
| checksum, | | | | |
| etc.) | | | | |
+--------------+------------+--------------+-------------+----------+
| Shared | X | | X | |
| libraries | | | | |
+--------------+------------+--------------+-------------+----------+
| Other | X | | X | |
| software con | | | | |
| figuration | | | | |
| information | | | | |
+--------------+------------+--------------+-------------+----------+
| *External vu | | | | |
| lnerability | | | | |
| description | | | | |
| data* | | | | |
+--------------+------------+--------------+-------------+----------+
| Ingest Date | X | | X | |
+--------------+------------+--------------+-------------+----------+
| Date of | X | | X | |
| Release | | | | |
+--------------+------------+--------------+-------------+----------+
| Version | X | | X | |
+--------------+------------+--------------+-------------+----------+
| External | X | | X | X |
| vuln ID | | | | |
+--------------+------------+--------------+-------------+----------+
| Severity | | | | X |
| Score | | | | |
+--------------+------------+--------------+-------------+----------+
| *Assessment | | | | |
Coffin, et al. Expires December 10, 2016 [Page 13]
Internet-Draft SACM Vuln Scenario June 2016
| Results* | | | | |
+--------------+------------+--------------+-------------+----------+
| Date of | | | X | X |
| assessment | | | | |
+--------------+------------+--------------+-------------+----------+
| Date of data | | X | X | X |
| collection | | | | |
+--------------+------------+--------------+-------------+----------+
| Endpoint ide | | X | X | X |
| ntification | | | | |
| and/or | | | | |
| locally | | | | |
| assigned ID | | | | |
+--------------+------------+--------------+-------------+----------+
| Vulnerable | X | X | X | X |
| software | | | | |
| product(s) | | | | |
+--------------+------------+--------------+-------------+----------+
| Endpoint vul | | | X | X |
| nerability | | | | |
| status | | | | |
+--------------+------------+--------------+-------------+----------+
| Vulnerabilit | X | | | X |
| y | | | | |
| description | | | | |
+--------------+------------+--------------+-------------+----------+
| Vulnerabilit | X | | | X |
| y | | | | |
| rememdiation | | | | |
+--------------+------------+--------------+-------------+----------+
Table 1: Vulnerability Assessment Attributes
Appendix E. Alignment with Other Existing Works
E.1. Critical Security Controls
The Council on CyberSecurity's Critical Security Controls
[critical-controls] includes security controls 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.
E.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
Coffin, et al. Expires December 10, 2016 [Page 14]
Internet-Draft SACM Vuln Scenario June 2016
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-10, 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, 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 description information from the source
in Step 1, to producing assessment results in Step 6.
Coffin, et al. Expires December 10, 2016 [Page 15]
Internet-Draft SACM Vuln Scenario June 2016
E.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
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 F. 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
Coffin, et al. Expires December 10, 2016 [Page 16]
Internet-Draft SACM Vuln Scenario June 2016
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
align almost exactly with the scenario described in this document.
Instead of collecting automatable security configuration
checklists, the enterprise would collect automatable vulnerability
description information 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 vulnerability description data 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 describes vulnerability assessment and aligns well with
the vulnerability scenario described in this document. The
endpoint assets are identified and associated data is published in
a Repository. Vulnerability description information is collected
and saved in a Repository as it is released. The vulnerability
description information is queued for later assessment, then the
Coffin, et al. Expires December 10, 2016 [Page 17]
Internet-Draft SACM Vuln Scenario June 2016
assessment results and vulnerability description information are
stored after assessment. The only real difference in this SACM
usage scenario is 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 G. 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
[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 assessment results data
set should include. In the case of vulnerability assessment
results, 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 assessment results. The concern here is with vulnerability
description data, 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, how the endpoint is used, 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. In addition, the storage of these
attributes could be central (stored in a data repository) or they
could be assigned and stored on the endpoints themselves.
Appendix H. SACM Use Case Alignment
H.1. Endpoint Identification
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.
Coffin, et al. Expires December 10, 2016 [Page 18]
Internet-Draft SACM Vuln Scenario June 2016
H.2. Endpoint Data Collection
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.
H.3. Vulnerability Description Information
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.
H.4. Applicability
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.
H.5. Secondary Assessment
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
Coffin, et al. Expires December 10, 2016 [Page 19]
Internet-Draft SACM Vuln Scenario June 2016
additional and more specific component inventories and collections of
endpoint attributes and their values.
H.6. Assessment Results
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.
Appendix I. Implementation Examples
I.1. Endpoint Data Collection
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, the
identity of all installed software including the endpoint operating
system, could be collected and used 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.
I.2. Vulnerability Description Information
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.
Coffin, et al. Expires December 10, 2016 [Page 20]
Internet-Draft SACM Vuln Scenario June 2016
I.3. Secondary Assessment
Within the SACM Architecture, the assessment task would be handled by
the Evaluator component. If pre-assessment data is used, this would
be stored on and 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.
I.4. Assessment Results
The OVAL Results Model provides a data model to encode the results of
the assessment, which could then be stored in a Repository and later
accessed. The assessment results described in this scenario could be
stored and later accessed using the OVAL Results Model. Note that
the use of the OVAL Results Model for sharing results is not
recommended per section 7.3 of the OVAL and the SACM Information
Model [draft-hansbury-sacm-oval-info-model-mapping-01].
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.
Coffin, et al. Expires December 10, 2016 [Page 21]
Internet-Draft SACM Vuln Scenario June 2016
Authors' Addresses
Christopher Coffin
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA
Email: ccoffin@mitre.org
Brant Cheikes
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA
Email: bcheikes@mitre.org
Charles Schmidt
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA
Email: cmschmidt@mitre.org
Daniel Haynes
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA
Email: dhaynes@mitre.org
Jessica Fitzgerald-McKay
Department of Defense
9800 Savage Road
Ft. Meade, Maryland
USA
Email: jmfitz2@nsa.gov
Coffin, et al. Expires December 10, 2016 [Page 22]
Internet-Draft SACM Vuln Scenario June 2016
David Waltermire
National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, Maryland 20877
USA
Email: david.waltermire@nist.gov
Coffin, et al. Expires December 10, 2016 [Page 23]