draft-coffin-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 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-coffin-sacm-vuln-scenario-latest"
  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 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 provides a core narrative that walks
        through an automated enterprise vulnerability
        assessment scenario. It is aligned with the SACM use
        cases and begins with an enterprise ingesting
        vulnerability description data, followed by identifying
        endpoints on the network and collecting and storing information
        about them to enable posture assessment,
        and finally ends with assessing these
        endpoints against the vulnerability description
        data to determine which ones are affected.
        Processes that specifically overlap between this
        scenario and SACM use cases will be noted where
        applicable. Specifically, the relationship between
        this document and the SACM use case building block
        capabilities and the usage scenarios will be
        covered.</t>
    </abstract>
  </front>

  <middle>
    <section title="Scope">
      <t>The purpose of this document is to describe a
        detailed scenario for vulnerability assessment, and
        identify aspects of this scenario that could be used
        in the development of an information model. This
        includes classes of data, major roles, and a
        high-level description of role interactions.
        Additionally, this scenario intends to inform
        engineering work on protocol and data model
        development. The focus of the document is entirely
        intra-organizational and covers enterprise handling
        of vulnerability description data. The document does
        not attempt to cover the security disclosure itself
        and any prior activities of the security researcher
        or discloser, nor does it attempt to cover the
        specific activities of the vendor whose software is
        the focus of the vulnerability description data 
		(i.e., the vulnerable software).</t>

      <t>For the purposes of this document, the term
        "vulnerability description data" is intended to
        mean: "Data intended to alert enterprise IT
        resources to the existence of a flaw or flaws in
        software, hardware, and/or firmware, which could
        potentially have an impact on enterprise
        functionality and/or security." For the purpose of
        this scenario, such data also includes information
        that can be used to determine (to some level of
        accuracy, although possibly not conclusively)
        whether or not the flaw is present within an
        enterprise, when compared to information about the
        state of the enterprise's endpoints. For those who 
		are familiar with current security practices and 
		terminology, the use of vulnerability description 
		data is also synonymnous with security bulletin or
		advisory.</t>

      <t>This document makes no attempt to provide a
        definition of a normalized data format (e.g.
        industry standard) for vulnerability description
        data although there is nothing precluding the
        development of such a normalized data format. Also,
        it does not attempt to define procedures by which a
        vulnerability discoverer coordinates the release of
        vulnerability description data to other parties.</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>
        <list style="symbols">
          <t>The document begins with the assumption that
            the enterprise has received vulnerability
            description data, and that the data has already
            been processed into a format that the
            enterprise's security software tools can
            understand and use. In particular, this
            document: <list style="symbols">
              <t>Does not discuss how the enterprise
                identifies potentially relevant
                vulnerability description data.</t>
              <t>Does not discuss how the enterprise
                collects the vulnerability description
                data.</t>
              <t>Does not discuss how the enterprise
                assesses the authenticity of the
                vulnerability description data.</t>
              <t>Does not discuss parsing of the
                vulnerability description data into a usable
                format.</t>
            </list>
          </t>
          <t>The document assumes that the enterprise has a
            means of identifying enterprise endpoints. This
            could mean identifying endpoints as they join
            the network, actively scanning for connected
            endpoints, passive scanning of network traffic
            to identify connected endpoints, or some other
            method of accounting for the presence of all
            endpoints in the enterprise. The document also
            does not distinguish between physical endpoints
            and virtualized endpoints.</t>
          <t>The document assumes that the enterprise has a
            means of extracting relevant information about
            enterprise endpoints. Moreover, this extracted
            information is expressed in a format that is
            compatible with the information extracted from
            the vulnerability description data. The
            document: <list style="symbols">
              <t>Does not specify how relevant information
                is identified.</t>
              <t>Does not specify the mechanics of how
                relevant information is extracted from the
                data sources (such as the endpoint
                itself).</t>
              <t>Does not specify how extracted endpoint
                information and vulnerability description
                data is normalized to be compatible.</t>
            </list>Note that having a means of extracting
            relevant information about enterprise endpoints
            is within the scope of the SACM Endpoint
            Security Posture Assessment process. In the case
            of this document, this sub-process is assumed to
            be existent. </t>
          <t>The document assumes that all information
            described in the steps below is available in the
            vulnerability description data and serves as the
            basis of this assessment. Likewise, the document
            assumes that the enterprise can provide all
            relevant information about any endpoint needed
            to perform the described analysis. The authors
            recognize that this will not always be the case,
            but these assumptions are taken in order to show
            the breadth of data utilization in this
            scenario. Less complete information may require
            variations to the described steps.</t>
          <t>The document assumes that the enterprise has a
            policy by which assessment of endpoints based on
            vulnerability description data is prioritized.
            The document: <list style="symbols">
              <t>Does not specify how prioritization
                occurs.</t>
              <t>Does not specify how prioritization impacts
                assessment behaviors.</t>
            </list>
          </t>
          <t>The document assumes that the enterprise has a
            mechanism for long-term storage of vulnerability
            description data and endpoint assessment
            results (e.g., a data repository).</t>
          <t>This document assumes that the enterprise has a
            procedure for reassessment of endpoints at some
            point after initial assessment. The document:
              <list style="symbols">
              <t>Does not specify how a reassessment would
                impact individual assessment behaviors.
                (i.e., it is agnostic as to whether the
                assessment procedure is the same regardless
                of whether this is the first or a subsequent
                assessment for some set of vulnerability
                description data.)</t>
              <t>Does not provide recommendations or
                specifics on reassessment intervals.</t>
            </list>
          </t>
        </list>
      </t>
    </section>

    <section
      title="Endpoint Identification and Initial (Pre-Assessment) Data Collection">
      <t>The first step in this scenario involves
        identifying endpoints and collecting the basic
        or minumum set of system information attributes 
		from them such as operating system type 
		and version. Further examples of system 
		information and attributes can be found below in the 
		section titled Endpoint Data Collection. This identification occurs 
		prior to the receipt of any specific vulnerability 
		description data and is part of the regular, ongoing 
		monitoring of endpoints within an enterprise. This 
		process is not meant to report on, or gather data for 
		any specific vulnerabilities. The information gathered
        during this step could be applied in many enterprise
        automation efforts. Specifically, in addition to
        vulnerability management, it could be used by
        configuration and license management tasks. All of
        the information collected during this step is stored
        in a central location such as a Repository.</t>
      <t>This activity involves the following sub-steps:</t>
      <section title="Identification">
        <t>Prior to any other steps, the identification of
          endpoints must occur. This involves locating (at
          least virtually) and distinguishing between
          endpoints on the network in a way that allows each
          endpoint to be recognized in future interactions
          and selected for specific treatment. This not only
          allows later steps to determine the scope of what
          endpoints need to be assessed, but also allows for
          the unique identification of each endpoint. Unique
          and persistent endpoint IDs are used to allow for
          endpoints to be tracked over time and between
          sensors as well as allow for proper counts of
          assets during inventories and other similar
          collections. Endpoint identity can be established
          by collecting certain attributes that allow for
          unique and persistent tracking of endpoints on the
          enterprise network. Examples include, but are not
          limited to, IP address, MAC address, FQDNs,
          pre-provisioned identifiers such as GUIDs or
          copies of serial numbers, certificates, hardware
          identity values, or similar attributes. It is
          important to note that the persistency of these
          attributes will likely vary depending on the
          enterprise. For example, a statically assigned IP
          address is much more persistent than an IP address
          assigned via DHCP.</t>
		<section title="SACM Use Case Alignment">
        <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>
      <section title="Processing Artifacts">
        <t>Processing artifacts, such as the date and time
          the collection was performed, should be collected
          and stored. This timestamp is extremely important
          when performing later assessments, as it is needed
          for data freshness computations. The organization
          may develop rules for stale data and when a new
          data collection is required. This metadata is also
          helpful in correlating information across multiple
          data collections. This includes correlating both
          pre-assessment data and secondary assessment data
          (sections 4.3 Endpoint Data Collection and 6.2
          Secondary Assessment).</t>
      </section>
      <section title="Endpoint Data Collection">
        <t>The enterprise should perform ongoing collection
          of basic endpoint information such as operating
          system and version information, and an installed
          software inventory. This information is collected
          for general system monitoring as well as its
          potential use in activities such as vulnerability
          assessment.</t>
        <t>Some examples of basic information to collect about endpoints
          in this pre-assessment process could include:</t>
        <t>
          <list style="symbols">
            <t>Endpoint type - traditional (e.g.,
              workstation, server, etc.) network
              infrastructure (e.g., switches, routers,
              etc.), mobile (e.g., cell phones, tablets,
              laptops, etc.), and constrained (e.g.,
              industrial control systems, Internet of
              Things, etc.)</t>
            <t>Hardware version/firmware - e.g., BIOS
              version, firmware revision, etc.</t>
            <t>Operating system - e.g., Windows, Linux, Mac
              OS, Android</t>
            <t>Operating system attributes - e.g., version,
              patch level, service pack level,
              internationalized or localized version,
              etc.</t>
            <t>Installed software inventory - Would include
              the software names and versions and possibly
              other high-level attributes. Could be used to
              quickly determine endpoint applicability when
              new vulnerability description data
              arrives.</t>
		  </list>
        </t>
		  <t>Some additional and more advanced information to 
		    collect from endpoints in this pre-assessment 
			process could include:</t>
        <t>
          <list style="symbols">
            <t>Open ports and enabled services - This would
              include applications listening for incoming
              connections on open ports as well as services
              that are starting, running, suspended, or
              enabled to run pending some event.</t>
            <t>Operating system optional component inventory
              - some OS' have optional components that can
              be installed which may not show up as separate
              pieces of software (e.g., web and ftp servers,
              demo web pages, shared libraries, etc.). Note
              that this could also occur within third-party
              applications as well.</t>
            <t>Endpoint location - physical location (e.g.,
              department, room, Global Positioning System
              (GPS), etc.), logical location (e.g., what
              network infrastructure endpoints (e.g.
              switches, wireless access point, etc.) an
              endpoint is connected to, etc.</t>
            <t>Purpose - describes how the endpoint is used
              within the enterprise (e.g., end-user system,
              database server, public web server, etc.)</t>
            <t>Criticality - enterprise defined rating
              (possibly a score) that helps determine the
              criticality of the endpoint. If this endpoint
              is attacked or lost, what is the impact to the
              overall enterprise?</t>
          </list>
        </t>
        <t>It is important to note that some of these
          attributes may exist natively on the endpoint
          whereas other attributes may be assigned by a
          human, computed, or derived from other data and
          may or may not be available for collection on the
          endpoint.</t>
        <t>Furthermore, the possibility should be left open
          for enterprises to define their own custom queries
          and algorithms to gather and derive
          enterprise-specific attributes that are deemed of
          interest to regular enterprise operations.</t>
        <t>In addition to collecting these attributes,
          metadata about the attributes should also be
          collected which could include: <list>
            <t>Data origin - where the data originated
              from</t>
            <t>Data source - what provided the data</t>
            <t>Date and time of collection - when the data
              was collected</t>
          </list>
        </t>
		<section title="SACM Use Case Alignment">
        <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>
	  <section title="Implementation Examples">
	    <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 IF-M standard 
		  defines collection and validation of software identities
          using the ISO Software Identification Tag Standard. Using this 
		  standard, the identity of all installed software including the
          endpoint operating system, could be collected and used 
		  for later assessment.</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>
	  </section>
    </section>

    <section title="Vulnerability Description Data">
      <t>The next step in the Vulnerability Assessment
        scenario begins after vulnerability description data
        has been received and processed into a form that can
        be used in the assessment of the enterprise. As a
        part of the enterprise process for managing
        vulnerability description data, the enterprise
        should store all received and processed
        vulnerability description data in a Repository.
        The stored vulnerability description data can be
        used and compared with later vulnerability
        description data for the purpose of duplicate
        detection and in some cases, guidance on how to
        handle similar issues.</t>
      <t>All vulnerability description data should be
        assigned an internal tracking ID by the enterprise
        as a first step as this helps compensate for the 
		fact that incoming vulnerability description data 
		might not have a global identifier when it is 
		received, and might never be assigned one.</t>
      <t>High-level vulnerability description data metadata
        to store would include:</t>
      <t>
        <list style="symbols">
          <t>Ingest date and time - the date and time that
            the vulnerability description data was received
            by the enterprise.</t>
          <t>Date and time of vulnerability description data
            release (i.e., publication or disclosure date
            and time) - Some older vulnerability description
            data may be ingested long after publication.
            This can be useful when reviewing historical
            enterprise information to (potentially) identify
            the period when a particular endpoint was first
            assessed as vulnerable. Sometimes this
            information will help to differentiate between
            similar vulnerability description data.</t>
          <t>Version - the version or iteration of the
            vulnerability description data according to the
            author, if applicable.</t>
          <t>External Vulnerability Description Data ID(s)
            (if applicable) - any external or third-party
            IDs assigned to the vulnerability description
            data should be tracked. There could be multiple
            IDs in some cases (e.g., vendor bug id, global
            ID, discoverer's local ID, third-party
            vulnerability database ID, etc.).</t>
          <t>Severity Score (if available) - these may be
            useful for later mitigation prioritization.</t>
        </list>
      </t>
      <t>In addition to the described metadata, the raw or 
        original vulnerability description data would be 
		stored along with the specific information extracted 
		from it that is to be used in the applicability and 
		assessment process.</t>
      <section title="SACM Use Case Alignment">
      <t>This step aligns with the Data Publication and Data
        Retrieval building block capabilities because this
        section details storage of vulnerability description
        data within an enterprise Repository and later
        retrieval of the same.</t>
	  </section>
		<section title="Implementation Examples">
		  <t>The Common Vulnerability Reporting Framework (CVRF) 
		    is an XML-based language that attempts to standardize 
			the creation of vulnerability report documentation.
			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>
    <section title="Endpoint Applicability and Assessment">
      <t>When new vulnerability description data is received
        by the enterprise, applicable enterprise endpoints
        must be identified and assessed. Endpoints are first
        examined using the already obtained pre-assessment 
		data. If this is not sufficient to determine endpoint 
		applicability, a secondary data collection for 
		additional data and attributes may be performed to 
		determine status with regard to the vulnerability 
		description data.</t>
      <section title="Applicability">
        <t>The applicability of an endpoint and its
          vulnerability status can, in many cases, be
          determined entirely by the existence of a
          particular version of installed software on the
          endpoint. This data may have been collected in the
          pre-assessment data collection. If the
          applicability and vulnerability status of an
          endpoint can be determined entirely by the
          pre-collected data attribute set, no further data
          collection is required.</t>
        <t>Other cases may require specific data (i.e., file
          system attributes, specific configuration
          parameters, etc.) to be collected for the
          assessment of a particular vulnerability
          description data. In these cases, a secondary,
          targeted vulnerability assessment is required.
          Administrators may want to evaluate applicability
          to the vulnerability description data iteratively.
          Specifically, the process would compare against
          pre-collected data first (easy to do and the data
          is stored in a Repository), and then if needed,
          query endpoints that are not already excluded from
          applicability for additional required data. (I.e.,
          A "fast-fail" model). To do this, the criteria for
          determining applicability must be separable, so
          that some conclusions can be drawn based on the
          possession of partial data.</t>
		<section title="SACM Use Case Alignment">
        <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>
      <section title="Secondary Assessment">
        <t>If the applicability and vulnerability status of
          an endpoint cannot be determined by the
          pre-assessment data collection, a secondary and
          targeted assessment of the endpoint will be
          required. A secondary assessment may also be
          required in the case that data on-hand (either
          from pre-assessment or from prior secondary
          assessments) is stale or out-of-date.</t>
        <t>The following data types and attributes are
          examples of what might be required in the case of
          a secondary and targeted assessment:</t>
        <t>
          <list style="symbols">
            <t>Specific files and attributes - i.e., file
              name, versions, size, write date, modified
              date, checksum, etc. Some vulnerabilities may
              only be distinguishable through the presence
              or absence of specific files or their attributes.</t>
            <t>Shared libraries - Some vulnerabilities will
              affect many products across multiple vendors.
              In these cases the vulnerability may apply to
              a shared library. Under these circumstances,
              product versions may be less helpful than
              looking for the presence of one or more
              specific files and their attributes.</t>
            <t>Other software configuration information (if
              applicable) - e.g., Microsoft Windows registry
              queries, Apple configuration profiles, GConf,
              Proc filesystem, text configuration files and
              their parameters, and the installation paths.
              Sometimes vulnerabilities only affect certain
              software configurations and in some cases
              these are not the default configurations.
              Certain configuration attributes can be used
              to determine the current configuration
              state.</t>
          </list>
        </t>
        <t>Note that the secondary assessment described here
          does not need to be a pull assessment that is
          initiated by the server. The secondary assessment
          could also be part of a push to the server when
          the endpoint detects a change to a vulnerability
          assessment baseline.</t>
		<section title="SACM Use Case Alignment">
        <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 data (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>
	  	  <section title="Implementation Examples">
		<t>Within the SACM Architecture, the assessment task 
		  would be handled by the Evaluator component. If pre-assessment 
		  data is used, this would be stored on and obtained from a 
		  Data Store component.</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 IF-M 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>
    <section title="Assessment Results">
      <t>Assessment results present the results of an
        assessment, along with sufficient context so a human
        or machine can make the appropriate response. This
        context might include a description of the issue
        provided by the vulnerability description data, the
        endpoint attributes that indicate applicability, or
        other information needed to respond to the results
        of the assessment. Data in this step is stored for
        auditing and forensic purposes.</t>
      <t>The following details are important to track in
        assessment results. Note that information may be
        "included" by providing pointers to other records
        stored in a Repository (e.g., vulnerability 
		description data, endpoint data, etc.).</t>
      <t>
        <list style="symbols">
          <t>Date and time of assessment - The date and time
            that the assessment was performed. To understand
            when the data was compared against the
            vulnerability description data and what
            conclusions were drawn.</t>
          <t>Data collection/attribute age - The age of the
            data used in the assessment to make the endpoint
            status determination.</t>
          <t>Endpoint ID - The endpoint itself must be
            identified for tracking results over time.</t>
          <t>Vulnerability description data ID(s) - May include 
		    both the internally defined ID as well as one or 
			more externally defined IDs if they exist. The 
			internally assigned ID allows linkage to the 
			correct	vulnerability description data. If 
			available, external IDs provide a "pivot point" 
			to additional external information.</t>
          <t>Vulnerable software product(s) - Identifies the
            software products on the endpoint that resulted
            in the endpoint being declared applicable. Since
            some vulnerability description data identify
            vulnerabilities in multiple products, this will
            help identify the specific product (or products)
            found to be vulnerable in the endpoint
            assessment.</t>
          <t>Endpoint vulnerability status - The endpoint
            status based on the vulnerability description
            data. Does the vulnerability exist on the
            endpoint?</t>
          <t>Vulnerability description - Not needed for
            automated assessment but probably should be
            included for human review. The reason for
            inclusion is to support the human user
            understanding of the vulnerability assessment
            results within the application front-end or
            interface.</t>
		  <t>Vulnerability remediation - Similar to the above, 
		    remediation or vendor patch information would be 
			useful for a human response. In many cases, this 
			information may be a part of the description 
			information described above. Note that patch 
			information may change over time due to 
			supercession of the vendor patches.</t>
        </list>
      </t>
	  <section title="SACM Use Case Alignment">
      <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 title="Implementation Examples">
		  <t>The OVAL Results Model provides a data model to encode 
		    the results of the assessment, which could then be stored 
			in a Repository and later accessed. The assessment results 
			described in this scenario could be stored and later 
			accessed using the OVAL Results Model. Note that the use of 
			the OVAL Results Model for sharing results is not recommended 
			per section 7.3 of the 
			<xref target="draft-hansbury-sacm-oval-info-model-mapping-01">
			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>

    <!-- 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 vulnerability description data may
        provide attackers with useful information such as
        what software an enterprise is running on their
        endpoints. As a result, organizations should
        properly protect the vulnerability description data
        it ingests.***TODO IS THIS COVERED BY
        RFC7632???***</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;
      <!-- A reference written by by an organization not a person. -->
      <reference anchor="critical-controls">
        <front>
          <title abbrev="Critical Security Controls"
            >Critical Security Controls, Version 5.1</title>
          <author>
            <organization abbrev="Council on CyberSecurity"
              >Council on CyberSecurity</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="charter-ietf-sacm-01">
        <front>
          <title abbrev="Charter">Charter, Version
            1.0</title>
          <author>
            <organization abbrev="SACM">Security Automation
              and Continuous Monitoring</organization>
          </author>
          <date month="July" year="2013"/>
        </front>
      </reference>
	        <reference anchor="draft-hansbury-sacm-oval-info-model-mapping-01">
        <front>
          <title abbrev="OVAL and SACM Info Model">OVAL and the SACM Information Model</title>
          <author>
            <organization abbrev="SACM">Security Automation
              and Continuous Monitoring</organization>
          </author>
          <date month="November" year="2015"/>
        </front>
      </reference>
    </references>


    <section title="Change Log">
	  <section title="Changes in Revision 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 endoints
          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="Continuous Vulnerability Assessment">
      <t>It is not sufficient to perform a single assessment
        when vulnerability description data 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 intial 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 data and initial
        assessment has taken place. Moreover, enterprises
        might not wish to, or be able to, assess all
        vulnerability description data 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 ingest of the vulnerability
        description data, could be delayed, or the
        assessment might represent a reassessment of some
        vulnerability description data against which
        endpoints had previously been assessed. Moreover,
        the scenario incorporates long-term storage of
        collected data, vulnerability description data, and
        assessment results in order to facilitate meaningful
        and ongoing reassessment.</t>
    </section>

    <section title="Priority">
      <t>Priorities associated with the vulnerability
        description data, 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 description
        data scenario as they separable issues with their
        own sets of requirements.</t>
      <t>Priority in regard to vulnerability description
        data, can be viewed in a couple of different ways
        within an enterprise. The assessment prioritization
        involves prioritization of the vulnerability
        description data assessment process. This determines
        what vulnerability description data 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 data 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 data.</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="Data Attribute Table and Definitions">
      <section title="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 (Pre-Assessment) 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>

      <section title="Definitions">
        <t>Endpoint</t>
        <t>
          <list style="symbols">
            <t>Collection date/time - the date and time of
              data collection</t>
            <t>Endpoint type - the device type of the
              endpoint (e.g., standard computer, printer,
              router, mobile device, tablet, etc.)</t>
            <t>Hardware version/firmware - the hardware or
              firmware version if applicable (e.g., BIOS
              version, firmware revision, etc.)</t>
            <t>Operating system - Operating system name</t>
            <t>Operating system attributes - Operating
              system high-level attributes (e.g., version,
              service pack level, edition, etc.). Would not
              include configuration details.</t>
            <t>Installed software name - List of all
              installed software packages (i.e., software
              inventory). May or may not include software
              installed by the operating system.</t>
            <t>Installed software attributes - Software
              high-level attributes (e.g., version, patch
              level, install path, etc.). Would not include
              configuration details.</t>
            <t>Open ports/enabled services - Listening
              network ports (e.g., TCP, UDP, etc.) as well
              as services that are starting, running,
              suspended, or enabled to run pending some
              event. </t>
            <t>Operating system optional component inventory
              - Operating system specific components and
              software (when NOT already included in the
              general software inventory)</t>
            <t>Location - The physical location of an
              enterprise endpoint (e.g., department, room,
              etc.)</t>
            <t>Purpose - describes how the endpoint is used
              within the enterprise (e.g., end user system,
              database server, public web server, etc.)</t>
            <t>Criticality - An enterprise-defined rating
              (possibly a score) that helps determine the
              criticality of the endpoint. If this endpoint
              is attacked or lost, what is the impact to the
              overall enterprise?</t>
            <t>File system attributes - Attributes that
              describe the file or directory (e.g.,
              versions, size, write date, modified date,
              checksum, etc.)</t>
            <t>Shared libraries - libraries that can be used
              by and installed with many different software
              applications. A shared library vulnerability
              could affect multiple software applications in
              the same way.</t>
            <t>Other software configuration information -
              operating system or software application
              configuration attributes that go beyond that
              basic information already captured (e.g.,
              Microsoft Windows registry, Apple
              configuration profiles, GConf, Proc
              filesystem, text configuration files and their
              parameters, and the installation paths.)</t>
          </list>
        </t>
        <t>External vulnerability description data</t>
        <t>
          <list style="symbols">
            <t>Ingest Date - the date that the vulnerability
              description data was received by the
              enterprise.</t>
            <t>Date of Release - publication or disclosure
              date of the vulnerability description data</t>
            <t>Version - the version or iteration of the
              vulnerability description data according to
              the author, if applicable.</t>
            <t>External vuln ID - external or third-party IDs
              assigned to the vulnerability description
              data. Could be multiple IDs in some cases
              (e.g., vendor bug id, global ID, discoverer's
              local ID, third-party vulnerability database
              ID, etc.).</t>
            <t>Severity Score - the severity of the
              vulnerability description data according to
              the vulnerability description data author, if
              applicable.</t>
          </list>
        </t>
        <t>Assessment Results</t>
        <t>
          <list style="symbols">
            <t>Date of assessment - The date that the
              assessment was performed against an
              endpoint.</t>
            <t>Date of data collection - The age of the data
              used in the assessment to make the endpoint
              status determination.</t>
            <t>Endpoint identification and/or locally
              assigned ID - The ID assigned to the
              enterprise endpoint. Must be assigned for
              tracking results over time.</t>
            <t>Vulnerable software product(s) - The
              vulnerable software products identified as
              being installed on the endpoint.</t>
            <t>Endpoint vulnerability status - Overall
              vulnerability status of the enterprise
              endpoint (i.e., Pass or Fail)</t>
            <t>Vulnerability description - A
              human-consumable description of a
              vulnerability. Supports the human user
              understanding of the vulnerability assessment
              results within an application front-end or
              user interface.</t>
			<t>Vulnerability remediation - The fix, workaround, 
			  or patch information for a vulnerability. This 
			  information may be a part of the vulnerability 
			  description described previously. Note that this 
			  information can change over time due to vendor 
			  patch supercession.
              </t>
          </list>
        </t>
      </section>
    </section>

    <section title="Alignment with Other Existing Works">
      <section title="Critical Security Controls">
        <t>The Council on CyberSecurity's <xref
            target="critical-controls">Critical Security
            Controls</xref> includes security controls for a
          number of use scenarios, some of which are covered
          in this document. This section documents the
          alignment between the Council's controls and the
          relevant elements of the scenario.</t>
        <section title="Continuous Vulnerability Assessment">
          <t>"CSC 4: Continuous Vulnerability Assessment and
            Remediation," which is described by the Council
            on CyberSecurity as "Continuously acquire,
            assess, and take action on new information in
            order to identify vulnerabilities, remediate,
            and minimize the window of opportunity for
            attackers." The scenario described in this
            document is aligned with CSC 4 in multiple
            ways:</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 data 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 data 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-10, which deals with
            vulnerability priority. Vulnerability priority
            in this scenario is discussed in terms of the
            vulnerability description data 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, 4-8, and 4-9, which
            all deal with mitigations and patching, are out
            of scope for this work. Similarly, CSC 4-3
            prescribes performing scans in authenticated
            mode and CSC 4-6 prescribes monitoring logs.
            This scenario does not get into the means by
            which data is collected, focusing on "what" to
            collect rather than "how", and as such does not
            have corresponding sections, although the
            procedures described are not incompatible with
            either of these controls.</t>
          <t>The CSC 4 System Entity Relationship diagram
            and numbered steps directly align with the
            scenario described in this document with the
            exception of step 7 (patch response). Steps 1 -6
            in CSC 4 describe the overall process for
            vulnerability management starting with obtaining
            the vulnerability description data from the
            source in Step 1, to producing assessment
            results in step 6.</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 Council on
            CyberSecurity CSC 1 "Inventory of Authorized and
            Unauthorized Devices" and CSC 2 "Inventory of
            Authorized and Unauthorized Software." This
            scenario documents a process that is specific to
            collecting and maintaining hardware and software
            data attributes for vulnerability assessment
            purposes, but the collection of the hardware
            attributes and software inventory documented in
            the Endpoint Data Collection section that
            follows can also be used for the purpose of
            implementing authorized and unauthorized
            hardware and software management processes
            (e.g., scanning tools looking for unauthorized
            software). Moreover, the ability to accurately
            identify endpoints and, to a lesser degree,
            applications is integral to effective endpoint
            data collection and vulnerability
            management.</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 and 2-4
            by defining a software inventory process and a
            method of obtaining operating system and file
            system attributes. The rest of the items from
            CSC 1 and 2 deal with implementation details and
            would be out-of-scope for this document.</t>
          <t>CSC 2-9 describes the use of a software ID tag
            in XML format. SWID tags
            (https://en.wikipedia.org/wiki/ISO/IEC_19770)
            would also be a possible implementation for the
            Endpoint Data Collection section described in
            this scenario.</t>
        </section>
      </section>
    </section>

    <section title="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 data 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 data is collected and
            saved in a Repository as it is released. The
            vulnerability description data is queued for
            later assessment, then the assessment results
            and vulnerability description data 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>

  </back>

</rfc>