One document matched: draft-ietf-sacm-use-cases-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1213.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC0826 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0826.xml">
<!ENTITY RFC2790 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2790.xml">
<!ENTITY RFC2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC2922 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2922.xml">
<!ENTITY RFC3535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3535.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4363 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4363.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC6733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC6933 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6933.xml">
<!ENTITY I-D.draft-ietf-nea-pt-eap-09 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nea-pt-eap-09.xml">
<!-- <!ENTITY I-D.draft-asai-vmm-mib-04 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-asai-vmm-mib-04.xml"> -->
<!ENTITY I-D.draft-ietf-netmod-interfaces-cfg-12 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-interfaces-cfg-12.xml">
<!ENTITY I-D.draft-ietf-netmod-system-mgmt-08 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-system-mgmt-08.xml">
<!ENTITY I-D.draft-ietf-savi-framework-06 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-savi-framework-06.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-sacm-use-cases-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Enterprise Use Cases for Security Assessment">Using Security Posture Assessment
to Grant Access to Enterprise Network Resources</title>
<author fullname="David Waltermire" initials="D.W." surname="Waltermire">
<organization abbrev="NIST">National Institute of Standards and Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<code>20877</code>
<country>USA</country>
</postal>
<phone/>
<email>david.waltermire@nist.gov</email>
</address>
</author>
<author fullname="David Harrington" initials="D.B.H" surname="Harrington">
<organization>Effective Software</organization>
<address>
<postal>
<street>50 Harding Rd</street>
<city>Portsmouth</city>
<region>NH</region>
<code>03801</code>
<country>USA</country>
</postal>
<phone/>
<email>ietfdbh@comcast.net</email>
</address>
</author>
<date year="2013"/>
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>Security Automation and Continuous Monitoring WG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>security automation</keyword>
<keyword>continuous monitoring</keyword>
<keyword>endpoint</keyword>
<keyword>posture assessment</keyword>
<keyword>use case</keyword>
<keyword>asset management</keyword>
<keyword>configuration management</keyword>
<keyword>vulnerability management</keyword>
<keyword>content management</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This memo documents a sampling of use cases for securely aggregating configuration and
operational data and assessing that data to determine an organization's security posture.
From these operational use cases, we can derive common functional capabilities and
requirements to guide development of vendor-neutral, interoperable standards for aggregating
and assessing data relevant to security posture. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Our goal with this document is to improve our agreement on which problems we're trying to
solve. We need to start with short, simple problem statements and discuss those by email and
in person. Once we agree on which problems we're trying to solve, we can move on to propose
various solutions and decide which ones to use.</t>
<t>This document describes example use cases for endpoint posture assessment for enterprises.
It provides a sampling of use cases for securely aggregating configuration and operational
data and assessing that data to determine the security posture of individual endpoints, and,
in the aggregate, the security posture of an enterprise.</t>
<t>These use cases cross many IT security information domains. From these operational use
cases, we can derive common concepts, common information expressions, functional
capabilities and requirements to guide development of vendor-neutral, interoperable
standards for aggregating and assessing data relevant to security posture.</t>
<t>Using this standard data, tools can analyze the state of endpoints, user activities and
behaviour, and assess the security posture of an organization. Common expression of
information should enable interoperability between tools (whether customized, commercial, or
freely available), and the ability to automate portions of security processes to gain
efficiency, react to new threats in a timely manner, and free up security personnel to work
on more advanced problems. </t>
<t>The goal is to enable organizations to make informed decisions that support organizational
objectives, to enforce policies for hardening systems, to prevent network misuse, to
quantify business risk, and to collaborate with partners to identify and mitigate threats. </t>
<t>It is expected that use cases for enterprises and for service providers will largely
overlap, but there are additional complications for service providers, especially in
handling information that crosses administrative domains.</t>
<t>The output of endpoint posture assessment is expected to feed into additional processes,
such as policy-based enforcement of acceptable state, verification and monitoring of
security controls, and compliance to regulatory requirements.</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Endpoint Posture Assessment" anchor="endpoint-posture-assessment">
<t>Endpoint posture assessment involves collecting information about the posture of a given
endpoint. This posture information is gathered and then published to appropriate data
repositories to make collected information available for further analysis supporting
organizational security processes.</t>
<t>Endpoint posture assessment typically includes: <list style="symbols">
<t>Collecting the posture of a given endpoint;</t>
<t>Making that posture available to the enterprise for further analysis and action;
and</t>
<t>Assessing that the endpoint's posture is in compliance with enterprise standards and
policy.</t>
</list>
</t>
<section title="Example - Departmental Software Policy Compliance ">
<t>In order to meet compliance requirements and ensure that corporate finance information is
not revealed improperly, all computers in the finance department of Example Corporation
are required to run only 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.</t>
</section>
<section title="Main Success Scenario">
<t>
<list style="numbers">
<t>Define a target endpoint to be assessed</t>
<t>Select acceptable state policies to apply to the defined target</t>
<t>Identify the endpoint being assessed</t>
<t>Collect posture attributes from the target</t>
<t>Communicate target identity and collected posture to external system for
evaluation</t>
<!-- QUESTION: Is state evaluation part of this use case or UC3? -->
<t>Compare collected posture attributes from the target endpoint with expected state
values as expressed in acceptable state policies</t>
</list>
</t>
</section>
</section>
<section title="Use Cases" anchor="sec-use-cases">
<!-- <t>In general, the activities of managing
assets, configurations, and vulnerabilities are common between UC1, UC2, and UC3. UC2 uses these
activities to either grant or deny an entity access to a requested resource. UC3 uses these
activities in support of compliance measurement on a periodic basis.</t>
<t>At the most basic level, an enterprise needing to satisfy these use cases will need certain
capabilities to be met. Specifically, we are talking about risk management capabilities. This is the central problem domain, so it makes sense to be able to convey
information about technical and non-technical controls, benchmarks, control requirements,
control frameworks and other concepts in a common way.</t>
-->
<t>The use cases defined in this section support assessing endpoint posture in an automated
manner as described in Section <xref target="endpoint-posture-assessment"/>. The following
sub-sections describe use cases broken out by their corresponding IT decipline.</t>
<!-- TODO: Need to add additional information here once the use case is really fleshed out to make for a better transition. Should be something that describes the capabilities already included in this section below. -->
<section title="Asset Management" anchor="sec-uc-asset-management">
<t>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. </t>
<t>Managing endpoints and the different types of assets that compose them involves initially
discovering and characterizing each asset instance, and then identify them in a common
way. Characterization may take the form of logical characterization or security
characterization, where logical characterization may include business context not
otherwise related to security, but which may be used as information in support of decision
making later in risk management.</t>
<t>Coverage involves understanding what and how many assets are under control. Assessing 80%
of the enterprise assets is better than assessing 50% of the enterprise assets.</t>
<t>Getting asset details can be comparatively subtle - if an enterprise does not have a
precise understanding of its assets, then all acquired data and consequent actions taken
based on the data are considered suspect.</t>
<t>Assessing assets (managed and unmanaged) requires that we have visibility into the
posture of endpoints, the ability to understand the composition and relationships between
different assets types, and the ability to properly characterize them at the outset and
over time.</t>
<t>The following list details some requisite Asset Management capabilities: <list
style="symbols">
<t>Discover assets in the enterprise</t>
<t>Identify and describe assets using a common vocabulary between implementations</t>
<t>For a given endpoint, understand the composition and relationship of its constituent
assets</t>
<t>Characterize assets according to security and non-security asset properties</t>
<t>Reconcile asset representations originating from disparate tools</t>
<t>Manage asset information throughout the asset's life cycle</t>
</list>
</t>
<section title="Asset Discovery">
<t>Many network management systems periodically test for the presence of 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.</t>
<t>These standardized collections include ARP tables <xref target="RFC0826"/>, Interface
tables such as the Interfaces MIB (IF-MIB) <xref target="RFC2863"/> or the YANG module
ietf-interfaces <!-- xref target="I-D.draft-ietf-netmod-interfaces-cfg-12"/ -->, Link
Layer Discovery tables <xref target="RFC2922"/>, DHCP tables (Ref:???), and so on.</t>
</section>
<section title="Asset Identification">
<t>Identifying assets is critical for managing information provided about and collected
from endpoints. It is important to have stable mechanisms for identifying assets over
time to allow asset information to be correlated. It is often possible to use
standardized and proprietary identification mechanisms provided by hardware and software
asset vendors (e.g., CPU identifiers, product tags). In some cases these identifiers may
be stable for the life of the hardware component. In other cases (e.g., MAC addresses),
the identifier may be mutable within software. Organizationally provided identifiers can
also be used to identify assets such as those provided by hardware and software
certificates, and configurable identification sources. In other cases it may only be
possible to identify an asset by the network addressing information it is 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 identification viewpoints for an asset to correlate data generated from
endpoint, network, and human sources.</t>
<t>Some standards focus on identifying the hardware and the system software. For example,
the SYSTEM-MIB <xref target="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. </t>
<t>Similar information is available via the YANG module ietf-system
<!--xref target="I-D.draft-ietf-netmod-system-mgmt-08"/-->. This module includes data
node definitions for system identification, time-of-day management, user management, DNS
resolver configuration, and some protocol operations for system management.</t>
</section>
<section title="Endpoint Components and Asset Composition">
<t>It can be important to characterize the components of an endpoint, 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. </t>
<t>Example standardized data models include the ENTITY-MIB <xref target="RFC6933"/> the
Q-BRIDGE-MIB MIB <xref target="RFC4363"/> and the MIB for Virtual Machines Controlled by
a Hypervisor <!--xref target="draft-asai-vmm-mib-04"/-->.</t>
</section>
<section title="Asset Characterization">
<t>It is necessary to collect, store, manage, and exchange a variety of different asset
characteristics that provide additional context that 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.</t>
<t>Asset characteristics can take many forms depending on the asset type.</t>
<t>For hardware assets the following are often useful characteristics: <list
style="symbols">
<t>Manufacturer</t>
<t>Production version</t>
<t>Hardware characteristics (e.g., memory, storage, network interfaces)</t>
<t>End-of-support dates</t>
</list>
</t>
<t>For software assets the following are often useful characteristics: <list
style="symbols">
<t>Software version</t>
<t>Supported hardware platforms</t>
<t>Metadata identifying: product family, software function, edition, licensing</t>
<t>Other software dependencies</t>
<t>End-of-support dates</t>
</list>
</t>
<t>For managed endpoints, hardware, and software the following are often useful
characteristics: <list style="symbols">
<t>Owning organization</t>
<t>Responsible organizations and individuals (e.g., operations, security, inventory
management)</t>
<t>Assigned location for physical devices</t>
<t>Location within network(s)</t>
</list>
</t>
<t>This information is important to provide additional context for 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.</t>
<t>[TODO: Do we need more document characteristics or more examples?.]</t>
</section>
<section title="Asset Resources">
<t>This type of asset characterization describes the resources of an 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.</t>
<t>[TODO: Its not clear if this is asset characterization or data collection. One way to
look at asset characterization is that it is metadata that is provided by humans.
Endpoint data collection is information provided by machines. The previous list looks
like it is better oriented in the "machine" category. Do we want to move these examples
to a different sub-section?]</t>
<t>An example is the HOST-RESOURCES-MIB <xref target="RFC2790"/></t>
</section>
<section title="Asset Representation Reconciliation">
<t>[TODO: We need to describe here how different asset identification viewpoints are
reconciled (e.g., endpoint vs. network, passive vs. active]</t>
</section>
<section title="Asset Life Cycle">
<t>[TODO: What do we want to say here?]</t>
</section>
</section>
<section title="Endpoint Configuration Management" anchor="sec-uc-configuration-management">
<t>Organizations manage a variety of configurations within their enterprise including:
endpoints, the hardware they are composed of, installed software, hardware/software
licenses used, and configurations.</t>
<t>Security configuration management (SCM) deals with the configuration of endpoints,
including networking infrastructure devices and computing hosts. Data will include
installed hardware and software, its configuration, and its use on the endpoint.</t>
<t>[TODO: While some configuration settings might not be considered security relevant, it is
not always possible to draw a clear distinction between security and non-security settings
(e.g., power saving features). Do we want to make a distinction between security and
non-security configuration settings?]</t>
<t>The following list details some requisite Configuration Management capabilities: <list
style="symbols">
<t>[todo]</t>
</list>
</t>
<section title="Organizing Configuration Metadata">
<t>Configuration metadata supports tooling helping organizations understand what
configuration they should implement, using specific configuration values.</t>
<t>Enable data repositories containing machine-represtations of: <list>
<t>Configuration scoring: Characterizations of the relative security value of dsscrete
configuration settings and specific values</t>
<t>Configuration dependencies (e.g., lists of settings, associated software,
pre-requisite configurations)</t>
<t>Control catalog mappings supporting compliance [todo: in scope?]</t>
</list>
</t>
</section>
<section title="Publishing Recommended Configuration Posture">
<t>Provide a mechanism for vendors and organizations to exchange machine-oriented
descriptions of recommended configuration setting for software products. Enable
organizations to apply recommended settings as expected configuration posture. Enable
association of data-driven collection instructions using appropriate formats.</t>
</section>
<section title="Defining Organizationally Expected Configuration Posture">
<t>Provide a mechanism for organizations to define and exchange expected configuration
posture including: authorized software and associated configuration settings.</t>
<t>[TODO: Should software installation posture be defined seperately?]</t>
</section>
<section title="Collecting Endpoint Configuration Posture">
<t>Enable collection and exchange of actual configuration posture including: installed
software and values for configured settings.</t>
<t>[TODO: Should collecting software installation posture be defined seperately?]</t>
</section>
<section title="Comparing Expected and Actual Configuration Posture">
<t>Enable evaluation of actual configuration posture against expected configuration
posture. Generate a machine-oriented description of conformant and non-conformat posture
including software inventory and configuration values.</t>
<t>[TODO: Should collecting software installation posture be defined seperately?]</t>
<t>[TODO: Examining software version configuration - Example - HOST-RESOURCES-MIB</t>
</section>
<section title="Examining configuration of logical to physical mappings">
<t>[TODO: not sure what this is? Is it in scope?]</t>
<t>Example - ENTITY-MIB</t>
</section>
<section title="Configuring Endpoint Interfaces">
<t>[TODO: not sure what this is? Is it in scope?]</t>
<t>Example - YANG module ietf-interfaces</t>
</section>
</section>
<section title="Endpoint Posture Change Management" anchor="sec-capability-change-management">
<t>Organizations manage a variety of changes within their enterprise including: [todo] </t>
<t>The following list details some requisite Change Management capabilities: <list
style="symbols">
<t>[todo]</t>
</list>
</t>
<section title="Defining and Exchanging Baselines">
<t>[todo]</t>
</section>
<section title="Detecting Unauthorized Changes">
<t>[todo]</t>
<t>[todo: figure out where these need to go]</t>
<section title="Endpoint Addressing Changes">
<t>Example - DHCP addressing</t>
</section>
<section title="Service Authorization Changes">
<t>Example - RADIUS network access</t>
</section>
<section title="Dynamic Resource Assignment Changes">
<t>Example - NAT logging</t>
</section>
<section title="Security Authorization Status Changes">
<t>Example - SYSLOG Authorization messages. SYSLOG <xref target="RFC5424"/> includes
facilities for security authorization messages. These messages can be used to alert an
analysts that an authorization attempt failed, and the analyst might choose to follow
up and assess potential attacks on the relevant endpoint. </t>
</section>
</section>
</section>
<section title="Security Vulnerability Management"
anchor="sec-capability-vulnerability-management">
<t> Vulnerability management involves identifying the patch level of software installed on
the device and the identification of insecure custom code (e.g. web vulnerabilities). All
vulnerabilities need to be addressed as part of a comprehensive risk management program,
which is a superset of software vulnerabilities. Thus, the capability of assessing
non-software vulnerabilities applicable to the system is required. Additionally, it may be
necessary to support non-technical assessment of data relating to assets such as aspects
related to operational and management controls.</t>
<t>policy attribute collection</t>
<t>The following list details some requisite Vulnerability Management capabilities: <list
style="symbols">
<t>Collect the state of non-technical controls commonly called administrative controls
(i.e. policy, process, procedure)</t>
<t>Collect the state of technical controls including, but not necessarily limited to:
<list style="symbols">
<t>Software inventory (e.g. operating system, applications, patches)</t>
<t>Configuration settings</t>
</list>
</t>
</list>
</t>
<section title="Example - NIDS response">
<t>1. An organization's Network Intrusion Detection System detects a suspect packet
received by an endpoint and sends an alert to an analyst. The analyst looks up the
endpoint in the asset inventory database, looks up the configuration policy associated
with that endpoint, and initiates an endpoint assessment of installed software and
patches on the endpoint to determine if the endpoint is compliant with policy. </t>
<t>The analyst reviews the results of the assessment and takes action according to
organization policy and procedures. </t>
</section>
<section title="Example - Historical vulnerability analysis">
<t>When a serious vulnerability or a zero-day attack is discovered, one of the first
priorities in any organization is to determine which endpoints may have been affected
and assess those endpoints to try to determine whether they were compromised. Checking
current endpoint state is not sufficient because an endpoint may have been temporarily
compromised due to this vulnerability and then the infection may have removed itself. In
fact, the vulnerable software may have been removed or upgraded since the compromise
took place. And if the endpoint is still compromised, the malware on the endpoint may
cause it to lie about its configuration. In this environment, maintaining historical
information about endpoint configuration is essential. Such information can be used to
find endpoints that had the vulnerable software installed at some point in time. Those
endpoints can be checked for current or past indicators of compromise such as files or
behavior linked to a known exploit for this vulnerability. Endpoints found to be
vulnerable can be isolated to prevent infection while remediation is done. Endpoints
believed to be compromised can be isolated for analysis and to limit the spread of
infection. </t>
</section>
<section title="Source Address Validation">
<t>Source Address Validation Improvement methods were developed to prevent nodes attached
to the same IP link from spoofing each other's IP addresses, so as to complement ingress
filtering with finer- grained, standardized IP source address validation. The framework
document <!-- xref target="I-D.draft-ietf-savi-framework-06"/ --> describes and
motivates the design of the SAVI methods. Particular SAVI methods are described in other
documents. </t>
</section>
</section>
<section title="Data Collection" anchor="sec-capability-data-collection">
<t>Central to any automated assessment solution is the ability to collect data from, or
related to, an endpoint, such as the security state of the endpoint and its constituent
assets. </t>
<t>So, is data collection a requirement or an architectural concept rather than a use
case?</t>
<t>QUESTION: Understand more about what is meant by non-software vulnerabilities </t>
</section>
<section title="Assessment Result Analysis" anchor="sec-capability-assessment-result-analysis">
<t>The data collected needs to be analyzed for compliance to a standard stipulated by the
enterprise. Analysis methods may vary between enterprises, but commonly take a similar
form.</t>
<t>The following capabilities support the analysis of assessment results: <list
style="symbols">
<t>Comparing actual state to expected state</t>
<t>Scoring/weighting individual comparison results</t>
<t>Relating specific comparisons to benchmark-level requirements</t>
<t>Relating benchmark-level requirements to one or more control frameworks</t>
</list>
</t>
</section>
<section title="Content Management" anchor="sec-capability-content-management">
<t>The capabilities required to support risk management state measurement will yield volumes
of content. The efficacy of risk management state measurement depends directly on the
stability of the driving content, and, subsequently, the ability to change content
according to enterprise needs.</t>
<t>Capabilities supporting Content Management should provide the ability to create/define or
modify content, as well as store and retrieve said content of at least the following
types: <list style="symbols">
<t>Configuration checklists</t>
<t>Assessment rules</t>
<t>Data collection rules and methods</t>
<t>Scoring models</t>
<t>Vulnerability information</t>
<t>Patch information</t>
<t>Asset characterization data and rules</t>
</list>
</t>
<t>Note that the ability to modify content is in direct support of tailoring content for
enterprise-specific needs.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This memo documents, for Informational purposes, use cases for security automation. While
it is about security, it does not affect security.</t>
</section>
<section title="Acknowledgements">
<t>The National Institute of Standards and Technology (NIST) and/or the MITRE Corporation have
developed specifications under the general term "Security Automation" including languages,
protocols, enumerations, and metrics.</t>
<t>The authors would like to recognize and thank Adam Montville for his work on early edits of
this draft. Additionally, the authors would like to thank Kathleen Moriarty and Stephen
Hanna for contributing text to this document. The authors would also like to acknowledge the
members of the SACM mailing list for their keen and insightful feedback on the concepts and
text within this document.</t>
</section>
<section title="Change Log">
<section title="draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00">
<t>
<list style="symbols">
<t>Transitioned from individual I/D to WG I/D based on WG consensus call.</t>
<t>Fixed a number of spelling errors. Thank you Erik!</t>
<t>Added keywords to the front matter.</t>
<t>Removed the terminology section from the draft. Terms have been moved to:
draft-dbh-sacm-terminology-00</t>
<t>Removed requirements to be moved into a new I/D.</t>
<t>Extracted the functionality from the examples and made the examples less
prominent.</t>
<t>Renamed "Functional Capabilities and Requirements" section to "Use Cases". <list>
<t>Reorganized the "Asset Management" sub-section. Added new text throughout. <list
style="symbols">
<t>Renamed a few sub-section headings.</t>
<t>Added text to the "Asset Characterization" sub-section.</t>
</list>
</t>
</list>
</t>
<t>Renamed "Security Configuration Management" to "Endpoint Configuration Management".
Not sure if the "security" distinction is important. <list style="symbols">
<t>Added new sections, partially integrated existing content.</t>
<t>Additional text is needed in all of the sub-sections.</t>
</list>
</t>
<t>Changed "Security Change Management" to "Endpoint Posture Change Management". Added
new skeletal outline sections for future updates.</t>
</list>
</t>
</section>
<section title="-04- to -05-">
<t><list style="symbols">
<t> Are we including user activities and behavior in the scope of this work? That seems
to be layer 8 stuff, appropriate to an IDS/IPS application, not Internet stuff. </t>
<t>I removed the references to what the WG will do because this belongs in the charter,
not the (potentially long-lived) use cases document. I removed mention of charter
objectives because the charter may go through multiple iterations over time; there is
a website for hosting the charter; this document is not the correct place for that
discussion.</t>
<t>I moved the discussion of NIST specifications to the acknowledgements section.</t>
<t>Removed the portion of the introduction that describes the chapters; we have a table
of concepts, and the existing text seemed redundant.</t>
<t>Removed marketing claims, to focus on technical concepts and technical analysis, that
would enable subsequent engineering effort.</t>
<t>Removed (commented out in XML) UC2 and UC3, and eliminated some text that referred to
these use cases. </t>
<t>Modified IANA and Security Consideration sections. </t>
<t>Moved Terms to the front, so we can use them in the subsequent text. </t>
<t>Removed the "Key Concepts" section, since the concepts of ORM and IRM were not
otherwise mentioned in the document. This would seem more appropriate to the arch doc
rather than use cases.</t>
<t>Removed role=editor from David Waltermire's info, since there are three editors on
the document. The editor is most important when one person writes the document that
represents the work of multiple people. When there are three editors, this role
marking isn't necessary.</t>
<t>Modified text to describe that this was specific to enterprises, and that it was
expected to overlap with service provider use cases, and described the context of this
scoped work within a larger context of policy enforcement, and verification.</t>
<t>The document had asset management, but the charter mentioned asset, change,
configuration, and vulnerability management, so I added sections for each of those
categories.</t>
<t>Added text to Introduction explaining goal of the document.</t>
<t>Added sections on various example use cases for asset management, config management,
change management, and vulnerability management.</t>
</list></t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119; </references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC0826; &RFC1213;
&RFC2790; &RFC2863; &RFC2922; &RFC4363;
&RFC5424; &RFC6933;
<!--
&I-D.draft-ietf-nea-pt-eap-09;
&RFC6876;
&I-D.draft-ietf-netmod-interfaces-cfg-12;
&I-D.draft-ietf-netmod-system-mgmt-08;
&I-D.draft-ietf-savi-framework-06;
&RFC2865;
&RFC3535;
&RFC3552;
&RFC4949;
&RFC5209;
&RFC5226;
&RFC5792;
&RFC5793;
&RFC6733;
-->
<!-- &I-D.draft-asai-vmm-mib-04; -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:29:30 |