draft-ietf-sacm-use-cases-05.txt   draft-ietf-sacm-use-cases-06.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: May 24, 2014 Effective Software Expires: September 4, 2014 Effective Software
November 20, 2013 March 3, 2014
Endpoint Security Posture Assessment - Enterprise Use Cases Endpoint Security Posture Assessment - Enterprise Use Cases
draft-ietf-sacm-use-cases-05 draft-ietf-sacm-use-cases-06
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 May 24, 2014. This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 4 2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 3
2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Define, Publish, Query and Retrieve Content . . . . . 5 2.1.1. Define, Publish, Query and Retrieve Security
2.1.2. Endpoint Identification and Assessment Planning . . . 7 Automation Data . . . . . . . . . . . . . . . . . . . 5
2.1.3. Endpoint Posture Attribute Value Collection . . . . . 8 2.1.2. Endpoint Identification and Assessment Planning . . . 9
2.1.4. Posture Evaluation . . . . . . . . . . . . . . . . . 8 2.1.3. Endpoint Posture Attribute Value Collection . . . . . 10
2.1.5. Mining the Database . . . . . . . . . . . . . . . . . 9 2.1.4. Posture Evaluation . . . . . . . . . . . . . . . . . 11
2.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 10 2.1.5. Mining the Database . . . . . . . . . . . . . . . . . 12
2.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Definition and Publication of Automatable 2.2.1. Definition and Publication of Automatable
Configuration Guides . . . . . . . . . . . . . . . . 10 Configuration Checklists . . . . . . . . . . . . . . 13
2.2.2. Automated Checklist Verification . . . . . . . . . . 11 2.2.2. Automated Checklist Verification . . . . . . . . . . 14
2.2.3. Detection of Posture Deviations . . . . . . . . . . . 13 2.2.3. Detection of Posture Deviations . . . . . . . . . . . 16
2.2.4. Endpoint Information Analysis and Reporting . . . . . 14 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 . . . . . . . . . . . . . . . . . . 15 Ice Station Zebra . . . . . . . . . . . . . . . . . . 18
2.2.6. Identification and Retrieval of Repository Content . 17 2.2.6. Identification and Retrieval of Guidance . . . . . . 20
2.2.7. Content Change Detection . . . . . . . . . . . . . . 18 2.2.7. Guidance Change Detection . . . . . . . . . . . . . . 21
2.2.8. Others... . . . . . . . . . . . . . . . . . . . . . . 18 2.2.8. Others... . . . . . . . . . . . . . . . . . . . . . . 21
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 19 6.1. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 22
6.2. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 20 6.2. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 22
6.3. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 20 6.3. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 23
6.4. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 21 6.4. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 23
6.5. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 21 6.5. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 24
6.6. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 6.6. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 24
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 22 6.7. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
6.7. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 23 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.8. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 24 7. Informative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Our goal with this document is to improve our agreement on which
problems we're trying to solve. We need to start with short, simple
problem statements and discuss those by email and in person. Once we
agree on which problems we're trying to solve, we can move on to
propose various solutions and decide which ones to use.
This document describes example use cases for endpoint posture This document describes the core set of use cases for endpoint
assessment for enterprises. It provides a sampling of use cases for posture assessment for enterprises. It provides a discussion of
securely aggregating configuration and operational data and these use cases and associated building block capabilities that
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. enterprise. Additionally, this document describes a set of usage
scenarios that provide examples for using the use cases and
associated building blocks to address a variety of operational
functions.
These use cases cross many IT security information domains. From These use cases and usage sceneries cross many IT security
these operational use cases, we can derive common concepts, common information domains. From these operational use cases, we can derive
information expressions, functional capabilities and requirements to common concepts, common information expressions, functional
guide development of vendor-neutral, interoperable standards for capabilities and requirements to guide development of vendor-neutral,
aggregating and evaluating data relevant to security posture. interoperable standards for aggregating and evaluating data relevant
to security posture.
Using this standard data, tools can analyze the state of endpoints, Using this standard data, tools can analyze the state of endpoints,
user activities and behaviour, and evaluate the security posture of user activities and behaviour, and evaluate the security posture of
an organization. Common expression of information should enable an organization. Common expression of information should enable
interoperability between tools (whether customized, commercial, or interoperability between tools (whether customized, commercial, or
freely available), and the ability to automate portions of security freely available), and the ability to automate portions of security
processes to gain efficiency, react to new threats in a timely processes to gain efficiency, react to new threats in a timely
manner, and free up security personnel to work on more advanced manner, and free up security personnel to work on more advanced
problems. problems.
skipping to change at page 4, line 24 skipping to change at page 4, line 13
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 content that is needed to drive data acquire any supporting security automation data that is needed to
collection and analysis. 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
operator or an application might trigger the process with a operator or an application might trigger the process with a
request, or the endpoint might trigger the process using an request, or the endpoint might trigger the process using an
event-driven notification. event-driven notification.
QUESTION: Since this is about security automation, can we drop
the User and just use Application? Is there a better term to
use here? Once the policy is selected, the rest seems like
something we definitely would want to automate, so I dropped
the User part.
2. An operator/application selects one or more target endpoints to 2. An operator/application selects one or more target endpoints to
be assessed. be assessed.
3. A operator/application selects which policies are applicable to 3. An operator/application selects which policies are applicable to
the targets. the targets.
4. For each target: 4. For each target:
A. The application determines which (sets of) posture attributes A. The application determines which (sets of) posture attributes
need to be collected for evaluation. need to be collected for evaluation. Implementations should
be able to support (possibly mixed) sets of standardized and
QUESTION: It was suggested that mentioning several common proprietary attributes.
acquisition methods, such as local API, WMI, Puppet, DCOM,
SNMP, CMDB query, and NEA, without forcing any specific
method would be good. I have concerns this could devolve
into a "what about my favorite?" contest. OTOH, the
charter does specifically call for use of existing
standards where applicable, so the use cases document
might be a good neutral location for such information, and
might force us to consider what types of external
interfaces we might need to support when we consider the
requirements. It appears that the generic workflow
sequence would be a good place to mention such common
acquisition methods.
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
skipping to change at page 5, line 40 skipping to change at page 5, line 12
attributes about the target from the intermediary/agents. attributes about the target from the intermediary/agents.
Such agents might be local or external. Such agents might be local or external.
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, possibly an external
process or external system. 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.
QUESTION: Evaluator generates a report or log or G. The evaluator reports the evaluation result for the requested
notification of some type? assessment, in a standardized or proprietary format, such as
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 content. pertaining to the publication and use of supporting data. Each use
case is defined by a short summary containing a simple problem
statement, followed by a discussion of related concepts, and a
listing of associated building blocks which represent the
capabilities needed to support the use case. These use cases and
building blocks identify separate units of functionality that may be
supported by different components of an architectural model.
2.1.1. Define, Publish, Query and Retrieve Content 2.1.1. Define, Publish, Query and Retrieve Security Automation Data
This use case describes the need for content to be defined and This use case describes the need for security automation data to be
published to a data store, as well as queried and retrieved from the defined and published to one or more data stores, as well as queried
data store for the explicit use of posture collection and evaluation. and retrieved from these data stores for the explicit use of posture
It is expected that multiple information models will be supported to collection and evaluation.
address the information needed to support the exchange of endpoint
metadata, and the collection and evaluation of endpoint posture Security automation data is a general concept that refers to any data
attribute values. It is likely that multiple data models will be expression that may be generated and/or used as part of the process
used to express these information models requiring specialized or of collecting and evaluating endpoint posture. Different types of
extensible content data stores. security automation data will generally fall into one of three
categories:
Guidance: Instructions and related metadata that guide the attribute
collection and evaluation processes. The purpose of this data
is to allow implementations to be data-driven enabling their
behavior to be customized without requiring changes to deployed
software.
This type of data tends to change in units of months and days.
In cases where assessments are made more dynamic, it may be
necessary to handle changes in the scope of hours or minutes.
This data will typically be provided by large organizations,
product vendors, and some 3rd-parties. Thus, it will tend to
be shared across large enterprises and customer communities.
In some cases access may be controlled to specific
authenticated users. In other cases, the data may be provided
broadly with little to no access control.
This includes:
* Listings of attribute identifiers for which values may be
collected and evaluated
* Lists of attributes that are to be collected along with
metadata that includes: when to collect a set of attributes
based on a defined interval or event, the duration of
collection, and how to go about collecting a set of
attributes.
* Guidance that specifies how old collected data can be to be
used for evaluation.
* Policies that define how to target and perform the
evaluation of a set of attributes for different kinds or
groups of endpoints and the assets they are composed of. In
some cases it may be desirable to maintain hierarchies of
policies as well.
* References to human oriented-data that provide technical,
organizational, and/or policy context. This might include
references to: best practices documents, legal guidance and
legislation, and instructional materials related to the
automation data in question.
Attribute Data: Data collected through automated and manual
mechanisms describing organizational and posture details
pertaining to specific endpoints and the assets that they are
composed of (e.g., hardware, software, accounts). The purpose
of this type of data is to characterize an endpoint (e.g.,
endpoint type, organizationally expected function/role) and to
provide actual and expected state data pertaining to one or
more endpoints. This data is used to determine what posture
attributes to collect from which endpoints and to feed one or
more evaluations.
This type of data tends to change in units of days, minutes, a
seconds with posture attribute values typically changing more
frequently than endpoint characterizations. This data tends to
be organizationally and endpoint specific, with specific
operational groups of endpoints tending to exhibit similar
attribute profiles. This data will generally not be shared
outside an organizational boundary and will generally require
authentication with specific access controls.
This includes:
* Endpoint characterization data that describes the endpoint
type, organizationally expected function/role, etc.
* Collected endpoint posture attribute values and related
context including: time of collection, tools used for
collection, etc.
* Organizationally defined expected posture attribute values
targeted to specific evaluation guidance and endpoint
characteristics. This allows a common set of guidance to be
parameterized for use with different groups of endpoints.
Processing Artifacts: Data that is generated by and is specific to
an individual assessment process. This data may be used as
part of the interactions between architectural components to
drive and coordinate collection and evaluation activities. Its
lifespan will be bounded by the lifespan of the assessment. It
may also be exchanged and stored to provide historic context
around an assessment activity so that individual assessments
can be grouped, evaluated, and reported in an enterprise
context.
This includes:
* The identified set of endpoints for which an assessment
should be performed.
* The identified set of posture attributes that need to be
collected from specific endpoints to perform an evaluation.
* The resulting data generated by an evaluation process
including the context of what was assessed, what it was
assessed against, what collected data was used, when it was
collected, and when the evaluation was performed.
The information model for security automation data must support a
variety of different data types as described above, along with the
associated metadata that is needed to support publication, query, and
retrieval operations. It is expected that multiple data models will
be used to express specific data types requiring specialized or
extensible security automation data repositories. The different
temporal characteristics, access patterns, and access control
dimensions of each data type may also require different protocols and
data models to be supported furthering the potential requirement for
specialized data repositories. See [RFC3444] for a description and
discussion of distinctions between an information and data model. It
is likely that additional kinds of data will be identified through
the process of defining requirements and an architectural model.
Implementations supporting this building block will need to be
extensible to accommodate the addition of new types of data, both
proprietary or (preferably) using a standard format.
The building blocks of this use case are: The building blocks of this use case are:
Content Definition: Defining the content to drive collection and Data Definition: Security automation data will guide and inform
evaluation. This may include evaluating existing stores of collection and evaluation processes. This data may be designed
content to find content to reuse and the creation of new by a variety of roles - application implementers may build
content. Developed content will be based on available data security automation data into their applications;
models which may be standardized or proprietary. administrators may define guidance based on organizational
policies; operators may define guidance and attribute data as
needed for evaluation at runtime, and so on. Data producers
may choose to reuse data from existing stores of security
automation data and may create new data. Data producers may
develop data based on available standardized or proprietary
data models, such as those used for network management and/or
host management.
Content Publication: The capability to publish content to a content Data Publication: The capability to enable data producers to publish
data store for further use. Published content may be made data to a security automation data store for further use.
publicly available or may be based on an authorization decision Published data may be made publicly available or access may be
using authenticated credentials. As a result, the visibility based on an authorization decision using authenticated
of content to an operator or application may be public, credentials. As a result, the visibility of specific security
automation data to an operator or application may be public,
enterprise-scoped, private, or controlled within any other enterprise-scoped, private, or controlled within any other
scope. scope.
Content Query: An operator or application should be able to query a Data Query: An operator or application should be able to query a
content data store using a set of specified criteria. The security automation data store using a set of specified
result of the query will be a listing matching the query. The criteria. The result of the query will be a listing matching
query result listing may contain publication metadata (e.g., the query. The query result listing may contain publication
create date, modified date, publisher, etc.) and/or the full metadata (e.g., create date, modified date, publisher, etc.)
content, a summary, snippet, or the location to retrieve the and/or the full data, a summary, snippet, or the location to
content. retrieve the data.
Content Retrieval: The act of acquiring one or more specific content Data Retrieval: An user, operator, or application acquires one or
entries. This capability is useful if the location of the more specific security automation data entries. The location
content is known a priori, perhaps as the result of request of the data may be known a priori, or may be determined based
based on decisions made using information from a previous on decisions made using information from a previous query.
query.
Content Change Detection: An operator or application needs to Data Change Detection: An operator or application needs to know when
identify content of interest that is new, updated, or deleted security automation data they interested in has been published
in a content data store which they have been authorized to to, updated in, or deleted from a security automation data
access. store which 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 content based on specific data models that are used to instances of security automation data based on specific data models
drive assessment planning (see section 2.1.2), posture attribute that are used to drive assessment planning (see section 2.1.2),
value collection (see section 2.1.3), and posture evaluation (see posture attribute value collection (see section 2.1.3), and posture
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: The purpose of discovery is to determine the Endpoint Discovery: To determine the current or historic presence of
type of endpoint to be posture assessed. endpoints in the environment that are available for posture
assessment.
QUESTION: Is it just the type? Or is it to identify what Endpoint Characterization: The act of acquiring, through automated
endpoint instances to target for assessment using metadata such collection or manual input, and organizing attributes
as the endpoint's organizationally expected type (e.g., associated with an endpoint (e.g., type, organizationally
expected function/role, etc.) expected function/role, hardware/software versions).
Identify Endpoint Targets Determine the candidate endpoint target(s) Identify Endpoint Targets: Determine the candidate endpoint
to perform the assessment against. Depending on the assessment target(s) against which to perform the assessment. Depending
trigger, a single endpoint may be targeted or multiple on the assessment trigger, a single endpoint or multiple
endpoints may be targeted based on discovered endpoint endpoints may be targeted based on characterized endpoint
metadata. This may be driven by content that describes the attributes. Guidance describing the assessment to be performed
applicable targets for assessment. In this case the Content may contain instructions or references used to determine the
Query and/or Content Retrieval building blocks (see section applicable assessment targets. In this case the Data Query and
2.1.1) may be used to acquire this content. /or Data Retrieval building blocks (see section 2.1.1) may be
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 dependant on the component inventory, then this capability
is not required for use in performing the assessment. This is not required for use in performing the assessment. This
process can be treated as a collection use case for specific process can be treated as a collection use case for specific
posture attributes. In this case the building blocks for posture 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 component inventory is known, it is then necessary to calculate
what posture attributes are required to be collected to perform what posture attributes are required to be collected to perform
the evaluation. If this is driven by content, then the Content the evaluation. If this is driven by guidance, then the Data
Query and/or Content Retrieval building blocks (see section Query and/or Data Retrieval building blocks (see section 2.1.1)
2.1.1) may be used to acquire this content. may be used to acquire this data.
QUESTION: Are we missing a building block that determines what QUESTION: Are we missing a building block that determines what
previously collected data, if any, is suitable for evaluation and previously collected data, if any, is suitable for evaluation and
what data needs to be actually collected? 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
2.2.2, 2.2.3 which rely on historical 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 is detected).
3. Due to a scheduled or ad hoc collection task. 3. Due to a scheduled or ad hoc collection task.
The building blocks of this use case are: The building blocks of this use case are:
Collection Content Acquisition: If content is required to drive the Collection Guidance Acquisition: If guidance is required to drive
collection of posture attributes values, this capability is the collection of posture attributes values, this capability is
used to acquire this content from one or more content data used to acquire this data from one or more security automation
stores. Depending on the trigger, the specific content to data stores. Depending on the trigger, the specific guidance
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 content to use based on the component inventory determine the guidance to use based on the component inventory
or other assessment criteria. The Content Query and/or Content 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 content. 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 content that attribute values. This may be based on collection guidance
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 Evaluation
This use case describes the process of evaluating collected posture This use case describes the process of evaluating collected posture
attribute values representing actual endpoint state against the attribute values representing actual endpoint state against the
expected state selected for the assessment. This use case can be expected state selected for the assessment. This use case can be
skipping to change at page 9, line 15 skipping to change at page 11, line 35
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:
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. 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 Content Acquisition: If content is required to drive the Evaluation Guidance Acquisition: If guidance is required to drive
evaluation of posture attributes values, this capability is the evaluation of posture attributes values, this capability is
used to acquire this content from one or more content data used to acquire this data from one or more security automation
stores. Depending on the trigger, the specific content to data stores. Depending on the trigger, the specific guidance
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 content to use based on the component inventory determine the guidance to use based on the component inventory
or other assessment criteria. The Content Query and/or Content 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 content. 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 results as expressed in the
specified content. 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.
QUESTION: What if data is unavailable or is not current enough
to support the evaluation? This could be caused if collection
did not occur (for some reason) and previous collection was too
old.
Completion of this process represents a complete assessment cycle as Completion of this process represents a complete assessment cycle as
defined in section 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 2.1.5. Mining the Database
This use case describes the need to analyze previously collected This use case describes the need to analyze previously collected
posture attribute values from one or more endpoints. This is an posture attribute values from one or more endpoints. This is an
alternate use case to Posture Evaluation (see section 2.1.4 that uses alternate use case to Posture Evaluation (see section 2.1.4) that
collected posture attributes values for analysis processes that may uses collected posture attributes values for analysis processes that
do more than evaluating expected vs. actual state(s). may do more than evaluating expected vs. actual state(s).
The building blocks of this use case are: The building blocks of this use case are:
Query: Query a data store for specific posture attribute values. Query: Query a data store for specific posture attribute values.
Change Detection: An operator should have a mechanism to detect the Change Detection: An operator should have a mechanism to detect the
availability of new or changes to existing posture attribute availability of new or changes to existing posture attribute
values. The timeliness of detection may vary from immediate to values. The timeliness of detection may vary from immediate to
on demand. Having the ability to filter what changes are on demand. Having the ability to filter what changes are
detected will allow the operator to focus on the changes that detected will allow the operator to focus on the changes that
are relevant to their use. are relevant to their use.
QUESTION: Does this warrant a separate use case, or should this be QUESTION: Does this warrant a separate use case, or should this be
incorporated into the previous use case? 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.
2.2.1. Definition and Publication of Automatable Configuration Guides 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
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.
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 devices intended function and what configurations depending on the devices 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 an automatable configuration
checklist 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 checklist to a public content for each setting. They publish these checklist to a public security
repository that customers can query to retrieve applicable checklist automation data store that customers can query to retrieve applicable
for their deployed specialized endpoint devices. checklist for their deployed specialized endpoint devices.
Automatable configuration checklist could also come from sources Automatable configuration checklist 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:
Content Definition: To allow content to be defined using Data Definition: To allow guidance to be defined using standardized
standardized or proprietary data models that will drive or proprietary data models that will drive Collection and
Collection and Evaluation. Evaluation.
Content Publication: Providing a mechanism to publish created Data Publication: Providing a mechanism to publish created guidance
content to a content data store. to a security automation data store.
Content Query: To locate and select existing content that may be Data Query: To locate and select existing guidance that may be
reused. reused.
Content Retrieval To retrieve specific content from a content data Data Retrieval To retrieve specific guidance from a security
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 content 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 insure Multiple checklists are used from different vendors to insure
adequate coverage of all IT assets. adequate coverage of all IT assets.
skipping to change at page 11, line 32 skipping to change at page 14, line 29
To identify what checklists are needed, they use automation to gather To identify what checklists are needed, they use automation to gather
an inventory of the software versions utilized by all IT assets in an inventory of the software versions utilized by all IT assets in
the enterprise. This data gathering will involve querying existing the enterprise. This data gathering will involve querying existing
data stores of previously collected endpoint software inventory data stores of previously collected endpoint software inventory
posture data and actively collecting data from reachable endpoints as posture data and actively collecting data from reachable endpoints as
needed utilizing network and systems management protocols. needed utilizing network and systems management protocols.
Previously collected data may be provided by periodic data Previously collected data may be provided by periodic data
collection, network connection-driven data collection, or ongoing collection, network connection-driven data collection, or ongoing
event-driven monitoring of endpoint posture changes. event-driven monitoring of endpoint posture changes.
Using the gathered hardware and software inventory data and Using the collected hardware and software inventory data and
associated asset management data that may indicate the organizational associated asset characterization data that may indicate the
defined functions of each endpoint, checklist content is queried, organizational defined functions of each endpoint, checklist guidance
located and downloaded from the appropriate vendor and 3rd-party is queried, located and downloaded from the appropriate vendor and
content repositories for the appropriate checklists. This content is 3rd-party security automation data store for the appropriate
cached locally to reduce the need to download the checklist content checklists. This guidance is cached locally to reduce the need to
multiple times. retrieve the data multiple times.
Driven by the setting data provided in the checklist, a combination Driven by the setting data provided in the checklist, a combination
of existing configuration data stores and data collection methods are of existing configuration data stores and data collection methods are
used to gather the appropriate posture attributes from each endpoint. used to gather the appropriate posture attributes from (or pertaining
Specific data is gathered based on the defined enterprise function to) each endpoint. Specific posture attribute values are gathered
and software inventory of each endpoint. The data collection paths based on the defined enterprise function and software inventory of
used to collect software inventory posture will be used again for each endpoint. The collection mechanisms used to collect software
this purpose. Once the data is gathered, the actual state is inventory posture will be used again for this purpose. Once the data
evaluated against the expected state criteria in each applicable is gathered, the actual state is evaluated against the expected state
checklist. The results of this evaluation are provided to criteria defined in each applicable checklist. The results of this
appropriate operators and applications to drive additional business evaluation are provided to appropriate operators and applications to
logic. drive additional business logic.
Checklists could include searching for indicators of compromise on Checklists could include searching for indicators of compromise on
the endpoint (e.g., file hashes); identifying malicious activity the endpoint (e.g., file hashes); identifying malicious activity
(e.g. command and control traffic); detecting presence of (e.g. command and control traffic); detecting presence of
unauthorized/malicious software, hardware, and configuration items; unauthorized/malicious software, hardware, and configuration items;
and other indicators. and other indicators.
A checklist can be assessed as a whole, or a specific subset of the A checklist can be assessed as a whole, or a specific subset of the
checklist can be assessed resulting in partial data collection and checklist can be assessed resulting in partial data collection and
evaluation. evaluation.
skipping to change at page 13, line 13 skipping to change at page 16, line 10
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.
Collection Content Acquisition: Based on the identified posture Collection Guidance Acquisition: Based on the identified posture
attributes, the application will query appropriate content data attributes, the application will query appropriate security
stores to find the "applicable" data collection content for automation data stores to find the "applicable" collection
each endpoint in question. guidance for each endpoint in question.
Posture Attribute Value Collection: For each endpoint, the values Posture Attribute Value Collection: For each endpoint, the values
for the required posture attributes are collected. for the required posture attributes are collected.
Posture Attribute Value Query: If previously collected posture Posture Attribute Value Query: If previously collected posture
attribute values are used, they are queried from the attribute values are used, they are queried from the
appropriate data stores for the target endpoint(s). appropriate data stores for the target endpoint(s).
Evaluation Content Acquisition: Any content 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 content 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
skipping to change at page 13, line 52 skipping to change at page 16, line 49
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 indicating any
deviations to the device's operators. Once the baseline has been deviations 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 section
2.2.2), this usage scenario supports assessment of checklists. It 2.2.2), this usage scenario supports assessment based on automatable
differs from that scenario by monitoring for specific endpoint checklists. It differs from that scenario by monitoring for specific
posture changes on an ongoing basis. When the endpoint detects a endpoint posture changes on an ongoing basis. When the endpoint
posture change, an alert is generated identifying the specific detects a posture change, an alert is generated identifying the
changes in posture allowing a delta assessment to be performed specific changes in posture allowing assessment of the delta to be
instead of a full assessment in the previous case. This usage performed instead of a full assessment in the previous case. This
scenario employs the same building blocks as Automated Checklist usage scenario employs the same building blocks as
Verification (see section 2.2.2). It differs slightly in how it uses Automated Checklist Verification (see section 2.2.2). It differs
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.
Posture Attribute Value Query: The previous state of posture Posture Attribute Value Query: The previous state of posture
skipping to change at page 15, line 33 skipping to change at page 18, line 29
current on vulnerability testing. Interactive assessments are 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
content repository 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 CMDB. When new
vulnerabilities are reported to the content repository, a request to vulnerabilities are reported to the security automation data store, a
the live asset is only done if the artifacts in the CMDB are request to the live asset is only done if the artifacts in the CMDB
incomplete and/or not current enough. 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 expose is calculated where the level of compliance and vulnerability expose 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.
Like the Automated Checklist Verification usage scenario (see section Like the Automated Checklist Verification usage scenario (see section
2.2.2), this usage scenario supports assessment of checklists. It 2.2.2), this usage scenario supports assessment based on checklists.
differs from that scenario in how content, collected posture values, It differs from that scenario in how guidance, collected posture
and evaluation results are exchanged due to bandwidth limitations and attribute values, and evaluation results are exchanged due to
availability. This usage scenario employs the same building blocks bandwidth limitations and availability. This usage scenario employs
as Automated Checklist Verification (see section 2.2.2). It differs the same building blocks as Automated Checklist Verification (see
slightly in how it uses the following building blocks: section 2.2.2). It differs slightly in how it uses the following
building blocks:
Endpoint Component Inventory: It is likely that the component Endpoint Component Inventory: It is likely that the component
inventory will not change. If it does, this information will inventory will not change. If it does, this information will
need to be batched and transmitted during the next need to be batched and transmitted during the next
communication window. communication window.
Collection Content 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
content will need to batched and transmitted during the next guidance will need to batched and transmitted during the next
communication window. Content 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 in the same way.
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 Content 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
content will need to batched and transmitted during the next guidance will need to batched and transmitted during the next
communication window. Content 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 content, 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
satellite site. satellite site.
This usage scenario highlights the need to support low-bandwidth, This usage scenario highlights the need to support low-bandwidth,
intermittent, or high-latency links. intermittent, or high-latency links.
2.2.6. Identification and Retrieval of Repository Content 2.2.6. Identification and Retrieval of Guidance
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 content data stores application will need to identify one or more security automation
that contain the content entries necessary to perform data collection data stores that contain the guidance entries necessary to perform
and evaluation tasks. The location of a given content entry will data collection and evaluation tasks. The location of a given
either be known a priori or known content repositories will need to guidance entry will either be known a priori or known security
be queried to retrieve applicable content. automation data stores will need to be queried to retrieve applicable
guidance.
To query content 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 content-specific criteria elements. Once the modification time) and guidance data-specific criteria elements.
criteria is defined, one or more content data stores will need to be Once the criteria is defined, one or more security automation data
queried generating a result set. Depending on how the results are stores will need to be queried generating a result set. Depending on
used, it may be desirable to return the matching content directly, a how the results are used, it may be desirable to return the matching
snippet of the content matching the query, or a resolvable location guidance directly, a snippet of the guidance matching the query, or a
to retrieve the content at a later time. The content matching the resolvable location to retrieve the data at a later time. The
query will be restricted based the authorized level of access allowed guidance matching the query will be restricted based the authorized
to the requester. level of access allowed to the requester.
If the location of content is identified in the query result set, the If the location of guidance is identified in the query result set,
content will be retrieved when needed using one or more content 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 content. In this maintain a local cache of previously retrieved data. In this case,
case, only content that is determined to be stale by some measure only guidance that is determined to be stale by some measure will be
will be retrieved from the remote content store. retrieved from the remote data store.
Alternately, content can be discovered by iterating over content Alternately, guidance can be discovered by iterating over data
published with a given context within a content repository. Specific published with a given context within a security automation data
content can be selected and retrieved as needed. store. Specific guidance can be selected and retrieved as needed.
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:
Content Query: Enables an operator or application to query one or Data Query: Enables an operator or application to query one or more
more content data stores for content using a set of specified security automation data stores for guidance using a set of
criteria. specified criteria.
Content Retrieval: If content locations are returned in the query Data Retrieval: If data locations are returned in the query result
result set, then specific content entries can be retrieved and set, then specific guidance entries can be retrieved and
possibly cached locally. possibly cached locally.
2.2.7. Content 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 content in a content repository for which they have been deleted guidance in a security automation data store for which they
authorized to access. This may be achieved by querying or iterating have been authorized to access. This may be achieved by querying or
over content in a content repository, or through a notification iterating over guidance in a security automation data store, or
mechanism that alerts to changes made to a content repository. through a notification mechanism that alerts to changes made to a
security automation data store.
Once content 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:
Content Change Detection: Allows an operator or application to Data Change Detection: Allows an operator or application to identify
identify content changes in a content data store which they guidance changes in a security automation data store which they
have been authorized to access. have been authorized to access.
Content Retrieval: If content locations are provided by the change Data Retrieval: If data locations are provided by the change
detection mechanism, then specific content entries can be detection mechanism, then specific guidance entries can be
retrieved and possibly cached locally. retrieved and possibly cached locally.
2.2.8. Others... 2.2.8. Others...
Additional use cases will be identified as we work through other Additional usage scenarios will be identified as we work through
domains. other domains.
3. IANA Considerations 3. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
4. Security Considerations 4. Security Considerations
This memo documents, for Informational purposes, use cases for This memo documents, for Informational purposes, use cases for
security automation. While it is about security, it does not affect security automation. While it is about security, it does not affect
security. security.
skipping to change at page 19, line 12 skipping to change at page 22, line 15
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. -04- to -05- 6.1. -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.2. -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 20, line 11 skipping to change at page 23, line 35
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.2. -03- to -04- 6.3. -03- to -04-
Added four new use cases regarding content repository. Added four new use cases regarding content repository.
6.3. -02- to -03- 6.4. -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 21, line 5 skipping to change at page 24, line 25
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.4. -01- to -02- 6.5. -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.5. -00- to -01- 6.6. -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 22, line 20 skipping to change at page 25, line 39
"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.6. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 6.7. 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 23, line 11 skipping to change at page 26, line 30
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.7. waltermire -04- to -05- 6.8. 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 I removed the references to what the WG will do because this
belongs in the charter, not the (potentially long-lived) use cases belongs 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
skipping to change at page 24, line 20 skipping to change at page 27, line 38
o The document had asset management, but the charter mentioned o The document had asset management, but the charter mentioned
asset, change, configuration, and vulnerability management, so I asset, change, configuration, and vulnerability management, so I
added sections for each of those categories. added sections for each of those categories.
o Added text to Introduction explaining goal of the document. o Added text to Introduction explaining goal of the document.
o Added sections on various example use cases for asset management, o Added sections on various example use cases for asset management,
config management, change management, and vulnerability config management, change management, and vulnerability
management. management.
7. References 7. Informative References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
"Remote Authentication Dial In User Service (RADIUS)", RFC Information Models and Data Models", RFC 3444, January
2865, June 2000. 2003.
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 USA
Email: david.waltermire@nist.gov Email: david.waltermire@nist.gov
 End of changes. 88 change blocks. 
279 lines changed or deleted 449 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/