draft-ietf-sacm-use-cases-07.txt   draft-ietf-sacm-use-cases-08.txt 
Security Automation and Continuous Monitoring WG D. Waltermire Security Automation and Continuous Monitoring WG D. Waltermire
Internet-Draft NIST Internet-Draft NIST
Intended status: Informational D. Harrington Intended status: Informational D. Harrington
Expires: October 31, 2014 Effective Software Expires: August 30, 2015 Effective Software
April 29, 2014 February 26, 2015
Endpoint Security Posture Assessment - Enterprise Use Cases Endpoint Security Posture Assessment - Enterprise Use Cases
draft-ietf-sacm-use-cases-07 draft-ietf-sacm-use-cases-08
Abstract Abstract
This memo documents a sampling of use cases for securely aggregating This memo documents a sampling of use cases for securely aggregating
configuration and operational data and evaluating that data to configuration and operational data and evaluating that data to
determine an organization's security posture. From these operational determine an organization's security posture. From these operational
use cases, we can derive common functional capabilities and use cases, we can derive common functional capabilities and
requirements to guide development of vendor-neutral, interoperable requirements to guide development of vendor-neutral, interoperable
standards for aggregating and evaluating data relevant to security standards for aggregating and evaluating data relevant to security
posture. posture.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2014. This Internet-Draft will expire on August 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 3 2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 4
2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Define, Publish, Query and Retrieve Security 2.1.1. Define, Publish, Query and Retrieve Security
Automation Data . . . . . . . . . . . . . . . . . . . 5 Automation Data . . . . . . . . . . . . . . . . . . . 5
2.1.2. Endpoint Identification and Assessment Planning . . . 9 2.1.2. Endpoint Identification and Assessment Planning . . . 9
2.1.3. Endpoint Posture Attribute Value Collection . . . . . 10 2.1.3. Endpoint Posture Attribute Value Collection . . . . . 10
2.1.4. Posture Attribute Evaluation . . . . . . . . . . . . 11 2.1.4. Posture Attribute Evaluation . . . . . . . . . . . . 11
2.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 12 2.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Definition and Publication of Automatable 2.2.1. Definition and Publication of Automatable
Configuration Checklists . . . . . . . . . . . . . . 12 Configuration Checklists . . . . . . . . . . . . . . 12
2.2.2. Automated Checklist Verification . . . . . . . . . . 13 2.2.2. Automated Checklist Verification . . . . . . . . . . 13
2.2.3. Detection of Posture Deviations . . . . . . . . . . . 16 2.2.3. Detection of Posture Deviations . . . . . . . . . . . 16
2.2.4. Endpoint Information Analysis and Reporting . . . . . 17 2.2.4. Endpoint Information Analysis and Reporting . . . . . 17
2.2.5. Asynchronous Compliance/Vulnerability Assessment at 2.2.5. Asynchronous Compliance/Vulnerability Assessment at
Ice Station Zebra . . . . . . . . . . . . . . . . . . 17 Ice Station Zebra . . . . . . . . . . . . . . . . . . 18
2.2.6. Identification and Retrieval of Guidance . . . . . . 19 2.2.6. Identification and Retrieval of Guidance . . . . . . 20
2.2.7. Guidance Change Detection . . . . . . . . . . . . . . 20 2.2.7. Guidance Change Detection . . . . . . . . . . . . . . 21
2.2.8. Others... . . . . . . . . . . . . . . . . . . . . . . 20
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. -06- to -07- . . . . . . . . . . . . . . . . . . . . . . 21 6.1. -07- to -08- . . . . . . . . . . . . . . . . . . . . . . 22
6.2. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 21 6.2. -06- to -07- . . . . . . . . . . . . . . . . . . . . . . 22
6.3. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 22 6.3. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 22
6.4. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 23 6.4. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 23
6.5. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 23 6.5. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 24
6.6. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 24 6.6. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 24
6.7. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 24 6.7. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 24
6.8. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 6.8. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 25
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 25 6.9. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
6.9. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 26 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 26
7. Informative References . . . . . . . . . . . . . . . . . . . 27 6.10. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 7. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document describes the core set of use cases for endpoint This document describes the core set of use cases for endpoint
posture assessment for enterprises. It provides a discussion of posture assessment for enterprises. It provides a discussion of
these use cases and associated building block capabilities that these use cases and associated building block capabilities. The
support securely aggregating configuration and operational data and described use cases support:
evaluating that data to determine the security posture of individual
endpoints, and, in the aggregate, the security posture of an
enterprise. Additionally, this document describes a set of usage
scenarios that provide examples for using the use cases and
associated building blocks to address a variety of operational
functions.
These use cases and usage scenarios cross many IT security o securely collecting and aggregating configuration and operational
information domains. From these operational use cases, we can derive data, and
common concepts, common information expressions, functional
capabilities and requirements to guide development of vendor-neutral, o evaluating that data to determine the security posture of
interoperable standards for aggregating and evaluating data relevant individual endpoints.
to security posture.
Additionally, this document describes a set of usage scenarios that
provide examples for using the use cases and associated building
blocks to address a variety of operational functions.
These operational use cases and related usage scenarios cross many IT
security domains. The use cases enable the derivation of common:
o concepts that are expressed as building blocks in this document,
o characteristics to inform development of a requirements document
o information concepts to inform development of an information model
document, and
o functional capabilities to inform development of an architecture
document.
Togther these ideas will be used to guide development of vendor-
neutral, interoperable standards for collecting, aggregating, and
evaluating data relevant to security posture.
Using this standard data, tools can analyze the state of endpoints, Using this standard data, tools can analyze the state of endpoints,
user activities and behaviour, and evaluate the security posture of user activities and behaviour, and evaluate the security posture of
an organization. Common expression of information should enable an organization. Common expression of information should enable
interoperability between tools (whether customized, commercial, or interoperability between tools (whether customized, commercial, or
freely available), and the ability to automate portions of security freely available), and the ability to automate portions of security
processes to gain efficiency, react to new threats in a timely processes to gain efficiency, react to new threats in a timely
manner, and free up security personnel to work on more advanced manner, and free up security personnel to work on more advanced
problems. problems.
skipping to change at page 9, line 42 skipping to change at page 10, line 7
collection or manual input, and organizing attributes collection or manual input, and organizing attributes
associated with an endpoint (e.g., type, organizationally associated with an endpoint (e.g., type, organizationally
expected function/role, hardware/software versions). expected function/role, hardware/software versions).
Identify Endpoint Targets: Determine the candidate endpoint Identify Endpoint Targets: Determine the candidate endpoint
target(s) against which to perform the assessment. Depending target(s) against which to perform the assessment. Depending
on the assessment trigger, a single endpoint or multiple on the assessment trigger, a single endpoint or multiple
endpoints may be targeted based on characterized endpoint endpoints may be targeted based on characterized endpoint
attributes. Guidance describing the assessment to be performed attributes. Guidance describing the assessment to be performed
may contain instructions or references used to determine the may contain instructions or references used to determine the
applicable assessment targets. In this case the Data Query and applicable assessment targets. In this case the Data Query
/or Data Retrieval building blocks (see section 2.1.1) may be and/or Data Retrieval building blocks (see section 2.1.1) may
used to acquire this data. be used to acquire this data.
Endpoint Component Inventory: To determine what applicable desired Endpoint Component Inventory: To determine what applicable desired
states should be assessed, it is first necessary to acquire the states should be assessed, it is first necessary to acquire the
inventory of software, hardware, and accounts associated with inventory of software, hardware, and accounts associated with
the targeted endpoint(s). If the assessment of the endpoint is the targeted endpoint(s). If the assessment of the endpoint is
not dependent on the these details, then this capability is not not dependent on the these details, then this capability is not
required for use in performing the assessment. This process required for use in performing the assessment. This process
can be treated as a collection use case for specific posture can be treated as a collection use case for specific posture
attributes. In this case the building blocks for attributes. In this case the building blocks for
Endpoint Posture Attribute Value Collection (see section 2.1.3) Endpoint Posture Attribute Value Collection (see section 2.1.3)
skipping to change at page 10, line 38 skipping to change at page 10, line 51
This use case describes the process of collecting a set of posture This use case describes the process of collecting a set of posture
attribute values related to one or more endpoints. This use case can attribute values related to one or more endpoints. This use case can
be initiated by a variety of triggers including: be initiated by a variety of triggers including:
1. A posture change or significant event on the endpoint. 1. A posture change or significant event on the endpoint.
2. A network event (e.g., endpoint connects to a network/VPN, 2. A network event (e.g., endpoint connects to a network/VPN,
specific netflow is detected). specific netflow is detected).
3. Due to a scheduled or ad hoc collection task. 3. A scheduled or ad hoc collection task.
The building blocks of this use case are: The building blocks of this use case are:
Collection Guidance Acquisition: If guidance is required to drive Collection Guidance Acquisition: If guidance is required to drive
the collection of posture attributes values, this capability is the collection of posture attributes values, this capability is
used to acquire this data from one or more security automation used to acquire this data from one or more security automation
data stores. Depending on the trigger, the specific guidance data stores. Depending on the trigger, the specific guidance
to acquire might be known. If not, it may be necessary to to acquire might be known. If not, it may be necessary to
determine the guidance to use based on the component inventory determine the guidance to use based on the component inventory
or other assessment criteria. The Data Query and/or Data or other assessment criteria. The Data Query and/or Data
skipping to change at page 11, line 27 skipping to change at page 11, line 39
use case is to support evaluation of actual endpoint state against use case is to support evaluation of actual endpoint state against
the expected state selected for the assessment. the expected state selected for the assessment.
This use case can be initiated by a variety of triggers including: This use case can be initiated by a variety of triggers including:
1. A posture change or significant event on the endpoint. 1. A posture change or significant event on the endpoint.
2. A network event (e.g., endpoint connects to a network/VPN, 2. A network event (e.g., endpoint connects to a network/VPN,
specific netflow is detected). specific netflow is detected).
3. Due to a scheduled or ad hoc evaluation task. 3. A scheduled or ad hoc evaluation task.
The building blocks of this use case are: The building blocks of this use case are:
Collected Posture Change Detection: An operator or application has a Collected Posture Change Detection: An operator or application has a
mechanism to detect the availability of new, or changes to mechanism to detect the availability of new, or changes to
existing, posture attribute values. The timeliness of existing, posture attribute values. The timeliness of
detection may vary from immediate to on-demand. Having the detection may vary from immediate to on-demand. Having the
ability to filter what changes are detected will allow the ability to filter what changes are detected will allow the
operator to focus on the changes that are relevant to their use operator to focus on the changes that are relevant to their use
and will enable evaluation to occur dynamically based on and will enable evaluation to occur dynamically based on
skipping to change at page 14, line 5 skipping to change at page 14, line 18
To identify what checklists are needed, they use automation to gather To identify what checklists are needed, they use automation to gather
an inventory of the software versions utilized by all IT assets in an inventory of the software versions utilized by all IT assets in
the enterprise. This data gathering will involve querying existing the enterprise. This data gathering will involve querying existing
data stores of previously collected endpoint software inventory data stores of previously collected endpoint software inventory
posture data and actively collecting data from reachable endpoints as posture data and actively collecting data from reachable endpoints as
needed utilizing network and systems management protocols. needed utilizing network and systems management protocols.
Previously collected data may be provided by periodic data Previously collected data may be provided by periodic data
collection, network connection-driven data collection, or ongoing collection, network connection-driven data collection, or ongoing
event-driven monitoring of endpoint posture changes. event-driven monitoring of endpoint posture changes.
Using the collected hardware and software inventory data and Appropriate checklists are queried, located and downloaded from the
associated asset characterization data that may indicate the relevant guidance data stores. The specific data stores queried and
organizational defined functions of each endpoint, checklist guidance the specifics of each query may be driven by data including:
is queried, located and downloaded from the appropriate vendor and
3rd-party security automation data store for the appropriate o collected hardware and software inventory data, and
checklists. This guidance is cached locally to reduce the need to
o associated asset characterization data that may indicate the
organizational defined functions of each endpoint.
Checklists may be sourced from guidance data stores maintained by an
application or OS vendor, an industry group, a regulatory authority,
or directly by the enterprise.
The retrieved guidance is cached locally to reduce the need to
retrieve the data multiple times. retrieve the data multiple times.
Driven by the setting data provided in the checklist, a combination Driven by the setting data provided in the checklist, a combination
of existing configuration data stores and data collection methods are of existing configuration data stores and data collection methods are
used to gather the appropriate posture attributes from (or pertaining used to gather the appropriate posture attributes from (or pertaining
to) each endpoint. Specific posture attribute values are gathered to) each endpoint. Specific posture attribute values are gathered
based on the defined enterprise function and software inventory of based on the defined enterprise function and software inventory of
each endpoint. The collection mechanisms used to collect software each endpoint. The collection mechanisms used to collect software
inventory posture will be used again for this purpose. Once the data inventory posture will be used again for this purpose. Once the data
is gathered, the actual state is evaluated against the expected state is gathered, the actual state is evaluated against the expected state
criteria defined in each applicable checklist. The results of this criteria defined in each applicable checklist.
evaluation are provided to appropriate operators and applications to
drive additional business logic.
Checklists could include searching for indicators of compromise on
the endpoint (e.g., file hashes); identifying malicious activity
(e.g. command and control traffic); detecting presence of
unauthorized/malicious software, hardware, and configuration items;
and other indicators.
A checklist can be assessed as a whole, or a specific subset of the A checklist can be assessed as a whole, or a specific subset of the
checklist can be assessed resulting in partial data collection and checklist can be assessed resulting in partial data collection and
evaluation. evaluation.
Checklists could also come from sources other than the application or The results of checklist evaluation are provided to appropriate
OS vendor, such as industry groups or regulatory authorities, or operators and applications to drive additional business logic.
enterprises could develop their own checklists. Specific applications for checklist evaluation results are out-of-
scope for current SACM efforts. Irrespective of specific
applications, the availability, timeliness, and liveness of results
is often of general concern. Network latency and available bandwidth
often create operational constriants that require trade-offs between
these concerns and need to be considered.
While specific applications for checklists results are out-of-scope Uses of checklists and associated evaluation results may include, but
for current SACM efforts, how the data is used may illuminate are not limited to:
specific latency and bandwidth requirements. For this purpose use of
checklist assessment results may include, but are not limited to:
o Detecting endpoint posture deviations as part of a change o Detecting endpoint posture deviations as part of a change
management program to include changes to hardware and software management program to:
inventory including patches, changes to configuration items, and
other posture aspects. * identify missing required patches,
* unauthorized changes to hardware and software inventory, and
* unauthorized changes to configuration items.
o Determining compliance with organizational policies governing o Determining compliance with organizational policies governing
endpoint posture. endpoint posture.
o Searching for current and historic signs of infection by malware
and determining the scope of infection within an enterprise.
o Informing configuration management, patch management, and o Informing configuration management, patch management, and
vulnerability mitigation and remediation decisions. vulnerability mitigation and remediation decisions.
o Searching for current and historic indicators of compromise.
o Detecting current and historic infection by malware and
determining the scope of infection within an enterprise.
o Detecting performance, attack and vulnerable conditions that o Detecting performance, attack and vulnerable conditions that
warrant additional network diagnostics, monitoring, and analysis. warrant additional network diagnostics, monitoring, and analysis.
o Informing network access control decision making for wired, o Informing network access control decision making for wired,
wireless, or VPN connections. wireless, or VPN connections.
This usage scenario employs the following building blocks defined in This usage scenario employs the following building blocks defined in
Section 2.1.1 above: Section 2.1.1 above:
Endpoint Discovery: The purpose of discovery is to determine the Endpoint Discovery: The purpose of discovery is to determine the
skipping to change at page 17, line 26 skipping to change at page 17, line 48
standards), which allows the administrator to detect that the other standards), which allows the administrator to detect that the other
endpoints are also infected. endpoints are also infected.
This is just one example of the useful analysis that a skilled This is just one example of the useful analysis that a skilled
analyst can do using data stores of endpoint posture. analyst can do using data stores of endpoint posture.
This usage scenario employs the following building blocks defined in This usage scenario employs the following building blocks defined in
Section 2.1.1 above: Section 2.1.1 above:
Posture Attribute Value Query: Previously collected posture Posture Attribute Value Query: Previously collected posture
attribute values are queried from the appropriate data stores attribute values for the target endpoint(s) are queried from
for the target endpoint(s). the appropriate data stores using a standardized method.
This usage scenario highlights the need to query a repository for This usage scenario highlights the need to query a repository for
attributes to see which attributes certain endpoints have in common. attributes to see which attributes certain endpoints have in common.
2.2.5. Asynchronous Compliance/Vulnerability Assessment at Ice Station 2.2.5. Asynchronous Compliance/Vulnerability Assessment at Ice Station
Zebra Zebra
A university team receives a grant to do research at a government A university team receives a grant to do research at a government
facility in the arctic. The only network communications will be via facility in the arctic. The only network communications will be via
an intermittent low-speed high-latency high-cost satellite link. an intermittent low-speed high-latency high-cost satellite link.
skipping to change at page 20, line 45 skipping to change at page 21, line 28
Section 2.1.1 above: Section 2.1.1 above:
Data Change Detection: Allows an operator or application to identify Data Change Detection: Allows an operator or application to identify
guidance changes in a security automation data store which they guidance changes in a security automation data store which they
have been authorized to access. have been authorized to access.
Data Retrieval: If data locations are provided by the change Data Retrieval: If data locations are provided by the change
detection mechanism, then specific guidance entries can be detection mechanism, then specific guidance entries can be
retrieved and possibly cached locally. retrieved and possibly cached locally.
2.2.8. Others...
Additional usage scenarios will be identified as we work through
other domains.
3. IANA Considerations 3. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
4. Security Considerations 4. Security Considerations
This memo documents, for Informational purposes, use cases for This memo documents, for Informational purposes, use cases for
security automation. While it is about security, it does not affect security automation. Specific security considerations will be
security. provided in related documents (e.g., requirements, architecture,
information model, data model, protocol) as appropriate to the
function described in each related document.
5. Acknowledgements 5. Acknowledgements
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.
Adam Montville edited early versions of this draft. Adam Montville edited early versions of this draft.
Kathleen Moriarty, and Stephen Hanna contributed text describing the Kathleen Moriarty, and Stephen Hanna contributed text describing the
scope of the document. scope of the document.
Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa
Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and
Aron Woland provided use cases text for various revisions of this Aron Woland provided use cases text for various revisions of this
draft. draft.
6. Change Log 6. Change Log
6.1. -06- to -07- 6.1. -07- to -08-
Reworked long sentences throughout the document by shortening or
using bulleted lists.
Re-ordered and condensed text in the "Automated Checklist
Verification" sub-section to improve the conceptual presentation and
to clarify longer sentences.
Clarified that the "Posture Attribute Value Query" building block
represents a standardized interface in the context of SACM.
Removed the "others" sub-section within the "usage scenarios"
section.
Updated the "Security Considerations" section to identify that actual
SACM security considerations will be discussed in the appropriate
related documents.
6.2. -06- to -07-
A number of edits were made to section 2 to resolve open questions in A number of edits were made to section 2 to resolve open questions in
the draft based on meeting and mailing list discussions. the draft based on meeting and mailing list discussions.
Section 2.1.5 was merged into section 2.1.4. Section 2.1.5 was merged into section 2.1.4.
6.2. -05- to -06- 6.3. -05- to -06-
Updated the "Introduction" section to better reflect the use case, Updated the "Introduction" section to better reflect the use case,
building block, and usage scenario structure changes from previous building block, and usage scenario structure changes from previous
revisions. revisions.
Updated most uses of the terms "content" and "content repository" to Updated most uses of the terms "content" and "content repository" to
use "guidance" and "security automation data store" respectively. use "guidance" and "security automation data store" respectively.
In section 2.1.1, added a discussion of different data types and In section 2.1.1, added a discussion of different data types and
renamed "content" to "data" in the building block names. renamed "content" to "data" in the building block names.
skipping to change at page 22, line 15 skipping to change at page 23, line 8
In section 2.1.2, separated out the building block concepts of In section 2.1.2, separated out the building block concepts of
"Endpoint Discovery" and "Endpoint Characterization" based on mailing "Endpoint Discovery" and "Endpoint Characterization" based on mailing
list discussions. list discussions.
Addressed some open questions throughout the draft based on consensus Addressed some open questions throughout the draft based on consensus
from mailing list discussions and the two virtual interim meetings. from mailing list discussions and the two virtual interim meetings.
Changed many section/sub-section names to better reflect their Changed many section/sub-section names to better reflect their
content. content.
6.3. -04- to -05- 6.4. -04- to -05-
Changes in this revision are focused on section 2 and the subsequent Changes in this revision are focused on section 2 and the subsequent
subsections: subsections:
o Moved existing use cases to a subsection titled "Usage Scenarios". o Moved existing use cases to a subsection titled "Usage Scenarios".
o Added a new subsection titled "Use Cases" to describe the common o Added a new subsection titled "Use Cases" to describe the common
use cases and building blocks used to address the "Usage use cases and building blocks used to address the "Usage
Scenarios". The new use cases are: Scenarios". The new use cases are:
skipping to change at page 23, line 16 skipping to change at page 24, line 8
new security vulnerability content that match a selection filter" new security vulnerability content that match a selection filter"
to "Content Change Detection" and generalized the description to to "Content Change Detection" and generalized the description to
be neutral to implementation approaches. be neutral to implementation approaches.
o Removed out-of-scope usage scenarios: "Remediation and Mitigation" o Removed out-of-scope usage scenarios: "Remediation and Mitigation"
and "Direct Human Retrieval of Ancillary Materials" and "Direct Human Retrieval of Ancillary Materials"
Updated acknowledgements to recognize those that helped with editing Updated acknowledgements to recognize those that helped with editing
the use case text. the use case text.
6.4. -03- to -04- 6.5. -03- to -04-
Added four new use cases regarding content repository. Added four new use cases regarding content repository.
6.5. -02- to -03- 6.6. -02- to -03-
Expanded the workflow description based on ML input. Expanded the workflow description based on ML input.
Changed the ambiguous "assess" to better separate data collection Changed the ambiguous "assess" to better separate data collection
from evaluation. from evaluation.
Added use case for Search for Signs of Infection. Added use case for Search for Signs of Infection.
Added use case for Remediation and Mitigation. Added use case for Remediation and Mitigation.
skipping to change at page 24, line 5 skipping to change at page 24, line 45
third-party evaluator. third-party evaluator.
Added use case for Compromised Endpoint Identification. Added use case for Compromised Endpoint Identification.
Added use case for Suspicious Endpoint Behavior. Added use case for Suspicious Endpoint Behavior.
Added use case for Vulnerable Endpoint Identification. Added use case for Vulnerable Endpoint Identification.
Updated Acknowledgements Updated Acknowledgements
6.6. -01- to -02- 6.7. -01- to -02-
Changed title Changed title
removed section 4, expecting it will be moved into the requirements removed section 4, expecting it will be moved into the requirements
document. document.
removed the list of proposed capabilities from section 3.1 removed the list of proposed capabilities from section 3.1
Added empty sections for Search for Signs of Infection, Remediation Added empty sections for Search for Signs of Infection, Remediation
and Mitigation, and Endpoint Information Analysis and Reporting. and Mitigation, and Endpoint Information Analysis and Reporting.
Removed Requirements Language section and rfc2119 reference. Removed Requirements Language section and rfc2119 reference.
Removed unused references (which ended up being all references). Removed unused references (which ended up being all references).
6.7. -00- to -01- 6.8. -00- to -01-
o Work on this revision has been focused on document content o Work on this revision has been focused on document content
relating primarily to use of asset management data and functions. relating primarily to use of asset management data and functions.
o Made significant updates to section 3 including: o Made significant updates to section 3 including:
* Reworked introductory text. * Reworked introductory text.
* Replaced the single example with multiple use cases that focus * Replaced the single example with multiple use cases that focus
on more discrete uses of asset management data to support on more discrete uses of asset management data to support
skipping to change at page 25, line 20 skipping to change at page 26, line 10
"Deconfliction of Asset Identities". "Deconfliction of Asset Identities".
* Expanded the subsections for: Asset Identification, Asset * Expanded the subsections for: Asset Identification, Asset
Characterization, and Deconfliction of Asset Identities. Characterization, and Deconfliction of Asset Identities.
* Added a new subsection for Asset Targeting. * Added a new subsection for Asset Targeting.
* Moved remaining sections to "Other Unedited Content" for future * Moved remaining sections to "Other Unedited Content" for future
updating. updating.
6.8. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 6.9. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00
o Transitioned from individual I/D to WG I/D based on WG consensus o Transitioned from individual I/D to WG I/D based on WG consensus
call. call.
o Fixed a number of spelling errors. Thank you Erik! o Fixed a number of spelling errors. Thank you Erik!
o Added keywords to the front matter. o Added keywords to the front matter.
o Removed the terminology section from the draft. Terms have been o Removed the terminology section from the draft. Terms have been
moved to: draft-dbh-sacm-terminology-00 moved to: draft-dbh-sacm-terminology-00
skipping to change at page 26, line 11 skipping to change at page 27, line 5
is important. is important.
* Added new sections, partially integrated existing content. * Added new sections, partially integrated existing content.
* Additional text is needed in all of the sub-sections. * Additional text is needed in all of the sub-sections.
o Changed "Security Change Management" to "Endpoint Posture Change o Changed "Security Change Management" to "Endpoint Posture Change
Management". Added new skeletal outline sections for future Management". Added new skeletal outline sections for future
updates. updates.
6.9. waltermire -04- to -05- 6.10. waltermire -04- to -05-
o Are we including user activities and behavior in the scope of this o 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 work? That seems to be layer 8 stuff, appropriate to an IDS/IPS
application, not Internet stuff. application, not Internet stuff.
o Removed the references to what the WG will do because this belongs o Removed the references to what the WG will do because this belongs
in the charter, not the (potentially long-lived) use cases in the charter, not the (potentially long-lived) use cases
document. I removed mention of charter objectives because the document. I removed mention of charter objectives because the
charter may go through multiple iterations over time; there is a charter may go through multiple iterations over time; there is a
website for hosting the charter; this document is not the correct website for hosting the charter; this document is not the correct
 End of changes. 33 change blocks. 
94 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/