One document matched: draft-waltermire-sacm-use-cases-05.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 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 RFC6933 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6933.xml">
<!ENTITY I-D.draft-ietf-nea-pt-eap-06 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nea-pt-eap-06.xml">
<!ENTITY I-D.draft-ietf-nea-pt-tls-08 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nea-pt-tls-08.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-waltermire-sacm-use-cases-05" 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></phone>
<email>david.waltermire@nist.gov</email>
</address>
</author>
<author fullname="Adam W. Montville" initials="A.W.M."
surname="Montville">
<organization abbrev="TW">Tripwire, Inc.</organization>
<address>
<postal>
<street>101 SW Main Street, Suite 1500</street>
<city>Portland</city>
<region>Oregon</region>
<code>97204</code>
<country>USA</country>
</postal>
<phone></phone>
<email>amontville@tripwire.com</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></phone>
<email>ietfdbh@comcast.net</email>
</address>
</author>
<date year="2013" />
<!-- Meta-data Declarations -->
<area>General</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 continuous monitoring model sacm endpoint</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 analyse 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 anchor="sec-terms" title="Terms and Definitions">
<t>assessment
<list>
<t>Defined in <xref target="RFC5209"/> as "the process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy."</t>
<t>Within this document the use of the term is expanded to support other uses of collected posture (e.g. reporting, network enforcement, vulnerability detection, license management). The phrase "set of capabilities on the endpoint" includes: hardware and software installed on the endpoint."</t>
</list>
</t>
<t>asset
<list>
<t>Defined in <xref target="RFC4949"/> as "a system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protect by a countermeasure, or (c) required for a system's mission.</t>
</list>
</t>
<t>attribute
<list>
<t>Defined in <xref target="RFC5209"/> as "data element including any requisite meta-data describing an observed, expected, or the operational status of an endpoint feature (e.g., anti-virus software is currently in use)."</t>
</list>
</t>
<t>endpoint
<list>
<t>Defined in <xref target="RFC5209"/> as "any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address."</t>
<t>Network infrastructure devices (e.g. switches, routers, firewalls), which fit the definition, are also considered to be endpoints within this document.</t>
<t>Based on the previous definition of an asset, an endpoint is a type of asset.</t>
</list>
</t>
<t>posture
<list>
<t>Defined in <xref target="RFC5209"/> as "configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy."</t>
<t>This term is used within the scope of this document to represent the state information that is collected from an endpoint (e.g. software/hardware inventory, configuration settings).</t>
</list>
</t>
<t>posture attributes
<list>
<t>Defined in <xref target="RFC5209"/> as "attributes describing the configuration or status (posture) of a feature of the endpoint. For example, a Posture Attribute might describe the version of the operating system installed on the system."</t>
<t>Within this document this term represents a specific assertion about endpoint state (e.g. configuration setting, installed software, hardware). The phrase "features of the endpoint" refers to installed software or software components.</t>
</list>
</t>
<t>system resource
<list>
<t>Defined in <xref target="RFC4949"/> as "data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment.</t>
</list>
</t>
<!--
<t>
<list>
<t>Defined in <xref target="RFC"/> as </t>
</list>
</t>
-->
<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>
<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="Functional Capabilities and Requirements" anchor="sec-capability">
<!-- <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 capabilities in this section support assessing endpoint posture in an automated manner as described in Section <xref target="endpoint-posture-assessment"></xref>.</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-capability-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>
<section title="Example - Asset Discovery within a subnet">
<t>Many network management systems detect the presence of assets in a subnet, such as an Ethernet subnet, by monitoring the MAC addresses
bradcast within the subnet to determine who responds to broadcasts, and determing the location of the endpoint relative to a bridge. This
information is useful for initally discovering
and characterizing endpoints belonging to a particular type of network (e.g. Ethernet), and for detecting new nodes in the subnet. This type
of information may be accessible by accessing ARP tables <xref target="RFC0826"/>,
Etherlike-MIB <xref target="RFC3535"/>,
the Link Layer Discovery Protocol MIB <xref target="RFC2922"/>,
the
Interfaces MIB (IF-MIB) <xref target="RFC2863"/>,
the YANG module ietf-interfaces <!-- xref target="I-D.draft-ietf-netmod-interfaces-cfg-12"/ -->, and others.
</t>
</section>
<section title="Example - Asset Discovery by IP Address">
<t>Many network management systems periodically test for the presence of endpoints or interfaces in a network by broadcasting ICMP echo
commands (pings) to a range of IP addresses and recording the addresses of nodes that respond. This helps discover the endpoints in the network,
including endpoints that have suddenly appeared in a network tha are not authorized to be part of the network.
</t>
</section>
<section title="Example - Asset Characterization using system information">
<t>The SYSTEM-MIB <xref target="RFC1213"/> contains information to help characterize an endpoint, including 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
decription includes the vendor, product type, model number, OS version, and networking software version. This is a key MIB module mandated for
all SNMP-managed endpoints.
</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="Example - Asset Characterization using the ENTITY-MIB">
<t>The ENTITY-MIB <xref target="RFC6933"/> contains information to describe the components of an endpoint, including physical and logical components, and the
relationships between the components. The information about the physical entities includes manufacturer-assigned serial number, manufacture date,
administratively-assigned AssetID, and UUID. Logical entities may be defined, and associated with the physical entities using a mapping table.
</t>
</section>
<section title="Example - Asset Characterization using the HOST-RESOURCES-MIB">
<t>The HOST-RESOURCES-MIB <xref target="RFC2790"/> contains information to describe the resources of an endpoint, including storage, memory, installed software,
running software, software versions, processes, user sessions, devices (processors, disks, printers, network interfaces, etc.). This MIB module
also provides monitoring of performance and error states.
</t>
</section>
<section title="Concepts">
<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>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>Identify and describe assets using a common vocabulary between implementations</t>
<t>Reconcile asset representations originating from disparate tools</t>
<t>Manage asset information throughout the asset's life cycle</t>
</list>
</t>
</section>
<section title="Requirements">
<t>
<list>
<t>A method MUST be provided for identifying an endpoint (asset identification) as a unique entity within the its administrative domain.</t>
<t>The endpoint identifier SHOULD be able to be determined in an automated manner.</t>
<t>The endpoint identifier, as communicated between entities, SHOULD be held to a minimal size.</t>
<t>A method MUST be provided for defining an endpoint (asset classification) based on a set of organizationally relevant properties (e.g. organizational affiliation, criticality, function).</t>
</list>
</t>
</section>
</section>
<section title="Security Configuration Management" anchor="sec-capability-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>
<section title="Example - ENTITY-MIB">
</section>
<section title="Example - HOST-RESOURCES-MIB">
</section>
<section title="Example - YANG module ietf-interfaces">
</section>
<section title="Concepts">
<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>The following list details some requisite Configuration Management capabilities:
<list style="symbols">
<t>[todo]</t>
</list>
</t>
</section>
<section title="Requirements">
<t>
<list>
<t>[todo]</t>
</list>
</t>
</section>
</section>
<section title="Security Change Management" anchor="sec-capability-change-management">
<t>Organizations manage a variety of changes within their enterprise including: [todo] </t>
<section title="Example - DHCP addressing">
</section>
<section title="Example - RADIUS network access">
</section>
<section title="Example - NAT logging">
</section>
<section title="Example - SYSLOG Authorization messages">
<t>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 title="Concepts">
<t>[todo]</t>
<t>The following list details some requisite Change Management capabilities:
<list style="symbols">
<t>[todo]</t>
</list>
</t>
</section>
<section title="Requirements">
<t>
<list>
<t>[todo]</t>
</list>
</t>
</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>
<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 associtaed with that endpoint, and initates 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 title="Concepts">
<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>
<section title="Requirements">
<t>
<list>
<t>[todo]</t>
</list>
</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>
<section title="Concepts">
<!-- QUESTION: Understand more about what is meant by non-software vulnerabilities -->
<t>The following assessment capabilities support SCM:
<list style="symbols">
<t>[todo]</t>
</list>
</t>
</section>
<section title="Requirements">
<t>One or more data formats MUST be identified to describe instructions, data collection methods, to drive data collection (e.g. technical, interrogative).</t>
<t>One or more data formats MUST be identified to instruct what posture attributes need to be collected for a specific set of endpoints.
<list>
<t>A method MUST be provided to include OPTIONAL instructions on describing what content must be run on the endpoint.</t>
<t>A method MUST be provided to include OPTIONAL instructions that determine how to collect data supporting any particular test for that endpoint.</t>
</list>
</t>
<t>A method MUST be provided for retrieving data collection instructions from a remote host (see Section <xref target="sec-capability-content-management"/>).</t>
<t>One or more data formats MUST be identified to capture the results of data collection.
<list>
<t>This expression MUST be capable of supporting the characterization of assets and any related configuration settings that together compose an endpoint.
<list>
<t>A mechanism MUST be provided to identify the software and hardware asset instances that compose an endpoint.
<list>
<t>An asset identifier SHOULD be able to be determined in an automated manner</t>
<t>An asset identifier, as communicated between entities, SHOULD be held to a minimal size.</t>
<t>An asset identifier SHOULD be able to represented in a simple unambiguous manner, such as a reference, so that its embedded use in places like applicability clauses for individual benchmark tests can be kept from making their usage unwieldy.</t>
</list>
</t>
<t>A mechanism MUST be provided to associate configuration settings values to the installed software.</t>
<t>A mechanism MUST be provided to identify additional collected posture attribute/value pairs related to an endpoint.</t>
</list>
</t>
<t>A mechanism MUST be provided to identify the endpoint the results pertain to (see Section <xref target="sec-capability-asset-management"/>.</t>
<t>A mechanism MUST be provided to associate the data collection method with the collected value.</t>
<t>A mechanism MUST be provided to include provenance information describing what sensor of software collected the data.</t>
<t>A mechanism MUST be provided to include entailment information, perhaps by reference, describing the methodology used to collect the data.</t>
</list>
</t>
<t>A method of communicating data collection results to another system for further analysis MUST be identified.</t>
<t>TODO: Communicate, unambiguously and to the necessary level of detail**, the asset details between software components</t>
</section>
</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>
<section title="Concepts">
<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="Requirements">
<!-- TODO: Use of an applicability concept, against a collection of assets to determine what policies (test expressions) are suitable for collection and evaluation. -->
<t>A method MUST be provided for selecting acceptable state policy, describing how to evaluate collected information, based on characteristics of the endpoint and organizational policy.</t>
<t>A method MUST be provided for comparing collected data to expected state values (test evaluation).</t>
<t>Any results produced by analysis processes MUST be capable of being transformed into a human-readable format.</t>
</section>
</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>
<section title="Concepts">
<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 title="Requirements">
<t>A protocol MUST be identified for retrieving SACM content from a content repository</t>
<t>A protocol MUST be identified for querying SACM content held in a content repository. The protocol MUST support querying content by applicability to asset characteristics.
<list>
<t>TODO: Determine what content can or must be run on the endpoint</t>
</list>
</t>
<t>A protocol MUST be identified for curating SACM content in a content repository. Note: This might be an area where we can limit the scope of work relative to the initial SACM charter.</t>
</section>
</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 thank Kathleen Moriarty and Stephen Hanna for contributing text to this document. The author 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="-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 Waltmire'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;
&RFC2865;
&RFC2922;
&RFC3535;
&RFC3552;
&RFC4949;
&RFC5209;
&RFC5226;
&RFC5424;
&RFC5792;
&RFC5793;
&RFC6733;
&RFC6933;
&I-D.draft-ietf-nea-pt-eap-06;
&I-D.draft-ietf-nea-pt-tls-08;
&I-D.draft-ietf-netmod-interfaces-cfg-12;
&I-D.draft-ietf-netmod-system-mgmt-08;
&I-D.draft-ietf-savi-framework-06;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:55:50 |