draft-ietf-sacm-use-cases-00.txt   draft-ietf-sacm-use-cases-01.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: February 23, 2014 Effective Software Expires: March 16, 2014 Effective Software
August 22, 2013 September 12, 2013
Using Security Posture Assessment to Grant Access to Enterprise Network Using Security Posture Assessment to Grant Access to Enterprise Network
Resources Resources
draft-ietf-sacm-use-cases-00 draft-ietf-sacm-use-cases-01
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 assessing that data to configuration and operational data and assessing 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 assessing data relevant to security standards for aggregating and assessing data relevant to security
posture. posture.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 February 23, 2014. This Internet-Draft will expire on March 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 4 3. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 4
3.1. Example - Departmental Software Policy Compliance . . . . 4 3.1. Definition and Publication of Automatable Configuration
3.2. Main Success Scenario . . . . . . . . . . . . . . . . . . 4 Guides . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Automated Checklist Verification . . . . . . . . . . . . 6
4.1. Asset Management . . . . . . . . . . . . . . . . . . . . 5 3.3. Organizational Software Policy Compliance . . . . . . . . 7
4.1.1. Asset Discovery . . . . . . . . . . . . . . . . . . . 6 3.4. Detection of Posture Deviations . . . . . . . . . . . . . 7
4.1.2. Asset Identification . . . . . . . . . . . . . . . . 6 3.5. Others... . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.3. Endpoint Components and Asset Composition . . . . . . 7 4. Functional Capabilities . . . . . . . . . . . . . . . . . . . 7
4.1.4. Asset Characterization . . . . . . . . . . . . . . . 7 4.1. Asset Identification . . . . . . . . . . . . . . . . . . 8
4.1.5. Asset Resources . . . . . . . . . . . . . . . . . . . 9 4.1.1. Asset Class Identification . . . . . . . . . . . . . 8
4.1.6. Asset Representation Reconciliation . . . . . . . . . 9 4.1.2. Asset Instance Identification . . . . . . . . . . . . 9
4.1.7. Asset Life Cycle . . . . . . . . . . . . . . . . . . 9 4.2. Asset Characterization . . . . . . . . . . . . . . . . . 10
4.2. Endpoint Configuration Management . . . . . . . . . . . . 9 4.3. Deconfliction of Asset Identities . . . . . . . . . . . . 13
4.2.1. Organizing Configuration Metadata . . . . . . . . . . 10 4.4. Asset Targeting . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Publishing Recommended Configuration Posture . . . . 10 4.5. Other Unedited Content . . . . . . . . . . . . . . . . . 15
4.2.3. Defining Organizationally Expected Configuration 4.5.1. Endpoint Configuration Management . . . . . . . . . . 15
Posture . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.1.1. Organizing Configuration Metadata . . . . . . . . 15
4.2.4. Collecting Endpoint Configuration Posture . . . . . . 10 4.5.1.2. Publishing Recommended Configuration Posture . . 16
4.2.5. Comparing Expected and Actual Configuration Posture . 10 4.5.1.3. Defining Organizationally Expected Configuration
4.2.6. Examining configuration of logical to physical Posture . . . . . . . . . . . . . . . . . . . . . 16
mappings . . . . . . . . . . . . . . . . . . . . . . 11 4.5.1.4. Collecting Endpoint Configuration Posture . . . . 16
4.2.7. Configuring Endpoint Interfaces . . . . . . . . . . . 11 4.5.1.5. Comparing Expected and Actual Configuration
4.3. Endpoint Posture Change Management . . . . . . . . . . . 11 Posture . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Defining and Exchanging Baselines . . . . . . . . . . 11 4.5.1.6. Examining configuration of logical to physical
4.3.2. Detecting Unauthorized Changes . . . . . . . . . . . 11 mappings . . . . . . . . . . . . . . . . . . . . 17
4.3.2.1. Endpoint Addressing Changes . . . . . . . . . . . 11 4.5.1.7. Configuring Endpoint Interfaces . . . . . . . . . 17
4.3.2.2. Service Authorization Changes . . . . . . . . . . 11 4.5.2. Endpoint Posture Change Management . . . . . . . . . 17
4.3.2.3. Dynamic Resource Assignment Changes . . . . . . . 11 4.5.2.1. Defining and Exchanging Baselines . . . . . . . . 17
4.3.2.4. Security Authorization Status Changes . . . . . . 12 4.5.2.2. Detecting Unauthorized Changes . . . . . . . . . 17
4.4. Security Vulnerability Management . . . . . . . . . . . . 12 4.5.3. Security Vulnerability Management . . . . . . . . . . 18
4.4.1. Example - NIDS response . . . . . . . . . . . . . . . 12 4.5.3.1. Example - NIDS response . . . . . . . . . . . . . 18
4.4.2. Example - Historical vulnerability analysis . . . . . 13 4.5.3.2. Example - Historical vulnerability analysis . . . 19
4.4.3. Source Address Validation . . . . . . . . . . . . . . 13 4.5.3.3. Source Address Validation . . . . . . . . . . . . 19
4.5. Data Collection . . . . . . . . . . . . . . . . . . . . . 13 4.5.4. Data Collection . . . . . . . . . . . . . . . . . . . 19
4.6. Assessment Result Analysis . . . . . . . . . . . . . . . 13 4.5.5. Assessment Result Analysis . . . . . . . . . . . . . 20
4.7. Content Management . . . . . . . . . . . . . . . . . . . 14 4.5.6. Content Management . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 8.1. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 21
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 15 8.2. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
8.2. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 16 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Our goal with this document is to improve our agreement on which 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 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 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 agree on which problems we're trying to solve, we can move on to
propose various solutions and decide which ones to use. propose various solutions and decide which ones to use.
This document describes example use cases for endpoint posture This document describes example use cases for endpoint posture
skipping to change at page 4, line 18 skipping to change at page 4, line 18
compliance to regulatory requirements. compliance to regulatory requirements.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Endpoint Posture Assessment 3. Endpoint Posture Assessment
Endpoint posture assessment involves collecting information about the Endpoint posture assessment involves orchestrating and performing
posture of a given endpoint. This posture information is gathered data collection and analysis pertaining to the posture of a given
and then published to appropriate data repositories to make collected endpoint. Typically, endpoint posture information is gathered and
then published to appropriate data repositories to make collected
information available for further analysis supporting organizational information available for further analysis supporting organizational
security processes. security processes.
Endpoint posture assessment typically includes: Endpoint posture assessment typically includes:
o Collecting the posture of a given endpoint; o Collecting the posture of a given endpoint;
o Making that posture available to the enterprise for further o Making that posture available to the enterprise for further
analysis and action; and analysis and action; and
o Assessing that the endpoint's posture is in compliance with o Performing analysis to assess that the endpoint's posture is in
enterprise standards and policy. compliance with enterprise standards and policy.
3.1. Example - Departmental Software Policy Compliance
In order to meet compliance requirements and ensure that corporate As part of these activities it is often necessary to identify and
finance information is not revealed improperly, all computers in the acquire any supporting content that is needed to drive data
finance department of Example Corporation are required to run only collection and analysis.
software contained on an approved list and to be configured to
download and install software patches every night. Each computer is
checked to make sure it complies with this policy whenever it
connects to the network and at least once a day thereafter. These
daily compliance checks assess the posture of each computer and
report on its compliance with policy.
3.2. Main Success Scenario The following is a typical success scenario for endpoint posture
assessment:
1. Define a target endpoint to be assessed 1. Define a target endpoint to be assessed
2. Select acceptable state policies to apply to the defined target 2. Select acceptable state policies to apply to the defined target
3. Identify the endpoint being assessed 3. Identify the endpoint being assessed
4. Collect posture attributes from the target 4. Collect posture attributes from the target
5. Communicate target identity and collected posture to external 5. Communicate target identity and collected posture to external
system for evaluation system for evaluation
6. Compare collected posture attributes from the target endpoint 6. Compare collected posture attributes from the target endpoint
with expected state values as expressed in acceptable state with expected state values as expressed in acceptable state
policies policies
4. Use Cases The following subsections detail specific use cases for data
collection, analysis, and related operations pertaining to the
publication and use of supporting content.
The use cases defined in this section support assessing endpoint 3.1. Definition and Publication of Automatable Configuration Guides
posture in an automated manner as described in Section Section 3.
The following sub-sections describe use cases broken out by their
corresponding IT decipline.
4.1. Asset Management QUESTION: This use case applies equally to vendors representing other
endpoint types. Should this be generalized to capture this notion?
Organizations manage a variety of assets within their enterprise A network device vendor manufactures a number of enterprise grade
including: endpoints, the hardware they are composed of, installed routers and other network devices. The also develop and maintain an
software, hardware/software licenses used, and configurations. operating system for these devices that enables end-user
organizations to configure a number of security and operational
settings for these devices. As part of their customer support
activities, they publish a number of secure configuration guides that
provide minimum security guidelines for configuring their devices.
Managing endpoints and the different types of assets that compose Each guide they produce applies to a specific model of device and
them involves initially discovering and characterizing each asset version of the operating system and provides a number of specialized
instance, and then identify them in a common way. Characterization configurations depending on the devices intended function and what
may take the form of logical characterization or security add-on hardware modules and software licenses are installed on the
characterization, where logical characterization may include business device. To enable their customers to assess the security posture of
context not otherwise related to security, but which may be used as their devices to ensure that all appropriate minimal security
information in support of decision making later in risk management. settings are enabled, they publish an automatable configuration
checklist using a popular data format that defines what settings to
check using a network management protocol and appropriate values for
each setting. They publish these guides to a public content
repository that customers can query to retrieve applicable guides for
their deployed enterprise network infrastructure endpoints.
Coverage involves understanding what and how many assets are under To support this use case, the following capabilities will be
control. Assessing 80% of the enterprise assets is better than utilized:
assessing 50% of the enterprise assets.
Getting asset details can be comparatively subtle - if an enterprise o Asset Identification (see section 4.1) - Hardware and software
does not have a precise understanding of its assets, then all class-level asset identities will be used to identify the
acquired data and consequent actions taken based on the data are applicable targets for each configuration guide and within the
considered suspect. guide specialized targets for licensed features and hardware
modules.
Assessing assets (managed and unmanaged) requires that we have o Asset Characterization - Asset characteristics will be used to
visibility into the posture of endpoints, the ability to understand identify the target endpoint functions addressed by each
the composition and relationships between different assets types, and configuration guide.
the ability to properly characterize them at the outset and over
time.
The following list details some requisite Asset Management o Asset Targeting - Applicability expressions will be described
capabilities: using asset identification and characterization attributes to
scope the checklist and specific groupings of configurations to
associated hardware and software products, features, and asset
functions.
o Discover assets in the enterprise o [TODO: Need to list other functions here as the sections
stabilize.]
o Identify and describe assets using a common vocabulary between QUESTION: Is providing traceability to functional capabilities
implementations useful? If so, we need to replicate this for the other use cases.
o For a given endpoint, understand the composition and relationship 3.2. Automated Checklist Verification
of its constituent assets
o Characterize assets according to security and non-security asset A financial services company operates a heterogeneous IT environment.
properties In support of their risk management program, they utilize vendor
provided automatable security configuration checklists for each
operating system and application used within their IT environment.
Multiple checklists are used from different vendors to insure
adequate coverage of all IT assets.
o Reconcile asset representations originating from disparate tools To identify what checklists are needed, they use automation to gather
an inventory of the software versions utilized by all IT assets in
the enterprise. This data gathering will involve querying existing
data stores of previously collected endpoint software inventory
posture data and actively collecting data from reachable endpoints as
needed utilizing network and systems management protocols.
Previously collected data may be provided by periodic data
collection, network connection-driven data collection, or ongoing
event-driven monitoring of endpoint posture changes.
o Manage asset information throughout the asset's life cycle Using the gathered software inventory data and associated asset
management data indicating the organizational defined functions of
each endpoint, they locate and query each vendors content repository
for the appropriate checklists. These checklists are cached locally
to reduce the need to download the checklist multiple times.
4.1.1. Asset Discovery Driven by the setting data provided in the checklist, a combination
of existing configuration data stores and data collection methods are
used to gather the appropriate posture information from each
endpoint. Specific data is gathered based on the defined enterprise
function and software inventory of each endpoint. The data
collection paths used to collect software inventory posture will be
used again for this purpose. Once the data is gathered, the actual
state is evaluated against the expected state criteria in each
applicable checklist. Deficiencies are identified and reported to
the appropriate endpoint operators for remedy.
Many network management systems periodically test for the presence of 3.3. Organizational Software Policy Compliance
endpoints or interfaces in a network, including discovering endpoints
that have suddenly appeared in a network that are not authorized to
be part of the network. Other approaches can be used to identify new
endpoints as they connect to the network alowing for authentication
and authorization to occur dynamically as part of a network access
control decision. There are many layers of endpoints, and many
standardized information models for determining endpoints in a
network.
These standardized collections include ARP tables [RFC0826], Example Corporation, in support of compliance requirements, has
Interface tables such as the Interfaces MIB (IF-MIB) [RFC2863] or the identified a number of secure baselines for different endpoint types
YANG module ietf-interfaces , Link Layer Discovery tables [RFC2922], that exist across their enterprise IT environment. Determining which
DHCP tables (Ref:???), and so on. baseline applies to a given endpoint is based on the organizationally
defined function of the device.
4.1.2. Asset Identification Each baseline, defined using an automatable standardized data format,
identifies the expected hardware, software and patch inventory, and
software configuration item values for each endpoint type. As part
of their compliance activities, they require that all endpoints
connecting to their network meet the appropriate baselines. Each
endpoint is checked to make sure it complies with the appropriate
baseline whenever it connects to the network and at least once a day
thereafter. These daily compliance checks assess the posture of each
endpoint and report on its compliance with the appropriate baseline.
[TODO: Need to speak to how the baselines are identified for a given
endpoint connecting to the network.]
3.4. Detection of Posture Deviations
Example corporation has established secure configuration baselines
for each different type of endpoint within their enterprise
including: network infrastructure, mobile, client, and server
computing platforms. These baselines define an approved list of
hardware, software (i.e., operating system, applications, and
patches), and associated required configurations. When an endpoint
connects to the network, the appropriate baseline configuration is
communicated to the endpoint based on its location in the network,
the expected function of the device, and other asset management data.
It is checked for compliance with the baseline indicating any
deviations to the device's operators. Once the baseline has been
established, the endpoint is monitored for any change events
pertaining to the baseline on an ongoing basis. When a change occurs
to posture defined in the baseline, updated posture information is
exchanged allowing operators to be notified and/or automated action
to be taken.
3.5. Others...
Additional use cases will be identified as we work through other
domains.
4. Functional Capabilities
The use cases defined in the previous section highlight various uses
of endpoint posture assessment to support a variety of IT security
business processes. The following subsections address derived
functional capabilities that are needed to support these use cases.
4.1. Asset Identification
Organizations manage a variety of assets within their enterprise
including: endpoints, the hardware they are composed of, installed
software, hardware/software licenses used, and configurations.
Identifying assets is critical for managing information provided Identifying assets is critical for managing information provided
about and collected from endpoints. It is important to have stable about and collected from endpoints. In order to manage these assets
mechanisms for identifying assets over time to allow asset over time it is necessary to uniquely identify them and to use this
information to be correlated. It is often possible to use identification to express asset properties and to establish
standardized and proprietary identification mechanisms provided by relationships between different assets.
hardware and software asset vendors (e.g., CPU identifiers, product
tags). In some cases these identifiers may be stable for the life of When possible, stable identification mechanisms should be used that
the hardware component. In other cases (e.g., MAC addresses), the will allow the asset to be identified over time enabling information
identifier may be mutable within software. Organizationally provided pertaining to the asset to be correlated. In some cases stable asset
identifiers can also be used to identify assets such as those identifiers may not be available or they may change over time due to
provided by hardware and software certificates, and configurable operational conditions. For example, identifiers may be stable for
identification sources. In other cases it may only be possible to the life of a hardware component. In other cases (e.g., MAC
identify an asset by the network addressing information it is addresses), the identifier may be mutable within software. In an
currently using, requiring additional context to correlate asset
information across multiple network connection sessions. In an
enterprise context it is often necessary to use multiple enterprise context it is often necessary to use multiple
identification viewpoints for an asset to correlate data generated identification viewpoints for an asset to correlate data generated
from endpoint, network, and human sources. from endpoint, network, and human sources. To deal with these
scenarios, it is important to use multiple forms of asset
identification concurrently to allow asset data to be deconflicted
(see section Section 4.3.
Some standards focus on identifying the hardware and the system REQUIREMENT: Many standard and proprietary forms of asset
software. For example, the SYSTEM-MIB [RFC1213] contains a identification exist today. To provide adequate coverage, use of any
description of the endpoint, an authoritative identifier of the type identification mechanism, both standardized and proprietary, SHOULD
of endpoint assigned by the vendor of the endpoint, an administrative be allowed.
name for the endpoint, plus the endpoint's contact person, the
location of the endpoint, system time, and an enumerator that Object-oriented programming introduces two different concepts when
identifies the layer of services provided by the endpoint. The dealing with data: classes and instances. A class represents a data
system description includes the vendor, product type, model number, type which can be varied in a number of ways, while an instance
OS version, and networking software version. represents a realized variation of a class. This distinction can be
applied to identifying assets as described in the following
subsections.
4.1.1. Asset Class Identification
An asset class identifies a distinct type of asset. Assets
identified at the class level are useful for describing things that
can be instantiated or duplicated. Having the ability to associate
data with asset classes enable common properties and relationships to
be expressed that apply to all copies.
Examples of class-level asset identities include:
o Software releases and patches - Identifiers that represent
distinct software revision releases for firmware, operating
systems, applications, software suites, and patches and other
forms of software updates.
o Hardware components - Identifiers that distinguish specific parts
and production runs for hardware devices and components.
o Organizational endpoint types - Identifiers that represent
distinct endpoint configurations associated with a specific
organizational IT function.
o Others? - Please suggest any additional examples on the list
By identifying different types of assets at the class-level, common
characteristics (see section 4.2) and content (see section 4.4) can
be associated. Using class identification it is possible to define
relationships between assets and other data including: software
dependencies, associated patches, supported hardware architectures,
associated vulnerabilities, and related configuration items.
In many object-oriented languages classes can exist in hierarchies.
This enables association of data at different levels of abstraction.
This is also a useful concept for asset identification. For example,
a class may exist for router endpoint types, with subclasses
representing different vendor product releases. This enables
characteristics and content to be associated at various levels of
abstraction reducing data management challenges.
A variety of asset identification schemes exist for asset classes,
including some that can be exposed within an operating environment
for data collection. These may include: part numbers and revisions
for hardware and software product identifiers. [TODO: We need
examples of existing standardized asset class identification schemes?
REQUIREMENT: When available these asset identifiers SHOULD be used to
identify asset classes in collected and analyzed data.
4.1.2. Asset Instance Identification
An asset instance identifies a specific copy or variation of an asset
identification class. Identification of asset instances is necessary
for expressing specific properties and relationships within an
installed context. For example a network interface card installed in
a specific router in branch office's network closet, or a word
processing application release installed on Bob's desktop.
Identification of asset instances can be supported using a variety of
identification schemes. Hardware vendors often expose asset instance
identification data to the operating system including: product tags,
CPU identifiers, etc. In some cases, such as for software, it may be
necessary to express instance information as a relation to the
installed device. For example, using a software class identifier
with a hardware identifier to establish the software instance on a
specific endpoint. Organizationally provided identifiers can also be
used to identify assets such as those provided by hardware and
software certificates, and other configurable identification sources.
Accessing specific identifiers on an endpoint may require privileges
on the device. When identifying an endpoint from a network context,
or if other forms of device identification are not available or
access is not authorized, it may be necessary to identify an endpoint
using network addressing information (e.g., MAC addresses, IP
addresses). If only network data is used, additional analysis will
be needed to correlate an endpoint's identity across multiple
connection sessions often resulting in partial confidence of the
assets identity over time.
Some existing standards support the identification of the hardware
and the system software on a given endpoint. For example, the
SYSTEM-MIB [RFC1213] contains a description of the endpoint, an
authoritative identifier of the type of endpoint assigned by the
vendor of the endpoint, an administrative name for the endpoint, plus
the endpoint's contact person, the location of the endpoint, system
time, and an enumerator that identifies the layer of services
provided by the endpoint. The system description includes the
vendor, product type, model number, OS version, and networking
software version.
Similar information is available via the YANG module ietf-system . Similar information is available via the YANG module ietf-system .
This module includes data node definitions for system identification, This module includes data node definitions for system identification,
time-of-day management, user management, DNS resolver configuration, time-of-day management, user management, DNS resolver configuration,
and some protocol operations for system management. and some protocol operations for system management.
4.1.3. Endpoint Components and Asset Composition 4.2. Asset Characterization
It can be important to characterize the components of an endpoint, TERM: Asset characterization is the process of defining attributes
including physical and logical components, and the relationships that describe properties of an identified asset.
between the components, such as containment of components within
other components, or mappings between logical entities and the
physical entities used to instantiate them. The information about
the physical entities might include manufacturer-assigned serial
number, manufacture date, an asset identifier for the component, and
so. Logical entities may be defined, and associated with the
physical entities using a mapping table.
Example standardized data models include the ENTITY-MIB [RFC6933] the Asset characterization provides additional context that is useful to
Q-BRIDGE-MIB MIB [RFC4363] and the MIB for Virtual Machines support automated and human decision making as part of operational
Controlled by a Hypervisor . and security processes. It is necessary to gather, organize, store,
manage, and exchange a variety of different asset characteristics.
Often this information helps to bridge automated and human-oriented
processes. To assess assets (managed and unmanaged), we need to
understand the composition and relationships between different assets
types. We need the ability to properly characterize assets at the
outset and over time.
4.1.4. Asset Characterization Managing endpoints, and the different types of assets that compose
them, involves initially identifying and characterizing each asset.
This information is important to provide additional context for
supporting management of assets using human and automated processes.
Characterization may include business context not otherwise related
to security, but which may be used as information in support of
security decision making. For example, it may be possible to
automate assessing that an endpoint is out of compliance with
organizational configuration guidelines, but additional information
is needed to determine who to notify to correct the configuration.
Information provided by asset characterization will enable
notifications to be sent, trouble tickets to be generated, or
specific reports to be generated at a dashboard for a systems
administrator.
It is necessary to collect, store, manage, and exchange a variety of The following are examples of useful asset characteristics that may
different asset characteristics that provide additional context that be provided:
is useful to support automated and human decision making as part of
operational and security processes. Often this information helps to
bridge automated and human-oriented processes. In many cases it is
impractical or infeasible to collect specific asset details using
technical data collection mechanisms.
Asset characteristics can take many forms depending on the asset For asset classes:
type.
For hardware assets the following are often useful characteristics: o Information pertaining to the developer, manufacturer, and/or
publisher of hardware and software
o Manufacturer o The composition, dependencies, and function of hardware and
software
o Production version o Production version
o Hardware characteristics (e.g., memory, storage, network o Hardware characteristics and software operational requirements
(e.g., processor architecture, memory, storage, network
interfaces) interfaces)
o Metadata identifying: product family, edition, licensing
o End-of-support dates o End-of-support dates
For software assets the following are often useful characteristics: For asset instances:
o Software version o The business and operational context (e.g., required function/
role, owning organization, responsible parties)
o Supported hardware platforms o The composition and relationship of its constituent and containing
assets (e.g., installed hardware and software versions
o Metadata identifying: product family, software function, edition, o Assigned location for physical devices
licensing
o Other software dependencies o The current location within network(s)
o End-of-support dates o Current/historic operational state (e.g., running software,
processes, user sessions)
For managed endpoints, hardware, and software the following are often It can be important to characterize the components of an endpoint,
useful characteristics: including physical and logical components, and the relationships
between the components, such as containment of components within
other components, or mappings between logical entities and the
physical entities used to instantiate them. The information about
the physical entities might include manufacturer-assigned serial
number, manufacture date, an asset identifier for the component, and
so. Logical entities may be defined, and associated with the
physical entities using a mapping table.
o Owning organization Assets may be characterized based on data collected directly from
endpoints (see section 4.5.4) or by data provided by humans. While
machnine-oriented sources of asset characterization data may be
preferred, in many cases it is impractical or infeasible to collect
specific asset details using technical data collection mechanisms.
This is often true for asset characterization details that relate to
the business, operational, or security context of the asset. In
these cases human data entry is required to provide the necessary
data.
o Responsible organizations and individuals (e.g., operations, Asset characterization data may be made available to tools from a
security, inventory management) variety of sources. Asset data that is human-oriented and that
infrequently changes may be provided as records in a content
repository. Other sources of asset characterization data may
include: asset management, configuration management, and other
enterprise data stores.
o Assigned location for physical devices Example standardized data models include the ENTITY-MIB [RFC6933] the
Q-BRIDGE-MIB MIB [RFC4363] and the MIB for Virtual Machines
Controlled by a Hypervisor .
o Location within network(s) Another example is the HOST-RESOURCES-MIB [RFC2790].
This information is important to provide additional context for [QUESTION: Do we need to document more examples?.]
supporting management of assets using human and automated processes.
For example, it may be possible to automate assessing that an
endpoint is out of compliance with organizational configuration
guidelines, but additional information is needed to determine who to
notify to correct the configuration. Information provided by asset
characterization will enable notifications to be sent, trouble
tickets to be generated, or specific reports to be generated at a
dashboard for a systems administrator.
[TODO: Do we need more document characteristics or more examples?.] [QUESTION: Are these examples appropriate for this section? They
seem to be more about data collection.]
4.1.5. Asset Resources [QUESTION: It's not clear if aspects of endpoint posture should be
included in this category. One way to look at asset characterization
is that it is metadata that is provided by humans only. Do we want
to move concepts that pertain to posture collected from endpoints to
a different sub-section?]
This type of asset characterization describes the resources of an 4.3. Deconfliction of Asset Identities
endpoint, such as installed software, running software, software
versions, processes, user sessions, devices (processors, disks,
printers, network interfaces, etc.). This might also provides
monitoring of performance and error states for the related resources.
[TODO: Its not clear if this is asset characterization or data Different tools and data sources will use varying methods for asset
collection. One way to look at asset characterization is that it is identification. These methods should be standardized as much as
metadata that is provided by humans. Endpoint data collection is possible to reduce the need for deconfliction. In reality, it will
information provided by machines. The previous list looks like it is not be possible to standardize all forms of asset identification due
better oriented in the "machine" category. Do we want to move these to legacy, authorization, or network visibility concerns. In these
examples to a different sub-section?] cases, multiple forms of asset identity will need to be collected to
enable tools to perform correlation of provided asset identification
data.
An example is the HOST-RESOURCES-MIB [RFC2790] For class-level asset identities, it may be necessary for vendors and
end-user organizations to provide mapping data enabling translations
between different representations. Maintaining mappings between
asset identification representations is often a labor-intensive,
manual process that should be avoided by encouraging use of
standardized asset identifiers.
4.1.6. Asset Representation Reconciliation For instance-level asset identities, multiple forms of asset
identification should be provided when collecting data from
endpoints. Algorithms can then be used to weight and reconcile
different types asset identities, and collected characteristics to
correlate new data collected with historic information pertaining to
an asset and/or endpoint. In many cases where insufficient
identification information is available, it may only be possible to
associate data collected from different points of view at a minimum
level of confidence.
[TODO: We need to describe here how different asset identification 4.4. Asset Targeting
viewpoints are reconciled (e.g., endpoint vs. network, passive vs.
active]
4.1.7. Asset Life Cycle TERM: Asset targeting is the use of asset identification and
categorization information to drive human-directed, automated
decision making for data collection and analysis in support of
endpoint posture assessment.
[TODO: What do we want to say here?] Endpoints, and the assets that compose them, contain a wealth of
posture information. It is impractical to collect the full posture
of all endpoints managed by and accessing resources within an
organization. To support practical assessment of endpoint posture,
it is necessary to collect specific posture information from
endpoints based on an anticipated or actual need for the data. This
collection may be performed by polling the endpoint for specific
posture information on an ad-hoc basis or at regular intervals, or by
communicating to the endpoint what posture information it should
monitor and provide when changes occur. To support both methods, it
will be necessary to associate what posture details need to be
collected with asset identification and categorization information
that describe what types of endpoints and assets that may provide
these details. Furthermore, it will be necessary to use asset
identification and categorization information to identify what assets
should be evaluated for specific assessments.
4.2. Endpoint Configuration Management When defining content that drives data collection and analysis
activities, or that provides information that enriches analysis of
collected data, the need exists to relate this data to identified
assets or to categories of assets described by asset characteristics.
These associations, often called "statements of applicability" are
critical to exposing information for machine processing.
Statements of applicability enable digital policies (e.g.,
checklists, baselines, access control rules), data records (e.g.,
vulnerability data, associations of patches to software) to be
associated with asset, security, operational, and business contexts.
Using these associations, applicable content can be queried in
content repositories and made available at the points where the data
needs to be used. They also enable humans to query and (re)use
content provided by other individuals in their organization, by
vendors, and 3rd parties in constructing policies and configuring
data collection and analysis tools.
For example, in order to establish an understanding of the security
state of endpoints managed by an organization, the security system
needs to be able to make use of various asset management data. It
needs to:
o Determine what is the expected state for those endpoints. To do
this it will need to identify what expected state criteria is
associated with the endpoint based on the identification and
characterization of the endpoint, and any assets that compose the
endpoint.
o Once the criteria is identified, it will need to determine what
actual state data is needed to feed the analysis. This data will
need to be retrieved from existing data stores and from the
endpoints directly if necessary. Data collection rules may be
associated with specific asset identifiers or characteristics that
indicate what data sources or collectors to use to acquire the
data.
o Once the necessary actual state information is acquired, the
evaluator may need additional content to perform the analysis.
Based on the collected information, specific records will be
queried from a content repository based on asset identifiers and
characteristics.
o Finally, the appropriate assessment can be performed.
4.5. Other Unedited Content
The current editorial focus has been on the old asset management
subsection. The content in these subsections needs to be reworked
next.
4.5.1. Endpoint Configuration Management
Organizations manage a variety of configurations within their Organizations manage a variety of configurations within their
enterprise including: endpoints, the hardware they are composed of, enterprise including: endpoints, the hardware they are composed of,
installed software, hardware/software licenses used, and installed software, hardware/software licenses used, and
configurations. configurations.
Security configuration management (SCM) deals with the configuration Security configuration management (SCM) deals with the configuration
of endpoints, including networking infrastructure devices and of endpoints, including networking infrastructure devices and
computing hosts. Data will include installed hardware and software, computing hosts. Data will include installed hardware and software,
its configuration, and its use on the endpoint. its configuration, and its use on the endpoint.
skipping to change at page 10, line 7 skipping to change at page 15, line 50
security relevant, it is not always possible to draw a clear security relevant, it is not always possible to draw a clear
distinction between security and non-security settings (e.g., power distinction between security and non-security settings (e.g., power
saving features). Do we want to make a distinction between security saving features). Do we want to make a distinction between security
and non-security configuration settings?] and non-security configuration settings?]
The following list details some requisite Configuration Management The following list details some requisite Configuration Management
capabilities: capabilities:
o [todo] o [todo]
4.2.1. Organizing Configuration Metadata 4.5.1.1. Organizing Configuration Metadata
Configuration metadata supports tooling helping organizations Configuration metadata supports tooling helping organizations
understand what configuration they should implement, using specific understand what configuration they should implement, using specific
configuration values. configuration values.
Enable data repositories containing machine-represtations of: Enable data repositories containing machine-readable representations
of:
Configuration scoring: Characterizations of the relative security Configuration scoring: Characterizations of the relative security
value of dsscrete configuration settings and specific values value of discrete configuration settings and specific values
Configuration dependencies (e.g., lists of settings, associated Configuration dependencies (e.g., lists of settings, associated
software, pre-requisite configurations) software, pre-requisite configurations)
Control catalog mappings supporting compliance [todo: in scope?] Control catalog mappings supporting compliance [todo: in scope?]
4.2.2. Publishing Recommended Configuration Posture 4.5.1.2. Publishing Recommended Configuration Posture
Provide a mechanism for vendors and organizations to exchange Provide a mechanism for vendors and organizations to exchange
machine-oriented descriptions of recommended configuration setting machine-oriented descriptions of recommended configuration setting
for software products. Enable organizations to apply recommended for software products. Enable organizations to apply recommended
settings as expected configuration posture. Enable association of settings as expected configuration posture. Enable association of
data-driven collection instructions using appropriate formats. data-driven collection instructions using appropriate formats.
4.2.3. Defining Organizationally Expected Configuration Posture 4.5.1.3. Defining Organizationally Expected Configuration Posture
Provide a mechanism for organizations to define and exchange expected Provide a mechanism for organizations to define and exchange expected
configuration posture including: authorized software and associated configuration posture including: authorized software and associated
configuration settings. configuration settings.
[TODO: Should software installation posture be defined seperately?] [TODO: Should software installation posture be defined separately?]
4.2.4. Collecting Endpoint Configuration Posture 4.5.1.4. Collecting Endpoint Configuration Posture
Enable collection and exchange of actual configuration posture Enable collection and exchange of actual configuration posture
including: installed software and values for configured settings. including: installed software and values for configured settings.
[TODO: Should collecting software installation posture be defined [TODO: Should collecting software installation posture be defined
seperately?] separately?]
4.2.5. Comparing Expected and Actual Configuration Posture 4.5.1.5. Comparing Expected and Actual Configuration Posture
Enable evaluation of actual configuration posture against expected Enable evaluation of actual configuration posture against expected
configuration posture. Generate a machine-oriented description of configuration posture. Generate a machine-oriented description of
conformant and non-conformat posture including software inventory and conformant and non-conformant posture including software inventory
configuration values. and configuration values.
[TODO: Should collecting software installation posture be defined [TODO: Should collecting software installation posture be defined
seperately?] separately?]
[TODO: Examining software version configuration - Example - HOST- [TODO: Examining software version configuration - Example - HOST-
RESOURCES-MIB RESOURCES-MIB
4.2.6. Examining configuration of logical to physical mappings 4.5.1.6. Examining configuration of logical to physical mappings
[TODO: not sure what this is? Is it in scope?] [TODO: not sure what this is? Is it in scope?]
Example - ENTITY-MIB Example - ENTITY-MIB
4.2.7. Configuring Endpoint Interfaces 4.5.1.7. Configuring Endpoint Interfaces
[TODO: not sure what this is? Is it in scope?] [TODO: not sure what this is? Is it in scope?]
Example - YANG module ietf-interfaces Example - YANG module ietf-interfaces
4.3. Endpoint Posture Change Management 4.5.2. Endpoint Posture Change Management
Organizations manage a variety of changes within their enterprise Organizations manage a variety of changes within their enterprise
including: [todo] including: [todo]
The following list details some requisite Change Management The following list details some requisite Change Management
capabilities: capabilities:
o [todo] o [todo]
4.3.1. Defining and Exchanging Baselines 4.5.2.1. Defining and Exchanging Baselines
[todo] [todo]
4.3.2. Detecting Unauthorized Changes 4.5.2.2. Detecting Unauthorized Changes
[todo] [todo]
[todo: figure out where these need to go] [todo: figure out where these need to go]
4.3.2.1. Endpoint Addressing Changes 4.5.2.2.1. Endpoint Addressing Changes
Example - DHCP addressing Example - DHCP addressing
4.3.2.2. Service Authorization Changes 4.5.2.2.2. Service Authorization Changes
Example - RADIUS network access Example - RADIUS network access
4.3.2.3. Dynamic Resource Assignment Changes 4.5.2.2.3. Dynamic Resource Assignment Changes
Example - NAT logging Example - NAT logging
4.3.2.4. Security Authorization Status Changes 4.5.2.2.4. Security Authorization Status Changes
Example - SYSLOG Authorization messages. SYSLOG [RFC5424] includes Example - SYSLOG Authorization messages. SYSLOG [RFC5424] includes
facilities for security authorization messages. These messages can facilities for security authorization messages. These messages can
be used to alert an analysts that an authorization attempt failed, be used to alert an analysts that an authorization attempt failed,
and the analyst might choose to follow up and assess potential and the analyst might choose to follow up and assess potential
attacks on the relevant endpoint. attacks on the relevant endpoint.
4.4. Security Vulnerability Management 4.5.3. Security Vulnerability Management
Vulnerability management involves identifying the patch level of Vulnerability management involves identifying the patch level of
software installed on the device and the identification of insecure software installed on the device and the identification of insecure
custom code (e.g. web vulnerabilities). All vulnerabilities need to custom code (e.g. web vulnerabilities). All vulnerabilities need to
be addressed as part of a comprehensive risk management program, be addressed as part of a comprehensive risk management program,
which is a superset of software vulnerabilities. Thus, the which is a superset of software vulnerabilities. Thus, the
capability of assessing non-software vulnerabilities applicable to capability of assessing non-software vulnerabilities applicable to
the system is required. Additionally, it may be necessary to support the system is required. Additionally, it may be necessary to support
non-technical assessment of data relating to assets such as aspects non-technical assessment of data relating to assets such as aspects
related to operational and management controls. related to operational and management controls.
skipping to change at page 12, line 42 skipping to change at page 18, line 45
administrative controls (i.e. policy, process, procedure) administrative controls (i.e. policy, process, procedure)
o Collect the state of technical controls including, but not o Collect the state of technical controls including, but not
necessarily limited to: necessarily limited to:
* Software inventory (e.g. operating system, applications, * Software inventory (e.g. operating system, applications,
patches) patches)
* Configuration settings * Configuration settings
4.4.1. Example - NIDS response 4.5.3.1. Example - NIDS response
1. An organization's Network Intrusion Detection System detects a 1. An organization's Network Intrusion Detection System detects a
suspect packet received by an endpoint and sends an alert to an suspect packet received by an endpoint and sends an alert to an
analyst. The analyst looks up the endpoint in the asset inventory analyst. The analyst looks up the endpoint in the asset inventory
database, looks up the configuration policy associated with that database, looks up the configuration policy associated with that
endpoint, and initiates an endpoint assessment of installed software endpoint, and initiates an endpoint assessment of installed software
and patches on the endpoint to determine if the endpoint is compliant and patches on the endpoint to determine if the endpoint is compliant
with policy. with policy.
The analyst reviews the results of the assessment and takes action The analyst reviews the results of the assessment and takes action
according to organization policy and procedures. according to organization policy and procedures.
4.4.2. Example - Historical vulnerability analysis 4.5.3.2. Example - Historical vulnerability analysis
When a serious vulnerability or a zero-day attack is discovered, one When a serious vulnerability or a zero-day attack is discovered, one
of the first priorities in any organization is to determine which of the first priorities in any organization is to determine which
endpoints may have been affected and assess those endpoints to try to endpoints may have been affected and assess those endpoints to try to
determine whether they were compromised. Checking current endpoint determine whether they were compromised. Checking current endpoint
state is not sufficient because an endpoint may have been temporarily state is not sufficient because an endpoint may have been temporarily
compromised due to this vulnerability and then the infection may have compromised due to this vulnerability and then the infection may have
removed itself. In fact, the vulnerable software may have been removed itself. In fact, the vulnerable software may have been
removed or upgraded since the compromise took place. And if the removed or upgraded since the compromise took place. And if the
endpoint is still compromised, the malware on the endpoint may cause endpoint is still compromised, the malware on the endpoint may cause
it to lie about its configuration. In this environment, maintaining it to lie about its configuration. In this environment, maintaining
historical information about endpoint configuration is essential. historical information about endpoint configuration is essential.
Such information can be used to find endpoints that had the Such information can be used to find endpoints that had the
vulnerable software installed at some point in time. Those endpoints vulnerable software installed at some point in time. Those endpoints
can be checked for current or past indicators of compromise such as can be checked for current or past indicators of compromise such as
files or behavior linked to a known exploit for this vulnerability. files or behavior linked to a known exploit for this vulnerability.
Endpoints found to be vulnerable can be isolated to prevent infection Endpoints found to be vulnerable can be isolated to prevent infection
while remediation is done. Endpoints believed to be compromised can while remediation is done. Endpoints believed to be compromised can
be isolated for analysis and to limit the spread of infection. be isolated for analysis and to limit the spread of infection.
4.4.3. Source Address Validation 4.5.3.3. Source Address Validation
Source Address Validation Improvement methods were developed to Source Address Validation Improvement methods were developed to
prevent nodes attached to the same IP link from spoofing each other's prevent nodes attached to the same IP link from spoofing each other's
IP addresses, so as to complement ingress filtering with finer- IP addresses, so as to complement ingress filtering with finer-
grained, standardized IP source address validation. The framework grained, standardized IP source address validation. The framework
document describes and motivates the design of the SAVI methods. document describes and motivates the design of the SAVI methods.
Particular SAVI methods are described in other documents. Particular SAVI methods are described in other documents.
4.5. Data Collection 4.5.4. Data Collection
Central to any automated assessment solution is the ability to Central to any automated assessment solution is the ability to
collect data from, or related to, an endpoint, such as the security collect data from, or related to, an endpoint, such as the security
state of the endpoint and its constituent assets. state of the endpoint and its constituent assets.
So, is data collection a requirement or an architectural concept So, is data collection a requirement or an architectural concept
rather than a use case? rather than a use case?
QUESTION: Understand more about what is meant by non-software QUESTION: Understand more about what is meant by non-software
vulnerabilities vulnerabilities
4.6. Assessment Result Analysis 4.5.5. Assessment Result Analysis
The data collected needs to be analyzed for compliance to a standard The data collected needs to be analyzed for compliance to a standard
stipulated by the enterprise. Analysis methods may vary between stipulated by the enterprise. Analysis methods may vary between
enterprises, but commonly take a similar form. enterprises, but commonly take a similar form.
The following capabilities support the analysis of assessment The following capabilities support the analysis of assessment
results: results:
o Comparing actual state to expected state o Comparing actual state to expected state
o Scoring/weighting individual comparison results o Scoring/weighting individual comparison results
o Relating specific comparisons to benchmark-level requirements o Relating specific comparisons to benchmark-level requirements
o Relating benchmark-level requirements to one or more control o Relating benchmark-level requirements to one or more control
frameworks frameworks
4.7. Content Management 4.5.6. Content Management
The capabilities required to support risk management state The capabilities required to support risk management state
measurement will yield volumes of content. The efficacy of risk measurement will yield volumes of content. The efficacy of risk
management state measurement depends directly on the stability of the management state measurement depends directly on the stability of the
driving content, and, subsequently, the ability to change content driving content, and, subsequently, the ability to change content
according to enterprise needs. according to enterprise needs.
Capabilities supporting Content Management should provide the ability Capabilities supporting Content Management should provide the ability
to create/define or modify content, as well as store and retrieve to create/define or modify content, as well as store and retrieve
said content of at least the following types: said content of at least the following types:
skipping to change at page 15, line 27 skipping to change at page 21, line 35
The authors would like to recognize and thank Adam Montville for his The authors would like to recognize and thank Adam Montville for his
work on early edits of this draft. Additionally, the authors would work on early edits of this draft. Additionally, the authors would
like to thank Kathleen Moriarty and Stephen Hanna for contributing like to thank Kathleen Moriarty and Stephen Hanna for contributing
text to this document. The authors would also like to acknowledge text to this document. The authors would also like to acknowledge
the members of the SACM mailing list for their keen and insightful the members of the SACM mailing list for their keen and insightful
feedback on the concepts and text within this document. feedback on the concepts and text within this document.
8. Change Log 8. Change Log
8.1. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 8.1. -00- to -01-
o Work on this revision has been focused on document content
relating primarily to use of asset management data and functions.
o Made significant updates to section 3 including:
* Reworked introductory text.
* Replaced the single example with multiple use cases that focus
on more discrete uses of asset management data to support
hardware and software inventory, and configuration management
use cases.
* For one of the use cases, added mapping to functional
capabilities used. If popular, this will be added to the other
use cases as well.
* Additional use cases will be added in the next revision
capturing additional discussion from the list.
o Made significant updates to section 4 including:
* Renamed the section heading from "Use Cases" to "Functional
Capabilities" since use cases are covered in section 3. This
section now extrapolates specific functions that are needed to
support the use cases.
* Started work to flatten the section, moving select subsections
up from under asset management.
* Removed the subsections for: Asset Discovery, Endpoint
Components and Asset Composition, Asset Resources, and Asset
Life Cycle.
* Renamed the subsection "Asset Representation Reconciliation" to
"Deconfliction of Asset Identities".
* Expanded the subsections for: Asset Identification, Asset
Characterization, and Deconfliction of Asset Identities.
* Added a new subsection for Asset Targeting.
* Moved remaining sections to "Other Unedited Content" for future
updating.
8.2. 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
o Removed requirements to be moved into a new I/D. o Removed requirements to be moved into a new I/D.
o Extracted the functionality from the examples and made the o Extracted the functionality from the examples and made the
examples less prominent. examples less prominent.
o Renamed "Functional Capabilities and Requirements" section to "Use o Renamed "Functional Capabilities and Requirements" section to "Use
Cases". Cases".
Reorganized the "Asset Management" sub-section. Added new text * Reorganized the "Asset Management" sub-section. Added new text
throughout. throughout.
+ Renamed a few sub-section headings. + Renamed a few sub-section headings.
+ Added text to the "Asset Characterization" sub-section. + Added text to the "Asset Characterization" sub-section.
o Renamed "Security Configuration Management" to "Endpoint o Renamed "Security Configuration Management" to "Endpoint
Configuration Management". Not sure if the "security" distinction Configuration Management". Not sure if the "security" distinction
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.
8.2. -04- to -05- 8.3. -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
 End of changes. 94 change blocks. 
248 lines changed or deleted 564 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/