draft-ietf-sacm-vuln-scenario-00.txt   draft-ietf-sacm-vuln-scenario-01.txt 
SACM C. Coffin SACM C. Coffin
Internet-Draft B. Cheikes Internet-Draft B. Cheikes
Intended status: Informational C. Schmidt Intended status: Informational C. Schmidt
Expires: December 10, 2016 D. Haynes Expires: January 8, 2017 D. Haynes
The MITRE Corporation The MITRE Corporation
J. Fitzgerald-McKay J. Fitzgerald-McKay
Department of Defense Department of Defense
D. Waltermire D. Waltermire
National Institute of Standards and Technology National Institute of Standards and Technology
June 8, 2016 July 7, 2016
SACM Vulnerability Assessment Scenario SACM Vulnerability Assessment Scenario
draft-ietf-sacm-vuln-scenario-00 draft-ietf-sacm-vuln-scenario-01
Abstract Abstract
This document describes an automated enterprise vulnerability This document describes an automated enterprise vulnerability
assessment scenario aligned with the SACM Use Cases. The scenario assessment scenario aligned with the SACM Use Cases. The scenario
assumes the existence of an endpoint management capability and begins assumes the existence of an endpoint management capability and begins
with an enterprise ingesting vulnerability description information. with an enterprise ingesting vulnerability description information.
Endpoints are assessed against the vulnerability description Endpoints are assessed against the vulnerability description
information based a combination of examining known endpoint information based on a combination of examining known endpoint
characterization information and collected endpoint information. characterization information and collected endpoint information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Vulnerability Assessment Pre-requisites . . . . . . . . . . . 4 4. Vulnerability Assessment Pre-requisites . . . . . . . . . . . 4
4.1. Endpoint Management Capability . . . . . . . . . . . . . 4 4.1. Endpoint Management Capability . . . . . . . . . . . . . 4
4.2. Vulnerability Description Information . . . . . . . . . . 5 4.2. Vulnerability Description Information . . . . . . . . . . 5
5. Endpoint Vulnerability Assessment Capability . . . . . . . . 5 5. Endpoint Vulnerability Assessment Capability . . . . . . . . 5
6. Vulnerability Assessment Results . . . . . . . . . . . . . . 6 6. Vulnerability Assessment Results . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8
A.1. Changes Since Adopted as a WG I-D -00 . . . . . . . . . . 7 A.1. Changes in Revision -01 . . . . . . . . . . . . . . . . . 8
A.2. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 8 A.2. Changes Since Adopted as a WG I-D -00 . . . . . . . . . . 9
Appendix B. Continuous Vulnerability Assessment . . . . . . . . 10 A.3. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 9
Appendix C. Priority . . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Implementation Examples . . . . . . . . . . . . . . 11
Appendix D. Data Attribute Table . . . . . . . . . . . . . . . . 11 B.1. Endpoint Data Collection . . . . . . . . . . . . . . . . 11
D.1. Table . . . . . . . . . . . . . . . . . . . . . . . . . . 11 B.2. Vulnerability Description Information . . . . . . . . . . 12
Appendix E. Alignment with Other Existing Works . . . . . . . . 14 B.3. Secondary Assessment . . . . . . . . . . . . . . . . . . 12
E.1. Critical Security Controls . . . . . . . . . . . . . . . 14 B.4. Assessment Results . . . . . . . . . . . . . . . . . . . 12
E.1.1. Continuous Vulnerability Assessment . . . . . . . . . 14 Appendix C. Priority . . . . . . . . . . . . . . . . . . . . . . 13
E.1.2. Hardware and Software Inventories . . . . . . . . . . 16 Appendix D. SACM Usage Scenarios . . . . . . . . . . . . . . . . 14
Appendix F. SACM Usage Scenarios . . . . . . . . . . . . . . . . 16 Appendix E. SACM Requirements and Charter - Future Work . . . . 15
Appendix G. SACM Requirements and Charter - Future Work . . . . 18 Appendix F. SACM Use Case Alignment . . . . . . . . . . . . . . 16
Appendix H. SACM Use Case Alignment . . . . . . . . . . . . . . 18 F.1. Endpoint Identification . . . . . . . . . . . . . . . . . 16
H.1. Endpoint Identification . . . . . . . . . . . . . . . . . 18 F.2. Endpoint Data Collection . . . . . . . . . . . . . . . . 16
H.2. Endpoint Data Collection . . . . . . . . . . . . . . . . 19 F.3. Vulnerability Description Information . . . . . . . . . . 17
H.3. Vulnerability Description Information . . . . . . . . . . 19 F.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 17
H.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 F.5. Secondary Assessment . . . . . . . . . . . . . . . . . . 17
H.5. Secondary Assessment . . . . . . . . . . . . . . . . . . 19 F.6. Assessment Results . . . . . . . . . . . . . . . . . . . 17
H.6. Assessment Results . . . . . . . . . . . . . . . . . . . 20 Appendix G. Alignment with Other Existing Works . . . . . . . . 17
Appendix I. Implementation Examples . . . . . . . . . . . . . . 20 G.1. Critical Security Controls . . . . . . . . . . . . . . . 17
I.1. Endpoint Data Collection . . . . . . . . . . . . . . . . 20 G.1.1. Continuous Vulnerability Assessment . . . . . . . . . 18
I.2. Vulnerability Description Information . . . . . . . . . . 20 G.1.2. Hardware and Software Inventories . . . . . . . . . . 19
I.3. Secondary Assessment . . . . . . . . . . . . . . . . . . 21 Appendix H. Continuous Vulnerability Assessment . . . . . . . . 19
I.4. Assessment Results . . . . . . . . . . . . . . . . . . . 21 Appendix I. Data Attribute Table . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Scope 1. Introduction
This document describes a detailed, enterprise-specific vulnerability This document describes a detailed, enterprise-specific vulnerability
assessment scenario from which information model elements can be assessment scenario from which information model elements can be
discovered. Such elements may include classes of data, major roles, discovered. This scenario also informs protocol and data model
and role interactions. This scenario also informs protocol and data development in support of vulnerability assessment, as part of
model development in support of vulnerability assessment, as part of overall posture assessment (see Appendix B for examples of solutions
overall posture assessment. Vulnerability discovery, disclosure, and that support this scenario).
publication is out of scope.
Vulnerability discovery, disclosure, publication, and prioritization
is out of scope. However, given the importance of prioritization in
an enterprise's vulnerability assessment process, it is discussed in
Appendix C.
Information on how the scenario aligns with SACM and other existing
work is discussed in Appendix D through Appendix G.
2. Terminology 2. Terminology
Vulnerability description information: Information pertaining to the Vulnerability description information: Information pertaining to the
existence of a flaw or flaws in software, hardware, and/or existence of a flaw or flaws in software, hardware, and/or
firmware, which could potentially have an adverse impact on firmware, which could potentially have an adverse impact on
enterprise IT functionality and/or security. Vulnerability enterprise IT functionality and/or security. Vulnerability
description information should contain enough information to description information should contain enough information to
support vulnerability detection. support vulnerability detection.
skipping to change at page 3, line 46 skipping to change at page 4, line 5
Vulnerability management capability: An enterprise IT capability Vulnerability management capability: An enterprise IT capability
managing endpoint vulnerabilities and associated metadata on an managing endpoint vulnerabilities and associated metadata on an
ongoing basis by ingesting vulnerability description ongoing basis by ingesting vulnerability description
information and vulnerability detection data, and performing a information and vulnerability detection data, and performing a
vulnerability assessment. vulnerability assessment.
Vulnerability assessment: The process of determining whether a set Vulnerability assessment: The process of determining whether a set
of endpoints is vulnerable according to the information of endpoints is vulnerable according to the information
contained in the vulnerability description information. contained in the vulnerability description information.
Supplemental collection: The task of collecting specific endpoint
information from the target endpoint, that is not available
from the endpoint management capability, in order to make a
determination about that endpoint (vulnerability status,
identification, etc.).
3. Assumptions 3. Assumptions
A number of assumptions must be stated in order to further clarify A number of assumptions must be stated in order to further clarify
the position and scope of this document. the position and scope of this document.
The document assumes that: The document assumes that:
o The enterprise has received vulnerability description information, o The enterprise has received vulnerability description information,
and that the information has already been processed into and that the information has already been processed into
vulnerability detection data that the enterprise's security vulnerability detection data that the enterprise's security
software tools can understand and use. software tools can understand and use.
o The enterprise has a means of identifying enterprise endpoints o The enterprise has a means of identifying enterprise endpoints
although assertions about some details of this capability are through the execution of Target Endpoint Discovery Tasks although
made. assertions about some details of this capability are made.
o The enterprise has a means of extracting relevant information o The enterprise has a means of extracting relevant information
about enterprise endpoints in a form that is compatible with the about enterprise endpoints in a form that is compatible with the
vulnerability description data. vulnerability description data.
o All information described in this scenario is available in the o All information described in this scenario is available in the
vulnerability description data and serves as the basis of this vulnerability description data and serves as the basis of this
assessment. assessment.
o The enterprise can provide all relevant information about any o The enterprise can provide all relevant information about any
endpoint needed to perform the described assessment. endpoint needed to perform the described assessment.
o The enterprise has a mechanism for long-term storage of o The enterprise has a mechanism for long-term storage of
vulnerability description information, vulnerability detection vulnerability description information, vulnerability detection
data, and vulnerability assessment results. data, and vulnerability assessment results.
o The enterprise has a procedure for reassessment of endpoints at o The enterprise has a procedure for reassessment of endpoints at
some point after initial assessment. some point after initial assessment (see Appendix H for more
information).
4. Vulnerability Assessment Pre-requisites 4. Vulnerability Assessment Pre-requisites
In order to successfully support the vulnerability assessment In order to successfully support the vulnerability assessment
scenario, an enterprise needs to have the following capabilities scenario, an enterprise needs to have the following capabilities
deployed on their network and information readily available. deployed on their network and information readily available.
4.1. Endpoint Management Capability 4.1. Endpoint Management Capability
An endpoint management capability is assumed to be in place within An endpoint management capability is assumed to be in place within
the enterprise, and is expected to collect a minimum set of the enterprise, and is expected to collect a minimum set of
attributes from the endpoints under management, and to establish an attributes from the endpoints under management via Collection Tasks
endpoint's identity within the scope of that domain. Endpoint and to establish an endpoint's identity within the scope of that
identity can be established by collecting certain attributes (as part domain. Endpoint identity can be established by collecting certain
of the minimum set of attributes) that allow for unique and identifying attributes, collectively known as the Target Endpoint
persistent tracking of endpoints on the enterprise network. Examples Identifier, that allow for unique and persistent tracking of
include, but are not limited to, IP address, MAC address, Fully endpoints on the enterprise network. Examples include, but are not
Qualified Domain Names (FQDNs), pre-provisioned identifiers such as limited to, IP address, MAC address, Fully Qualified Domain Names
Globally Unique Identifiers (GUIDs) or copies of serial numbers, (FQDNs), pre-provisioned identifiers such as Globally Unique
certificates, hardware identity values, or similar attributes. All Identifiers (GUIDs) or copies of serial numbers, certificates,
of the information collected by the endpoint management capability is hardware identity values, or similar attributes. To simplify the
identification of an endpoint, a Target Endpoint Label may be created
and assigned to refer to the Target Endpoint Identifier. All of the
information collected by the endpoint management capability is
stored, with appropriate metadata (i.e. timestamp), in a central stored, with appropriate metadata (i.e. timestamp), in a central
location. The endpoint management capability is expected to be location and used to build up a Target Endpoint Characterization
performed on an ongoing basis, resulting in routine, or even event- Record and Target Endpoint Profile via a Target Endpoint
driven, collection of basic endpoint information. Characterization Task. 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 See Appendix I for information-specific details.
details.
4.2. Vulnerability Description Information 4.2. Vulnerability Description Information
Vulnerability description information is expected to be periodically Vulnerability description information is expected to be periodically
received by the enterprise. Upon receipt, the vulnerability received by the enterprise. Upon receipt, the vulnerability
description information is expected to be assigned a unique tracking description information is expected to be assigned a unique tracking
identifier, stored in a repository (with appropriate metadata) in raw identifier, stored in a repository (with appropriate metadata) in raw
form, and transformed into a machine-readable vulnerability detection form, and transformed into a machine-readable vulnerability detection
data with unique tracking identifier understood by the components data with unique tracking identifier understood by the components
described by this scenario. This transformed form can be referred to described by this scenario. This transformed form can be referred to
as the vulnerability detection data. At some point, receipt and as the vulnerability detection data. At some point, receipt and
processing of vulnerability description data is expected to trigger processing of vulnerability description data is expected to trigger
the vulnerability assessment. the vulnerability assessment.
See "Data Attribute Tables and Definitions" for information-specific See Appendix I for information-specific details.
details.
5. Endpoint Vulnerability Assessment Capability 5. Endpoint Vulnerability Assessment Capability
When new vulnerability description information is received by the When new vulnerability description information is received by the
enterprise, affected endpoints are identified and assessed. The enterprise, affected endpoints are identified and assessed. The
vulnerability is said to apply to an endpoint if the endpoint vulnerability is said to apply to an endpoint if the endpoint
satisfies the conditions expressed in the vulnerability detection satisfies the conditions expressed in the vulnerability detection
data. data.
A vulnerability assessment (i.e. vulnerability detection) is A vulnerability assessment (i.e. vulnerability detection) is
performed in two steps: performed in two steps:
o Endpoint information collected by the endpoint management o Endpoint information collected by the endpoint management
capability is examined. capability is examined by the vulnerability management capability
through Evaluation Tasks.
o If the data possessed by the endpoint management capability is o If the data possessed by the endpoint management capability is
insufficient, then necessary data is collected from the target insufficient, a Collection Task is triggered and the necessary
endpoint. data is collected from the target endpoint.
Vulnerability detection relies on the examination of different Vulnerability detection relies on the examination of different
endpoint information depending on the nature of a specific endpoint information depending on the nature of a specific
vulnerability. Common endpoint information used to detect a vulnerability. Common endpoint information used to detect a
vulnerability includes: vulnerability includes:
o A specific software version is installed on the endpoint o A specific software version is installed on the endpoint
o File system attributes o File system attributes
o Specific state attributes o Specific state attributes
In many cases, the endpoint information needed to determine an In many cases, the endpoint information needed to determine an
endpoint's vulnerability status will have been previously collected endpoint's vulnerability status will have been previously collected
by the Endpoint Management Capability and available in a Repository. by the Endpoint Management Capability and available in a Repository.
However, in other cases, the necessary endpoint information will not However, in other cases, the necessary endpoint information will not
be readily available in a Repository and a supplemental collection be readily available in a Repository and a Collection Task will be
will be necessary. Of course, an implementation of an endpoint triggered to collect it from the target endpoint. Of course, an
management capability may prefer to enable operators to perform implementation of an endpoint management capability may prefer to
supplemental collection under certain circumstances, even when enable operators to perform this collection under certain
sufficient information can be provided by the endpoint management circumstances, even when sufficient information can be provided by
capability (e.g. there may be freshness requirements for the endpoint management capability (e.g. there may be freshness
information). requirements for information).
Supplemental collection of endpoint information for the purpose of The collection of additional endpoint information for the purpose of
vulnerability assessment does not necessarily need to be a pull by vulnerability assessment does not necessarily need to be a pull by
the vulnerability assessment capability. Under certain deployment the vulnerability assessment capability. Over time, some new pieces
scenarios, once the necessary detection information is known, the of information that are needed during common types of assessments
information beyond that which is available in the endpoint management might be identified. An endpoint management capability can be
capability can be pushed to the vulnerability assessment capability reconfigured to have this information delivered automatically. This
by the endpoint whenever that information changes. avoids the need to trigger additional Collection Tasks to gather this
information during assessments, streamlining the assessment process.
Likewise, it might be observed that certain information delivered by
an endpoint management capability is rarely used. In this case, it
might be useful to re-configure the endpoint management capability to
no longer collect this information to reduce network and processing
overhead. Instead, a new Collection Task can be triggered to gather
this data on the rare occasions when it is needed.
See "Data Attribute Tables and Definitions" for information-specific See Appendix I for information-specific details.
details.
6. Vulnerability Assessment Results 6. Vulnerability Assessment Results
Vulnerability assessment results present evaluation results along Vulnerability assessment results present evaluation results along
with sufficient context, so that appropriate action can be taken. with sufficient context, so that appropriate action can be taken.
Vulnerability assessment results are ideally stored for later use. Vulnerability assessment results are ideally stored for later use.
See "Data Attribute Tables and Definitions" for information-specific See Appendix I for information-specific details.
details.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
This document provides a core narrative that walks through an This document provides a core narrative that walks through an
automated enterprise vulnerability assessment scenario and is aligned automated enterprise vulnerability assessment scenario and is aligned
with SACM "Endpoint Security Posture Assessment: Enterprise Use with SACM "Endpoint Security Posture Assessment: Enterprise Use
Cases" [RFC7632]. As a result, the security considerations for Cases" [RFC7632]. As a result, the security considerations for
[RFC7632] apply to this document. Furthermore, the vulnerability [RFC7632] apply to this document. Furthermore, the data collected as
description information may provide attackers with useful information part of the vulnerability assessment may provide attackers with
such as what software an enterprise is running on their endpoints. useful information such as what software an enterprise is running on
As a result, organizations should properly protect the vulnerability their endpoints. As a result, organizations should consider properly
description data it ingests. protecting this information.
9. Informative References 9. Informative References
[charter-ietf-sacm-01] [charter-ietf-sacm-01]
Security Automation and Continuous Monitoring, "Charter, Security Automation and Continuous Monitoring, "Charter,
Version 1.0", July 2013. Version 1.0", October 2015,
<https://datatracker.ietf.org/doc/charter-ietf-sacm/>.
[critical-controls] [critical-controls]
Council on CyberSecurity, "Critical Security Controls, Center for Internet Security, "Critical Security Controls,
Version 5.1". Version 6.0", <https://www.cisecurity.org/critical-
controls.cfm>.
[draft-hansbury-sacm-oval-info-model-mapping-01] [cvrf] Industry Consortium for Advancement of Security on the
Internet, "Common Vulnerability and Reporting Framework",
May 2012, <http://www.icasi.org/cvrf/>.
[draft-hansbury-sacm-oval-info-model-mapping-02]
Security Automation and Continuous Monitoring, "OVAL and Security Automation and Continuous Monitoring, "OVAL and
the SACM Information Model", November 2015. the SACM Information Model", March 2016,
<https://datatracker.ietf.org/doc/draft-hansbury-sacm-
oval-info-model-mapping>.
[I-D.coffin-sacm-nea-swid-patnc]
Coffin, C., Haynes, D., Schmidt, C., and J. Fitzgerald-
McKay, "SWID Message and Attributes for PA-TNC", draft-
coffin-sacm-nea-swid-patnc-01 (work in progress), June
2016.
[I-D.cokus-sacm-oval-results-model]
Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez,
"OVAL(R) Results Model", draft-cokus-sacm-oval-results-
model-00 (work in progress), March 2016.
[I-D.haynes-sacm-oval-definitions-model]
Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez,
"OVAL(R) Definitions Model", draft-haynes-sacm-oval-
definitions-model-00 (work in progress), March 2016.
[I-D.ietf-sacm-requirements] [I-D.ietf-sacm-requirements]
Cam-Winget, N. and L. Lorenzin, "Security Automation and Cam-Winget, N. and L. Lorenzin, "Security Automation and
Continuous Monitoring (SACM) Requirements", draft-ietf- Continuous Monitoring (SACM) Requirements", draft-ietf-
sacm-requirements-13 (work in progress), March 2016. sacm-requirements-13 (work in progress), March 2016.
[I-D.rothenberg-sacm-oval-sys-char-model]
Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez,
"OVAL(R) System Characteristics Model", draft-rothenberg-
sacm-oval-sys-char-model-00 (work in progress), March
2016.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632, Posture Assessment: Enterprise Use Cases", RFC 7632,
DOI 10.17487/RFC7632, September 2015, DOI 10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>. <http://www.rfc-editor.org/info/rfc7632>.
Appendix A. Change Log Appendix A. Change Log
A.1. Changes Since Adopted as a WG I-D -00 A.1. Changes in Revision -01
Clarified how the endpoint management capability can reconfigured
over time to adapt to the needs of an enterprise. GitHub issue #12
(https://github.com/sacmwg/vulnerability-scenario/issues/12).
Included references to the various appendices in the document.
GitHub issue #18 (https://github.com/sacmwg/vulnerability-scenario/
issues/18).
Fixed typos and other minor editorial changes in the document.
GitHub issue #19 (https://github.com/sacmwg/vulnerability-scenario/
issues/18). GitHub issue #20 (https://github.com/sacmwg/
vulnerability-scenario/issues/20). GitHub issue #22
(https://github.com/sacmwg/vulnerability-scenario/issues/22).
Updated references to the Critical Controls to Version 6.0. GitHub
issue #23 (https://github.com/sacmwg/vulnerability-scenario/
issues/23).
Aligned the scenario with SACM Tasks. GitHub issue #25
(https://github.com/sacmwg/vulnerability-scenario/issues/25).
A.2. Changes Since Adopted as a WG I-D -00
Made various organizational and editorial changes as proposed by Adam Made various organizational and editorial changes as proposed by Adam
Montville. GitHub issue #4 (https://github.com/sacmwg/vulnerability- Montville. GitHub issue #4 (https://github.com/sacmwg/vulnerability-
scenario/issues/4). scenario/issues/4).
Removed the TODO from the Security Considerations section Removed the TODO from the Security Considerations section
(https://github.com/sacmwg/vulnerability-scenario/issues/8). (https://github.com/sacmwg/vulnerability-scenario/issues/8).
Clarified the definition of "vulnerability detection data" to explain Clarified the definition of "vulnerability detection data" to explain
how it was guidance and provided instructions for security tools on how it was guidance and provided instructions for security tools on
skipping to change at page 8, line 29 skipping to change at page 9, line 47
issues/15). issues/15).
Determine if we need to remove references to the long-term storage of Determine if we need to remove references to the long-term storage of
data in repositories. GitHub issue #16 (https://github.com/sacmwg/ data in repositories. GitHub issue #16 (https://github.com/sacmwg/
vulnerability-scenario/issues/16). vulnerability-scenario/issues/16).
Moved the information needs captured in Appendix D.2 into the Moved the information needs captured in Appendix D.2 into the
Information Model. GitHub issue #17 (https://github.com/sacmwg/ Information Model. GitHub issue #17 (https://github.com/sacmwg/
vulnerability-scenario/issues/17). vulnerability-scenario/issues/17).
A.2. Changes in Revision draft-coffin-sacm-vuln-scenario-01 A.3. Changes in Revision draft-coffin-sacm-vuln-scenario-01
Clarification of the vulnerability description data IDs in sections 4 Clarification of the vulnerability description data IDs in sections 4
and 6. and 6.
Added "vulnerability remediation" to the Assessment Results and Data Added "vulnerability remediation" to the Assessment Results and Data
Attribute Table and Definitions sections. Attribute Table and Definitions sections.
Added Implementation Examples to Endpoint Identification and Initial Added Implementation Examples to Endpoint Identification and Initial
(Pre-Assessment) Data Collection, Vulnerability Description Data, (Pre-Assessment) Data Collection, Vulnerability Description Data,
Endpoint Applicability and Assessment, and Assessment Results Endpoint Applicability and Assessment, and Assessment Results
skipping to change at page 10, line 5 skipping to change at page 11, line 23
Merged the list of "basic endpoint information" and the list of Merged the list of "basic endpoint information" and the list of
"human-assigned endpoint attributes" as both represent data we want "human-assigned endpoint attributes" as both represent data we want
to collect about an endpoint. Whether or not that data is natively to collect about an endpoint. Whether or not that data is natively
available on the endpoint for collection or assigned by a human, available on the endpoint for collection or assigned by a human,
computed, or derived from other data which may or may not be computed, or derived from other data which may or may not be
available on the endpoint for collection seems arbitrary. With this available on the endpoint for collection seems arbitrary. With this
scenario, we primarily care about expressing information needs rather scenario, we primarily care about expressing information needs rather
than how the information is collected or from where. than how the information is collected or from where.
Appendix B. Continuous Vulnerability Assessment Appendix B. Implementation Examples
It is not sufficient to perform a single assessment when B.1. Endpoint Data Collection
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. Within the SACM Architecture, the Internal and External Collector
However, it does not make any assumptions as to when this assessment components could be used to allow enterprises to collect posture
occurs relative to the original receipt of the vulnerability attributes that demonstrate compliance with enterprise policy.
description data that led to this assessment. The assessment could Endpoints can be required to provide posture attributes, which may
immediately follow the ingestion of the vulnerability description include identification attributes to enable persistent
information, could be delayed, or the assessment might represent a communications.
reassessment of some vulnerability description information against
which endpoints had previously been assessed. Moreover, the scenario The SWID Message and Attributes for PA-TNC standard
incorporates long-term storage of collected data, vulnerability [I-D.coffin-sacm-nea-swid-patnc] defines collection and validation of
description information, and assessment results in order to software identities using the ISO Software Identification Tag
facilitate meaningful and ongoing reassessment. Standard. Using this standard, the identity of all installed
software including the endpoint operating system, could be collected
and used for later assessment.
The OVAL Definitions Model [I-D.haynes-sacm-oval-definitions-model]
provides a data model that can be used to specify what posture
attributes to collect as well as their expected values which can be
used to drive an assessment.
The OVAL System Characteristics Model
[I-D.rothenberg-sacm-oval-sys-char-model] can be used to capture
information about an endpoint. The model is specifically suited to
expressing OS information, endpoint identification information (such
as IP and MAC addresses), and other endpoint metadata.
B.2. Vulnerability Description Information
The Common Vulnerability Reporting Framework (CVRF) [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.
B.3. Secondary Assessment
Within the SACM Architecture, the assessment task would be handled by
the Evaluator component. If previously collected data is used, it
would be obtained from a Data Store component.
Within the SACM Architecture, the Internal and External Collector
components could be used to allow enterprises to collect posture
attributes that demonstrate compliance with enterprise policy.
Endpoints can be required to provide posture attributes, which may
include identification attributes to enable persistent
communications.
The SWID Message and Attributes for PA-TNC standard defines
collection and validation of software identities using the ISO
Software Identification Tag Standard. Using this standard, all
installed software including the endpoint operating system could be
collected and stored for later assessment.
The OVAL Definitions Model provides a data model that can be used to
specify what posture attributes to collect as well as their expected
values which can be used to drive an assessment.
The OVAL System Characteristics Model can be used to capture
information about an endpoint. The model is specifically suited to
expressing OS information, endpoint identification information (such
as IP and MAC addresses), and other endpoint metadata.
The SACM Internal and External Attribute Collector components can be
used to allow enterprises to collect posture attributes that
demonstrate compliance with enterprise policy. Endpoints can be
required to provide posture attributes, which may include
identification attributes to enable persistent communications.
B.4. Assessment Results
The OVAL Results Model [I-D.cokus-sacm-oval-results-model] provides a
data model to encode the results of the assessment, which could then
be stored in a Repository and later accessed. The assessment results
described in this scenario could be stored and later accessed using
the OVAL Results Model. Note that the use of the OVAL Results Model
for sharing results is not recommended per section 7.3 of the OVAL
and the SACM Information Model
[draft-hansbury-sacm-oval-info-model-mapping-02].
Within the SACM Architecture, the generation of the assessment
results would occur in the Report Generator component. Those results
might then be moved to a Data Store component for later sharing and
retrieval as defined by SACM.
Appendix C. Priority Appendix C. Priority
Priorities associated with the vulnerability description information, Priorities associated with the vulnerability description information,
assessment results, and any remedy is important, but is treated as a assessment results, and any remedy is important, but is treated as a
separate challenge and, as such, has not been integrated into the separate challenge and, as such, has not been integrated into the
description of this scenario. Nevertheless, it is important to point description of this scenario. Nevertheless, it is important to point
out and describe the use of priorities in the overall vulnerability out and describe the use of priorities in the overall vulnerability
assessment scenario as a separate issue with its own sets of assessment scenario as a separate issue with its own sets of
requirements. requirements.
skipping to change at page 11, line 41 skipping to change at page 14, line 21
o Severity attributes - A rating or score that attempts to provide o Severity attributes - A rating or score that attempts to provide
the level of severity or criticality associated with a given the level of severity or criticality associated with a given
vulnerability. vulnerability.
o Cyber threat intelligence - information such as tactics, o Cyber threat intelligence - information such as tactics,
techniques, and procedures of threat actors, indicators of techniques, and procedures of threat actors, indicators of
compromise, incidents, courses of action, etc. that help the compromise, incidents, courses of action, etc. that help the
enterprise understand relevant threats and how to detect, enterprise understand relevant threats and how to detect,
mitigate, or respond to them. mitigate, or respond to them.
Appendix D. Data Attribute Table Appendix D. SACM Usage Scenarios
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 |
| | | (Pre- | Assessment | |
| | | Assessment) | | |
| | | Data | | |
| | | Collection | | |
+--------------+------------+--------------+-------------+----------+
| *Endpoint* | | | | |
+--------------+------------+--------------+-------------+----------+
| Collection | | X | X | |
| date/time | | | | |
+--------------+------------+--------------+-------------+----------+
| Endpoint | | X | X | |
| type | | | | |
+--------------+------------+--------------+-------------+----------+
| Hardware ver | X | X | X | |
| sion/firmwar | | | | |
| e | | | | |
+--------------+------------+--------------+-------------+----------+
| Operating | X | X | X | |
| system | | | | |
+--------------+------------+--------------+-------------+----------+
| Operating | X | X | X | |
| system | | | | |
| attributes | | | | |
| (e.g., | | | | |
| version, | | | | |
| service pack | | | | |
| level, | | | | |
| edition, | | | | |
| etc.) | | | | |
+--------------+------------+--------------+-------------+----------+
| Installed | X | X | X | X |
| software | | | | |
| name | | | | |
+--------------+------------+--------------+-------------+----------+
| Installed | X | X | X | X |
| software | | | | |
| attributes | | | | |
| (e.g., | | | | |
| version, | | | | |
| patch level, | | | | |
| install | | | | |
| path, etc.) | | | | |
+--------------+------------+--------------+-------------+----------+
| Open ports/s | X | X | X | |
| ervices | | | | |
+--------------+------------+--------------+-------------+----------+
| Operating | X | X | X | |
| system | | | | |
| optional | | | | |
| component | | | | |
| inventory | | | | |
+--------------+------------+--------------+-------------+----------+
| Location | | X | | X |
+--------------+------------+--------------+-------------+----------+
| Purpose | | X | | X |
+--------------+------------+--------------+-------------+----------+
| Criticality | | X | | X |
+--------------+------------+--------------+-------------+----------+
| File system | X | | X | |
| attributes | | | | |
| (e.g., | | | | |
| versions, | | | | |
| size, write | | | | |
| date, | | | | |
| modified | | | | |
| date, | | | | |
| checksum, | | | | |
| etc.) | | | | |
+--------------+------------+--------------+-------------+----------+
| Shared | X | | X | |
| libraries | | | | |
+--------------+------------+--------------+-------------+----------+
| Other | X | | X | |
| software con | | | | |
| figuration | | | | |
| information | | | | |
+--------------+------------+--------------+-------------+----------+
| *External vu | | | | |
| lnerability | | | | |
| description | | | | |
| data* | | | | |
+--------------+------------+--------------+-------------+----------+
| Ingest Date | X | | X | |
+--------------+------------+--------------+-------------+----------+
| Date of | X | | X | |
| Release | | | | |
+--------------+------------+--------------+-------------+----------+
| Version | X | | X | |
+--------------+------------+--------------+-------------+----------+
| External | X | | X | X |
| vuln ID | | | | |
+--------------+------------+--------------+-------------+----------+
| Severity | | | | X |
| Score | | | | |
+--------------+------------+--------------+-------------+----------+
| *Assessment | | | | |
| Results* | | | | |
+--------------+------------+--------------+-------------+----------+
| Date of | | | X | X |
| assessment | | | | |
+--------------+------------+--------------+-------------+----------+
| Date of data | | X | X | X |
| collection | | | | |
+--------------+------------+--------------+-------------+----------+
| Endpoint ide | | X | X | X |
| ntification | | | | |
| and/or | | | | |
| locally | | | | |
| assigned ID | | | | |
+--------------+------------+--------------+-------------+----------+
| Vulnerable | X | X | X | X |
| software | | | | |
| product(s) | | | | |
+--------------+------------+--------------+-------------+----------+
| Endpoint vul | | | X | X |
| nerability | | | | |
| status | | | | |
+--------------+------------+--------------+-------------+----------+
| Vulnerabilit | X | | | X |
| y | | | | |
| description | | | | |
+--------------+------------+--------------+-------------+----------+
| Vulnerabilit | X | | | X |
| y | | | | |
| rememdiation | | | | |
+--------------+------------+--------------+-------------+----------+
Table 1: Vulnerability Assessment Attributes
Appendix E. Alignment with Other Existing Works
E.1. Critical Security Controls
The Council on CyberSecurity's Critical Security Controls
[critical-controls] includes security controls 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
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.
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" The SACM "Endpoint Security Posture Assessment: Enterprise Use Cases"
document ([RFC7632]) defines multiple usage scenarios that are meant document ([RFC7632]) defines multiple usage scenarios that are meant
to provide examples of implementing the use cases and building block to provide examples of implementing the use cases and building block
capabilities. Below is a brief summary of some of these usage capabilities. Below is a brief summary of some of these usage
scenarios and how this document aligns and/or adds additional value scenarios and how this document aligns and/or adds additional value
to the identified usage scenarios. to the identified usage scenarios.
o Automated Checklist Verification (2.2.2) - "An enterprise operates o Automated Checklist Verification (2.2.2) - "An enterprise operates
a heterogeneous IT environment. They utilize vendor-provided a heterogeneous IT environment. They utilize vendor-provided
skipping to change at page 18, line 10 skipping to change at page 15, line 37
endpoint assets are identified and associated data is published in endpoint assets are identified and associated data is published in
a Repository. Vulnerability description information is collected a Repository. Vulnerability description information is collected
and saved in a Repository as it is released. The vulnerability and saved in a Repository as it is released. The vulnerability
description information is queued for later assessment, then the description information is queued for later assessment, then the
assessment results and vulnerability description information are assessment results and vulnerability description information are
stored after assessment. The only real difference in this SACM stored after assessment. The only real difference in this SACM
usage scenario is the timing of the assessments. The scenario usage scenario is the timing of the assessments. The scenario
described within this document would have no problems adjusting to described within this document would have no problems adjusting to
the timing of this SACM usage scenario or anything similar. the timing of this SACM usage scenario or anything similar.
Appendix G. SACM Requirements and Charter - Future Work Appendix E. SACM Requirements and Charter - Future Work
In the course authoring this document, some additional considerations In the course authoring this document, some additional considerations
for possible future work were noted. The following points were taken for possible future work were noted. The following points were taken
from the SACM Requirements [I-D.ietf-sacm-requirements], SACM Charter from the SACM Requirements [I-D.ietf-sacm-requirements], SACM Charter
[charter-ietf-sacm-01], and SACM Use Cases ([RFC7632]) documents and [charter-ietf-sacm-01], and SACM Use Cases ([RFC7632]) documents and
represent work that may be necessary to support the tasks or goals of represent work that may be necessary to support the tasks or goals of
SACM going forward. SACM going forward.
o The SACM requirements mentions "Result Reporting" with o The SACM requirements mentions "Result Reporting" with
applications but no detail around what the assessment results data applications but no detail around what the assessment results data
skipping to change at page 18, line 42 skipping to change at page 16, line 21
this scenario are touched on in the SACM use cases, but the topic this scenario are touched on in the SACM use cases, but the topic
could probably be explored in much more depth. Enterprise policy could probably be explored in much more depth. Enterprise policy
and behaviors could be greatly influenced by endpoint attributes and behaviors could be greatly influenced by endpoint attributes
such as locations, how the endpoint is used, and criticality. such as locations, how the endpoint is used, and criticality.
When and how these data attributes are collected, as well as what When and how these data attributes are collected, as well as what
the minimum or common set might look like, would be good topics the minimum or common set might look like, would be good topics
for future related SACM work. In addition, the storage of these for future related SACM work. In addition, the storage of these
attributes could be central (stored in a data repository) or they attributes could be central (stored in a data repository) or they
could be assigned and stored on the endpoints themselves. could be assigned and stored on the endpoints themselves.
Appendix H. SACM Use Case Alignment Appendix F. SACM Use Case Alignment
H.1. Endpoint Identification F.1. Endpoint Identification
This sub-step aligns with the Endpoint Discovery, Endpoint This sub-step aligns with the Endpoint Discovery, Endpoint
Characterization, and Endpoint Target Identification building block Characterization, and Endpoint Target Identification building block
capabilities. The alignment is due to the fact that the purpose of capabilities. The alignment is due to the fact that the purpose of
this sub-step is to discover, identify, and characterize all this sub-step is to discover, identify, and characterize all
endpoints on an enterprise network. endpoints on an enterprise network.
H.2. Endpoint Data Collection F.2. Endpoint Data Collection
This sub-step aligns with the Data Publication building block This sub-step aligns with the Data Publication building block
capability because this section involves storage of endpoint capability because this section involves storage of endpoint
attributes within an enterprise Repository. This sub-step also attributes within an enterprise Repository. This sub-step also
aligns with the Endpoint Characterization and Endpoint Target aligns with the Endpoint Characterization and Endpoint Target
Identification building block capabilities because it further Identification building block capabilities because it further
characterizes the endpoint through automated and possibly manual characterizes the endpoint through automated and possibly manual
means. There is direct alignment with the Endpoint Component means. There is direct alignment with the Endpoint Component
Inventory, Posture Attribute Identification, and Posture Attribute Inventory, Posture Attribute Identification, and Posture Attribute
Value Collection building block capabilities since the purpose of Value Collection building block capabilities since the purpose of
this sub-step is to perform an initial inventory of the endpoint and this sub-step is to perform an initial inventory of the endpoint and
collect basic attributes and their values. Last, there is alignment collect basic attributes and their values. Last, there is alignment
with the Collection Guidance Acquisition building block capabilities with the Collection Guidance Acquisition building block capabilities
as the inventory and collection of endpoint attributes would be as the inventory and collection of endpoint attributes would be
directed by some type of enterprise or third-party guidance. directed by some type of enterprise or third-party guidance.
H.3. Vulnerability Description Information F.3. Vulnerability Description Information
This step aligns with the Data Publication and Data Retrieval This step aligns with the Data Publication and Data Retrieval
building block capabilities because this section details storage of building block capabilities because this section details storage of
vulnerability description information within an enterprise Repository vulnerability description information within an enterprise Repository
and later retrieval of the same. and later retrieval of the same.
H.4. Applicability F.4. Applicability
This sub-step aligns with the Data Retrieval, Data Query, and Posture This sub-step aligns with the Data Retrieval, Data Query, and Posture
Attribute Value Query building block capabilities because, in this Attribute Value Query building block capabilities because, in this
sub-step, the process is attempting to determine the vulnerability sub-step, the process is attempting to determine the vulnerability
status of the endpoint using the data that has previously been status of the endpoint using the data that has previously been
collected. collected.
H.5. Secondary Assessment F.5. Secondary Assessment
This sub-step aligns with the Data Publication building block This sub-step aligns with the Data Publication building block
capability because this section details storage of endpoint capability because this section details storage of endpoint
attributes within an enterprise Repository. The sub-step also aligns attributes within an enterprise Repository. The sub-step also aligns
with the Collection Guidance Acquisition building block capability with the Collection Guidance Acquisition building block capability
since the vulnerability description information (guidance) drives the since the vulnerability description information (guidance) drives the
collection of additional endpoint attributes. collection of additional endpoint attributes.
This sub-step aligns with the Endpoint Characterization (both manual This sub-step aligns with the Endpoint Characterization (both manual
and automated) and Endpoint Target Identification building block and automated) and Endpoint Target Identification building block
capabilities because it could further characterize the endpoint capabilities because it could further characterize the endpoint
through automated and possibly manual means. There is direct through automated and possibly manual means. There is direct
alignment with the Endpoint Component Inventory, Posture Attribute alignment with the Endpoint Component Inventory, Posture Attribute
Identification, and Posture Attribute Value Collection building block Identification, and Posture Attribute Value Collection building block
capabilities since the purpose of this sub-step is to perform capabilities since the purpose of this sub-step is to perform
additional and more specific component inventories and collections of additional and more specific component inventories and collections of
endpoint attributes and their values. endpoint attributes and their values.
H.6. Assessment Results F.6. Assessment Results
This step aligns with the Data Publication and Data Retrieval This step aligns with the Data Publication and Data Retrieval
building block capabilities because this section details storage of building block capabilities because this section details storage of
vulnerability assessment results within an enterprise Repository and vulnerability assessment results within an enterprise Repository and
later retrieval of the same. later retrieval of the same.
Appendix I. Implementation Examples Appendix G. Alignment with Other Existing Works
I.1. Endpoint Data Collection G.1. Critical Security Controls
Within the SACM Architecture, the Internal and External Collector The Center for Internet Security's Critical Security Controls
components could be used to allow enterprises to collect posture [critical-controls] includes security controls for a number of usage
attributes that demonstrate compliance with enterprise policy. scenarios, some of which are covered in this document. This section
Endpoints can be required to provide posture attributes, which may documents the alignment between the Center's controls and the
include identification attributes to enable persistent relevant elements of the scenario.
communications.
The SWID Message and Attributes for PA-TNC standard defines G.1.1. Continuous Vulnerability Assessment
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 "CSC 4: Continuous Vulnerability Assessment and Remediation," which
specify what posture attributes to collect as well as their expected is described by the Center for Internet Security as "Continuously
values which can be used to drive an assessment. 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:
The OVAL System Characteristics Model can be used to capture CSC 4.1 applies to this scenario in that it calls for running
information about an endpoint. The model is specifically suited to regular, automated scanning to deliver prioritized lists of
expressing OS information, endpoint identification information (such vulnerabilities with which to respond. The scenario described in
as IP and MAC addresses), and other endpoint metadata. 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.
I.2. Vulnerability Description Information This scenario assumes that the enterprise already has a source for
vulnerability description information as described in CSC 4.4.
The Common Vulnerability Reporting Framework (CVRF) is an XML-based Both CSC 4.2 and 4.7 are made possible by writing information to a
language that attempts to standardize the creation of vulnerability Repository since this makes previously collected data available for
description information. Using CVRF, the enterprise could create later analysis.
automated tools based on the standardized schema which would obtain
the needed and relevant information useful for later assessments and
assessment results.
I.3. Secondary Assessment While this scenario does not go into the details of how
prioritization would be calculated or applied, it does touch on some
of the important ways in which prioritization would impact the
endpoint assessment process in the Priority section. As such, the
Priority section aligns with CSC 4.8, which deals with vulnerability
priority. Vulnerability priority in this scenario is discussed in
terms of the vulnerability description information priority during
receipt, as well as the vulnerability priority with regards to
remedies.
Within the SACM Architecture, the assessment task would be handled by The described scenario does not address the details of applying a
the Evaluator component. If pre-assessment data is used, this would remedy based on assessment results. As such, CSC 4.5 which deals
be stored on and obtained from a Data Store component. with mitigations and patching, is out of scope for this work.
Similarly, CSC 4.3 prescribes performing scans in authenticated mode
and CSC 4.6 prescribes monitoring logs. This scenario does not get
into the means by which data is collected, focusing on "what" to
collect rather than "how", and as such does not have corresponding
sections, although the procedures described are not incompatible with
either of these controls.
Within the SACM Architecture, the Internal and External Collector The CSC 4 System Entity Relationship diagram directly aligns with the
components could be used to allow enterprises to collect posture scenario described in this document with the exception of applying
attributes that demonstrate compliance with enterprise policy. patches to endpoints.
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 G.1.2. Hardware and Software Inventories
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 This scenario is also aligned with, and describes a process for,
specify what posture attributes to collect as well as their expected collecting and maintaining hardware and software inventories, which
values which can be used to drive an assessment. are covered by the Center for Internet Security CSC 1 "Inventory of
Authorized and Unauthorized Devices" and CSC 2 "Inventory of
Authorized and Unauthorized Software." This scenario documents a
process that is specific to collecting and maintaining hardware and
software data attributes for vulnerability assessment purposes, but
the collection of the hardware attributes and software inventory
documented in the Endpoint Data Collection section that follows can
also be used for the purpose of implementing authorized and
unauthorized hardware and software management processes (e.g.,
scanning tools looking for unauthorized software). Moreover, the
ability to accurately identify endpoints and, to a lesser degree,
applications is integral to effective endpoint data collection and
vulnerability management.
The OVAL System Characteristics Model can be used to capture The Endpoint Data Collection section does not have coverage for the
information about an endpoint. The model is specifically suited to specific details described in CSC 1 and 2 as they are different
expressing OS information, endpoint identification information (such processes and would be out-of-scope of this scenario, but the section
as IP and MAC addresses), and other endpoint metadata. does provide the data necessary to support the controls.
The SACM Internal and External Attribute Collector components can be The Endpoint Identification and Endpoint Data Collection sections
used to allow enterprises to collect posture attributes that within this scenario align with CSC 1.1 and 1.4 by identifying
demonstrate compliance with enterprise policy. Endpoints can be enterprise endpoints and collecting their hardware and network
required to provide posture attributes, which may include attributes. The Endpoint Data Collection section aligns with and
identification attributes to enable persistent communications. supports CSC 2.3 by defining a software inventory process and a
method of obtaining operating system and file system attributes. The
rest of the items from CSC 1 and 2 deal with implementation details
and would be out-of-scope for this document.
I.4. Assessment Results Appendix H. Continuous Vulnerability Assessment
The OVAL Results Model provides a data model to encode the results of It is not sufficient to perform a single assessment when
the assessment, which could then be stored in a Repository and later vulnerability description information is published without any
accessed. The assessment results described in this scenario could be further checking. Doing so does not address the possibility that the
stored and later accessed using the OVAL Results Model. Note that reported vulnerability might be introduced to the enterprise
the use of the OVAL Results Model for sharing results is not environment after the initial assessment completes. For example, new
recommended per section 7.3 of the OVAL and the SACM Information endpoints can be introduced to the environment which have old
Model [draft-hansbury-sacm-oval-info-model-mapping-01]. 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.
Within the SACM Architecture, the generation of the assessment The scenario above describes a single assessment of endpoints.
results would occur in the Report Generator component. Those results However, it does not make any assumptions as to when this assessment
might then be moved to a Data Store component for later sharing and occurs relative to the original receipt of the vulnerability
retrieval as defined by SACM. 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 I. Data Attribute Table
The following table maps all major data attributes against each major
process where they are used.
+--------------+------------+-------------+-------------+-----------+
| | vulnerabil | Endpoint Id | Endpoint Ap | Assessmen |
| | ity descri | entificatio | plicability | t Results |
| | ption data | n and | and | |
| | | Initial | Assessment | |
| | | Data | | |
| | | Collection | | |
+--------------+------------+-------------+-------------+-----------+
| *Endpoint* | | | | |
+--------------+------------+-------------+-------------+-----------+
| Collection | | X | X | |
| date/time | | | | |
+--------------+------------+-------------+-------------+-----------+
| Endpoint | | X | X | |
| type | | | | |
+--------------+------------+-------------+-------------+-----------+
| Hardware ver | X | X | X | |
| sion/firmwar | | | | |
| e | | | | |
+--------------+------------+-------------+-------------+-----------+
| Operating | X | X | X | |
| system | | | | |
+--------------+------------+-------------+-------------+-----------+
| Operating | X | X | X | |
| system | | | | |
| attributes | | | | |
| (e.g., | | | | |
| version, | | | | |
| service pack | | | | |
| level, | | | | |
| edition, | | | | |
| etc.) | | | | |
+--------------+------------+-------------+-------------+-----------+
| Installed | X | X | X | X |
| software | | | | |
| name | | | | |
+--------------+------------+-------------+-------------+-----------+
| Installed | X | X | X | X |
| software | | | | |
| attributes | | | | |
| (e.g., | | | | |
| version, | | | | |
| patch level, | | | | |
| install | | | | |
| path, etc.) | | | | |
+--------------+------------+-------------+-------------+-----------+
| Open ports/s | X | X | X | |
| ervices | | | | |
+--------------+------------+-------------+-------------+-----------+
| Operating | X | X | X | |
| system | | | | |
| optional | | | | |
| component | | | | |
| inventory | | | | |
+--------------+------------+-------------+-------------+-----------+
| Location | | X | | X |
+--------------+------------+-------------+-------------+-----------+
| Purpose | | X | | X |
+--------------+------------+-------------+-------------+-----------+
| Criticality | | X | | X |
+--------------+------------+-------------+-------------+-----------+
| File system | X | | X | |
| attributes | | | | |
| (e.g., | | | | |
| versions, | | | | |
| size, write | | | | |
| date, | | | | |
| modified | | | | |
| date, | | | | |
| checksum, | | | | |
| etc.) | | | | |
+--------------+------------+-------------+-------------+-----------+
| Shared | X | | X | |
| libraries | | | | |
+--------------+------------+-------------+-------------+-----------+
| Other | X | | X | |
| software con | | | | |
| figuration | | | | |
| information | | | | |
+--------------+------------+-------------+-------------+-----------+
| *External vu | | | | |
| lnerability | | | | |
| description | | | | |
| data* | | | | |
+--------------+------------+-------------+-------------+-----------+
| Ingest Date | X | | X | |
+--------------+------------+-------------+-------------+-----------+
| Date of | X | | X | |
| Release | | | | |
+--------------+------------+-------------+-------------+-----------+
| Version | X | | X | |
+--------------+------------+-------------+-------------+-----------+
| External | X | | X | X |
| vuln ID | | | | |
+--------------+------------+-------------+-------------+-----------+
| Severity | | | | X |
| Score | | | | |
+--------------+------------+-------------+-------------+-----------+
| *Assessment | | | | |
| Results* | | | | |
+--------------+------------+-------------+-------------+-----------+
| Date of | | | X | X |
| assessment | | | | |
+--------------+------------+-------------+-------------+-----------+
| Date of data | | X | X | X |
| collection | | | | |
+--------------+------------+-------------+-------------+-----------+
| Endpoint ide | | X | X | X |
| ntification | | | | |
| and/or | | | | |
| locally | | | | |
| assigned ID | | | | |
+--------------+------------+-------------+-------------+-----------+
| Vulnerable | X | X | X | X |
| software | | | | |
| product(s) | | | | |
+--------------+------------+-------------+-------------+-----------+
| Endpoint vul | | | X | X |
| nerability | | | | |
| status | | | | |
+--------------+------------+-------------+-------------+-----------+
| Vulnerabilit | X | | | X |
| y | | | | |
| description | | | | |
+--------------+------------+-------------+-------------+-----------+
| Vulnerabilit | X | | | X |
| y | | | | |
| remediation | | | | |
+--------------+------------+-------------+-------------+-----------+
Table 1: Vulnerability Assessment Attributes
Authors' Addresses Authors' Addresses
Christopher Coffin Christopher Coffin
The MITRE Corporation The MITRE Corporation
202 Burlington Road 202 Burlington Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: ccoffin@mitre.org Email: ccoffin@mitre.org
 End of changes. 62 change blocks. 
440 lines changed or deleted 496 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/