draft-ietf-sacm-use-cases-10.txt   rfc7632.txt 
Security Automation and Continuous Monitoring WG D. Waltermire Internet Engineering Task Force (IETF) D. Waltermire
Internet-Draft NIST Request for Comments: 7632 NIST
Intended status: Informational D. Harrington Category: Informational D. Harrington
Expires: January 2, 2016 Effective Software ISSN: 2070-1721 Effective Software
July 1, 2015 September 2015
Endpoint Security Posture Assessment - Enterprise Use Cases Endpoint Security Posture Assessment: Enterprise Use Cases
draft-ietf-sacm-use-cases-10
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 2, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7632.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 6
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 . . . . . 11
2.1.4. Posture Attribute Evaluation . . . . . . . . . . . . 11 2.1.4. Posture Attribute Evaluation . . . . . . . . . . . . 11
2.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 12 2.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 13
2.2.1. Definition and Publication of Automatable 2.2.1. Definition and Publication of Automatable
Configuration Checklists . . . . . . . . . . . . . . 12 Configuration Checklists . . . . . . . . . . . . . . 13
2.2.2. Automated Checklist Verification . . . . . . . . . . 13 2.2.2. Automated Checklist Verification . . . . . . . . . . 14
2.2.3. Detection of Posture Deviations . . . . . . . . . . . 16 2.2.3. Detection of Posture Deviations . . . . . . . . . . . 17
2.2.4. Endpoint Information Analysis and Reporting . . . . . 17 2.2.4. Endpoint Information Analysis and Reporting . . . . . 18
2.2.5. Asynchronous Compliance/Vulnerability Assessment at 2.2.5. Asynchronous Compliance/Vulnerability Assessment at
Ice Station Zebra . . . . . . . . . . . . . . . . . . 18 Ice Station Zebra . . . . . . . . . . . . . . . . . . 18
2.2.6. Identification and Retrieval of Guidance . . . . . . 20 2.2.6. Identification and Retrieval of Guidance . . . . . . 20
2.2.7. Guidance Change Detection . . . . . . . . . . . . . . 21 2.2.7. Guidance Change Detection . . . . . . . . . . . . . . 21
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 3. Security Considerations . . . . . . . . . . . . . . . . . . . 22
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4. Informative References . . . . . . . . . . . . . . . . . . . 22
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. -08- to -09- . . . . . . . . . . . . . . . . . . . . . . 22
6.2. -07- to -08- . . . . . . . . . . . . . . . . . . . . . . 22
6.3. -06- to -07- . . . . . . . . . . . . . . . . . . . . . . 23
6.4. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 23
6.5. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 23
6.6. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 24
6.7. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 24
6.8. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 25
6.9. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 25
6.10. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 26
6.11. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 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. The these use cases and associated building-block capabilities. The
described use cases support: described use cases support:
o securely collecting and aggregating configuration and operational o securely collecting and aggregating configuration and operational
data, and data, and
o evaluating that data to determine the security posture of o evaluating that data to determine the security posture of
individual endpoints. individual endpoints.
Additionally, this document describes a set of usage scenarios that Additionally, this document describes a set of usage scenarios that
provide examples for using the use cases and associated building provide examples for using the use cases and associated building
blocks to address a variety of operational functions. blocks to address a variety of operational functions.
These operational use cases and related usage scenarios cross many IT These operational use cases and related usage scenarios cross many IT
security domains. The use cases enable the derivation of common: security domains. The use cases enable the derivation of common:
o concepts that are expressed as building blocks in this document, o concepts that are expressed as building blocks in this document,
o characteristics to inform development of a requirements document o characteristics to inform development of a requirements document,
o information concepts to inform development of an information model o information concepts to inform development of an information model
document, and document, and
o functional capabilities to inform development of an architecture o functional capabilities to inform development of an architecture
document. document.
Together these ideas will be used to guide development of vendor- Together, these ideas will be used to guide development of vendor-
neutral, interoperable standards for collecting, aggregating, and neutral, interoperable standards for collecting, aggregating, and
evaluating data relevant to security posture. 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 as
user activities and behaviour, and evaluate the security posture of well as user activities and behaviour, and evaluate the security
an organization. Common expression of information should enable posture of an organization. Common expression of information should
interoperability between tools (whether customized, commercial, or enable interoperability between tools (whether customized,
freely available), and the ability to automate portions of security commercial, or freely available), and the ability to automate
processes to gain efficiency, react to new threats in a timely portions of security processes to gain efficiency, react to new
manner, and free up security personnel to work on more advanced threats in a timely manner, and free up security personnel to work on
problems. more advanced problems.
The goal is to enable organizations to make informed decisions that The goal is to enable organizations to make informed decisions that
support organizational objectives, to enforce policies for hardening support organizational objectives, to enforce policies for hardening
systems, to prevent network misuse, to quantify business risk, and to systems, to prevent network misuse, to quantify business risk, and to
collaborate with partners to identify and mitigate threats. collaborate with partners to identify and mitigate threats.
It is expected that use cases for enterprises and for service It is expected that use cases for enterprises and for service
providers will largely overlap. When considering this overlap, there providers will largely overlap. When considering this overlap, there
are additional complications for service providers, especially in are additional complications for service providers, especially in
handling information that crosses administrative domains. handling information that crosses administrative domains.
skipping to change at page 4, line 21 skipping to change at page 4, line 26
Endpoint posture assessment involves orchestrating and performing Endpoint posture assessment involves orchestrating and performing
data collection and evaluating the posture of a given endpoint. data collection and evaluating the posture of a given endpoint.
Typically, endpoint posture information is gathered and then Typically, endpoint posture information is gathered and then
published to appropriate data repositories to make collected published to appropriate data repositories to make collected
information available for further analysis supporting organizational information available for further analysis supporting organizational
security processes. security processes.
Endpoint posture assessment typically includes: Endpoint posture assessment typically includes:
o Collecting the attributes of a given endpoint; o collecting the attributes of a given endpoint;
o Making the attributes available for evaluation and action; and o making the attributes available for evaluation and action; and
o Verifying that the endpoint's posture is in compliance with o verifying that the endpoint's posture is in compliance with
enterprise standards and policy. enterprise standards and policy.
As part of these activities, it is often necessary to identify and As part of these activities, it is often necessary to identify and
acquire any supporting security automation data that is needed to acquire any supporting security automation data that is needed to
drive and feed data collection and evaluation processes. drive and feed data collection and evaluation processes.
The following is a typical workflow scenario for assessing endpoint The following is a typical workflow scenario for assessing endpoint
posture: posture:
1. Some type of trigger initiates the workflow. For example, an 1. Some type of trigger initiates the workflow. For example, an
skipping to change at page 5, line 14 skipping to change at page 5, line 21
B. The application might retrieve previously collected B. The application might retrieve previously collected
information from a cache or data store, such as a data store information from a cache or data store, such as a data store
populated by an asset management system. populated by an asset management system.
C. The application might establish communication with the C. The application might establish communication with the
target, mutually authenticate identities and authorizations, target, mutually authenticate identities and authorizations,
and collect posture attributes from the target. and collect posture attributes from the target.
D. The application might establish communication with one or D. The application might establish communication with one or
more intermediary/agents, mutually authenticate their more intermediaries or agents, which may be local or
external. When establishing connections with an intermediary
or agent, the application can mutually authenticate their
identities and determine authorizations, and collect posture identities and determine authorizations, and collect posture
attributes about the target from the intermediary/agents. attributes about the target from the intermediaries or
Such agents might be local or external. agents.
E. The application communicates target identity and (sets of) E. The application communicates target identity and (sets of)
collected attributes to an evaluator, possibly an external collected attributes to an evaluator, which is possibly an
process or external system. external process or external system.
F. The evaluator compares the collected posture attributes with F. The evaluator compares the collected posture attributes with
expected values as expressed in policies. expected values as expressed in policies.
G. The evaluator reports the evaluation result for the requested G. The evaluator reports the evaluation result for the requested
assessment, in a standardized or proprietary format, such as assessment, in a standardized or proprietary format, such as
a report, a log entry, a database entry, or a notification. a report, a log entry, a database entry, or a notification.
2.1. Use Cases 2.1. Use Cases
The following subsections detail specific use cases for assessment The following subsections detail specific use cases for assessment
planning, data collection, analysis, and related operations planning, data collection, analysis, and related operations
pertaining to the publication and use of supporting data. Each use pertaining to the publication and use of supporting data. Each use
case is defined by a short summary containing a simple problem case is defined by a short summary containing a simple problem
statement, followed by a discussion of related concepts, and a statement, followed by a discussion of related concepts, and a
listing of associated building blocks which represent the listing of associated building blocks that represent the capabilities
capabilities needed to support the use case. These use cases and needed to support the use case. These use cases and building blocks
building blocks identify separate units of functionality that may be identify separate units of functionality that may be supported by
supported by different components of an architectural model. different components of an architectural model.
2.1.1. Define, Publish, Query and Retrieve Security Automation Data 2.1.1. Define, Publish, Query, and Retrieve Security Automation Data
This use case describes the need for security automation data to be This use case describes the need for security automation data to be
defined and published to one or more data stores, as well as queried defined and published to one or more data stores, as well as queried
and retrieved from these data stores for the explicit use of posture and retrieved from these data stores for the explicit use of posture
collection and evaluation. collection and evaluation.
Security automation data is a general concept that refers to any data Security automation data is a general concept that refers to any data
expression that may be generated and/or used as part of the process expression that may be generated and/or used as part of the process
of collecting and evaluating endpoint posture. Different types of of collecting and evaluating endpoint posture. Different types of
security automation data will generally fall into one of three security automation data will generally fall into one of three
categories: categories:
Guidance: Instructions and related metadata that guide the attribute Guidance: Instructions and related metadata that guide the attribute
collection and evaluation processes. The purpose of this data collection and evaluation processes. The purpose of this data
is to allow implementations to be data-driven enabling their is to allow implementations to be data-driven, thus enabling
behavior to be customized without requiring changes to deployed their behavior to be customized without requiring changes to
software. deployed software.
This type of data tends to change in units of months and days. This type of data tends to change in units of months and days.
In cases where assessments are made more dynamic, it may be In cases where assessments are made more dynamic, it may be
necessary to handle changes in the scope of hours or minutes. necessary to handle changes in the scope of hours or minutes.
This data will typically be provided by large organizations, This data will typically be provided by large organizations,
product vendors, and some 3rd-parties. Thus, it will tend to product vendors, and some third parties. Thus, it will tend to
be shared across large enterprises and customer communities. be shared across large enterprises and customer communities.
In some cases access may be controlled to specific In some cases, access may be controlled to specific
authenticated users. In other cases, the data may be provided authenticated users. In other cases, the data may be provided
broadly with little to no access control. broadly with little to no access control.
This includes: This includes:
* Listings of attribute identifiers for which values may be * Listings of attribute identifiers for which values may be
collected and evaluated collected and evaluated.
* Lists of attributes that are to be collected along with * Lists of attributes that are to be collected along with
metadata that includes: when to collect a set of attributes metadata that includes: when to collect a set of attributes
based on a defined interval or event, the duration of based on a defined interval or event, the duration of
collection, and how to go about collecting a set of collection, and how to go about collecting a set of
attributes. attributes.
* Guidance that specifies how old collected data can be to be * Guidance that specifies how old collected data can be when
used for evaluation. used for evaluation.
* Policies that define how to target and perform the * Policies that define how to target and perform the
evaluation of a set of attributes for different kinds or evaluation of a set of attributes for different kinds or
groups of endpoints and the assets they are composed of. In groups of endpoints and the assets they are composed of. In
some cases it may be desirable to maintain hierarchies of some cases, it may be desirable to maintain hierarchies of
policies as well. policies as well.
* References to human-oriented data that provide technical, * References to human-oriented data that provide technical,
organizational, and/or policy context. This might include organizational, and/or policy context. This might include
references to: best practices documents, legal guidance and references to: best practices documents, legal guidance and
legislation, and instructional materials related to the legislation, and instructional materials related to the
automation data in question. automation data in question.
Attribute Data: Data collected through automated and manual Attribute Data: Data collected through automated and manual
mechanisms describing organizational and posture details mechanisms describing organizational and posture details
pertaining to specific endpoints and the assets that they are pertaining to specific endpoints and the assets that they are
composed of (e.g., hardware, software, accounts). The purpose composed of (e.g., hardware, software, accounts). The purpose
of this type of data is to characterize an endpoint (e.g., of this type of data is to characterize an endpoint (e.g.,
endpoint type, organizationally expected function/role) and to endpoint type, organizationally expected function/role) and to
provide actual and expected state data pertaining to one or provide actual and expected state data pertaining to one or
more endpoints. This data is used to determine what posture more endpoints. This data is used to determine what posture
attributes to collect from which endpoints and to feed one or attributes to collect from which endpoints and to feed one or
more evaluations. more evaluations.
This type of data tends to change in units of days, minutes, a This type of data tends to change in units of days, minutes,
seconds with posture attribute values typically changing more and seconds, with posture attribute values typically changing
frequently than endpoint characterizations. This data tends to more frequently than endpoint characterizations. This data
be organizationally and endpoint specific, with specific tends to be organizationally and endpoint specific, with
operational groups of endpoints tending to exhibit similar specific operational groups of endpoints tending to exhibit
attribute profiles. This data will generally not be shared similar attribute profiles. Generally, this data will not be
outside an organizational boundary and will generally require shared outside an organizational boundary and will require
authentication with specific access controls. authentication with specific access controls.
This includes: This includes:
* Endpoint characterization data that describes the endpoint * Endpoint characterization data that describes the endpoint
type, organizationally expected function/role, etc. type, organizationally expected function/role, etc.
* Collected endpoint posture attribute values and related * Collected endpoint posture attribute values and related
context including: time of collection, tools used for context including: time of collection, tools used for
collection, etc. collection, etc.
skipping to change at page 8, line 24 skipping to change at page 8, line 35
be used to express specific data types requiring specialized or be used to express specific data types requiring specialized or
extensible security automation data repositories. The different extensible security automation data repositories. The different
temporal characteristics, access patterns, and access control temporal characteristics, access patterns, and access control
dimensions of each data type may also require different protocols and dimensions of each data type may also require different protocols and
data models to be supported furthering the potential requirement for data models to be supported furthering the potential requirement for
specialized data repositories. See [RFC3444] for a description and specialized data repositories. See [RFC3444] for a description and
discussion of distinctions between an information and data model. It discussion of distinctions between an information and data model. It
is likely that additional kinds of data will be identified through is likely that additional kinds of data will be identified through
the process of defining requirements and an architectural model. the process of defining requirements and an architectural model.
Implementations supporting this building block will need to be Implementations supporting this building block will need to be
extensible to accommodate the addition of new types of data, both extensible to accommodate the addition of new types of data, whether
proprietary or (preferably) using a standard format. proprietary or (preferably) using a standard format.
The building blocks of this use case are: The building blocks of this use case are:
Data Definition: Security automation data will guide and inform Data Definition: Security automation data will guide and inform
collection and evaluation processes. This data may be designed collection and evaluation processes. This data may be designed
by a variety of roles - application implementers may build by a variety of roles -- application implementers may build
security automation data into their applications; security automation data into their applications;
administrators may define guidance based on organizational administrators may define guidance based on organizational
policies; operators may define guidance and attribute data as policies; operators may define guidance and attribute data as
needed for evaluation at runtime, and so on. Data producers needed for evaluation at runtime; and so on. Data producers
may choose to reuse data from existing stores of security may choose to reuse data from existing stores of security
automation data and/or may create new data. Data producers may automation data and/or may create new data. Data producers may
develop data based on available standardized or proprietary develop data based on available standardized or proprietary
data models, such as those used for network management and/or data models, such as those used for network management and/or
host management. host management.
Data Publication: The capability to enable data producers to publish Data Publication: The capability to enable data producers to publish
data to a security automation data store for further use. data to a security automation data store for further use.
Published data may be made publicly available or access may be Published data may be made publicly available or access may be
based on an authorization decision using authenticated based on an authorization decision using authenticated
skipping to change at page 9, line 16 skipping to change at page 9, line 28
metadata (e.g., create date, modified date, publisher, etc.) metadata (e.g., create date, modified date, publisher, etc.)
and/or the full data, a summary, snippet, or the location to and/or the full data, a summary, snippet, or the location to
retrieve the data. retrieve the data.
Data Retrieval: A user, operator, or application acquires one or Data Retrieval: A user, operator, or application acquires one or
more specific security automation data entries. The location more specific security automation data entries. The location
of the data may be known a priori, or may be determined based of the data may be known a priori, or may be determined based
on decisions made using information from a previous query. on decisions made using information from a previous query.
Data Change Detection: An operator or application needs to know when Data Change Detection: An operator or application needs to know when
security automation data they interested in has been published security automation data they are interested in has been
to, updated in, or deleted from a security automation data published to, updated in, or deleted from a security automation
store which they have been authorized to access. data store that they have been authorized to access.
These building blocks are used to enable acquisition of various These building blocks are used to enable acquisition of various
instances of security automation data based on specific data models instances of security automation data based on specific data models
that are used to drive assessment planning (see section 2.1.2), that are used to drive assessment planning (see Section 2.1.2),
posture attribute value collection (see section 2.1.3), and posture posture attribute value collection (see Section 2.1.3), and posture
evaluation (see section 2.1.4). evaluation (see Section 2.1.4).
2.1.2. Endpoint Identification and Assessment Planning 2.1.2. Endpoint Identification and Assessment Planning
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. Endpoints are identified in support of discovery assessment. Endpoints are identified in support of discovery
using information previously obtained or by using other by using information previously obtained or using other
collection mechanisms to gather identification and collection mechanisms to gather identification and
characterization data. Previously obtained data may originate characterization data. Previously obtained data may originate
from sources such as network authentication exchanges. 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 Endpoint Target Identification: 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 applicable assessment targets. In this case, the Data Query
and/or Data Retrieval building blocks (see section 2.1.1) may and/or Data Retrieval building blocks (see Section 2.1.1) may
be 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)
can be used. can be used.
Posture Attribute Identification: Once the endpoint targets and Posture Attribute Identification: Once the endpoint targets and
their associated asset inventory is known, it is then necessary their associated asset inventory is known, it is then necessary
to calculate what posture attributes are required to be to calculate what posture attributes are required to be
collected to perform the desired evaluation. When available, collected to perform the desired evaluation. When available,
existing posture data is queried for suitability using the Data existing posture data is queried for suitability using the Data
Query building block (see section 2.1.1). Such posture data is Query building block (see Section 2.1.1). Such posture data is
suitable if it is complete and current enough for use in the suitable if it is complete and current enough for use in the
evaluation. Any unsuitable posture data is identified for evaluation. Any unsuitable posture data is identified for
collection. collection.
If this is driven by guidance, then the Data Query and/or Data If this is driven by guidance, then 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 data. 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:
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 [RFC3954] is detected).
3. 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
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 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 Attribute Evaluation 2.1.4. Posture Attribute Evaluation
This use case represents the action of analyzing collected posture This use case represents the action of analyzing collected posture
attribute values as part of an assessment. The primary focus of this attribute values as part of an assessment. The primary focus of this
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 [RFC3954] is detected).
3. 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 posture attribute
existing, posture attribute values. The timeliness of values or changes to existing ones. 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
detected changes. 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 using the Data Query building block queried to retrieve them using the Data Query building block
(see section 2.1.1). If all posture attribute values are (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 values 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. Such results include a set of posture evaluation results. Such results include
metadata required to provide a level of assurance with respect metadata required to provide a level of assurance with respect
to the posture attribute data and, therefore, evaluation to the posture attribute data and, therefore, evaluation
results. Examples of such metadata include provenance and or results. Examples of such metadata include provenance and or
availability data. availability data.
skipping to change at page 13, line 13 skipping to change at page 13, line 35
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.
Each guide they produce applies to a specific model of device and Each guide they produce applies to a specific model of device and
version of the operating system and provides a number of specialized version of the operating system and provides a number of specialized
configurations depending on the device's intended function and what configurations depending on the device's intended function and what
add-on hardware modules and software licenses are installed on the add-on hardware modules and software licenses are installed on the
device. To enable their customers to evaluate the security posture device. To enable their customers to evaluate the security posture
of their devices to ensure that all appropriate minimal security of their devices to ensure that all appropriate minimal security
settings are enabled, they publish an automatable configuration settings are enabled, they publish automatable configuration
checklists using a popular data format that defines what settings to checklists using a popular data format that defines what settings to
collect using a network management protocol and appropriate values collect using a network management protocol and appropriate values
for each setting. They publish these checklists to a public security for each setting. They publish these checklists to a public security
automation data store that customers can query to retrieve applicable automation data store that customers can query to retrieve applicable
checklist(s) for their deployed specialized endpoint devices. checklist(s) for their deployed specialized endpoint devices.
Automatable configuration checklist could also come from sources Automatable configuration checklists could also come from sources
other than a device vendor, such as industry groups or regulatory other than a device vendor, such as industry groups or regulatory
authorities, or enterprises could develop their own checklists. authorities, or enterprises could develop their own checklists.
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:
Data Definition: To allow guidance to be defined using standardized Data Definition: To allow guidance to be defined using standardized
or proprietary data models that will drive collection and or proprietary data models that will drive collection and
evaluation. evaluation.
skipping to change at page 13, line 48 skipping to change at page 14, line 22
automation data store for editing. automation data store for editing.
While each building block can be used in a manual fashion by a human While each building block can be used in a manual fashion by a human
operator, it is also likely that these capabilities will be operator, it is also likely that these capabilities will be
implemented together in some form of a guidance editor or generator implemented together in some form of a guidance editor or generator
application. application.
2.2.2. Automated Checklist Verification 2.2.2. Automated Checklist Verification
A financial services company operates a heterogeneous IT environment. A financial services company operates a heterogeneous IT environment.
In support of their risk management program, they utilize vendor In support of their risk management program, they utilize vendor-
provided automatable security configuration checklists for each provided automatable security configuration checklists for each
operating system and application used within their IT environment. operating system and application used within their IT environment.
Multiple checklists are used from different vendors to ensure
Multiple checklists are used from different vendors to insure
adequate coverage of all IT assets. adequate coverage of all IT assets.
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.
Appropriate checklists are queried, located and downloaded from the Appropriate checklists are queried, located, and downloaded from the
relevant guidance data stores. The specific data stores queried and relevant guidance data stores. The specific data stores queried and
the specifics of each query may be driven by data including: the specifics of each query may be driven by data including:
o collected hardware and software inventory data, and o collected hardware and software inventory data, and
o associated asset characterization data that may indicate the o associated asset characterization data that may indicate the
organizational defined functions of each endpoint. organizationally defined functions of each endpoint.
Checklists may be sourced from guidance data stores maintained by an Checklists may be sourced from guidance data stores maintained by an
application or OS vendor, an industry group, a regulatory authority, application or OS vendor, an industry group, a regulatory authority,
or directly by the enterprise. or directly by the enterprise.
The retrieved guidance is cached locally to reduce the need to 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
skipping to change at page 14, line 50 skipping to change at page 15, line 21
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. criteria defined in each applicable checklist.
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.
The results of checklist evaluation are provided to appropriate The results of checklist evaluation are provided to appropriate
operators and applications to drive additional business logic. operators and applications to drive additional business logic.
Specific applications for checklist evaluation results are out-of- Specific applications for checklist evaluation results are out of
scope for current SACM efforts. Irrespective of specific scope for current SACM (Security Automation and Continuous
applications, the availability, timeliness, and liveness of results Monitoring) efforts. Irrespective of specific applications, the
is often of general concern. Network latency and available bandwidth availability, timeliness, and liveness of results are often of
often create operational constraints that require trade-offs between general concern. Network latency and available bandwidth often
these concerns and need to be considered. create operational constraints that require trade-offs between these
concerns and need to be considered.
Uses of checklists and associated evaluation results may include, but Uses of checklists and associated evaluation results may include, but
are not limited to: 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: management program to identify:
* identify missing required patches, * missing required patches,
* unauthorized changes to hardware and software inventory, and * unauthorized changes to hardware and software inventory, and
* unauthorized changes to configuration items. * unauthorized changes to configuration items.
o Determining compliance with organizational policies governing o Determining compliance with organizational policies governing
endpoint posture. endpoint posture.
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 Searching for current and historic indicators of compromise.
o Detecting current and historic infection by malware and o Detecting current and historic infection by malware and
determining the scope of infection within an enterprise. 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
type of endpoint to be posture assessed. type of endpoint to be posture assessed.
Identify Endpoint Targets: To identify what potential endpoint Endpoint Target Identification: To identify what potential endpoint
targets the checklist should apply to based on organizational targets the checklist should apply to based on organizational
policies. policies.
Endpoint Component Inventory: Collecting and consuming the software Endpoint Component Inventory: Collecting and consuming the software
and hardware inventory for the target endpoints. and hardware inventory for the target endpoints.
Posture Attribute Identification: To determine what data needs to be Posture Attribute Identification: To determine what data needs to be
collected to support evaluation, the checklist is evaluated collected to support evaluation, the checklist is evaluated
against the component inventory and other endpoint metadata to against the component inventory and other endpoint metadata to
determine the set of posture attribute values that are needed. determine the set of posture attribute values that are needed.
skipping to change at page 16, line 28 skipping to change at page 17, line 7
Evaluation Guidance Acquisition: Any guidance that is needed to Evaluation Guidance Acquisition: Any guidance that is needed to
support evaluation is queried and retrieved. support evaluation is queried and retrieved.
Posture Attribute Evaluation: The resulting posture attribute values Posture Attribute Evaluation: The resulting posture attribute values
from previous collection processes are evaluated using the from previous collection processes are evaluated using the
evaluation guidance to provide a set of posture results. evaluation guidance to provide a set of posture results.
2.2.3. Detection of Posture Deviations 2.2.3. Detection of Posture Deviations
Example corporation has established secure configuration baselines Example Corporation has established secure configuration baselines
for each different type of endpoint within their enterprise for each different type of endpoint within their enterprise
including: network infrastructure, mobile, client, and server including: network infrastructure, mobile, client, and server
computing platforms. These baselines define an approved list of computing platforms. These baselines define an approved list of
hardware, software (i.e., operating system, applications, and hardware, software (i.e., operating system, applications, and
patches), and associated required configurations. When an endpoint patches), and associated required configurations. When an endpoint
connects to the network, the appropriate baseline configuration is connects to the network, the appropriate baseline configuration is
communicated to the endpoint based on its location in the network, communicated to the endpoint based on its location in the network,
the expected function of the device, and other asset management data. the expected function of the device, and other asset management data.
It is checked for compliance with the baseline indicating any It is checked for compliance with the baseline, and any deviations
deviations to the device's operators. Once the baseline has been are indicated to the device's operators. Once the baseline has been
established, the endpoint is monitored for any change events established, the endpoint is monitored for any change events
pertaining to the baseline on an ongoing basis. When a change occurs pertaining to the baseline on an ongoing basis. When a change occurs
to posture defined in the baseline, updated posture information is to posture defined in the baseline, updated posture information is
exchanged, allowing operators to be notified and/or automated action exchanged, allowing operators to be notified and/or automated action
to be taken. to be taken.
Like the Automated Checklist Verification usage scenario (see section Like the Automated Checklist Verification usage scenario (see
2.2.2), this usage scenario supports assessment based on automatable Section 2.2.2), this usage scenario supports assessment based on
checklists. It differs from that scenario by monitoring for specific automatable checklists. It differs from that scenario by monitoring
endpoint posture changes on an ongoing basis. When the endpoint for specific endpoint posture changes on an ongoing basis. When the
detects a posture change, an alert is generated identifying the endpoint detects a posture change, an alert is generated identifying
specific changes in posture allowing assessment of the delta to be the specific changes in posture, thus allowing assessment of the
performed instead of a full assessment in the previous case. This delta to be performed instead of a full assessment as in the previous
usage scenario employs the same building blocks as case. This usage scenario employs the same building blocks as
Automated Checklist Verification (see section 2.2.2). It differs Automated Checklist Verification (see section 2.2.2). It differs
slightly in how it uses the following building blocks: slightly in how it uses the following building blocks:
Endpoint Component Inventory: Additionally, changes to the hardware Endpoint Component Inventory: Additionally, changes to the hardware
and software inventory are monitored, with changes causing and software inventory are monitored, with changes causing
alerts to be issued. alerts to be issued.
Posture Attribute Value Collection: After the initial assessment, Posture Attribute Value Collection: After the initial assessment,
posture attributes are monitored for changes. If any of the posture attributes are monitored for changes. If any of the
selected posture attribute values change, an alert is issued. selected posture attribute values change, an alert is issued.
skipping to change at page 18, line 12 skipping to change at page 18, line 36
attribute values for the target endpoint(s) are queried from attribute values for the target endpoint(s) are queried from
the appropriate data stores using a standardized method. 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.
During their extended expedition, they will need to show continue During their extended expedition, they will need to show continued
compliance with the security policies of the university, the compliance with the security policies of the university, the
government, and the provider of the satellite network as well as keep government, and the provider of the satellite network, as well as
current on vulnerability testing. Interactive assessments are keep current on vulnerability testing. Interactive assessments are
therefore not reliable, and since the researchers have very limited therefore not reliable, and since the researchers have very limited
funding they need to minimize how much money they spend on network funding, they need to minimize how much money they spend on network
data. data.
Prior to departure they register all equipment with an asset Prior to departure, they register all equipment with an asset
management system owned by the university, which will also initiate management system owned by the university, which will also initiate
and track assessments. and track assessments.
On a periodic basis -- either after a maximum time delta or when the On a periodic basis -- either after a maximum time delta or when the
security automation data store has received a threshold level of new security automation data store has received a threshold level of new
vulnerability definitions -- the university uses the information in vulnerability definitions -- the university uses the information in
the asset management system to put together a collection request for the asset management system to put together a collection request for
all of the deployed assets that encompasses the minimal set of all of the deployed assets that encompasses the minimal set of
artifacts necessary to evaluate all three security policies as well artifacts necessary to evaluate all three security policies as well
as vulnerability testing. as vulnerability testing.
In the case of new critical vulnerabilities, this collection request In the case of new critical vulnerabilities, this collection request
consists only of the artifacts necessary for those vulnerabilities consists only of the artifacts necessary for those vulnerabilities,
and collection is only initiated for those assets that could and collection is only initiated for those assets that could
potentially have a new vulnerability. potentially have a new vulnerability.
(Optional) Asset artifacts are cached in a local CMDB. When new (Optional) Asset artifacts are cached in a local configuration
vulnerabilities are reported to the security automation data store, a management database (CMDB). When new vulnerabilities are reported to
request to the live asset is only done if the artifacts in the CMDB the security automation data store, a request to the live asset is
are incomplete and/or not current enough. only done if the artifacts in the CMDB are incomplete and/or not
current enough.
The collection request is queued for the next window of connectivity. The collection request is queued for the next window of connectivity.
The deployed assets eventually receive the request, fulfill it, and The deployed assets eventually receive the request, fulfill it, and
queue the results for the next return opportunity. queue the results for the next return opportunity.
The collected artifacts eventually make it back to the university The collected artifacts eventually make it back to the university
where the level of compliance and vulnerability exposed is calculated where the level of compliance and vulnerability exposed is calculated
and asset characteristics are compared to what is in the asset and asset characteristics are compared to what is in the asset
management system for accuracy and completeness. management system for accuracy and completeness.
skipping to change at page 19, line 33 skipping to change at page 20, line 13
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. batched and transmitted.
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.
Posture Attribute Evaluation: Due to the caching of posture Posture Attribute Evaluation: Due to the caching of posture
attribute values and evaluation guidance, evaluation may be attribute values and evaluation guidance, evaluation may be
performed at both the university campus as well as the performed at both the university campus as well as the
skipping to change at page 20, line 17 skipping to change at page 20, line 41
In preparation for performing an assessment, an operator or In preparation for performing an assessment, an operator or
application will need to identify one or more security automation application will need to identify one or more security automation
data stores that contain the guidance entries necessary to perform data stores that contain the guidance entries necessary to perform
data collection and evaluation tasks. The location of a given data collection and evaluation tasks. The location of a given
guidance entry will either be known a priori or known security guidance entry will either be known a priori or known security
automation data stores will need to be queried to retrieve applicable automation data stores will need to be queried to retrieve applicable
guidance. guidance.
To query guidance it will be necessary to define a set of search To query guidance it will be necessary to define a set of search
criteria. This criteria will often utilize a logical combination of criteria. This criteria will often utilize a logical combination of
publication metadata (e.g. publishing identity, create time, publication metadata (e.g., publishing identity, create time,
modification time) and guidance data-specific criteria elements. modification time) and criteria elements specific to the guidance
Once the criteria is defined, one or more security automation data data. Once the criteria are defined, one or more security automation
stores will need to be queried generating a result set. Depending on data stores will need to be queried, thus generating a result set.
how the results are used, it may be desirable to return the matching Depending on how the results are used, it may be desirable to return
guidance directly, a snippet of the guidance matching the query, or a the matching guidance directly, a snippet of the guidance matching
resolvable location to retrieve the data at a later time. The the query, or a resolvable location to retrieve the data at a later
guidance matching the query will be restricted based the authorized time. The guidance matching the query will be restricted based on
level of access allowed to the requester. the authorized level of access allowed to the requester.
If the location of guidance is identified in the query result set, If the location of guidance is identified in the query result set,
the guidance will be retrieved when needed using one or more data the guidance will be retrieved when needed using one or more data
retrieval requests. A variation on this approach would be to retrieval requests. A variation on this approach would be to
maintain a local cache of previously retrieved data. In this case, maintain a local cache of previously retrieved data. In this case,
only guidance that is determined to be stale by some measure will be only guidance that is determined to be stale by some measure will be
retrieved from the remote data store. retrieved from the remote data store.
Alternately, guidance can be discovered by iterating over data Alternately, guidance can be discovered by iterating over data
published with a given context within a security automation data published with a given context within a security automation data
skipping to change at page 21, line 11 skipping to change at page 21, line 33
Data Retrieval: If data locations are returned in the query result Data Retrieval: If data locations are returned in the query result
set, then specific guidance entries can be retrieved and set, then specific guidance entries can be retrieved and
possibly cached locally. possibly cached locally.
2.2.7. Guidance Change Detection 2.2.7. Guidance Change Detection
An operator or application may need to identify new, updated, or An operator or application may need to identify new, updated, or
deleted guidance in a security automation data store for which they deleted guidance in a security automation data store for which they
have been authorized to access. This may be achieved by querying or have been authorized to access. This may be achieved by querying or
iterating over guidance in a security automation data store, or iterating over guidance in a security automation data store, or
through a notification mechanism that alerts to changes made to a through a notification mechanism that generates alerts when changes
security automation data store. are made to a security automation data store.
Once guidance changes have been determined, data collection and Once guidance changes have been determined, data collection and
evaluation activities may be triggered. evaluation activities may be triggered.
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:
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 for which
have been authorized to access. they 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.
3. IANA Considerations 3. Security Considerations
This memo includes no request to IANA.
4. Security Considerations
This memo documents, for informational purposes, use cases for This memo documents, for informational purposes, use cases for
security automation. Specific security and privacy considerations security automation. Specific security and privacy considerations
will be provided in related documents (e.g., requirements, will be provided in related documents (e.g., requirements,
architecture, information model, data model, protocol) as appropriate architecture, information model, data model, protocol) as appropriate
to the function described in each related document. to the function described in each related document.
One consideration for security automation is that a malicious actor One consideration for security automation is that a malicious actor
could use the security automation infrastructure and related could use the security automation infrastructure and related
collected data to gain access to an item of interest. This may collected data to gain access to an item of interest. This may
include personal data, private keys, software and configuration state include personal data, private keys, software and configuration state
that can be used to inform an attack against the network and that can be used to inform an attack against the network and
endpoints, and other sensitive information. It is important that endpoints, and other sensitive information. It is important that
security and privacy considerations in the related documents identify security and privacy considerations in the related documents indicate
methods to both identify and prevent such activity. methods to both identify and prevent such activity.
For consideration are means for protecting the communications as well For consideration are means for protecting the communications as well
as the systems that store the information. For communications as the systems that store the information. For communications
between the varying SACM components there should be considerations between the varying SACM components, there should be considerations
for protecting the confidentiality, data integrity and peer entity for protecting the confidentiality, data integrity, and peer entity
authentication. For exchanged information, there should be a means authentication. For exchanged information, there should be a means
to authenticate the origin of the information. This is important to authenticate the origin of the information. This is important
where tracking the provenance of data is needed. Also, for any where tracking the provenance of data is needed. Also, for any
systems that store information that could be used for unauthorized or systems that store information that could be used for unauthorized or
malicious purposes, methods to identify and protect against malicious purposes, methods to identify and protect against
unauthorized usage, inappropriate usage, and denial of service need unauthorized usage, inappropriate usage, and denial of service need
to be considered. to be considered.
5. Acknowledgements 4. Informative References
Adam Montville edited early versions of this draft.
Kathleen Moriarty, and Stephen Hanna contributed text describing the
scope of the document.
Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa
Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and
Aron Woland provided use cases text for various revisions of this
draft.
6. Change Log
6.1. -08- to -09-
Fixed a number of gramatical nits throughout the draft identified by
the SECDIR review.
Added additional text to the security considerations about malicious
actors.
6.2. -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.3. -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.4. -05- to -06-
Updated the "Introduction" section to better reflect the use case,
building block, and usage scenario structure changes from previous
revisions.
Updated most uses of the terms "content" and "content repository" to
use "guidance" and "security automation data store" respectively.
In section 2.1.1, added a discussion of different data types and
renamed "content" to "data" in the building block names.
In section 2.1.2, separated out the building block concepts of
"Endpoint Discovery" and "Endpoint Characterization" based on mailing
list discussions.
Addressed some open questions throughout the draft based on consensus
from mailing list discussions and the two virtual interim meetings.
Changed many section/sub-section names to better reflect their
content.
6.5. -04- to -05-
Changes in this revision are focused on section 2 and the subsequent
subsections:
o Moved existing use cases to a subsection titled "Usage Scenarios".
o Added a new subsection titled "Use Cases" to describe the common
use cases and building blocks used to address the "Usage
Scenarios". The new use cases are:
* Define, Publish, Query and Retrieve Content
* Endpoint Identification and Assessment Planning
* Endpoint Posture Attribute Value Collection
* Posture Evaluation
* Mining the Database
o Added a listing of building blocks used for all usage scenarios.
o Combined the following usage scenarios into "Automated Checklist
Verification": "Organizational Software Policy Compliance",
"Search for Signs of Infection", "Vulnerable Endpoint
Identification", "Compromised Endpoint Identification",
"Suspicious Endpoint Behavior", "Traditional endpoint assessment
with stored results", "NAC/NAP connection with no stored results
using an endpoint evaluator", and "NAC/NAP connection with no
stored results using a third-party evaluator".
o Created new usage scenario "Identification and Retrieval of
Repository Content" by combining the following usage scenarios:
"Repository Interaction - A Full Assessment" and "Repository
Interaction - Filtered Delta Assessment"
o Renamed "Register with repository for immediate notification of
new security vulnerability content that match a selection filter"
to "Content Change Detection" and generalized the description to
be neutral to implementation approaches.
o Removed out-of-scope usage scenarios: "Remediation and Mitigation"
and "Direct Human Retrieval of Ancillary Materials"
Updated acknowledgements to recognize those that helped with editing
the use case text.
6.6. -03- to -04-
Added four new use cases regarding content repository.
6.7. -02- to -03-
Expanded the workflow description based on ML input.
Changed the ambiguous "assess" to better separate data collection
from evaluation.
Added use case for Search for Signs of Infection.
Added use case for Remediation and Mitigation.
Added use case for Endpoint Information Analysis and Reporting.
Added use case for Asynchronous Compliance/Vulnerability Assessment
at Ice Station Zebra.
Added use case for Traditional endpoint assessment with stored
results.
Added use case for NAC/NAP connection with no stored results using an
endpoint evaluator.
Added use case for NAC/NAP connection with no stored results using a
third-party evaluator.
Added use case for Compromised Endpoint Identification.
Added use case for Suspicious Endpoint Behavior.
Added use case for Vulnerable Endpoint Identification.
Updated Acknowledgements
6.8. -01- to -02-
Changed title
removed section 4, expecting it will be moved into the requirements
document.
removed the list of proposed capabilities from section 3.1
Added empty sections for Search for Signs of Infection, Remediation
and Mitigation, and Endpoint Information Analysis and Reporting.
Removed Requirements Language section and rfc2119 reference.
Removed unused references (which ended up being all references).
6.9. -00- to -01-
o Work on this revision has been focused on document content
relating primarily to use of asset management data and functions.
o Made significant updates to section 3 including:
* Reworked introductory text.
* 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.
* 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.
* Additional use cases will be added in the next revision
capturing additional discussion from the list.
o Made significant updates to section 4 including:
* 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.
* Started work to flatten the section, moving select subsections
up from under asset management.
* Removed the subsections for: Asset Discovery, Endpoint
Components and Asset Composition, Asset Resources, and Asset
Life Cycle.
* Renamed the subsection "Asset Representation Reconciliation" to
"Deconfliction of Asset Identities".
* Expanded the subsections for: Asset Identification, Asset
Characterization, and Deconfliction of Asset Identities.
* Added a new subsection for Asset Targeting.
* Moved remaining sections to "Other Unedited Content" for future
updating.
6.10. 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
call.
o Fixed a number of spelling errors. Thank you Erik!
o Added keywords to the front matter.
o Removed the terminology section from the draft. Terms have been
moved to: draft-dbh-sacm-terminology-00
o Removed requirements to be moved into a new I/D.
o Extracted the functionality from the examples and made the
examples less prominent.
o Renamed "Functional Capabilities and Requirements" section to "Use
Cases".
* Reorganized the "Asset Management" sub-section. Added new text
throughout.
+ Renamed a few sub-section headings.
+ Added text to the "Asset Characterization" sub-section.
o Renamed "Security Configuration Management" to "Endpoint
Configuration Management". Not sure if the "security" distinction
is important.
* Added new sections, partially integrated existing content.
* Additional text is needed in all of the sub-sections.
o Changed "Security Change Management" to "Endpoint Posture Change
Management". Added new skeletal outline sections for future
updates.
6.11. waltermire -04- to -05-
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
application, not Internet stuff.
o 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.
o Moved the discussion of NIST specifications to the
acknowledgements section.
o Removed the portion of the introduction that describes the
chapters; we have a table of concepts, and the existing text
seemed redundant.
o Removed marketing claims, to focus on technical concepts and
technical analysis, that would enable subsequent engineering
effort.
o Removed (commented out in XML) UC2 and UC3, and eliminated some
text that referred to these use cases.
o Modified IANA and Security Consideration sections.
o Moved Terms to the front, so we can use them in the subsequent
text.
o 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.
o 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.
o Modified text to describe that this was specific to enterprises, [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
and that it was expected to overlap with service provider use Information Models and Data Models", RFC 3444,
cases, and described the context of this scoped work within a DOI 10.17487/RFC3444, January 2003,
larger context of policy enforcement, and verification. <http://www.rfc-editor.org/info/rfc3444>.
o The document had asset management, but the charter mentioned [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
asset, change, configuration, and vulnerability management, so I Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
added sections for each of those categories. <http://www.rfc-editor.org/info/rfc3954>.
o Added text to Introduction explaining goal of the document. Acknowledgements
o Added sections on various example use cases for asset management, Adam Montville edited early versions of this document.
config management, change management, and vulnerability
management.
7. Informative References Kathleen Moriarty and Stephen Hanna contributed text describing the
scope of the document.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa
Information Models and Data Models", RFC 3444, January Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and
2003. Aron Woland provided text about the use cases for various revisions
of this document.
Authors' Addresses Authors' Addresses
David Waltermire David Waltermire
National Institute of Standards and Technology National Institute of Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, Maryland 20877 Gaithersburg, Maryland 20877
USA United States
Email: david.waltermire@nist.gov Email: david.waltermire@nist.gov
David Harrington David Harrington
Effective Software Effective Software
50 Harding Rd 16 Bayview Drive
Portsmouth, NH 03801 Westerly, Rhode Island 02891
USA United States
Email: ietfdbh@comcast.net Email: ietfdbh@gmail.com
 End of changes. 93 change blocks. 
497 lines changed or deleted 185 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/