draft-ietf-sacm-vuln-scenario.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC7632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7632.xml">
<!ENTITY I-D.ietf-sacm-requirements SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-requirements.xml">
<!ENTITY I-D.coffin-sacm-nea-swid-patnc SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-coffin-sacm-nea-swid-patnc-01.xml">

<!ENTITY I-D.haynes-sacm-oval-definitions-model SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-haynes-sacm-oval-definitions-model-01.xml">
<!ENTITY I-D.rothenberg-sacm-oval-sys-char-model SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-rothenberg-sacm-oval-sys-char-model-01.xml">
<!ENTITY I-D.cokus-sacm-oval-results-model SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-cokus-sacm-oval-results-model-01.xml">
<!ENTITY I-D.hansbury-sacm-oval-info-model-mapping SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-hansbury-sacm-oval-info-model-mapping-03.xml">

<!ENTITY critical-controls SYSTEM "http://www.counciloncybersecurity.org/critical-controls/">
<!ENTITY charter-ietf-sacm-01 SYSTEM "https://datatracker.ietf.org/doc/charter-ietf-sacm/">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-sacm-vuln-scenario-02"
  ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="SACM Vuln Scenario">SACM Vulnerability Assessment
      Scenario</title>

    <!-- Another author who claims to be an editor -->
    <author fullname="Christopher Coffin" initials="C.C."
      surname="Coffin">
      <organization>The MITRE Corporation</organization>
      <address>
        <postal>
          <street>202 Burlington Road</street>
          <!-- Reorder these if your country does things differently -->
          <city>Bedford</city>
          <region>MA</region>
          <code>01730</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>ccoffin@mitre.org</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <!-- Another author who claims to be an editor -->
    <author fullname="Brant Cheikes" initials="B.C." surname="Cheikes">
      <organization>The MITRE Corporation</organization>
      <address>
        <postal>
          <street>202 Burlington Road</street>
          <!-- Reorder these if your country does things differently -->
          <city>Bedford</city>
          <region>MA</region>
          <code>01730</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>bcheikes@mitre.org</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <!-- Another author who claims to be an editor -->
    <author fullname="Charles Schmidt" initials="C.S."
      surname="Schmidt">
      <organization>The MITRE Corporation</organization>
      <address>
        <postal>
          <street>202 Burlington Road</street>
          <!-- Reorder these if your country does things differently -->
          <city>Bedford</city>
          <region>MA</region>
          <code>01730</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>cmschmidt@mitre.org</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Daniel Haynes" initials="D.H." surname="Haynes">
      <organization>The MITRE Corporation</organization>
      <address>
        <postal>
          <street>202 Burlington Road</street>
          <!-- Reorder these if your country does things differently -->
          <city>Bedford</city>
          <region>MA</region>
          <code>01730</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>dhaynes@mitre.org</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Jessica Fitzgerald-McKay" initials="J.M."
      surname="Fitzgerald-McKay">
      <organization>Department of Defense</organization>
      <address>
        <postal>
          <street>9800 Savage Road</street>
          <city>Ft. Meade</city>
          <region>Maryland</region>
          <country>USA</country>
        </postal>
        <email>jmfitz2@nsa.gov</email>
      </address>
    </author>

    <author fullname="David Waltermire" initials="D.W."
      surname="Waltermire">
      <organization>National Institute of Standards and
        Technology</organization>
      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>Maryland</region>
          <code>20877</code>
          <country>USA</country>
        </postal>
        <email>david.waltermire@nist.gov</email>
      </address>
    </author>

    <date month="September" year="2016"/>

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>SACM</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>todo</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document describes an automated enterprise vulnerability
        assessment scenario aligned with the SACM Use Cases. The
        scenario assumes the existence of endpoint management
        capabilities 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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes a detailed, enterprise-specific
        vulnerability assessment scenario from which information model
        elements can be discovered. This scenario
        also informs protocol and data model development in support of
        vulnerability assessment, as part of overall posture
        assessment (see <xref target="implementation-examples"/> for 
        examples of solutions that support this scenario).</t> 
      <t>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
        <xref target="priority"/>.</t>
      <t>Information on how the scenario aligns with SACM and other existing
        work is discussed in <xref target="sacm-usage-scenarios"/> through 
        <xref target="alignment-with-other-existing-works"/>.</t>
    </section>
    <section title="Terminology">
      <t>
        <list style="hanging" hangIndent="6">
          <t hangText="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.</t>
          <t hangText="Vulnerability detection data:">A type of
            guidance extracted or derived from vulnerability description
            information that describes the specific mechanisms of
            vulnerability detection that is used by an enterprise's
            vulnerability management capabilities to determine if a
            vulnerability is present on an endpoint.</t>
          <t hangText="Endpoint management capabilities:">An enterprise
            IT department's ability to manage endpoint identity, endpoint
            information, and associated metadata on an ongoing
            basis.</t>
          <t hangText="Vulnerability management capabilities:">An
            enterprise IT department's ability to manage endpoint vulnerabilities
            and associated metadata on an ongoing basis by ingesting
            vulnerability description information and vulnerability
            detection data, and performing vulnerability
            assessments.</t>
          <t hangText="Vulnerability assessment capabilities:">An 
            enterprise IT department's ability to determine whether a 
            set of endpoints is vulnerable according to the information 
            contained in the vulnerability description information.</t>
        </list>
      </t>


    </section>

    <section title="Assumptions">
      <t>A number of assumptions must be stated in order to further
        clarify the position and scope of this document.</t>
      <t>The document assumes that: <list style="symbols">
          <t>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.</t>
          <t>The enterprise has a means of identifying enterprise
            endpoints through the execution of Target Endpoint Discovery
            Tasks although assertions about some details of this
            capability are made.</t>
          <t>The enterprise has a means of extracting relevant
            information about enterprise endpoints in a form that is
            compatible with the vulnerability description
            data.</t>
          <t>All information described in this scenario is available
            in the vulnerability description data and serves as the
            basis of assessments.</t>
          <t>The enterprise can provide all relevant information about
            any endpoint needed to perform the described
            assessment.</t>
          <t>The enterprise has a mechanism for long-term storage of
            vulnerability description information, vulnerability
            detection data, and vulnerability assessment results.</t>
          <t>The enterprise has a procedure for reassessment of
            endpoints at some point after initial assessment (see
            <xref target="continuous-vulnerability-assessment"/>
            for more information).</t>
        </list>
      </t>
    </section>

    <section title="Vulnerability Assessment Pre-requisites">
      <t>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.</t>
      <section title="Endpoint Management Capabilities">
        <t>Endpoint management capabilities are assumed to be in place
          within the enterprise, and are expected to collect a minimum
          set of attributes from the endpoints under 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 identifying attributes, 
          collectively known as the 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 capabilities is stored, with appropriate metadata
          (i.e. timestamp), in a central location and used to build up 
          a Target Endpoint Characterization Record and Target Endpoint 
          Profile via a Target Endpoint Characterization Task. The 
          endpoint management capabilities are expected to be performed on 
          an ongoing basis, resulting in routine, or even event-driven,
          collection of basic endpoint information.</t>

        <t>See <xref target="data-attribute-table"/> for
          information-specific details.</t>
      </section>

      <section title="Vulnerability Description Information">
        <t> 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. </t>
        <t>See <xref target="data-attribute-table"/> for
          information-specific details.</t>
      </section>

    </section>


    <section title="Endpoint Vulnerability Assessment Capabilities">
      <t>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.</t>
      <t>A vulnerability assessment (i.e. vulnerability detection) is
        performed in two steps:</t>
      <t>
        <list style="symbols">
          <t>Endpoint information collected by the endpoint management
            capabilities is examined by the vulnerability management
            capabilities through Evaluation Tasks.</t>
          <t>If the data possessed by the endpoint management
            capabilities is insufficient, a Collection Task is triggered
            and the necessary data is collected from the target endpoint.</t>
        </list>
      </t>

      <t>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:</t>
      <t>
        <list style="symbols">
          <t>A specific software version is installed on the
            endpoint</t>
          <t>File system attributes</t>
          <t>Specific state attributes</t>
        </list>
      </t>
      <t>In many cases, the endpoint information needed to determine
        an endpoint's vulnerability status will have been previously
        collected by the endpoint management capabilities and available
        in a Repository. However, in other cases, the necessary
        endpoint information will not be readily available in a
        Repository and a Collection Task will be triggered to collect it
        from the target endpoint. Of course, some implementations of  
        endpoint management capabilities may prefer to enable operators 
        to perform this collection under certain circumstances, even 
        when sufficient information can be provided by the endpoint 
        management capabilities (e.g. there may be freshness requirements 
        for information).</t>
      <t>The collection of additional endpoint information for the 
        purpose of vulnerability assessment does not necessarily need 
        to be a pull by the vulnerability assessment capabilities.  Over 
        time, some new pieces of information that are needed during 
        common types of assessments might be identified. Endpoint 
        management capabilities can be reconfigured to have this 
        information delivered automatically. This 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  
        endpoint management capabilities is rarely used. In this case, 
        it might be useful to re-configure the endpoint management 
        capabilities 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.</t>

      <t>See <xref target="data-attribute-table"/> for
        information-specific details.</t>

    </section>
    <section title="Vulnerability Assessment Results">
      <t>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.</t>
      <t>See <xref target="data-attribute-table"/> for
        information-specific details.</t>


    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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" <xref target="RFC7632"/>. As a result,
        the security considerations for <xref target="RFC7632"/> apply
        to this document. Furthermore, the data collected as part of the
        vulnerability 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 protecting this information.</t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      <!--&RFC2629;--> &RFC7632; &I-D.ietf-sacm-requirements; &I-D.coffin-sacm-nea-swid-patnc;
      &I-D.haynes-sacm-oval-definitions-model;&I-D.rothenberg-sacm-oval-sys-char-model;
      &I-D.cokus-sacm-oval-results-model;&I-D.hansbury-sacm-oval-info-model-mapping;
      <!-- A reference written by by an organization not a person. -->
      <reference anchor="critical-controls"  
        target="https://www.cisecurity.org/critical-controls.cfm">
        <front>
          <title abbrev="Critical Security Controls">
            Critical Security Controls, Version 6.0</title>
          <author>
            <organization abbrev="Center for Internet Security">Center
              for Internet Security</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="charter-ietf-sacm-01"
        target="https://datatracker.ietf.org/doc/charter-ietf-sacm/">
        <front>
          <title abbrev="Charter">Charter, Version 1.0</title>
          <author>
            <organization abbrev="SACM">Security Automation and
              Continuous Monitoring</organization>
          </author>
          <date month="October" year="2015"/>
        </front>
      </reference>
      <reference
        anchor="cvrf" 
        target="http://www.icasi.org/cvrf/">
        <front>
          <title abbrev="CVRF">Common Vulnerability and
          Reporting Framework</title>
          <author>
            <organization abbrev="ICASI">Industry Consortium for
            Advancement of Security on the Internet</organization>
          </author>
          <date month="May" year="2012"/>
        </front>
      </reference>
    </references>


    <section title="Change Log">
      <section title="Changes in Revision -02">
        <t>Changed "capability" in the context of endpoint management,
          vulnerability management, and vulnerability assessments to
          "capabilities" to avoid confusion with the term "capability"
          in the terminology draft.</t>
        <t>Made a few other minor editorial and clarification changes.</t>
      </section>
      <section title="Changes in Revision -01">
      	<t>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).</t>
        <t>Included references to the various appendices in the document. GitHub issue #18
          (https://github.com/sacmwg/vulnerability-scenario/issues/18).</t>
        <t>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).</t>
        <t>Updated references to the Critical Controls to Version 6.0. GitHub issue #23
          (https://github.com/sacmwg/vulnerability-scenario/issues/23).</t>
        <t>Aligned the scenario with SACM Tasks. GitHub issue #25
          (https://github.com/sacmwg/vulnerability-scenario/issues/25).</t>
      </section>
      <section title="Changes Since Adopted as a WG I-D -00">
        <t>Made various organizational and editorial changes as
          proposed by Adam Montville. GitHub issue #4
          (https://github.com/sacmwg/vulnerability-scenario/issues/4).</t>
        <t>Removed the TODO from the Security Considerations section
          (https://github.com/sacmwg/vulnerability-scenario/issues/8).</t>
        <t>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).</t>
        <t>Changed "targeted collection" to "supplemental collection".
          GitHub issue #14
          (https://github.com/sacmwg/vulnerability-scenario/issues/14).</t>
        <t>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).</t>
        <t>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).</t>
        <t>Moved the information needs captured in Appendix D.2 into
          the Information Model. GitHub issue #17
          (https://github.com/sacmwg/vulnerability-scenario/issues/17).</t>
      </section>
      <section title="Changes in Revision draft-coffin-sacm-vuln-scenario-01"
        anchor="changes-in-revision-01">
        <t>Clarification of the vulnerability description data IDs in
          sections 4 and 6.</t>
        <t>Added "vulnerability remediation" to the Assessment Results
          and Data Attribute Table and Definitions sections.</t>
        <t>Added Implementation Examples to Endpoint Identification
          and Initial (Pre-Assessment) Data Collection, Vulnerability
          Description Data, Endpoint Applicability and Assessment, and
          Assessment Results sections.</t>
        <t>Added an example to vulnerability description data in the
          scope section.</t>
        <t>Added a sentence to clarify vulnerability description data
          definition in the scope section.</t>
        <t>Added data repository example for long-term storage scope
          item.</t>
        <t>Added sentence to direct reader to examples of basic system
          information in endpoint identification section.</t>
        <t>Split the examples of information to collect in the
          pre-assessment collection section into a basic and advanced
          list.</t>
        <t>Added examples of data stored in the repository in the
          Assessment Results section.</t>
        <t>Added sentence for human-assigned attributes in the Future
          Work section.</t>
        <t>Replaced "vulnerability report" to "vulnerability
          description data" because the term report was causing
          confusion. Similarly, replaced "assessment report" with
          "assessment results".</t>
        <t>Replaced "Configuration Management Database (CMDB)" with
          "Repository" which is SACM's term for a data store.</t>
        <t>Replaced endpoint "Role" with "Purpose" because "Role" is
          already defined in SACM. Also, removed "Function" because it
          too is already defined in SACM.</t>
        <t>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.</t>
        <t>Included additional examples of software configuration
          information.</t>
        <t>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.</t>
        <t>Updated the Security Considerations section to mention
          those described in <xref target="RFC7632"/>.</t>
        <t>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.</t>
        <t>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.</t>
      </section>
    </section>
    <section title="Implementation Examples" anchor="implementation-examples">
      <section title="Endpoint Data Collection">
        <t>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.</t>
        <t>The SWID Message and Attributes for PA-TNC standard 
          <xref target="I-D.coffin-sacm-nea-swid-patnc"/> defines
          collection and validation of software identities using the
          ISO Software Identification Tag Standard. Using this
          standard, the identity of all installed software including
          the endpoint operating system, could be collected and used
          for later assessment.</t>
        <t>The OVAL Definitions Model 
          <xref target="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.</t>
        <t>The OVAL System Characteristics Model 
          <xref target="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.</t>
      </section>
      <section title="Vulnerability Description Information">
        <t>The Common Vulnerability Reporting Framework (CVRF)
          <xref target="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.</t>
      </section>
      <section title="Secondary Assessment">
        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
      </section>
      <section title="Assessment Results">
        <t>The OVAL Results Model 
          <xref target="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 <xref
            target="I-D.hansbury-sacm-oval-info-model-mapping">
            OVAL and the SACM Information Model</xref>.</t>
        <t>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.</t>
      </section>
    </section>
    <section title="Priority" anchor="priority">
      <t>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.</t>
      <t>Priority in regard to vulnerability description information,
        can be viewed in a couple of different ways within an
        enterprise. The assessment prioritization involves
        prioritization of the vulnerability description information
        assessment process. This determines what vulnerability
        description information is assessed, and in what order it is
        assessed in. For instance, a vulnerability affecting an
        operating system or application used throughout the enterprise
        would likely be prioritized higher than a vulnerability in an
        application which is used only on a few, low-criticality
        endpoints.</t>
      <t>The prioritization of remedies relates to the enterprise
        remediation and mitigation process based on the discovered
        vulnerabilities. Once an assessment has been performed and
        applicable endpoints identified, enterprise vulnerability
        managers must determine where to focus their efforts to apply
        appropriate remedies. For example, a vulnerability that is
        easily exploitable and which can allow arbitrary code
        execution might be remedied before a vulnerability that is
        more difficult to exploit or which just degrades
        performance.</t>
      <t>Some vulnerability description information include severities
        and/or other information that places the vulnerability in
        context. This information can be used in both of the priority
        types discussed above. In other cases, enterprise
        administrators may need to prioritize based only on what they
        know about their enterprise and the description provided in
        the vulnerability description information.</t>
      <t>Examples of data attributes specific to priority of
        assessments and/or remedies include (but not limited to) the
        following:</t>
      <t>
        <list style="symbols">
          <t>Enterprise - defined purpose of the device, criticality
            of the device, exposure of the device, etc.</t>
          <t>Severity attributes - A rating or score that attempts to
            provide the level of severity or criticality associated
            with a given vulnerability.</t>
          <t>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.</t>
        </list>
      </t>
    </section>
    
    <section title="SACM Usage Scenarios" anchor="sacm-usage-scenarios">
      <t>The SACM "Endpoint Security Posture Assessment: Enterprise
        Use Cases" document (<xref target="RFC7632"/>) defines
        multiple usage scenarios that are meant to provide examples of
        implementing the use cases and building block capabilities.
        Below is a brief summary of some of these usage scenarios and
        how this document aligns and/or adds additional value to the
        identified usage scenarios.</t>
      <t>
        <list style="symbols">
          <t>Automated Checklist Verification (2.2.2) - "An enterprise
            operates a heterogeneous IT environment. They utilize
            vendor-provided automatable security configuration
            checklists for each operating system and application used
            within their IT environment. Multiple checklists are used
            from different vendors to ensure adequate coverage of all
            IT assets." The usage scenario, as defined in the RFC, is
            targeted at the checklist level and can be interpreted as
            being specific to endpoint configuration. There is mention
            of patch assessment and vulnerability mitigation, but the
            usage scenario could be expanded upon by including
            vulnerability verification. Replacing the idea of a
            checklist in the SACM usage scenario with vulnerability
            would allow the usage scenario to align almost exactly
            with the scenario described in this document. Instead of
            collecting automatable security configuration checklists,
            the enterprise would collect automatable vulnerability
            description information available from the vendor as
            described or possibly from other interested
            third-parties.</t>
          <t>Detection of Posture Deviations (2.2.3) - "An enterprise
            has established secure configuration baselines for each
            different type of endpoint within their IT environment.
            When an endpoint connects to the network, the appropriate
            baseline configuration is communicated to the endpoint.
            Once the baseline has been established, the endpoint is
            monitored for any change events pertaining to the baseline
            on an ongoing basis. When a change occurs to posture
            defined in the baseline, updated posture information is
            exchanged. When the endpoint detects a posture change, an
            alert is generated identifying the specific changes in
            posture." This usage scenario would support the concept of
            endpoints signaling or alerting the enterprise to changes
            in the posture relates to endpoint vulnerabilities in the
            same way that it would for configurations. Replacing the
            idea of a checklist with vulnerability description data
            allows the SACM usage scenario and the scenario described
            in this document to align in their objectives.</t>
          <t>Asynchronous Compliance/Vulnerability Assessment at Ice
            Station Zebra (2.2.5) - "An isolated arctic IT environment
            that is separated from the main university network. The
            only network communications are via an intermittent,
            low-speed, high-latency, high-cost satellite link. Remote
            network admins will need to show continued compliance with
            the security policies of the university, the government,
            and the provider of the satellite network, as well as keep
            current on vulnerability testing." This SACM usage
            scenario describes vulnerability assessment and aligns
            well with the vulnerability scenario described in this
            document. The endpoint assets are identified and
            associated data is published in a Repository.
            Vulnerability description information is collected and
            saved in a Repository as it is released. The vulnerability
            description information is queued for later assessment,
            then the assessment results and vulnerability description
            information are stored after assessment. The only real
            difference in this SACM usage scenario is the timing of
            the assessments. The scenario described within this
            document would have no problems adjusting to the timing of
            this SACM usage scenario or anything similar.</t>
        </list>
      </t>
    </section>
    
    <section title="SACM Requirements and Charter - Future Work">
      <t>In the course authoring this document, some additional
        considerations for possible future work were noted. The
        following points were taken from the <xref
          target="I-D.ietf-sacm-requirements">SACM
          Requirements</xref>, <xref target="charter-ietf-sacm-01">SACM
            Charter</xref>, and SACM Use Cases (<xref target="RFC7632"
            />) documents and represent work that may be necessary to
        support the tasks or goals of SACM going forward.</t>
      <t>
        <list style="symbols">
          <t>The SACM requirements mentions "Result Reporting" with
            applications but no detail around what the assessment
            results data set should include. In the case of
            vulnerability assessment results, context is important and
            details beyond just a Pass or Fail result are needed in
            order to take action. A good example of this might be the
            Priority of the vulnerability itself and how many systems
            it affects within the enterprise. With this in mind, it
            might be worthwhile to investigate a minimum data set or
            schema for assessment results. The concern here is with
            vulnerability description data, but this could apply to
            other enterprise processes as well.</t>
          <t>The "Human-assigned endpoint attributes" mentioned
            previously in this scenario are touched on in the SACM use
            cases, but the topic could probably be explored in much
            more depth. Enterprise policy and behaviors could be
            greatly influenced by endpoint attributes such as
            locations, how the endpoint is used, and criticality. When
            and how these data attributes are collected, as well as
            what the minimum or common set might look like, would be
            good topics for future related SACM work. In addition, the
            storage of these attributes could be central (stored in a
            data repository) or they could be assigned and stored on
            the endpoints themselves.</t>
        </list>
      </t>
    </section>
    
    <section title="SACM Use Case Alignment">
      <section title="Endpoint Identification">
        <t>This sub-step aligns with the Endpoint Discovery, Endpoint
          Characterization, and Endpoint Target Identification
          building block capabilities. The alignment is due to the
          fact that the purpose of this sub-step is to discover,
          identify, and characterize all endpoints on an enterprise
          network.</t>
      </section>
      <section title="Endpoint Data Collection">
        <t>This sub-step aligns with the Data Publication building
          block capability because this section involves storage of
          endpoint attributes within an enterprise Repository. This
          sub-step also aligns with the Endpoint Characterization and
          Endpoint Target Identification building block capabilities
          because it further characterizes the endpoint through
          automated and possibly manual means. There is direct
          alignment with the Endpoint Component Inventory, Posture
          Attribute Identification, and Posture Attribute Value
          Collection building block capabilities since the purpose of
          this sub-step is to perform an initial inventory of the
          endpoint and collect basic attributes and their values.
          Last, there is alignment with the Collection Guidance
          Acquisition building block capabilities as the inventory and
          collection of endpoint attributes would be directed by some
          type of enterprise or third-party guidance.</t>
      </section>
      <section title="Vulnerability Description Information">
        <t>This step aligns with the Data Publication and Data
          Retrieval building block capabilities because this section
          details storage of vulnerability description information
          within an enterprise Repository and later retrieval of the
          same.</t>
      </section>
      <section title="Applicability">
        <t>This sub-step aligns with the Data Retrieval, Data Query,
          and Posture Attribute Value Query building block
          capabilities because, in this sub-step, the process is
          attempting to determine the vulnerability status of the
          endpoint using the data that has previously been
          collected.</t>
      </section>
      <section title="Secondary Assessment">
        <t>This sub-step aligns with the Data Publication building
          block capability because this section details storage of
          endpoint attributes within an enterprise Repository. The
          sub-step also aligns with the Collection Guidance
          Acquisition building block capability since the
          vulnerability description information (guidance) drives the
          collection of additional endpoint attributes.</t>
        <t>This sub-step aligns with the Endpoint Characterization
          (both manual and automated) and Endpoint Target
          Identification building block capabilities because it could
          further characterize the endpoint through automated and
          possibly manual means. There is direct alignment with the
          Endpoint Component Inventory, Posture Attribute
          Identification, and Posture Attribute Value Collection
          building block capabilities since the purpose of this
          sub-step is to perform additional and more specific
          component inventories and collections of endpoint attributes
          and their values.</t>
      </section>
      <section title="Assessment Results">
        <t>This step aligns with the Data Publication and Data
          Retrieval building block capabilities because this section
          details storage of vulnerability assessment results within
          an enterprise Repository and later retrieval of the
          same.</t>
      </section>
    </section>
    <section title="Alignment with Other Existing Works" 
      anchor="alignment-with-other-existing-works">
      <section title="Critical Security Controls">
        <t>The Center for Internet Security's <xref
          target="critical-controls">Critical Security
          Controls</xref> includes security controls for a number of
          usage scenarios, some of which are covered in this document.
          This section documents the alignment between the Center's
          controls and the relevant elements of the scenario.</t>
        <section title="Continuous Vulnerability Assessment">
          <t>"CSC 4: Continuous Vulnerability Assessment and
            Remediation," which is described by the Center for
            Internet Security 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:</t>
          <t>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.</t>
          <t>This scenario assumes that the enterprise already has a
            source for vulnerability description information as
            described in CSC 4.4.</t>
          <t>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.</t>
          <t>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.</t>
          <t>The described scenario does not address the details of
            applying a remedy based on assessment results. As such,
            CSC 4.5 which deals 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.</t>
          <t>The CSC 4 System Entity Relationship diagram directly 
            aligns with the scenario described in this document 
            with the exception of applying patches to endpoints.</t>
        </section>
        <section title="Hardware and Software Inventories">
          <t>This scenario is also aligned with, and describes a
            process for, collecting and maintaining hardware and
            software inventories, which 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.</t>
          <t>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.</t>
          <t>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 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.</t>
        </section>
      </section>
    </section>
    <section title="Continuous Vulnerability Assessment" 
      anchor="continuous-vulnerability-assessment">
      <t>It is not sufficient to perform a single assessment when
        vulnerability description information is published without any
        further checking. Doing so does not address the possibility
        that the reported vulnerability might be introduced to the
        enterprise environment after the initial assessment completes.
        For example, new endpoints can be introduced to the
        environment which have old software or are not up-to-date with
        patches. Another example is where unauthorized or obsolete
        software is installed on an existing endpoint by enterprise
        users after vulnerability description information and initial
        assessment has taken place. Moreover, enterprises might not
        wish to, or be able to, assess all vulnerability description
        information immediately when they come in. Conflicts with
        other critical activities or limited resources might mean that
        some alerts, especially those that the enterprise deems as
        "low priority", are not used to guide enterprise assessments
        until sometime after the initial receipt.</t>
      <t>The scenario above describes a single assessment of
        endpoints. However, it does not make any assumptions as to
        when this assessment occurs relative to the original receipt
        of the vulnerability description data that led to this
        assessment. The assessment could immediately follow the
        ingestion of the vulnerability description information, could
        be delayed, or the assessment might represent a reassessment
        of some vulnerability description information against which
        endpoints had previously been assessed. Moreover, the scenario
        incorporates long-term storage of collected data,
        vulnerability description information, and assessment results
        in order to facilitate meaningful and ongoing
        reassessment.</t>
    </section>
    <section anchor="data-attribute-table"
      title="Data Attribute Table">
        <t>The following table maps all major data attributes against
          each major process where they are used.</t>
        <texttable anchor="data_attribute_table"
          title="Vulnerability Assessment Attributes" style="all">
          <ttcol align="center"/>
          <ttcol align="center">vulnerability description data</ttcol>
          <ttcol align="center">Endpoint Identification and Initial
            Data Collection</ttcol>
          <ttcol align="center">Endpoint Applicability and
            Assessment</ttcol>
          <ttcol align="center">Assessment Results</ttcol>

          <c>*Endpoint*</c>
          <c/>
          <c/>
          <c/>
          <c/>

          <c>Collection date/time</c>
          <c/>
          <c>X</c>
          <c>X</c>
          <c/>

          <c>Endpoint type</c>
          <c/>
          <c>X</c>
          <c>X</c>
          <c/>

          <c>Hardware version/firmware</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c/>

          <c>Operating system</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c/>

          <c>Operating system attributes (e.g., version, service pack
            level, edition, etc.)</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c/>

          <c>Installed software name</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>

          <c>Installed software attributes (e.g., version, patch
            level, install path, etc.)</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>

          <c>Open ports/services</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c/>

          <c>Operating system optional component inventory</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c/>

          <c>Location</c>
          <c/>
          <c>X</c>
          <c/>
          <c>X</c>

          <c>Purpose</c>
          <c/>
          <c>X</c>
          <c/>
          <c>X</c>

          <c>Criticality</c>
          <c/>
          <c>X</c>
          <c/>
          <c>X</c>

          <c>File system attributes (e.g., versions, size, write date,
            modified date, checksum, etc.)</c>
          <c>X</c>
          <c/>
          <c>X</c>
          <c/>

          <c>Shared libraries</c>
          <c>X</c>
          <c/>
          <c>X</c>
          <c/>

          <c>Other software configuration information</c>
          <c>X</c>
          <c/>
          <c>X</c>
          <c/>

          <c>*External vulnerability description data*</c>
          <c/>
          <c/>
          <c/>
          <c/>

          <c>Ingest Date</c>
          <c>X</c>
          <c/>
          <c>X</c>
          <c/>

          <c>Date of Release</c>
          <c>X</c>
          <c/>
          <c>X</c>
          <c/>

          <c>Version</c>
          <c>X</c>
          <c/>
          <c>X</c>
          <c/>

          <c>External vuln ID</c>
          <c>X</c>
          <c/>
          <c>X</c>
          <c>X</c>

          <c>Severity Score</c>
          <c/>
          <c/>
          <c/>
          <c>X</c>

          <c>*Assessment Results*</c>
          <c/>
          <c/>
          <c/>
          <c/>

          <c>Date of assessment</c>
          <c/>
          <c/>
          <c>X</c>
          <c>X</c>

          <c>Date of data collection</c>
          <c/>
          <c>X</c>
          <c>X</c>
          <c>X</c>

          <c>Endpoint identification and/or locally assigned ID</c>
          <c/>
          <c>X</c>
          <c>X</c>
          <c>X</c>

          <c>Vulnerable software product(s)</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>
          <c>X</c>

          <c>Endpoint vulnerability status</c>
          <c/>
          <c/>
          <c>X</c>
          <c>X</c>

          <c>Vulnerability description </c>
          <c>X</c>
          <c/>
          <c/>
          <c>X</c>

          <c>Vulnerability remediation</c>
          <c>X</c>
          <c/>
          <c/>
          <c>X</c>
        </texttable>
    </section>
 
  </back>

</rfc>