draft-ietf-sacm-use-cases-06.txt   draft-ietf-sacm-use-cases-07.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: September 4, 2014 Effective Software Expires: October 31, 2014 Effective Software
March 3, 2014 April 29, 2014
Endpoint Security Posture Assessment - Enterprise Use Cases Endpoint Security Posture Assessment - Enterprise Use Cases
draft-ietf-sacm-use-cases-06 draft-ietf-sacm-use-cases-07
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 September 4, 2014. This Internet-Draft will expire on October 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 3 2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 3
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 Evaluation . . . . . . . . . . . . . . . . . 11 2.1.4. Posture Attribute Evaluation . . . . . . . . . . . . 11
2.1.5. Mining the Database . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . 13 Configuration Checklists . . . . . . . . . . . . . . 12
2.2.2. Automated Checklist Verification . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 18 Ice Station Zebra . . . . . . . . . . . . . . . . . . 17
2.2.6. Identification and Retrieval of Guidance . . . . . . 20 2.2.6. Identification and Retrieval of Guidance . . . . . . 19
2.2.7. Guidance Change Detection . . . . . . . . . . . . . . 21 2.2.7. Guidance Change Detection . . . . . . . . . . . . . . 20
2.2.8. Others... . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 22 6.1. -06- to -07- . . . . . . . . . . . . . . . . . . . . . . 21
6.2. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 22 6.2. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 21
6.3. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 23 6.3. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 22
6.4. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 23 6.4. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 23
6.5. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 24 6.5. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 23
6.6. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 24 6.6. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 24
6.7. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 6.7. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 24
6.8. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 25 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 25
6.8. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 26 6.9. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 26
7. Informative References . . . . . . . . . . . . . . . . . . . 27 7. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 that
support securely aggregating configuration and operational data and support securely aggregating configuration and operational data and
evaluating that data to determine the security posture of individual evaluating that data to determine the security posture of individual
endpoints, and, in the aggregate, the security posture of an endpoints, and, in the aggregate, the security posture of an
enterprise. Additionally, this document describes a set of usage enterprise. Additionally, this document describes a set of usage
scenarios that provide examples for using the use cases and scenarios that provide examples for using the use cases and
associated building blocks to address a variety of operational associated building blocks to address a variety of operational
functions. functions.
These use cases and usage sceneries cross many IT security These use cases and usage scenarios cross many IT security
information domains. From these operational use cases, we can derive information domains. From these operational use cases, we can derive
common concepts, common information expressions, functional common concepts, common information expressions, functional
capabilities and requirements to guide development of vendor-neutral, capabilities and requirements to guide development of vendor-neutral,
interoperable standards for aggregating and evaluating data relevant interoperable standards for aggregating and evaluating data relevant
to security posture. 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
skipping to change at page 9, line 25 skipping to change at page 9, line 25
This use case describes the process of discovering endpoints, This use case describes the process of discovering endpoints,
understanding their composition, identifying the desired state to understanding their composition, identifying the desired state to
assess against, and calculating what posture attributes to collect to assess against, and calculating what posture attributes to collect to
enable evaluation. This process may be a set of manual, automated, enable evaluation. This process may be a set of manual, automated,
or hybrid steps that are performed for each assessment. or hybrid steps that are performed for each assessment.
The building blocks of this use case are: The building blocks of this use case are:
Endpoint Discovery: To determine the current or historic presence of Endpoint Discovery: To determine the current or historic presence of
endpoints in the environment that are available for posture endpoints in the environment that are available for posture
assessment. assessment. Endpoints are identified in support of discovery
using information previously obtained or by using other
collection mechanisms to gather identification and
characterization data. Previously obtained data may originate
from sources such as network authentication exchanges.
Endpoint Characterization: The act of acquiring, through automated Endpoint Characterization: The act of acquiring, through automated
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 and
/or Data Retrieval building blocks (see section 2.1.1) may be /or Data Retrieval building blocks (see section 2.1.1) may be
used to acquire this data. used to acquire this data.
QUESTION: Should this include authentication of the target?
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 dependant on the component inventory, then this capability not dependent on the these details, then this capability is not
is not required for use in performing the assessment. This required for use in performing the assessment. This process
process can be treated as a collection use case for specific can be treated as a collection use case for specific posture
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)
can be used. can be used.
Posture Attribute Identification: Once the endpoint targets and Posture Attribute Identification: Once the endpoint targets and
component inventory is known, it is then necessary to calculate their associated asset inventory is known, it is then necessary
what posture attributes are required to be collected to perform to calculate what posture attributes are required to be
the evaluation. If this is driven by guidance, then the Data collected to perform the desired evaluation. When available,
Query and/or Data Retrieval building blocks (see section 2.1.1) existing posture data is queried for suitability using the Data
may be used to acquire this data. Query building block (see section 2.1.1). Such posture data is
suitable if it is complete and current enough for use in the
QUESTION: Are we missing a building block that determines what evaluation. Any unsuitable posture data is identified for
previously collected data, if any, is suitable for evaluation and collection.
what data needs to be actually collected? Should a building block be
identified that evaluates existing data to determine if it is current
enough for use in the evaluation or if current data should be
collected anyway according to a policy?
COMMENT(DR): Probably yes, taking into account usage scenarios like If this is driven by guidance, then the Data Query and/or Data
2.2.2, 2.2.3 which rely on historical data. Retrieval building blocks (see section 2.1.1) may be used to
acquire this data.
At this point the set of posture attribute values to use for At this point the set of posture attribute values to use for
evaluation are known and they can be collected if necessary (see evaluation are known and they can be collected if necessary (see
section 2.1.3). section 2.1.3).
2.1.3. Endpoint Posture Attribute Value Collection 2.1.3. Endpoint Posture Attribute Value Collection
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:
skipping to change at page 11, line 13 skipping to change at page 11, line 13
acquire this guidance. acquire this guidance.
Posture Attribute Value Collection: The accumulation of posture Posture Attribute Value Collection: The accumulation of posture
attribute values. This may be based on collection guidance attribute values. This may be based on collection guidance
that is associated with the posture attributes. that is associated with the posture attributes.
Once the posture attribute values are collected, they may be Once the posture attribute values are collected, they may be
persisted for later use or they may be immediately used for posture persisted for later use or they may be immediately used for posture
evaluation. evaluation.
2.1.4. Posture Evaluation 2.1.4. Posture Attribute Evaluation
This use case describes the process of evaluating collected posture This use case represents the action of analyzing collected posture
attribute values representing actual endpoint state against the attribute values as part of an assessment. The primary focus of this
expected state selected for the assessment. This use case can be use case is to support evaluation of actual endpoint state against
initiated by a variety of triggers including: the expected state selected for the assessment.
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. Due to 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
mechanism to detect the availability of new, or changes to
existing, posture attribute values. The timeliness of
detection may vary from immediate to on-demand. Having the
ability to filter what changes are detected will allow the
operator to focus on the changes that are relevant to their use
and will enable evaluation to occur dynamically based on
detected changes.
Posture Attribute Value Query: If previously collected posture Posture Attribute Value Query: If previously collected posture
attribute values are needed, the appropriate data stores are attribute values are needed, the appropriate data stores are
queried to retrieve them. If all posture attribute values are queried to retrieve them using the Data Query building block
(see section 2.1.1). If all posture attribute values are
provided directly for evaluation, then this capability may not provided directly for evaluation, then this capability may not
be needed. be needed.
Evaluation Guidance Acquisition: If guidance is required to drive Evaluation Guidance Acquisition: If guidance is required to drive
the evaluation of posture attributes values, this capability is the evaluation 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
Retrieval building blocks (see section 2.1.1) may be used to Retrieval building blocks (see section 2.1.1) may be used to
acquire this guidance. acquire this guidance.
Posture Attribute Evaluation: The comparison of posture attribute Posture Attribute Evaluation: The comparison of posture attribute
values against their expected results as expressed in the values against their expected values as expressed in the
specified guidance. The result of this comparison is output as specified guidance. The result of this comparison is output as
a set of posture evaluation results. a set of posture evaluation results. Such results include
metadata required to provide a level of assurance with respect
to the posture attribute data and, therefore, evaluation
results. Examples of such metadata include provenance and or
availability data.
QUESTION: What if data is unavailable or is not current enough While the primary focus of this use cases is around enabling the
to support the evaluation? This could be caused if collection comparison of expected vs. actual state, the same building blocks can
did not occur (for some reason) and previous collection was too support other analysis techniques that are applied to collected
old. posture attribute data (e.g., trending, historic analysis).
Completion of this process represents a complete assessment cycle as Completion of this process represents a complete assessment cycle as
defined in Section 2. defined in Section 2.
QUESTION: Since this indicates completion of the section 2 process, I
would expect section 3 to follow. But section continues with 2.1.5?
2.1.5. Mining the Database
This use case describes the need to analyze previously collected
posture attribute values from one or more endpoints. This is an
alternate use case to Posture Evaluation (see section 2.1.4) that
uses collected posture attributes values for analysis processes that
may do more than evaluating expected vs. actual state(s).
The building blocks of this use case are:
Query: Query a data store for specific posture attribute values.
Change Detection: An operator should have a mechanism to detect the
availability of new or changes to existing posture attribute
values. The timeliness of detection may vary from immediate to
on demand. Having the ability to filter what changes are
detected will allow the operator to focus on the changes that
are relevant to their use.
QUESTION: Does this warrant a separate use case, or should this be
incorporated into the previous use case?
COMMENT(DBH): I think the 2.1.5 use case is a subset of 2.1.4 use
case, specifically, the query of existing data is covered in Posture
Attribute Value Query, condition 1. I think Posture Attribute Value
Query should be modified to include the change detection, as part of
establishing what needs to be queried.
2.2. Usage Scenarios 2.2. Usage Scenarios
In this section, we describe a number of usage scenarios that utilize In this section, we describe a number of usage scenarios that utilize
aspects of endpoint posture assessment. These are examples of common aspects of endpoint posture assessment. These are examples of common
problems that can be solved with the building blocks defined above. problems that can be solved with the building blocks defined above.
COMMENT(DBH): I don't see "Search for signs of Infection",
"Vulnerability Endpoint Identification", "Compromised Endpoint
Identification", and "Suspicious Endpoint behavior", which were in
-04-. They were moved into "Automated Checklist Verification". But
the original usage scenarios did not mention checklists. Are we now
limiting SACM to a checklist-driven approaches? Do the authors of
the text in -04- agree that their use cases/usage scenarios are
adequately captured in -05-?
2.2.1. Definition and Publication of Automatable Configuration 2.2.1. Definition and Publication of Automatable Configuration
Checklists Checklists
A vendor manufactures a number of specialized endpoint devices. They A vendor manufactures a number of specialized endpoint devices. They
also develop and maintain an operating system for these devices that also develop and maintain an operating system for these devices that
enables end-user organizations to configure a number of security and enables end-user organizations to configure a number of security and
operational settings. As part of their customer support activities, operational settings. As part of their customer support activities,
they publish a number of secure configuration guides that provide they publish a number of secure configuration guides that provide
minimum security guidelines for configuring their devices. minimum security guidelines for configuring their devices.
skipping to change at page 18, line 5 skipping to change at page 17, line 29
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 are queried from the appropriate data stores
for the target endpoint(s). for the target endpoint(s).
QUESTION: Should we include other building blocks here?
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.
During their extended expedition they will need to show continue During their extended expedition they will need to show continue
skipping to change at page 19, line 31 skipping to change at page 19, line 5
Collection Guidance Acquisition: Due to intermittent communication Collection Guidance Acquisition: Due to intermittent communication
windows and bandwidth constraints, changes to collection windows and bandwidth constraints, changes to collection
guidance will need to batched and transmitted during the next guidance will need to batched and transmitted during the next
communication window. Guidance will need to be cached locally communication window. Guidance will need to be cached locally
to avoid the need for remote communications. to avoid the need for remote communications.
Posture Attribute Value Collection: The specific posture attribute Posture Attribute Value Collection: The specific posture attribute
values to be collected are identified remotely and batched for values to be collected are identified remotely and batched for
collection during the next communication window. If a delay is collection during the next communication window. If a delay is
introduced for collection to complete, results will need to be introduced for collection to complete, results will need to be
batched and transmitted in the same way. batched and transmitted.
COMMENT(DBH): Why "in the same way"? Maybe results could be
handled in a different way.
Posture Attribute Value Query: Previously collected posture Posture Attribute Value Query: Previously collected posture
attribute values will be stored in a remote data store for use attribute values will be stored in a remote data store for use
at the university at the university
Evaluation Guidance Acquisition: Due to intermittent communication Evaluation Guidance Acquisition: Due to intermittent communication
windows and bandwidth constraints, changes to evaluation windows and bandwidth constraints, changes to evaluation
guidance will need to batched and transmitted during the next guidance will need to batched and transmitted during the next
communication window. Guidance will need to be cached locally communication window. Guidance will need to be cached locally
to avoid the need for remote communications. to avoid the need for remote communications.
skipping to change at page 22, line 15 skipping to change at page 21, line 34
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. -05- to -06- 6.1. -06- to -07-
A number of edits were made to section 2 to resolve open questions in
the draft based on meeting and mailing list discussions.
Section 2.1.5 was merged into section 2.1.4.
6.2. -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 37 skipping to change at page 22, line 15
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.2. -04- to -05- 6.3. -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 35 skipping to change at page 23, line 16
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.3. -03- to -04- 6.4. -03- to -04-
Added four new use cases regarding content repository. Added four new use cases regarding content repository.
6.4. -02- to -03- 6.5. -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 25 skipping to change at page 24, line 5
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.5. -01- to -02- 6.6. -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.6. -00- to -01- 6.7. -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 39 skipping to change at page 25, line 20
"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.7. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 6.8. 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 30 skipping to change at page 26, line 11
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.8. waltermire -04- to -05- 6.9. 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 I removed the references to what the WG will do because this o Removed the references to what the WG will do because this belongs
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
place for that discussion. place for that discussion.
o I moved the discussion of NIST specifications to the o Moved the discussion of NIST specifications to the
acknowledgements section. acknowledgements section.
o Removed the portion of the introduction that describes the o Removed the portion of the introduction that describes the
chapters; we have a table of concepts, and the existing text chapters; we have a table of concepts, and the existing text
seemed redundant. seemed redundant.
o Removed marketing claims, to focus on technical concepts and o Removed marketing claims, to focus on technical concepts and
technical analysis, that would enable subsequent engineering technical analysis, that would enable subsequent engineering
effort. effort.
 End of changes. 35 change blocks. 
112 lines changed or deleted 89 lines changed or added

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