One document matched: draft-ietf-sacm-use-cases-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!--
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3535.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC6733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY I-D.draft-ietf-nea-pt-eap-09 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nea-pt-eap-09.xml">
<!ENTITY I-D.draft-ietf-netmod-interfaces-cfg-12 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-interfaces-cfg-12.xml">
<!ENTITY I-D.draft-ietf-netmod-system-mgmt-08 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-system-mgmt-08.xml">
<!ENTITY I-D.draft-ietf-savi-framework-06 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-savi-framework-06.xml">
-->
]>
<?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="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-sacm-use-cases-03" 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>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Enterprise Use Cases for Security Assessment">Endpoint Security Posture Assessment - Enterprise Use
Cases</title>
<author fullname="David Waltermire" initials="D.W." surname="Waltermire">
<organization abbrev="NIST">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>
<phone/>
<email>david.waltermire@nist.gov</email>
</address>
</author>
<author fullname="David Harrington" initials="D.B.H" surname="Harrington">
<organization>Effective Software</organization>
<address>
<postal>
<street>50 Harding Rd</street>
<city>Portsmouth</city>
<region>NH</region>
<code>03801</code>
<country>USA</country>
</postal>
<phone/>
<email>ietfdbh@comcast.net</email>
</address>
</author>
<date year="2013"/>
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>Security Automation and Continuous Monitoring WG</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>security automation</keyword>
<keyword>continuous monitoring</keyword>
<keyword>endpoint</keyword>
<keyword>posture assessment</keyword>
<keyword>use case</keyword>
<keyword>asset management</keyword>
<keyword>configuration management</keyword>
<keyword>vulnerability management</keyword>
<keyword>content management</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 memo documents a sampling of use cases for securely aggregating configuration and
operational data and evaluating that data to determine an organization's security posture.
From these operational use cases, we can derive common functional capabilities and
requirements to guide development of vendor-neutral, interoperable standards for aggregating
and evaluating data relevant to security posture. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Our goal with this document is to improve our agreement on which problems we're trying to
solve. We need to start with short, simple problem statements and discuss those by email and
in person. Once we agree on which problems we're trying to solve, we can move on to propose
various solutions and decide which ones to use.</t>
<t>This document describes example use cases for endpoint posture assessment for enterprises.
It provides a sampling of use cases for securely aggregating configuration and operational
data and evaluating that data to determine the security posture of individual endpoints, and,
in the aggregate, the security posture of an enterprise.</t>
<t>These use cases cross many IT security information domains. From these operational use
cases, we can derive common concepts, common information expressions, functional
capabilities and requirements to guide development of vendor-neutral, interoperable
standards for aggregating and evaluating data relevant to security posture.</t>
<t>Using this standard data, tools can analyze the state of endpoints, user activities and
behaviour, and evaluate the security posture of an organization. Common expression of
information should enable interoperability between tools (whether customized, commercial, or
freely available), and the ability to automate portions of security processes to gain
efficiency, react to new threats in a timely manner, and free up security personnel to work
on more advanced problems. </t>
<t>The goal is to enable organizations to make informed decisions that support organizational
objectives, to enforce policies for hardening systems, to prevent network misuse, to
quantify business risk, and to collaborate with partners to identify and mitigate threats. </t>
<t>It is expected that use cases for enterprises and for service providers will largely
overlap, but there are additional complications for service providers, especially in
handling information that crosses administrative domains.</t>
<t>The output of endpoint posture assessment is expected to feed into additional processes,
such as policy-based enforcement of acceptable state, verification and monitoring of
security controls, and compliance to regulatory requirements.</t>
</section>
<section title="Endpoint Posture Assessment" anchor="endpoint-posture-assessment">
<t>Endpoint posture assessment involves orchestrating and performing data collection and
evaluating the posture of a given endpoint. Typically, endpoint posture
information is gathered and then published to appropriate data repositories to make
collected information available for further analysis supporting organizational security
processes.</t>
<t>Endpoint posture assessment typically includes: <list style="symbols">
<t>Collecting the attributes of a given endpoint;</t>
<t>Making the attributes available for evaluation and action;
and</t>
<t>Verifying that the endpoint's posture is in compliance with
enterprise standards and policy.</t>
</list>
</t>
<t>As part of these activities it is often necessary to identify and acquire any supporting
content that is needed to drive data collection and analysis.</t>
<t>The following is a typical workflow scenario for assessing endpoint posture: <list
style="numbers">
<t>Some type of trigger initiates the workflow. For example, an operator or an application might trigger the process with a request, or the endpoint might trigger the process using an event-driven notification.
<list style="empty">
<t>QUESTION: Since this is about security automation, can we drop the User and just use Application? Is there a better term to use here? Once the policy is selected, the rest seems like something we definitely would want to automate, so I dropped the User part.</t>
</list>
</t>
<t>A user/application selects a target endpoint to be assessed.</t>
<t>A user/application selects which policies are applicable to the target.</t>
<t>The application determines which (sets of) posture attributes need to be collected for evaluation.
<list style="empty">
<t>QUESTION: It was suggested that mentioning several common acquisition methods, such as local API, WMI, Puppet, DCOM, SNMP, CMDB query, and NEA, without forcing any specific method would be good. I have concerns this could devolve into a "what about my favorite?" contest. OTOH, the charter does specifically call for use of existing standards where applicable, so the use cases document might be a good neutral location for such information, and might force us to consider what types of external interfaces we might need to support when we consider the requirements. It appears that the generic workflow sequence would be a good place to mention such common acquisition methods.</t>
</list>
</t>
<t>The application might retrieve previously collected information from a cache or data store, such as a data store populated by an asset management system.</t>
<t>The application might establish communication with the target, mutually authenticate identities and authorizations, and collect posture attributes from the target.</t>
<t>The application might establish communication with one or more intermediary/agents, mutually authenticate their identities and determine authorizations, and collect posture attributes about the target from the intermediary/agents. Such agents might be local or external.</t>
<t>The application communicates target identity and (sets of) collected attributes to an evaluator, possibly an external process or external system.</t>
<!-- QUESTION: Is state evaluation part of this use case or UC3? -->
<t>The evaluator compares the collected posture attributes with expected values as expressed in policies.
<list style="empty">
<t>QUESTION: Evaluator generates a report or log or notification of some type?</t>
</list>
</t>
</list>
</t>
<t>The following subsections detail specific use cases for data collection, analysis, and
related operations pertaining to the publication and use of supporting content.</t>
<section title="Definition and Publication of Automatable Configuration Guides">
<t>A vendor manufactures a number of specialized endpoint devices. They also develop and maintain an operating system for these devices that
enables end-user organizations to configure a number of security and operational settings. As part of their customer support activities, they publish a number of
secure configuration guides that provide minimum security guidelines for configuring their
devices.</t>
<t>Each guide they produce applies to a specific model of device and version of the
operating system and provides a number of specialized configurations depending on the
devices intended function and what add-on hardware modules and software licenses are
installed on the device. To enable their customers to evaluate the security posture of their
devices to ensure that all appropriate minimal security settings are enabled, they publish
an automatable configuration checklist using a popular data format that defines what
settings to collect using a network management protocol and appropriate values for each
setting. They publish these guides to a public content repository that customers can query
to retrieve applicable guides for their deployed enterprise network infrastructure
endpoints.</t>
<t>Guides could also come from sources other than a device vendor, such as industry groups or
regulatory authorities, or enterprises could develop their own checklists.</t>
</section>
<section title="Automated Checklist Verification">
<t>A financial services company operates a heterogeneous IT environment. In support of their
risk management program, 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 insure adequate coverage of all IT
assets.</t>
<t>To identify what checklists are needed, they use automation to gather an inventory of the
software versions utilized by all IT assets in the enterprise. This data gathering will
involve querying existing data stores of previously collected endpoint software inventory
posture data and actively collecting data from reachable endpoints as needed utilizing
network and systems management protocols. Previously collected data may be provided by
periodic data collection, network connection-driven data collection, or ongoing
event-driven monitoring of endpoint posture changes.</t>
<t>Using the gathered software inventory data and associated asset management data
indicating the organizational defined functions of each endpoint, they locate and query
each vendors content repository for the appropriate checklists. These checklists are
cached locally to reduce the need to download the checklist multiple times.</t>
<t>Driven by the setting data provided in the checklist, a combination of existing
configuration data stores and data collection methods are used to gather the appropriate
posture information from each endpoint. Specific data is gathered based on the defined
enterprise function and software inventory of each endpoint. The data collection paths
used to collect software inventory posture will be used again for this purpose. Once the
data is gathered, the actual state is evaluated against the expected state criteria in
each applicable checklist. Deficiencies are identified and reported to the appropriate
endpoint operators for remedy.</t>
<t>Checklists could also come from sources other than the application or
OS vendor, such as industry groups or regulatory authorities, or enterprises could develop their own checklists.</t>
</section>
<section title="Organizational Software Policy Compliance">
<t>Example Corporation, in support of compliance requirements, has identified a number of
secure baselines for different endpoint types that exist across their enterprise IT
environment. Determining which baseline applies to a given endpoint is based on the
organizationally defined function of the device.</t>
<t>Each baseline, defined using an automatable standardized data format, identifies the
expected hardware, software and patch inventory, and software configuration item values
for each endpoint type. As part of their compliance activities, they require that all
endpoints connecting to their network meet the appropriate baselines. The configuration
settings of each endpoint are collected and compared to the baseline to make sure the
configuration complies with the appropriate baseline whenever it connects to the
network and at least once a day thereafter. These daily compliance checks evaluate the
posture of each endpoint and report on its compliance with the appropriate baseline.</t>
<t>[TODO: Need to speak to how the baselines are identified for a given endpoint connecting
to the network.]</t>
</section>
<section title="Detection of Posture Deviations">
<t>Example corporation has established secure configuration baselines for each different
type of endpoint within their enterprise including: network infrastructure, mobile,
client, and server computing platforms. These baselines define an approved list of
hardware, software (i.e., operating system, applications, and patches), and associated required
configurations. When an endpoint connects to the network, the appropriate baseline
configuration is communicated to the endpoint based on its location in the network, the
expected function of the device, and other asset management data. It is checked for
compliance with the baseline indicating any deviations to the device's operators. 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 allowing operators to be notified
and/or automated action to be taken.</t>
</section>
<section title="Search for Signs of Infection">
<t>The Example Corporation carefully manages endpoint security
with tools that implement the SACM standards. One day, the
endpoint security team at Example Corporation learns about
a stealthy malware package. This malware has just been
discovered but has already spread widely around the world.
Certain signs of infection have been identified (e.g. the
presence of certain files). The security team would like
to know which endpoints owned by the Example Corporation
have been infected with this malware. They use their tools
to search for the signs of infection and generate a list of
infected endpoints.</t>
<t>The search for infected endpoints may be performed by
gathering new endpoint posture information regarding
the presence of the signs of infection. However, this
might miss finding endpoints that were previously
infected but where the infection has now erased itself.
Such previously infected endpoints may be detected
by searching a database of posture information
previously gathered for the signs of infection.
However, this will not work if the malware hides
its presence carefully or if the signs of infection
were not included in previous posture assessments.
In those cases, the database may be used to at least
detect which endpoints previously had software
vulnerable to infection by the malware.
</t>
</section>
<section title="Remediation and Mitigation">
<t>When Example Corporation discovers that one of its
endpoints is vulnerable to infection, a process of
mitigation and remediation is triggered. The first
step is mitigating the impact of the vulnerability,
perhaps by placing the endpoint into a safe network
or blocking network traffic that could infect the
endpoint. The second step is remediation: fixing
the vulnerability. In some cases, these steps may
happen automatically and rapidly. In other cases,
they may require human intervention either to
decide what response is most appropriate or to
complete the steps, which are sometimes complex.
</t>
<t>These same steps of mitigation and remediation may
be used when Example Corporation discovers that one
of its endpoints has become infected with some malware.
Alternatively, the infected endpoint may simply be
monitored or even placed into a honeynet or similar
environment to observe the malware's behavior and
lead the attackers astray.
</t>
<t>QUESTION: Is remediation and mitigation within the scope of the WG, and should the use case be included here?</t>
</section>
<section title="Endpoint Information Analysis and Reporting">
<t>Freed from the drudgery of manual endpoint compliance
monitoring, one of the security administrators at
Example Corporation notices (not using SACM standards)
that five endpoints have been uploading lots of data
to a suspicious server on the Internet. The administrator
queries the SACM database of endpoint posture to see
what software is installed on those endpoints and
finds that they all have a particular program installed.
She then searches the database to see which other
endpoints have that program installed. All these
endpoints are monitored carefully (not using SACM
standards), which allows the administrator to detect
that the other endpoints are also infected.
</t>
<t>This is just one example of the useful analysis
that a skilled analyst can do using the database
of endpoint posture that SACM can provide.
</t>
</section>
<section title="Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra">
<t>A university team receives a grant to do research at a government
facility in the arctic. The only network communications will be via an
intermittent low-speed high-latency high-cost satellite link. During
their extended expedition they will need to show continue 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. Interactive assessments are therefore not
reliable, and since the researchers have very limited funding they need
to minimize how much money they spend on network data.
</t>
<t>Prior to departure they register all equipment with an asset management
system owned by the university, which will also initiate and track
assessments.
</t>
<t>On a periodic basis -- either after a maximum time delta or when the
content repository has received a threshold level of new vulnerability
definitions -- the university uses the information in the asset
management system to put together a collection request for all of the
deployed assets that encompasses the minimal set of artifacts necessary
to evaluate all three security policies as well as vulnerability testing.
</t>
<t>In the case of new critical vulnerabilities this collection request
consists only of the artifacts necessary for those vulnerabilities and
collection is only initiated for those assets that could potentially
have a new vulnerability.
</t>
<t>[Optional] Asset artifacts are cached in a local CMDB. When new
vulnerabilities are reported to the content repository, a request to the
live asset is only done if the artifacts in the CMDB are incomplete
and/or not current enough.
</t>
<t>The collection request is queued for the next window of connectivity.
The deployed assets eventually receive the request, fulfill it, and
queue the results for the next return opportunity.
</t>
<t>The collected artifacts eventually make it back to the university where
the level of compliance and vulnerability expose is calculated and asset
characteristics are compared to what is in the asset management system
for accuracy and completeness.
</t>
</section>
<section title="Vulnerable Endpoint Identification">
<t>Typically vulnerability reports identify an executable or library that is vulnerable, or worst case the software that is vulnerable. This information is used to determine if an organization has one or more endpoints that have exposure to a vulnerability (i.e., what endpoints are vulnerable?). It is often necessary to know where you are running vulnerable code and what configurations are in place on the endpoint and upstream devices (e.g., IDS, firewall) that may limit the exposure. All of this information, along with details on the severity and impact of a vulnerability, is necessary to prioritize remedies.</t>
</section>
<section title="Compromised Endpoint Identification">
<t>Along with knowing if one or more endpoints are vulnerable, it is also important to know if you have been compromised. Indicators of compromise provide details that can be used to identify malware (e.g., file hashes), identify malicious activity (e.g. command and control traffic), presence of unauthorized/malicious configuration items, and other indicators. While important, this goes beyond determining organizational exposure.</t>
</section>
<section title="Suspicious Endpoint Behavior">
<t>This Use Case describes the collaboration between specific participants in an
information security system specific to detecting a connection attempt to a
known-bad Internet host by a botnet zombie that has made its way onto an
organization's Information Technology systems. The primary human actor is
the Security Operations Center Analyst, and the primary software actor is the
configuration assessment tool. Note, however, the dependencies on other
tools, such as asset management, intrusion detection, and messaging.
</t>
</section>
<section title="Traditional endpoint assessment with stored results">
<t>An external trigger initiates an assessment of an endpoint. The Controller uses the data in the Datastore to look up authentication information for the endpoint and passes that along with the assessment request details to the Evaluator. The Evaluator uses the Endpoint information to request taxonomy information from the Collector on the endpoint, which responds with those attributes. The Evaluator uses that taxonomy information along with the information in the original request from the Controller to request the appropriate content from the Content Repository. The Evaluator uses the content to derive the minimal set of endpoint attributes needed to perform the assessment and makes that request. The Evaluator uses the Collector response to do the assessment and returns the results to the Controller. The Controller puts the results in the Datastore.
</t>
</section>
<section title="NAC/NAP connection with no stored results using an endpoint evaluator">
<t>A mobile endpoint makes a VPN connection request. The NAC/NAP broker requests the results of the VPN connection assessment from the Controller. The Controller requests the VPN attributes from a Content Repository. The Controller requests an evaluation of the collected attributes from the Evaluator on the endpoint. The endpoint performs the assessment and returns the results. The Controller completes the original assessment request by returning the results to the NAC/NAP broker, which uses them to set the level of network access allowed to the endpoint.
</t>
<t>QUESTION: I edited these from Gunnar's email of 9/11, to try to reduce the use of "assessment", to focus on collection and evaluation, and deal with use cases rather than architecture. I am not sure I got all the concepts properly identified.</t>
</section>
<section title="NAC/NAP connection with no stored results using a third-party evaluator">
<t>A mobile endpoint makes a VPN connection request. The NAC/NAP broker requests the results of the VPN connection assessment from the Controller. The Controller requests the VPN attributes from a Content Repository. The Controller requests an evaluation of the collected attributes from an Evaluator in the network (rather than trusting an evaluator on the endpoint). The evaluator performs the evaluation and returns the results. The Controller completes the original assessment request by returning the results to the NAC/NAP broker, which uses them to set the level of network access allowed to the endpoint.
</t>
<t>QUESTION: I edited these from Gunnar's email of 9/11, to try to reduce the use of "assessment", to focus on collection and evaluation, and deal with use cases rather than architecture. I am not sure I got all the concepts properly identified.</t>
</section>
<section title="Repository Interaction">
<t>Additional use cases will be identified as we work through other domains.</t>
</section>
<section title="Others...">
<t>Additional use cases will be identified as we work through other domains.</t>
</section>
</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 memo documents, for Informational purposes, use cases for security automation. While
it is about security, it does not affect security.</t>
</section>
<section title="Acknowledgements">
<t>The National Institute of Standards and Technology (NIST) and/or the MITRE Corporation have
developed specifications under the general term "Security Automation" including languages,
protocols, enumerations, and metrics.</t>
<t>Adam Montville edited early versions of this draft.</t>
<t>Kathleen Moriarty and Stephen Hanna contributed text describing the scope of the document.</t>
<t>Steve Hanna provided use cases for Search for Signs of Infection, Remediation and Mitigation, and Endpoint Information Analysis and Reporting.</t>
<t>Gunnar Engelbach provided the use case about Ice Station Zebra.</t>
</section>
<section title="Change Log">
<section title="-02- to -03-">
<t>Expanded the workflow description based on ML input.</t>
<t>Changed the ambiguous "assess" to better separate data collection from evaluation.</t>
<t>Added use case for Search for Signs of Infection.</t>
<t>Added use case for Remediation and Mitigation.</t>
<t>Added use case for Endpoint Information Analysis and Reporting.</t>
<t>Added use case for Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra.</t>
<t>Added use case for Traditional endpoint assessment with stored results.</t>
<t>Added use case for NAC/NAP connection with no stored results using an endpoint evaluator.</t>
<t>Added use case for NAC/NAP connection with no stored results using a third-party evaluator.</t>
<t>Added use case for Compromised Endpoint Identification.</t>
<t>Added use case for Suspicious Endpoint Behavior.</t>
<t>Added use case for Vulnerable Endpoint Identification.</t>
<t>Updated Acknowledgements</t>
<t></t>
</section>
<section title="-01- to -02-">
<t>Changed title</t>
<t>removed section 4, expecting it will be moved into the requirements document.</t>
<t>removed the list of proposed caabilities from section 3.1</t>
<t>Added empty sections for Search for Signs of Infection, Remediation and Mitigation, and Endpoint Information Analysis and Reporting.</t>
<t>Removed Requirements Language section and rfc2119 reference.</t>
<t>Removed unused references (which ended up being all references).</t>
</section>
<section title="-00- to -01-">
<t>
<list style="symbols">
<t>Work on this revision has been focused on document content relating primarily to use of asset management data and functions.</t>
<t>Made significant updates to section 3 including:<list style="symbols">
<t>Reworked introductory text.</t>
<t>Replaced the single example with multiple use cases that focus on more discrete uses of asset management data to support hardware and software inventory, and configuration management use cases.</t>
<t>For one of the use cases, added mapping to functional capabilities used. If popular, this will be added to the other use cases as well.</t>
<t>Additional use cases will be added in the next revision capturing additional discussion from the list.</t>
</list></t>
<t>Made significant updates to section 4 including:<list style="symbols">
<t>Renamed the section heading from "Use Cases" to "Functional Capabilities" since use cases are covered in section 3. This section now extrapolates specific functions that are needed to support the use cases.</t>
<t>Started work to flatten the section, moving select subsections up from under asset management.</t>
<t>Removed the subsections for: Asset Discovery, Endpoint Components and Asset Composition, Asset Resources, and Asset Life Cycle.</t>
<t>Renamed the subsection "Asset Representation Reconciliation" to "Deconfliction of Asset Identities".</t>
<t>Expanded the subsections for: Asset Identification, Asset Characterization, and Deconfliction of Asset Identities.</t>
<t>Added a new subsection for Asset Targeting.</t>
<t>Moved remaining sections to "Other Unedited Content" for future updating.</t>
</list></t>
</list>
</t>
</section>
<section title="draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00">
<t>
<list style="symbols">
<t>Transitioned from individual I/D to WG I/D based on WG consensus call.</t>
<t>Fixed a number of spelling errors. Thank you Erik!</t>
<t>Added keywords to the front matter.</t>
<t>Removed the terminology section from the draft. Terms have been moved to:
draft-dbh-sacm-terminology-00</t>
<t>Removed requirements to be moved into a new I/D.</t>
<t>Extracted the functionality from the examples and made the examples less
prominent.</t>
<t>Renamed "Functional Capabilities and Requirements" section to "Use Cases". <list style="symbols">
<t>Reorganized the "Asset Management" sub-section. Added new text throughout. <list
style="symbols">
<t>Renamed a few sub-section headings.</t>
<t>Added text to the "Asset Characterization" sub-section.</t>
</list>
</t>
</list>
</t>
<t>Renamed "Security Configuration Management" to "Endpoint Configuration Management".
Not sure if the "security" distinction is important. <list style="symbols">
<t>Added new sections, partially integrated existing content.</t>
<t>Additional text is needed in all of the sub-sections.</t>
</list>
</t>
<t>Changed "Security Change Management" to "Endpoint Posture Change Management". Added
new skeletal outline sections for future updates.</t>
</list>
</t>
</section>
<section title="waltermire -04- to -05-">
<t><list style="symbols">
<t> Are we including user activities and behavior in the scope of this work? That seems
to be layer 8 stuff, appropriate to an IDS/IPS application, not Internet stuff. </t>
<t>I removed the references to what the WG will do because this belongs in the charter,
not the (potentially long-lived) use cases document. I removed mention of charter
objectives because the charter may go through multiple iterations over time; there is
a website for hosting the charter; this document is not the correct place for that
discussion.</t>
<t>I moved the discussion of NIST specifications to the acknowledgements section.</t>
<t>Removed the portion of the introduction that describes the chapters; we have a table
of concepts, and the existing text seemed redundant.</t>
<t>Removed marketing claims, to focus on technical concepts and technical analysis, that
would enable subsequent engineering effort.</t>
<t>Removed (commented out in XML) UC2 and UC3, and eliminated some text that referred to
these use cases. </t>
<t>Modified IANA and Security Consideration sections. </t>
<t>Moved Terms to the front, so we can use them in the subsequent text. </t>
<t>Removed the "Key Concepts" section, since the concepts of ORM and IRM were not
otherwise mentioned in the document. This would seem more appropriate to the arch doc
rather than use cases.</t>
<t>Removed role=editor from David Waltermire's info, since there are three editors on
the document. The editor is most important when one person writes the document that
represents the work of multiple people. When there are three editors, this role
marking isn't necessary.</t>
<t>Modified text to describe that this was specific to enterprises, and that it was
expected to overlap with service provider use cases, and described the context of this
scoped work within a larger context of policy enforcement, and verification.</t>
<t>The document had asset management, but the charter mentioned asset, change,
configuration, and vulnerability management, so I added sections for each of those
categories.</t>
<t>Added text to Introduction explaining goal of the document.</t>
<t>Added sections on various example use cases for asset management, config management,
change management, and vulnerability management.</t>
</list></t>
</section>
</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="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC2865;
<!--
&I-D.draft-ietf-nea-pt-eap-09;
&I-D.draft-ietf-netmod-interfaces-cfg-12;
&I-D.draft-ietf-netmod-system-mgmt-08;
&I-D.draft-ietf-savi-framework-06;
&RFC3535;
&RFC3552;
&RFC4949;
&RFC5209;
&RFC5226;
&RFC5792;
&RFC5793;
&RFC6733;
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:28:18 |