SACM                                                           C. Coffin
Internet-Draft                                                B. Cheikes
Intended status: Informational                                C. Schmidt
Expires: December 10, 2016 January 8, 2017                                       D. Haynes
                                                   The MITRE Corporation
                                                     J. Fitzgerald-McKay
                                                   Department of Defense
                                                           D. Waltermire
                          National Institute of Standards and Technology
                                                            June 8,
                                                            July 7, 2016

                 SACM Vulnerability Assessment Scenario
                    draft-ietf-sacm-vuln-scenario-00
                    draft-ietf-sacm-vuln-scenario-01

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 on 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. January 8, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Scope . . . .  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   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
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   7   8
     A.1.  Changes Since Adopted as a WG I-D -00 in Revision -01 . . . . . . . . . .   7
     A.2.  Changes in Revision draft-coffin-sacm-vuln-scenario-01 .   8
   Appendix B.  Continuous Vulnerability Assessment . . . . . .   8
     A.2.  Changes Since Adopted as a WG I-D -00 . .  10
   Appendix C.  Priority . . . . . . . .   9
     A.3.  Changes in Revision draft-coffin-sacm-vuln-scenario-01  .   9
   Appendix B.  Implementation Examples  . . . . . . . . . . . . . .  10
   Appendix D.  11
     B.1.  Endpoint Data Attribute Table Collection  . . . . . . . . . . . . . . . .  11
     D.1.  Table
     B.2.  Vulnerability Description Information . . . . . . . . . .  12
     B.3.  Secondary Assessment  . . . . . . . . . . . . . . . .  11
   Appendix E.  Alignment with Other Existing Works . .  12
     B.4.  Assessment Results  . . . . . .  14
     E.1.  Critical Security Controls . . . . . . . . . . . . .  12
   Appendix C.  Priority . .  14
       E.1.1.  Continuous Vulnerability Assessment . . . . . . . . .  14
       E.1.2.  Hardware and Software Inventories . . . . . . . . . .  16 .  13
   Appendix F. D.  SACM Usage Scenarios . . . . . . . . . . . . . . . .  16  14
   Appendix G. E.  SACM Requirements and Charter - Future Work  . . . .  18  15
   Appendix H. F.  SACM Use Case Alignment  . . . . . . . . . . . . . .  18
     H.1.  16
     F.1.  Endpoint Identification . . . . . . . . . . . . . . . . .  18
     H.2.  16
     F.2.  Endpoint Data Collection  . . . . . . . . . . . . . . . .  19
     H.3.  16
     F.3.  Vulnerability Description Information . . . . . . . . . .  19
     H.4.  17
     F.4.  Applicability . . . . . . . . . . . . . . . . . . . . . .  19
     H.5.  17
     F.5.  Secondary Assessment  . . . . . . . . . . . . . . . . . .  19
     H.6.  17
     F.6.  Assessment Results  . . . . . . . . . . . . . . . . . . .  20  17
   Appendix I.  Implementation Examples  . . . . . . . G.  Alignment with Other Existing Works  . . . . . . .  20
     I.1.  Endpoint Data Collection .  17
     G.1.  Critical Security Controls  . . . . . . . . . . . . . . .  20
     I.2.  17
       G.1.1.  Continuous Vulnerability Description Information . . . . Assessment . . . . . .  20
     I.3.  Secondary Assessment . . .  18
       G.1.2.  Hardware and Software Inventories . . . . . . . . . .  19
   Appendix H.  Continuous Vulnerability Assessment  . . . . .  21
     I.4.  Assessment Results . . .  19
   Appendix I.  Data Attribute Table . . . . . . . . . . . . . . . .  21  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22  23

1.  Scope  Introduction

   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. assessment (see Appendix B for examples of solutions
   that support this scenario).

   Vulnerability discovery, disclosure, publication, and
   publication 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

   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.).

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
      through the execution of Target Endpoint Discovery Tasks 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. assessment (see Appendix H for more
      information).

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, management via Collection Tasks
   and to establish an endpoint's identity within the scope of that
   domain.  Endpoint identity can be established by collecting certain attributes (as part
   of
   identifying attributes, collectively known as the minimum set of attributes) Target Endpoint
   Identifier, that allow for unique and persistent tracking of
   endpoints on the enterprise network.  Examples include, but are not
   limited to, IP address, MAC address, Fully Qualified Domain Names
   (FQDNs), pre-provisioned identifiers such as Globally Unique
   Identifiers (GUIDs) or copies of serial numbers, certificates,
   hardware identity values, or similar attributes.  To simplify the
   identification of an endpoint, a Target Endpoint Label may be created
   and assigned to refer to the Target Endpoint Identifier.  All of the
   information collected by the endpoint management capability is
   stored, with appropriate metadata (i.e. timestamp), in a central
   location.
   location and used to build up a Target Endpoint Characterization
   Record and Target Endpoint Profile via a Target Endpoint
   Characterization Task.  The endpoint management capability is
   expected to be performed on an ongoing basis, resulting in routine,
   or even event-
   driven, event-driven, collection of basic endpoint information.

   See "Data Attribute Tables and Definitions" Appendix I 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" Appendix I 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. examined by the vulnerability management capability
      through Evaluation Tasks.

   o  If the data possessed by the endpoint management capability is
      insufficient, then a Collection Task is triggered and the necessary
      data is collected from the target endpoint.

   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 Collection Task will be necessary.
   triggered to collect it from the target endpoint.  Of course, an
   implementation of an endpoint management capability may prefer to
   enable operators to perform
   supplemental this 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

   The collection of additional 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  Over time, some new pieces
   of information beyond that which is available in the are needed during common types of assessments
   might be identified.  An endpoint management capability can be pushed
   reconfigured to have this information delivered automatically.  This
   avoids the need to trigger additional Collection Tasks to gather this
   information during assessments, streamlining the vulnerability assessment capability 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 whenever that management capability to
   no longer collect this information changes.

   See "Data Attribute Tables to reduce network and Definitions" processing
   overhead.  Instead, a new Collection Task can be triggered to gather
   this data on the rare occasions when it is needed.

   See Appendix I 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" Appendix I for information-specific details.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   This document provides a core narrative that walks through an
   automated enterprise vulnerability assessment scenario and is aligned
   with SACM "Endpoint Security Posture Assessment: Enterprise Use
   Cases" [RFC7632].  As a result, the security considerations for
   [RFC7632] apply to this document.  Furthermore, the data collected as
   part of the vulnerability
   description information assessment may provide attackers with
   useful information such as what software an enterprise is running on
   their endpoints.  As a result, organizations should consider properly protect the vulnerability
   description data it ingests.
   protecting this information.

9.  Informative References

   [charter-ietf-sacm-01]
              Security Automation and Continuous Monitoring, "Charter,
              Version 1.0", July 2013. October 2015,
              <https://datatracker.ietf.org/doc/charter-ietf-sacm/>.

   [critical-controls]
              Council on CyberSecurity,
              Center for Internet Security, "Critical Security Controls,
              Version 5.1".

   [draft-hansbury-sacm-oval-info-model-mapping-01] 6.0", <https://www.cisecurity.org/critical-
              controls.cfm>.

   [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
              the SACM Information Model", November 2015. 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]
              Cam-Winget, N. and L. Lorenzin, "Security Automation and
              Continuous Monitoring (SACM) Requirements", draft-ietf-
              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
              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 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
   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).

   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.

A.3.  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.

   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.

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  Implementation Examples

B.1.  Endpoint Data Collection

   Within the possibility that SACM Architecture, the
   reported vulnerability might Internal and External Collector
   components could be introduced used to the allow enterprises to collect posture
   attributes that demonstrate compliance with enterprise
   environment after the initial assessment completes.  For example, new
   endpoints policy.
   Endpoints can be introduced required to the environment provide posture attributes, which have old
   software or are not up-to-date with patches.  Another example is
   where unauthorized or obsolete may
   include identification attributes to enable persistent
   communications.

   The SWID Message and Attributes for PA-TNC standard
   [I-D.coffin-sacm-nea-swid-patnc] defines collection and validation of
   software is identities using the ISO Software Identification Tag
   Standard.  Using this standard, the identity of all installed on an existing
   software including the endpoint by enterprise users after vulnerability description
   information operating system, could be collected
   and initial assessment has taken place.  Moreover,
   enterprises might not wish to, or used for later assessment.

   The OVAL Definitions Model [I-D.haynes-sacm-oval-definitions-model]
   provides a data model that can 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 used to specify what posture
   attributes to collect as
   "low priority", are not well as their expected values which can be
   used to guide enterprise assessments until
   sometime after the initial receipt. drive an assessment.

   The scenario above describes a single assessment of endpoints.
   However, it does not make any assumptions as OVAL System Characteristics Model
   [I-D.rothenberg-sacm-oval-sys-char-model] can be used to when this assessment
   occurs relative capture
   information about an endpoint.  The model is specifically suited to the original receipt of the vulnerability
   description data
   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 led attempts to this assessment.  The assessment could
   immediately follow standardize the ingestion creation of the
   vulnerability description
   information, information.  Using CVRF, the enterprise
   could be delayed, or create automated tools based on the assessment might represent a
   reassessment of some vulnerability description information against standardized schema which endpoints had previously been assessed.  Moreover,
   would obtain the scenario
   incorporates long-term storage of collected data, vulnerability
   description information, needed and assessment results in order to
   facilitate meaningful relevant information useful for later
   assessments and ongoing reassessment.

Appendix C.  Priority

   Priorities associated with assessment results.

B.3.  Secondary Assessment

   Within the SACM Architecture, the vulnerability description information, assessment results, and any remedy is important, but task would be handled by
   the Evaluator component.  If previously collected data is treated as used, it
   would be obtained from a
   separate challenge and, as such, has not been integrated into Data Store component.

   Within the
   description of this scenario.  Nevertheless, it is important to point
   out and describe the use of priorities in SACM Architecture, the overall vulnerability
   assessment scenario as a separate issue with its own sets of
   requirements.

   Priority in regard Internal and External Collector
   components could be used to vulnerability description information, allow enterprises to collect posture
   attributes that demonstrate compliance with enterprise policy.
   Endpoints can be
   viewed in a couple of different ways within an enterprise. required to provide posture attributes, which may
   include identification attributes to enable persistent
   communications.

   The
   assessment prioritization involves prioritization SWID Message and Attributes for PA-TNC standard defines
   collection and validation of software identities using 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 ISO
   Software Identification Tag Standard.  Using this standard, all
   installed software including the endpoint operating system or application used throughout the
   enterprise would likely could be prioritized higher than
   collected and stored for later assessment.

   The OVAL Definitions Model provides a vulnerability in
   an application which is data model that can be 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
   specify what posture attributes to focus collect as well as their
   efforts to apply appropriate remedies.  For example, a vulnerability
   that is easily exploitable and expected
   values which can allow arbitrary code
   execution might be remedied before a vulnerability that is more
   difficult used to exploit or which just degrades performance.

   Some vulnerability description information include severities and/or
   other drive an assessment.

   The OVAL System Characteristics Model can be used to capture
   information that places the vulnerability in context.  This 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 in both of the priority types discussed
   above.  In other cases, to allow enterprises to collect posture attributes that
   demonstrate compliance with enterprise administrators policy.  Endpoints can be
   required to provide posture attributes, which may need include
   identification attributes to
   prioritize based only on what they know about their enterprise and
   the description provided in the vulnerability description
   information.

   Examples of enable persistent communications.

B.4.  Assessment Results

   The OVAL Results Model [I-D.cokus-sacm-oval-results-model] provides a
   data attributes specific model to priority of assessments and/
   or remedies include (but not limited to) the following:

   o  Enterprise - defined purpose of encode the device, criticality results of the
      device, exposure of 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 device, etc.

   o  Severity attributes - A rating or score OVAL Results Model.  Note 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 use of
      compromise, incidents, courses the OVAL Results Model
   for sharing results is not recommended per section 7.3 of action, etc. that help the
      enterprise understand relevant threats OVAL
   and how to detect,
      mitigate, or respond 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 them.

Appendix D. a Data Attribute Table

D.1.  Table Store component for later sharing and
   retrieval as defined by SACM.

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 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 |
   assessment prioritization involves prioritization of the
   vulnerability description information assessment process.  This
   determines what vulnerability description information is assessed,
   and Initial  | in what order it is assessed in.  For instance, a vulnerability
   affecting an operating system or application used throughout the
   enterprise would likely be prioritized higher than a vulnerability in
   an application which is used only on a few, low-criticality
   endpoints.

   The prioritization of remedies relates to the enterprise remediation
   and     | 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 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 number of use
   scenarios, some of vulnerability
   that is easily exploitable and which are covered 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 this document. context.  This section
   documents the alignment between
   information can be used in both of the Council's controls priority types discussed
   above.  In other cases, enterprise administrators may need to
   prioritize based only on what they know about their enterprise and
   the
   relevant elements 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 scenario.

E.1.1.  Continuous Vulnerability Assessment

   "CSC 4: Continuous Vulnerability Assessment and Remediation," which
   is described by following:

   o  Enterprise - defined purpose of the Council on CyberSecurity as "Continuously
   acquire, assess, and take action on new information in order device, criticality of the
      device, exposure of the device, etc.

   o  Severity attributes - A rating or score that attempts to
   identify vulnerabilities, remediate, and minimize provide
      the window level of
   opportunity for attackers." 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.  SACM Usage Scenarios

   The scenario described in this SACM "Endpoint Security Posture Assessment: Enterprise Use Cases"
   document
   is aligned with CSC 4 in ([RFC7632]) defines multiple ways:

   CSC 4-1 applies to this scenario in usage scenarios that it calls for running
   regular, automated scanning are meant
   to deliver prioritized lists provide examples of
   vulnerabilities with which to respond.  The scenario described in
   this document implementing the use cases and building block
   capabilities.  Below is intended to be executed on a continuous basis, and
   the priorities brief summary of both vulnerability description information and the
   remedy some of vulnerabilities are discussed in the Priority section
   earlier in these usage
   scenarios and how this document.

   This scenario assumes that document aligns and/or adds additional value
   to the identified usage scenarios.

   o  Automated Checklist Verification (2.2.2) - "An enterprise already has operates
      a source heterogeneous IT environment.  They utilize vendor-provided
      automatable security configuration checklists for
   vulnerability description information as described in CSC 4-4.

   Both CSC 4-2 each operating
      system and 4-7 application used within their IT environment.  Multiple
      checklists are made possible by writing information used from different vendors 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 ensure adequate
      coverage of the important ways in which prioritization would impact the
   endpoint assessment process all IT assets."  The usage scenario, as defined in the Priority section.  As such,
      RFC, is targeted at the
   Priority section aligns with CSC 4-10, which deals with vulnerability
   priority.  Vulnerability priority in this scenario checklist level and can be interpreted as
      being specific to endpoint configuration.  There is discussed in
   terms mention of the
      patch assessment and vulnerability description information priority during
   receipt, as well as mitigation, but the vulnerability priority with regards to
   remedies.

   The described usage
      scenario does not address could be expanded upon by including vulnerability
      verification.  Replacing the details idea 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 checklist in
   authenticated mode and CSC 4-6 prescribes monitoring logs.  This the SACM usage
      scenario does not get into with vulnerability would allow the means by which data is collected,
   focusing on "what" usage scenario 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 almost exactly with the scenario described in this document with the
   exception document.
      Instead of step 7 (patch response).  Steps 1 -6 in CSC 4 describe
   the overall process for vulnerability management starting with
   obtaining collecting automatable security configuration
      checklists, the enterprise would collect automatable vulnerability
      description information available from the source
   in Step 1, 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 producing assessment results 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 Step 6.

E.1.2.  Hardware and Software Inventories

   This scenario the baseline, updated posture
      information is also aligned with, and describes a process for,
   collecting and maintaining hardware and software inventories, which
   are covered by exchanged.  When the Council on CyberSecurity CSC 1 "Inventory of
   Authorized and Unauthorized Devices" and CSC 2 "Inventory of
   Authorized and Unauthorized Software."  This scenario documents endpoint detects a
   process that posture
      change, an alert is generated identifying the specific to collecting and maintaining hardware and
   software data attributes for vulnerability assessment purposes, but changes in
      posture."  This usage scenario would support the collection concept of
      endpoints signaling or alerting the hardware attributes and software inventory
   documented enterprise to changes in the Endpoint Data Collection section
      posture relates to endpoint vulnerabilities in the same way that follows can
   also be used
      it would for configurations.  Replacing the purpose idea 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 checklist
      with vulnerability description data collection allows the SACM usage scenario
      and
   vulnerability management.

   The Endpoint Data Collection section does not have coverage for the
   specific details scenario described in CSC 1 and 2 as they are different
   processes and would be out-of-scope of this scenario, but 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 section
   does provide 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 data necessary to support university,
      the controls.

   The Endpoint Identification government, and Endpoint Data Collection sections
   within this the provider of the satellite network, as well
      as keep current on vulnerability testing."  This SACM usage
      scenario align with CSC 1-1 and 1-4 by identifying
   enterprise endpoints and collecting their hardware describes vulnerability assessment and network
   attributes.  The Endpoint Data Collection section aligns well with
      the vulnerability scenario described in this document.  The
      endpoint assets are identified and
   supports CSC 2-3 and 2-4 by defining associated data is published in
      a software inventory process Repository.  Vulnerability description information is collected
      and saved in a method of obtaining operating system and file system attributes. Repository as it is released.  The rest of vulnerability
      description information is queued for later assessment, then the items from CSC 1 and 2 deal with implementation
   details
      assessment results and would be out-of-scope for vulnerability description information are
      stored after assessment.  The only real difference in this document.

   CSC 2-9 describes SACM
      usage scenario is the use timing 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 assessments.  The scenario
      described in within this scenario. document would have no problems adjusting to
      the timing of this SACM usage scenario or anything similar.

Appendix F. E.  SACM Usage Scenarios 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 "Endpoint Security Posture Assessment: Enterprise Use Cases"
   document Cases ([RFC7632]) defines multiple usage scenarios documents and
   represent work that are meant
   to provide examples may be necessary to support the tasks or goals of implementing
   SACM going forward.

   o  The SACM requirements mentions "Result Reporting" with
      applications but no detail around what the use cases and building block
   capabilities.  Below assessment results data
      set should include.  In the case of vulnerability assessment
      results, context is important and details beyond just a brief summary Pass or
      Fail result are needed in order to take action.  A good example of some
      this might be the Priority of these usage
   scenarios the vulnerability itself and how
      many systems it affects within the enterprise.  With this document aligns and/or adds additional value in mind,
      it might be worthwhile to the identified usage scenarios.

   o  Automated Checklist Verification (2.2.2) - "An enterprise operates investigate a heterogeneous IT environment.  They utilize vendor-provided
      automatable security configuration checklists minimum data set or schema
      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." assessment results.  The usage scenario, concern here is with vulnerability
      description data, but this could apply to other enterprise
      processes as defined well.

   o  The "Human-assigned endpoint attributes" mentioned previously in
      this scenario are touched on in the
      RFC, is targeted at SACM use cases, but the checklist level topic
      could probably be explored in much more depth.  Enterprise policy
      and can behaviors could be interpreted greatly influenced by endpoint attributes
      such as
      being specific to locations, how the endpoint configuration.  There is mention of
      patch assessment used, and vulnerability mitigation, but criticality.
      When and how these data attributes are collected, as well as what
      the usage
      scenario could minimum or common set might look like, would be expanded upon by including vulnerability
      verification.  Replacing good topics
      for future related SACM work.  In addition, the idea storage of a checklist these
      attributes could be central (stored in a data repository) or they
      could be assigned and stored on the endpoints themselves.

Appendix F.  SACM usage
      scenario Use Case Alignment

F.1.  Endpoint Identification

   This sub-step aligns with vulnerability would allow the usage scenario Endpoint Discovery, Endpoint
   Characterization, and Endpoint Target Identification building block
   capabilities.  The alignment is due 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 fact that the vendor as described or
      possibly from other interested third-parties.

   o  Detection purpose of Posture Deviations (2.2.3) - "An
   this sub-step is to discover, identify, and characterize all
   endpoints on an enterprise has
      established secure configuration baselines for each different type network.

F.2.  Endpoint Data Collection

   This sub-step aligns with the Data Publication building block
   capability because this section involves storage of endpoint
   attributes within their IT environment.  When an endpoint
      connects to the network, the appropriate baseline configuration is
      communicated to the endpoint.  Once enterprise Repository.  This sub-step also
   aligns with the baseline has been
      established, Endpoint Characterization and Endpoint Target
   Identification building block capabilities because it further
   characterizes the endpoint through automated and possibly manual
   means.  There is monitored for any change events
      pertaining to direct alignment with the baseline on an ongoing basis.  When a change
      occurs to posture defined in Endpoint Component
   Inventory, Posture Attribute Identification, and Posture Attribute
   Value Collection building block capabilities since the baseline, updated posture
      information purpose of
   this sub-step is exchanged.  When to perform an initial inventory of the endpoint detects a posture
      change, an alert and
   collect basic attributes and their values.  Last, there is generated identifying alignment
   with the specific changes in
      posture."  This usage scenario would support Collection Guidance Acquisition building block capabilities
   as the concept inventory and collection of
      endpoints signaling or alerting the enterprise to changes in the
      posture relates to endpoint vulnerabilities in the same way that
      it attributes would for configurations.  Replacing the idea be
   directed by some type of a checklist enterprise or third-party guidance.

F.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 data allows the SACM usage scenario information within an enterprise Repository
   and later retrieval of the scenario described same.

F.4.  Applicability

   This sub-step aligns with the Data Retrieval, Data Query, and Posture
   Attribute Value Query building block capabilities because, 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
   sub-step, 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 process is attempting to show
      continued compliance with determine the security policies vulnerability
   status of the university, endpoint using the government, and data that has previously been
   collected.

F.5.  Secondary Assessment

   This sub-step aligns with the provider 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 satellite network, as well
      as keep current on vulnerability testing."  This SACM usage
      scenario describes vulnerability assessment and description information (guidance) drives the
   collection of additional endpoint attributes.

   This sub-step aligns well with the vulnerability scenario described in this document.  The
      endpoint assets are identified Endpoint Characterization (both manual
   and associated data is published in
      a Repository.  Vulnerability description information is collected automated) and saved in a Repository as Endpoint Target Identification building block
   capabilities because it is released.  The vulnerability
      description information is queued for later assessment, then could further characterize the
      assessment results endpoint
   through automated and vulnerability description information are
      stored after assessment.  The only real difference in this SACM
      usage scenario possibly manual means.  There is direct
   alignment with 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 Endpoint Component Inventory, Posture Attribute
   Identification, and Charter - Future Work

   In Posture Attribute Value Collection building block
   capabilities since the course authoring purpose of this document, some sub-step is to perform
   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 more specific component inventories and
   represent work that may be necessary to support the tasks or goals collections of
   SACM going forward.

   o  The SACM requirements mentions "Result Reporting"
   endpoint attributes and their values.

F.6.  Assessment Results

   This step aligns with
      applications but no detail around what the assessment results data
      set should include.  In the case Data Publication and Data Retrieval
   building block capabilities because this section details storage of
   vulnerability assessment
      results, context is important assessment results within an enterprise Repository and details beyond just
   later retrieval of the same.

Appendix G.  Alignment with Other Existing Works

G.1.  Critical Security Controls

   The Center for Internet Security's Critical Security Controls
   [critical-controls] includes security controls for a Pass or
      Fail result number of usage
   scenarios, some of which are needed covered in order to take action.  A good example of this might be document.  This section
   documents the Priority alignment between the Center's controls and the
   relevant elements of the vulnerability itself scenario.

G.1.1.  Continuous Vulnerability Assessment

   "CSC 4: Continuous Vulnerability Assessment and how
      many systems it affects within Remediation," which
   is described by the enterprise.  With this Center for Internet Security as "Continuously
   acquire, assess, and take action on new information in mind,
      it might be worthwhile order to investigate a minimum data set or schema
   identify vulnerabilities, remediate, and minimize the window of
   opportunity for assessment results. attackers."  The concern here scenario described in this document
   is aligned with vulnerability
      description data, but CSC 4 in multiple ways:

   CSC 4.1 applies to this could apply scenario in that it calls for running
   regular, automated scanning to other enterprise
      processes as well.

   o deliver prioritized lists of
   vulnerabilities with which to respond.  The "Human-assigned endpoint attributes" mentioned previously scenario described in
   this scenario are touched document is intended to be executed on in a continuous basis, and
   the SACM use cases, but priorities of both vulnerability description information and the topic
      could probably be explored
   remedy of vulnerabilities are discussed in much more depth.  Enterprise policy
      and behaviors could be greatly influenced by endpoint attributes
      such the Priority section
   earlier in this document.

   This scenario assumes that the enterprise already has a source for
   vulnerability description information as locations, how the endpoint is used, and criticality.
      When described in CSC 4.4.

   Both CSC 4.2 and how these data attributes 4.7 are collected, as well as what
      the minimum or common set might look like, would be good topics made possible by writing information to a
   Repository since this makes previously collected data available for future related SACM work.  In addition,
   later analysis.

   While this scenario does not go into the storage details of these
      attributes could how
   prioritization would be central (stored in a data repository) calculated or they
      could be assigned and stored applied, it does touch on some
   of the endpoints themselves.

Appendix H.  SACM Use Case Alignment

H.1.  Endpoint Identification

   This sub-step aligns with important ways in which prioritization would impact the Endpoint Discovery, Endpoint
   Characterization, and Endpoint Target Identification building block
   capabilities.  The alignment is due to
   endpoint assessment process in the fact that Priority section.  As such, the purpose of
   this sub-step is to discover, identify, and characterize all
   endpoints on an enterprise network.

H.2.  Endpoint Data Collection

   This sub-step
   Priority section aligns with the Data Publication building block
   capability because CSC 4.8, which deals with vulnerability
   priority.  Vulnerability priority in this section involves storage scenario is discussed in
   terms 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 vulnerability description information priority during
   receipt, as well as the endpoint through automated and possibly manual
   means.  There is direct alignment vulnerability priority with regards to
   remedies.

   The described scenario does not address the details of applying a
   remedy based on assessment results.  As such, CSC 4.5 which deals
   with the Endpoint Component
   Inventory, Posture Attribute Identification, mitigations and Posture Attribute
   Value Collection building block capabilities since the purpose patching, is out of scope for this sub-step 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 perform an initial inventory of the endpoint and
   collect basic attributes rather than "how", and their values.  Last, there is alignment
   with the Collection Guidance Acquisition building block capabilities as such does not have corresponding
   sections, although the inventory and collection of endpoint attributes would be
   directed by some type procedures described are not incompatible with
   either of enterprise or third-party guidance.

H.3.  Vulnerability Description Information

   This step these controls.

   The CSC 4 System Entity Relationship diagram directly aligns with the Data Publication and Data Retrieval
   building block capabilities because
   scenario described in this section details storage document with the exception of
   vulnerability description information within an enterprise Repository applying
   patches to endpoints.

G.1.2.  Hardware and later retrieval of the same.

H.4.  Applicability Software Inventories

   This sub-step aligns with the Data Retrieval, Data Query, scenario is also aligned with, and Posture
   Attribute Value Query building block capabilities because, in this
   sub-step, the describes a process is attempting to determine for,
   collecting and maintaining hardware and software inventories, which
   are covered by the vulnerability
   status Center for Internet Security CSC 1 "Inventory 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
   Authorized and Unauthorized Devices" and CSC 2 "Inventory of endpoint
   Authorized and Unauthorized Software."  This scenario documents a
   process that is specific to collecting and maintaining hardware and
   software data attributes within an enterprise Repository.  The sub-step also aligns
   with the Collection Guidance Acquisition building block capability
   since the for vulnerability description information (guidance) drives assessment purposes, but
   the collection of additional endpoint attributes.

   This sub-step aligns with the hardware attributes and software inventory
   documented in the Endpoint Characterization (both manual Data Collection section that follows can
   also be used for the purpose of implementing authorized and automated)
   unauthorized hardware and Endpoint Target Identification building block
   capabilities because it could further characterize 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
   through automated data collection and possibly manual means.  There is direct
   alignment with the
   vulnerability management.

   The Endpoint Component Inventory, Posture Attribute
   Identification, and Posture Attribute Value Data Collection building block
   capabilities since section does not have coverage for the purpose
   specific details described in CSC 1 and 2 as they are different
   processes and would be out-of-scope of this sub-step is scenario, but the section
   does provide the data necessary to perform
   additional support the controls.

   The Endpoint Identification and more specific component inventories Endpoint Data Collection sections
   within this scenario align with CSC 1.1 and collections of
   endpoint attributes 1.4 by identifying
   enterprise endpoints and collecting their values.

H.6.  Assessment Results

   This step aligns with the Data Publication hardware and network
   attributes.  The Endpoint Data Retrieval
   building block capabilities because this Collection section details storage of
   vulnerability assessment results within an enterprise Repository aligns with and
   supports CSC 2.3 by defining a software inventory process and
   later retrieval a
   method of obtaining operating system and file system attributes.  The
   rest of the same. items from CSC 1 and 2 deal with implementation details
   and would be out-of-scope for this document.

Appendix I.  Implementation Examples

I.1.  Endpoint Data Collection

   Within H.  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 SACM Architecture, possibility that the Internal and External Collector
   components could
   reported vulnerability might be used to allow enterprises introduced to collect posture
   attributes that demonstrate compliance with the enterprise policy.
   Endpoints
   environment after the initial assessment completes.  For example, new
   endpoints can be required introduced to provide posture attributes, the environment which may
   include identification attributes to enable persistent
   communications.

   The SWID Message and Attributes for PA-TNC standard defines
   collection and validation of have old
   software identities using the ISO
   Software Identification Tag Standard.  Using this standard, the
   identity of all installed or are not up-to-date with patches.  Another example is
   where unauthorized or obsolete software including the is installed on an existing
   endpoint operating
   system, could be collected by enterprise users after vulnerability description
   information 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 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 drive an assessment. guide enterprise assessments until
   sometime after the initial receipt.

   The OVAL System Characteristics Model can be used scenario above describes a single assessment of endpoints.
   However, it does not make any assumptions as to capture
   information about an endpoint.  The model is specifically suited when this assessment
   occurs relative 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 the original receipt of the vulnerability
   description data that attempts led to standardize this assessment.  The assessment could
   immediately follow the creation ingestion of the vulnerability description information.  Using CVRF, the enterprise
   information, could create
   automated tools based on be delayed, or the standardized schema assessment might represent a
   reassessment of some vulnerability description information against
   which would obtain endpoints had previously been assessed.  Moreover, the needed and relevant information useful for later assessments scenario
   incorporates long-term storage of collected data, vulnerability
   description information, and assessment results.

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 results in order to
   facilitate meaningful and obtained from a ongoing reassessment.

Appendix I.  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. Attribute Table

   The SWID Message 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 Attributes for PA-TNC standard defines
   collection    |     and validation of     |           |
   |              |            |   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 identities using the ISO
   Software Identification Tag Standard.  Using this standard, all
   installed   |            |             |             |           |
   |     name     |            |             |             |           |
   +--------------+------------+-------------+-------------+-----------+
   |  Installed   |     X      |      X      |      X      |     X     |
   |   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  |            |             |             |           |
   |    (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 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  |            |             |             |           |
   |    (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 the OVAL and the SACM Information
   Model [draft-hansbury-sacm-oval-info-model-mapping-01].

   Within the SACM Architecture, the generation    |     X      |             |      X      |           |
   |   Release    |            |             |             |           |
   +--------------+------------+-------------+-------------+-----------+
   |   Version    |     X      |             |      X      |           |
   +--------------+------------+-------------+-------------+-----------+
   |   External   |     X      |             |      X      |     X     |
   |   vuln ID    |            |             |             |           |
   +--------------+------------+-------------+-------------+-----------+
   |   Severity   |            |             |             |     X     |
   |    Score     |            |             |             |           |
   +--------------+------------+-------------+-------------+-----------+
   | *Assessment  |            |             |             |           |
   |   Results*   |            |             |             |           |
   +--------------+------------+-------------+-------------+-----------+
   |   Date of the    |            |             |      X      |     X     |
   |  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.  |            |             |             |           |
   +--------------+------------+-------------+-------------+-----------+
   | 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

   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

   David Waltermire
   National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, Maryland  20877
   USA

   Email: david.waltermire@nist.gov