One document matched: draft-coffin-sacm-vuln-scenario-00.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-00" 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="October" year="2015"/>
<!-- 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 "Endpoint Security
Posture Assessment: Enterprise Use Cases" <xref target="RFC7632"/>.
It begins with an enterprise ingesting a vulnerability report and ends at the point
of identifying affected endpoints. Processes that specifically overlap between this
scenario and RFC 7632 will be noted where applicable. Specifically, the relationship
between this document and the RFC 7632 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 can
also inform engineering work on protocol and data model development. The focus of
the document is entirely intra-organizational and covers enterprise handling of
vulnerability reports. 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
a vulnerability report.</t>
<t>For the purposes of this document, the term "vulnerability report" is intended to
mean: "A publication 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 a report 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.</t>
<t>This document makes no attempt to provide a definition of a normalized data format
for vulnerability reports. Also, it does not attempt to define procedures by which
a vulnerability discoverer coordinates the release of a report with 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 a
vulnerability report, and that the report 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 a potentially relevant
vulnerability report.</t>
<t>Does not discuss how the enterprise collects that report.</t>
<t>Does not discuss how the enterprise assesses the authenticity of the report.</t>
<t>Does not discuss parsing of the report 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.</t>
<t>The document assumes that the enterprise has a means of extracting relevant
infomation about enterprise endpoints. Moreover, this extracted information is
expressed in a format that is compatible with the information extracted from the
vulnerability report. 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 alert
information are 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 report 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 reports are 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 reports and endpoint assessment results.</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 a given vulnerability report.)</t>
<t>Does not provide guidance 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 basic system
information from them. This occurs prior to the receipt of any specific vulnerability report
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 CMDB.</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 systems need to
be assessed, but also allows for the unique identification of each endpoint. Unique
endpoint IDs are used to allow for systems to be tracked over time and also allow for
proper counts of assets during inventories and other similar collections. Endpoint identity
can be established by collecting certain system properties that allow persistent tracking
of the endpoints. 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.</t>
<t>This sub-step aligns with the Endpoint Discovery, Endpoint Characterization (automated
collection data only), 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="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 basic information to collect from endpoints in this pre-vulnerability report and
pre-assessment process could include:</t>
<t>
<list style="symbols">
<t>Endpoint type - e.g., standard computer, printer, router, mobile device, tablet,
etc.</t>
<t>Hardware version/firmware</t>
<t>Operating system - Windows, Linux, OSX, Android</t>
<t>Operating system attributes - e.g., version, patch level, service pack level,
internationalized or localized version, etc.</t>
<t>Installed software inventory - important for later assessments. Would include the
software names and versions (and possibly other high-level attributes). Could be used
to quickly determine endpoint applicability in later vulnerability reports.</t>
<t>Open ports/running services</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>
</list>
</t>
<t>In addition to the above, the possibility should be left open for enterprises to define
their own custom queries to gather enterprise-specific system attributes that are deemed
of interest to regular enterprise operations.</t>
<t>Human-assigned endpoint attributes are yet another type of data item that could be
collected here. This would include any attributes that cannot be collected
programmatically. The attributes could be manually entered into a CMDB by a human after
the initial data collection occurs. The attributes could help with system categorization
and may have influence on later prioritizations. The human-assigned attributes could
include:</t>
<t>
<list style="symbols">
<t>Location - physical location, department, room, etc.</t>
<t>Role - The function that the endpoint serves within the enterprise (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>This sub-step aligns with the Data Publication building block capability because this
section involves storage of endpoint attributes within an enterprise CMDB. This sub-step
also aligns with the Endpoint Characterization (both manual and automated) 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="Vulnerability Reports">
<t>The next step in the Vulnerability Assessment scenario begins after a vulnerability report
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 reports, the
enterprise should store all received and processed vulnerability reports in a CMDB. These
stored vulnerability reports can be used and compared with later vulnerability reports for
the purpose of duplicate detection and in some cases guidance on how to handle similar
issues.</t>
<t>All vulnerability reports should be assigned an internal tracking ID by the enterprise as
a first step. Incoming vulnerability reports might not have a global identifier when they
are received, and might never have one assigned.</t>
<t>High-level vulnerability report metadata to store would include:</t>
<t>
<list style="symbols">
<t>Ingest Date - the date that the report was received by the enterprise.</t>
<t>Date of Report Release (i.e., publication or disclosure date) - Some older reports 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 vulnerable. Sometimes this information will help to differentiate between
similar vulnerability reports.</t>
<t>Report Version - the version or iteration of the report according to the report author,
if applicable.</t>
<t>External Report ID(s) (if applicable) - any external or third-party IDs assigned to
the report 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, all vulnerability reports would be stored with the
information extracted from them that is to be used in the applicability and assessment
process.</t>
<t>This step aligns with the Data Publication and Data Retrieval building block capabilities
because this section details storage of vulnerability reports within an enterprise CMDB and
later retrieval of the same.</t>
</section>
<section title="Endpoint Applicability and Assessment">
<t>When a new vulnerability report is received by the enterprise, applicable enterprise
endpoints must be identified and assessed. Endpoints are first examined using 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 report.</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 would already 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 report. In these cases, a secondary, targeted vulnerability assessment is
required. Administrators may want to evaluate applicability to the vulnerability report
iteratively. Specifically, the process would compare against pre-collected data first
(easy to do and the data is stored in a CMDB), 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>
<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>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.</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) - such as Microsoft
Windows registry queries, 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>
<t>This sub-step aligns with the Data Publication building block capability because this
section details storage of endpoint attributes within an enterprise CMDB. The sub-step
also aligns with the Collection Guidance Acquisition building block capability since
the vulnerability report (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="Assessment Reports">
<t>An assessment report presents 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 report, the endpoint
attributes that indicate applicability, or other information needed to respond to the
report determination. Data in this step is stored for auditing and forensic purposes.</t>
<t>The following details are important to track in an assessment report. Note that
information may be "included" by providing pointers to other records stored in a CMDB.</t>
<t>
<list style="symbols">
<t>Date of assessment - The date that the assessment was performed. To understand when
the data was compared against the vulnerability report 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 report ID - Allows linkage to the correct vulnerability report. The ID
could be internally or externally defined (or both).</t>
<t>Vulnerable software product(s) - Identifies the software products on the endpoint that
resulted in the endpoint being declared applicable. Since some vulnerability reports
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
report. 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 report within the application front-end
or interface.</t>
</list>
</t>
<t>This step aligns with the Data Publication and Data Retrieval building block capabilities
because this section details storage of vulnerability assessment reports within an
enterprise CMDB and later retrieval of the same.</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"/> . It is for
informational purposes only. As a result, there are no specific security considerations.</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>
</references>
<section title="Continuous Vulnerability Assessment">
<t>It is not sufficient to perform a single assessment when a vulnerability report 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
such an assessment completes. For example, new endpoints can be introduced to the
environment which have old software or are not up-to-date with patches. This is
especially true of BYOD environments. Another example is where unauthorized or
obsolete software is installed on an existing endpoint by enterprise users after a
vulnerability report and initial assessment has taken place. Moreover, enterprises
might not wish to, or be able to, assess all vulnerability reports 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 report that led to this assessment. The assessment
could immediately follow ingest of the report, could be delayed, or the assessment
might represent a reassessment of some report against which endpoints had previously
been assessed. Moreover, the scenario incorporates long-term storage of collected
data, vulnerability reports, and assessment results in order to facilitate meaningful
ongoing reassessment.</t>
</section>
<section title="Priority">
<t>Priorities associated with both the reports 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 report scenario as they separable
issues with their own sets of requirements.</t>
<t>Priority in regard to vulnerability reports, can be viewed in a couple of different
ways within an enterprise. The assessment prioritization involves prioritization of
the vulnerability report assessment process. This determines which vulnerability
reports are assessed, and in what order they are 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 reports 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 report.</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 role 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>
</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>
<ttcol align="center">Vuln. Report</ttcol>
<ttcol align="center">Init. Collection</ttcol>
<ttcol align="center">Assessment</ttcol>
<ttcol align="center">Reporting</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>Role</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 Report*</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>Report Version</c>
<c>X</c>
<c/>
<c>X</c>
<c/>
<c>External Report ID</c>
<c>X</c>
<c/>
<c>X</c>
<c>X</c>
<c>Severity Score</c>
<c/>
<c/>
<c/>
<c>X</c>
<c>*Assessment Report*</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>
</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)</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/services - Listening network ports (TCP and UDP) and running
services</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 (department, room,
etc.)</t>
<t>Role - The function that the endpoint serves 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 state of a 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 (Microsoft Windows registry, text configuration files and
their parameters, and the installation paths.)</t>
</list>
</t>
<t>External Vulnerability Report</t>
<t>
<list style="symbols">
<t>Ingest Date - the date that the report was received by the enterprise.</t>
<t>Date of Release - publication or disclosure date of the vulnerability
report</t>
<t>Report Version - the version or iteration of the report according to the
report author, if applicable.</t>
<t>External Report ID - external or third-party IDs assigned to the report.
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 report according to the report author,
if applicable.</t>
</list>
</t>
<t>Assessment Report</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 report within an application front-end or user interface.</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 reports 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
reports as described in CSC 4-4.</t>
<t>Both CSC 4-2 and 4-7 are made possible by writing information to a CMDB 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 report 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 report from the source in
Step 1, to producing an assessment report 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 reports 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 a vulnerability report 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 does describe vulnerability assessment in particular, and
aligns exactly with the scenario described in this document. The endpoint assets
are identified and associated data is published in a CMDB. Vulnerability reports
are collected and saved in a CMDB as they are released. The reports are queued for
later assessment, then the results and resulting vulnerability reports are stored
after assessment. The only real difference in this SACM usage scenario is that of
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 result data set should include. In the case of vulnerability
assessment reports, 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 the reporting of results. The concern here is with
vulnerability reporting, 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, functions, 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.</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 14:00:27 |