draft-ietf-sacm-use-cases-08.txt   draft-ietf-sacm-use-cases-09.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: August 30, 2015 Effective Software Expires: September 25, 2015 Effective Software
February 26, 2015 March 24, 2015
Endpoint Security Posture Assessment - Enterprise Use Cases Endpoint Security Posture Assessment - Enterprise Use Cases
draft-ietf-sacm-use-cases-08 draft-ietf-sacm-use-cases-09
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 August 30, 2015. This Internet-Draft will expire on September 25, 2015.
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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Configuration Checklists . . . . . . . . . . . . . . 12 Configuration Checklists . . . . . . . . . . . . . . 12
2.2.2. Automated Checklist Verification . . . . . . . . . . 13 2.2.2. Automated Checklist Verification . . . . . . . . . . 13
2.2.3. Detection of Posture Deviations . . . . . . . . . . . 16 2.2.3. Detection of Posture Deviations . . . . . . . . . . . 16
2.2.4. Endpoint Information Analysis and Reporting . . . . . 17 2.2.4. Endpoint Information Analysis and Reporting . . . . . 17
2.2.5. Asynchronous Compliance/Vulnerability Assessment at 2.2.5. Asynchronous Compliance/Vulnerability Assessment at
Ice Station Zebra . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. -07- to -08- . . . . . . . . . . . . . . . . . . . . . . 22 6.1. -08- to -09- . . . . . . . . . . . . . . . . . . . . . . 22
6.2. -06- to -07- . . . . . . . . . . . . . . . . . . . . . . 22 6.2. -07- to -08- . . . . . . . . . . . . . . . . . . . . . . 22
6.3. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 22 6.3. -06- to -07- . . . . . . . . . . . . . . . . . . . . . . 22
6.4. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 23 6.4. -05- to -06- . . . . . . . . . . . . . . . . . . . . . . 23
6.5. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 24 6.5. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 23
6.6. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 24 6.6. -03- to -04- . . . . . . . . . . . . . . . . . . . . . . 24
6.7. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 24 6.7. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 24
6.8. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 25 6.8. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 25
6.9. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 6.9. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 25
6.10. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 26 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 26
6.10. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 27 6.11. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 27
7. Informative References . . . . . . . . . . . . . . . . . . . 28 7. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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:
skipping to change at page 3, line 28 skipping to change at page 3, line 30
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.
Togther 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,
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.
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, but there are additional providers will largely overlap. When considering this overlap, there
complications for service providers, especially in handling are additional complications for service providers, especially in
information that crosses administrative domains. handling information that crosses administrative domains.
The output of endpoint posture assessment is expected to feed into The output of endpoint posture assessment is expected to feed into
additional processes, such as policy-based enforcement of acceptable additional processes, such as policy-based enforcement of acceptable
state, verification and monitoring of security controls, and state, verification and monitoring of security controls, and
compliance to regulatory requirements. compliance to regulatory requirements.
2. Endpoint Posture Assessment 2. Endpoint Posture Assessment
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.
skipping to change at page 4, line 25 skipping to change at page 4, line 28
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
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.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
* Guidance that specifies how old collected data can be to be * Guidance that specifies how old collected data can be to be
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.,
skipping to change at page 7, line 35 skipping to change at page 7, line 35
* 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.
* Organizationally defined expected posture attribute values * Organizationally defined expected posture attribute values
targeted to specific evaluation guidance and endpoint targeted to specific evaluation guidance and endpoint
characteristics. This allows a common set of guidance to be characteristics. This allows a common set of guidance to be
parameterized for use with different groups of endpoints. parameterized for use with different groups of endpoints.
Processing Artifacts: Data that is generated by and is specific to Processing Artifacts: Data that is generated by, and is specific to,
an individual assessment process. This data may be used as an individual assessment process. This data may be used as
part of the interactions between architectural components to part of the interactions between architectural components to
drive and coordinate collection and evaluation activities. Its drive and coordinate collection and evaluation activities. Its
lifespan will be bounded by the lifespan of the assessment. It lifespan will be bounded by the lifespan of the assessment. It
may also be exchanged and stored to provide historic context may also be exchanged and stored to provide historic context
around an assessment activity so that individual assessments around an assessment activity so that individual assessments
can be grouped, evaluated, and reported in an enterprise can be grouped, evaluated, and reported in an enterprise
context. context.
This includes: This includes:
skipping to change at page 8, line 37 skipping to change at page 8, line 37
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 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
credentials. As a result, the visibility of specific security credentials. As a result, the visibility of specific security
automation data to an operator or application may be public, automation data to an operator or application may be public,
skipping to change at page 9, line 10 skipping to change at page 9, line 10
scope. scope.
Data Query: An operator or application should be able to query a Data Query: An operator or application should be able to query a
security automation data store using a set of specified security automation data store using a set of specified
criteria. The result of the query will be a listing matching criteria. The result of the query will be a listing matching
the query. The query result listing may contain publication the query. The query result listing may contain publication
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: An 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 interested in has been published
to, updated in, or deleted from a security automation data to, updated in, or deleted from a security automation data
store which they have been authorized to 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
skipping to change at page 12, line 31 skipping to change at page 12, line 31
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.
While the primary focus of this use cases is around enabling the While the primary focus of this use case is around enabling the
comparison of expected vs. actual state, the same building blocks can comparison of expected vs. actual state, the same building blocks can
support other analysis techniques that are applied to collected support other analysis techniques that are applied to collected
posture attribute data (e.g., trending, historic analysis). posture attribute data (e.g., trending, historic analysis).
Completion of this process represents a complete assessment cycle as Completion of this process represents a complete assessment cycle as
defined in Section 2. defined in Section 2.
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
skipping to change at page 13, line 9 skipping to change at page 13, line 9
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 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 an 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 checklist 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 for their deployed specialized endpoint devices. checklist(s) 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:
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.
Data Publication: Providing a mechanism to publish created guidance Data Publication: Providing a mechanism to publish created guidance
to a security automation data store. to a security automation data store.
Data Query: To locate and select existing guidance that may be Data Query: To locate and select existing guidance that may be
reused. reused.
Data Retrieval To retrieve specific guidance from a security Data Retrieval To retrieve specific guidance from a security
automation data store for editing. automation data store for editing.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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 efforts. Irrespective of specific
applications, the availability, timeliness, and liveness of results applications, the availability, timeliness, and liveness of results
is often of general concern. Network latency and available bandwidth is often of general concern. Network latency and available bandwidth
often create operational constriants that require trade-offs between often create operational constraints that require trade-offs between
these concerns and need to be considered. 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 missing required patches, * identify missing required patches,
skipping to change at page 16, line 23 skipping to change at page 16, line 23
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 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 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 based on automatable 2.2.2), this usage scenario supports assessment based on automatable
checklists. It differs from that scenario by monitoring for specific checklists. It differs from that scenario by monitoring for specific
endpoint posture changes on an ongoing basis. When the endpoint endpoint posture changes on an ongoing basis. When the endpoint
detects a posture change, an alert is generated identifying the detects a posture change, an alert is generated identifying the
specific changes in posture allowing assessment of the delta to be specific changes in posture allowing assessment of the delta to be
performed instead of a full assessment in the previous case. This performed instead of a full assessment in the previous case. This
usage scenario employs the same building blocks as usage scenario employs the same building blocks as
skipping to change at page 18, line 13 skipping to change at page 18, line 13
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 continue
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 keep
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
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 CMDB. When new
vulnerabilities are reported to the security automation data store, a vulnerabilities are reported to the security automation data store, a
request to the live asset is only done if the artifacts in the CMDB request to the live asset is only done if the artifacts in the CMDB
are 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 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.
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 based on checklists. 2.2.2), this usage scenario supports assessment based on checklists.
It differs from that scenario in how guidance, collected posture It differs from that scenario in how guidance, collected posture
attribute values, and evaluation results are exchanged due to attribute values, and evaluation results are exchanged due to
bandwidth limitations and availability. This usage scenario employs bandwidth limitations and availability. This usage scenario employs
the same building blocks as Automated Checklist Verification (see the same building blocks as Automated Checklist Verification (see
section 2.2.2). It differs slightly in how it uses the following section 2.2.2). It differs slightly in how it uses the following
skipping to change at page 21, line 34 skipping to change at page 21, line 34
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. 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. Specific security considerations will be security automation. Specific security considerations will be
provided in related documents (e.g., requirements, architecture, provided in related documents (e.g., requirements, architecture,
information model, data model, protocol) as appropriate to the information model, data model, protocol) as appropriate to the
function described in each related document. function described in each related document.
One consideration for security automation is that a malicious actor
could use the security automation infrastructure and related
collected data to determine endpoint weaknesses to exploit. It is
important that security considerations in the related documents
identify methods to both identify and prevent such activity.
Specifically, means for protecting the communications as well as the
systems that store the information. For communications between the
varying SACM components there should be considerations for protecting
the confidentiality, data integrity and peer entity authentication.
Also, for any systems that store information that could be used for
malicious purposes, methods to identify and protect against
unauthorized usage, inappropriate usage and denial of service need to
be considered.
5. Acknowledgements 5. Acknowledgements
Adam Montville edited early versions of this draft. Adam Montville edited early versions of this draft.
Kathleen Moriarty, and Stephen Hanna contributed text describing the Kathleen Moriarty, and Stephen Hanna contributed text describing the
scope of the document. scope of the document.
Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa
Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and
Aron Woland provided use cases text for various revisions of this Aron Woland provided use cases text for various revisions of this
draft. draft.
6. Change Log 6. Change Log
6.1. -07- to -08- 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 Reworked long sentences throughout the document by shortening or
using bulleted lists. using bulleted lists.
Re-ordered and condensed text in the "Automated Checklist Re-ordered and condensed text in the "Automated Checklist
Verification" sub-section to improve the conceptual presentation and Verification" sub-section to improve the conceptual presentation and
to clarify longer sentences. to clarify longer sentences.
Clarified that the "Posture Attribute Value Query" building block Clarified that the "Posture Attribute Value Query" building block
represents a standardized interface in the context of SACM. represents a standardized interface in the context of SACM.
Removed the "others" sub-section within the "usage scenarios" Removed the "others" sub-section within the "usage scenarios"
section. section.
Updated the "Security Considerations" section to identify that actual Updated the "Security Considerations" section to identify that actual
SACM security considerations will be discussed in the appropriate SACM security considerations will be discussed in the appropriate
related documents. related documents.
6.2. -06- to -07- 6.3. -06- to -07-
A number of edits were made to section 2 to resolve open questions in A number of edits were made to section 2 to resolve open questions in
the draft based on meeting and mailing list discussions. the draft based on meeting and mailing list discussions.
Section 2.1.5 was merged into section 2.1.4. Section 2.1.5 was merged into section 2.1.4.
6.3. -05- to -06- 6.4. -05- to -06-
Updated the "Introduction" section to better reflect the use case, Updated the "Introduction" section to better reflect the use case,
building block, and usage scenario structure changes from previous building block, and usage scenario structure changes from previous
revisions. revisions.
Updated most uses of the terms "content" and "content repository" to Updated most uses of the terms "content" and "content repository" to
use "guidance" and "security automation data store" respectively. use "guidance" and "security automation data store" respectively.
In section 2.1.1, added a discussion of different data types and In section 2.1.1, added a discussion of different data types and
renamed "content" to "data" in the building block names. renamed "content" to "data" in the building block names.
skipping to change at page 23, line 8 skipping to change at page 23, line 27
In section 2.1.2, separated out the building block concepts of In section 2.1.2, separated out the building block concepts of
"Endpoint Discovery" and "Endpoint Characterization" based on mailing "Endpoint Discovery" and "Endpoint Characterization" based on mailing
list discussions. list discussions.
Addressed some open questions throughout the draft based on consensus Addressed some open questions throughout the draft based on consensus
from mailing list discussions and the two virtual interim meetings. from mailing list discussions and the two virtual interim meetings.
Changed many section/sub-section names to better reflect their Changed many section/sub-section names to better reflect their
content. content.
6.4. -04- to -05- 6.5. -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 24, line 8 skipping to change at page 24, line 26
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.5. -03- to -04- 6.6. -03- to -04-
Added four new use cases regarding content repository. Added four new use cases regarding content repository.
6.6. -02- to -03- 6.7. -02- to -03-
Expanded the workflow description based on ML input. Expanded the workflow description based on ML input.
Changed the ambiguous "assess" to better separate data collection Changed the ambiguous "assess" to better separate data collection
from evaluation. from evaluation.
Added use case for Search for Signs of Infection. Added use case for Search for Signs of Infection.
Added use case for Remediation and Mitigation. Added use case for Remediation and Mitigation.
skipping to change at page 24, line 45 skipping to change at page 25, line 16
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.7. -01- to -02- 6.8. -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.8. -00- to -01- 6.9. -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 26, line 10 skipping to change at page 26, line 30
"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.9. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 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 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 27, line 5 skipping to change at page 27, line 21
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.10. waltermire -04- to -05- 6.11. waltermire -04- to -05-
o Are we including user activities and behavior in the scope of this o Are we including user activities and behavior in the scope of this
work? That seems to be layer 8 stuff, appropriate to an IDS/IPS work? That seems to be layer 8 stuff, appropriate to an IDS/IPS
application, not Internet stuff. application, not Internet stuff.
o Removed the references to what the WG will do because this belongs o Removed the references to what the WG will do because this belongs
in the charter, not the (potentially long-lived) use cases in the charter, not the (potentially long-lived) use cases
document. I removed mention of charter objectives because the document. I removed mention of charter objectives because the
charter may go through multiple iterations over time; there is a charter may go through multiple iterations over time; there is a
website for hosting the charter; this document is not the correct website for hosting the charter; this document is not the correct
 End of changes. 38 change blocks. 
49 lines changed or deleted 74 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/