draft-ietf-sacm-use-cases-02.txt   draft-ietf-sacm-use-cases-03.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: April 17, 2014 Effective Software Expires: April 22, 2014 Effective Software
October 14, 2013 October 19, 2013
Endpoint Security Posture Assessment - Enterprise Use Cases Endpoint Security Posture Assessment - Enterprise Use Cases
draft-ietf-sacm-use-cases-02 draft-ietf-sacm-use-cases-03
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 evaluating that data to
determine an organization's security posture. From these operational determine an organization's security posture. From these operational
use cases, we can derive common functional capabilities and use cases, we can derive common functional capabilities and
requirements to guide development of vendor-neutral, interoperable requirements to guide development of vendor-neutral, interoperable
standards for aggregating and assessing data relevant to security standards for aggregating and evaluating data relevant to security
posture. posture.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 17, 2014. This Internet-Draft will expire on April 22, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 3 2. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 3
2.1. Definition and Publication of Automatable Configuration 2.1. Definition and Publication of Automatable Configuration
Guides . . . . . . . . . . . . . . . . . . . . . . . . . 4 Guides . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Automated Checklist Verification . . . . . . . . . . . . 5 2.2. Automated Checklist Verification . . . . . . . . . . . . 6
2.3. Organizational Software Policy Compliance . . . . . . . . 6 2.3. Organizational Software Policy Compliance . . . . . . . . 7
2.4. Detection of Posture Deviations . . . . . . . . . . . . . 6 2.4. Detection of Posture Deviations . . . . . . . . . . . . . 7
2.5. Search for Signs of Infection . . . . . . . . . . . . . . 6 2.5. Search for Signs of Infection . . . . . . . . . . . . . . 7
2.6. Remediation and Mitigation . . . . . . . . . . . . . . . 7 2.6. Remediation and Mitigation . . . . . . . . . . . . . . . 8
2.7. Endpoint Information Analysis and Reporting . . . . . . . 7 2.7. Endpoint Information Analysis and Reporting . . . . . . . 8
2.8. Others... . . . . . . . . . . . . . . . . . . . . . . . . 7 2.8. Asynchronous Compliance/Vulnerability Assessment at Ice
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 Station Zebra . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 2.9. Vulnerable Endpoint Identification . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 2.10. Compromised Endpoint Identification . . . . . . . . . . . 10
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.11. Suspicious Endpoint Behavior . . . . . . . . . . . . . . 10
6.1. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 7 2.12. Traditional endpoint assessment with stored results . . . 11
6.2. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 8 2.13. NAC/NAP connection with no stored results using an
6.3. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- endpoint evaluator . . . . . . . . . . . . . . . . . . . 11
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 9 2.14. NAC/NAP connection with no stored results using a third-
6.4. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 9 party evaluator . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.15. Repository Interaction . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 2.16. Others... . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 11 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. -02- to -03- . . . . . . . . . . . . . . . . . . . . . . 13
6.2. -01- to -02- . . . . . . . . . . . . . . . . . . . . . . 13
6.3. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 14
6.4. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 15
6.5. waltermire -04- to -05- . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
assessment for enterprises. It provides a sampling of use cases for assessment for enterprises. It provides a sampling of use cases for
securely aggregating configuration and operational data and assessing securely aggregating configuration and operational data and
that data to determine the security posture of individual endpoints, evaluating that data to determine the security posture of individual
and, in the aggregate, the security posture of an enterprise. endpoints, and, in the aggregate, the security posture of an
enterprise.
These use cases cross many IT security information domains. From These use cases cross many IT security information domains. From
these operational use cases, we can derive common concepts, common these operational use cases, we can derive common concepts, common
information expressions, functional capabilities and requirements to information expressions, functional capabilities and requirements to
guide development of vendor-neutral, interoperable standards for guide development of vendor-neutral, interoperable standards for
aggregating and assessing data relevant to security posture. aggregating and evaluating data relevant to security posture.
Using this standard data, tools can analyze the state of endpoints, Using this standard data, tools can analyze the state of endpoints,
user activities and behaviour, and assess the security posture of an user activities and behaviour, and evaluate the security posture of
organization. Common expression of information should enable an organization. Common expression of information should enable
interoperability between tools (whether customized, commercial, or interoperability between tools (whether customized, commercial, or
freely available), and the ability to automate portions of security freely available), and the ability to automate portions of security
processes to gain efficiency, react to new threats in a timely processes to gain efficiency, react to new threats in a timely
manner, and free up security personnel to work on more advanced manner, and free up security personnel to work on more advanced
problems. problems.
The goal is to enable organizations to make informed decisions that The goal is to enable organizations to make informed decisions that
support organizational objectives, to enforce policies for hardening support organizational objectives, to enforce policies for hardening
systems, to prevent network misuse, to quantify business risk, and to systems, to prevent network misuse, to quantify business risk, and to
collaborate with partners to identify and mitigate threats. collaborate with partners to identify and mitigate threats.
skipping to change at page 3, line 32 skipping to change at page 4, line 4
providers will largely overlap, but there are additional providers will largely overlap, but there are additional
complications for service providers, especially in handling complications for service providers, especially in handling
information that crosses administrative domains. information that crosses administrative domains.
The output of endpoint posture assessment is expected to feed into The output of endpoint posture assessment is expected to feed into
additional processes, such as policy-based enforcement of acceptable additional processes, such as policy-based enforcement of acceptable
state, verification and monitoring of security controls, and state, verification and monitoring of security controls, and
compliance to regulatory requirements. compliance to regulatory requirements.
2. Endpoint Posture Assessment 2. Endpoint Posture Assessment
Endpoint posture assessment involves orchestrating and performing Endpoint posture assessment involves orchestrating and performing
data collection and analysis pertaining to the posture of a given data collection and evaluating the posture of a given endpoint.
endpoint. Typically, endpoint posture information is gathered and Typically, endpoint posture information is gathered and then
then published to appropriate data repositories to make collected 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 attributes of a given endpoint;
o Making that posture available to the enterprise for further o Making the attributes available for evaluation and action; and
analysis and action; and
o Performing analysis to assess that the endpoint's posture is in o Verifying that the endpoint's posture is in compliance with
compliance with enterprise standards and policy. enterprise standards and policy.
As part of these activities it is often necessary to identify and As part of these activities it is often necessary to identify and
acquire any supporting content that is needed to drive data acquire any supporting content that is needed to drive data
collection and analysis. collection and analysis.
The following is a typical workflow scenario for assessing endpoint The following is a typical workflow scenario for assessing endpoint
posture: posture:
1. Define a target endpoint to be assessed 1. Some type of trigger initiates the workflow. For example, an
operator or an application might trigger the process with a
request, or the endpoint might trigger the process using an
event-driven notification.
2. Select policies applicable to the target, and identify what QUESTION: Since this is about security automation, can we drop
posture attributes need to be collected for assessment. the User and just use Application? Is there a better term to
use here? Once the policy is selected, the rest seems like
something we definitely would want to automate, so I dropped
the User part.
3. Verify the identity of the target being assessed 2. A user/application selects a target endpoint to be assessed.
4. Collect posture attributes from the target 3. A user/application selects which policies are applicable to the
target.
5. Communicate target identity and collected attributes to external 4. The application determines which (sets of) posture attributes
system for evaluation need to be collected for evaluation.
6. Evaluator compares collected posture attributes from the target QUESTION: It was suggested that mentioning several common
with expected values as expressed in policies acquisition methods, such as local API, WMI, Puppet, DCOM,
SNMP, CMDB query, and NEA, without forcing any specific method
would be good. I have concerns this could devolve into a
"what about my favorite?" contest. OTOH, the charter does
specifically call for use of existing standards where
applicable, so the use cases document might be a good neutral
location for such information, and might force us to consider
what types of external interfaces we might need to support
when we consider the requirements. It appears that the
generic workflow sequence would be a good place to mention
such common acquisition methods.
5. The application might retrieve previously collected information
from a cache or data store, such as a data store populated by an
asset management system.
6. The application might establish communication with the target,
mutually authenticate identities and authorizations, and collect
posture attributes from the target.
7. The application might establish communication with one or more
intermediary/agents, mutually authenticate their identities and
determine authorizations, and collect posture attributes about
the target from the intermediary/agents. Such agents might be
local or external.
8. The application communicates target identity and (sets of)
collected attributes to an evaluator, possibly an external
process or external system.
9. The evaluator compares the collected posture attributes with
expected values as expressed in policies.
QUESTION: Evaluator generates a report or log or notification
of some type?
The following subsections detail specific use cases for data The following subsections detail specific use cases for data
collection, analysis, and related operations pertaining to the collection, analysis, and related operations pertaining to the
publication and use of supporting content. publication and use of supporting content.
2.1. Definition and Publication of Automatable Configuration Guides 2.1. Definition and Publication of Automatable Configuration Guides
A network device vendor manufactures a number of enterprise grade A vendor manufactures a number of specialized endpoint devices. They
routers and other network devices. They also develop and maintain an also develop and maintain an operating system for these devices that
operating system for these devices that enables end-user enables end-user organizations to configure a number of security and
organizations to configure a number of security and operational operational settings. As part of their customer support activities,
settings for these devices. As part of their customer support they publish a number of secure configuration guides that provide
activities, they publish a number of secure configuration guides that minimum security guidelines for configuring their devices.
provide minimum security guidelines for configuring their devices.
Each guide they produce applies to a specific model of device and Each guide they produce applies to a specific model of device and
version of the operating system and provides a number of specialized version of the operating system and provides a number of specialized
configurations depending on the devices intended function and what configurations depending on the devices intended function and what
add-on hardware modules and software licenses are installed on the add-on hardware modules and software licenses are installed on the
device. To enable their customers to assess the security posture of device. To enable their customers to evaluate the security posture
their devices to ensure that all appropriate minimal security of their devices to ensure that all appropriate minimal security
settings are enabled, they publish an automatable configuration settings are enabled, they publish an automatable configuration
checklist using a popular data format that defines what settings to checklist using a popular data format that defines what settings to
check using a network management protocol and appropriate values for collect using a network management protocol and appropriate values
each setting. They publish these guides to a public content for each setting. They publish these guides to a public content
repository that customers can query to retrieve applicable guides for repository that customers can query to retrieve applicable guides for
their deployed enterprise network infrastructure endpoints. their deployed enterprise network infrastructure endpoints.
Guides could also come from sources other than a device vendor, such Guides could also come from sources other than a device vendor, such
as industry groups or regulatory authorities, or enterprises could as industry groups or regulatory authorities, or enterprises could
develop their own checklists. develop their own checklists.
QUESTION: This use case applies equally to vendors representing other
endpoint types. Should this be generalized to capture this notion?
QUESTION: Is providing traceability to functional capabilities
useful? If so, we need to replicate this for the other use cases.
2.2. Automated Checklist Verification 2.2. Automated Checklist Verification
A financial services company operates a heterogeneous IT environment. A financial services company operates a heterogeneous IT environment.
In support of their risk management program, they utilize vendor In support of their risk management program, they utilize vendor
provided automatable security configuration checklists for each provided automatable security configuration checklists for each
operating system and application used within their IT environment. operating system and application used within their IT environment.
Multiple checklists are used from different vendors to insure Multiple checklists are used from different vendors to insure
adequate coverage of all IT assets. adequate coverage of all IT assets.
To identify what checklists are needed, they use automation to gather To identify what checklists are needed, they use automation to gather
skipping to change at page 6, line 21 skipping to change at page 7, line 21
Example Corporation, in support of compliance requirements, has Example Corporation, in support of compliance requirements, has
identified a number of secure baselines for different endpoint types identified a number of secure baselines for different endpoint types
that exist across their enterprise IT environment. Determining which that exist across their enterprise IT environment. Determining which
baseline applies to a given endpoint is based on the organizationally baseline applies to a given endpoint is based on the organizationally
defined function of the device. defined function of the device.
Each baseline, defined using an automatable standardized data format, Each baseline, defined using an automatable standardized data format,
identifies the expected hardware, software and patch inventory, and identifies the expected hardware, software and patch inventory, and
software configuration item values for each endpoint type. As part software configuration item values for each endpoint type. As part
of their compliance activities, they require that all endpoints of their compliance activities, they require that all endpoints
connecting to their network meet the appropriate baselines. Each connecting to their network meet the appropriate baselines. The
endpoint is checked to make sure it complies with the appropriate configuration settings of each endpoint are collected and compared to
baseline whenever it connects to the network and at least once a day the baseline to make sure the configuration complies with the
thereafter. These daily compliance checks assess the posture of each appropriate baseline whenever it connects to the network and at least
endpoint and report on its compliance with the appropriate baseline. once a day thereafter. These daily compliance checks evaluate 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 [TODO: Need to speak to how the baselines are identified for a given
endpoint connecting to the network.] endpoint connecting to the network.]
2.4. Detection of Posture Deviations 2.4. Detection of Posture Deviations
Example corporation has established secure configuration baselines Example corporation has established secure configuration baselines
for each different type of endpoint within their enterprise for each different type of endpoint within their enterprise
including: network infrastructure, mobile, client, and server including: network infrastructure, mobile, client, and server
computing platforms. These baselines define an approved list of computing platforms. These baselines define an approved list of
skipping to change at page 6, line 50 skipping to change at page 8, line 4
the expected function of the device, and other asset management data. the expected function of the device, and other asset management data.
It is checked for compliance with the baseline indicating any It is checked for compliance with the baseline indicating any
deviations to the device's operators. Once the baseline has been deviations to the device's operators. Once the baseline has been
established, the endpoint is monitored for any change events established, the endpoint is monitored for any change events
pertaining to the baseline on an ongoing basis. When a change occurs pertaining to the baseline on an ongoing basis. When a change occurs
to posture defined in the baseline, updated posture information is to posture defined in the baseline, updated posture information is
exchanged allowing operators to be notified and/or automated action exchanged allowing operators to be notified and/or automated action
to be taken. to be taken.
2.5. Search for Signs of Infection 2.5. Search for Signs of Infection
The Example Corporation carefully manages endpoint security with
tools that implement the SACM standards. One day, the endpoint
security team at Example Corporation learns about a stealthy malware
package. This malware has just been discovered but has already
spread widely around the world. Certain signs of infection have been
identified (e.g. the presence of certain files). The security team
would like to know which endpoints owned by the Example Corporation
have been infected with this malware. They use their tools to search
for the signs of infection and generate a list of infected endpoints.
TODO The search for infected endpoints may be performed by gathering new
endpoint posture information regarding the presence of the signs of
infection. However, this might miss finding endpoints that were
previously infected but where the infection has now erased itself.
Such previously infected endpoints may be detected by searching a
database of posture information previously gathered for the signs of
infection. However, this will not work if the malware hides its
presence carefully or if the signs of infection were not included in
previous posture assessments. In those cases, the database may be
used to at least detect which endpoints previously had software
vulnerable to infection by the malware.
2.6. Remediation and Mitigation 2.6. Remediation and Mitigation
TODO When Example Corporation discovers that one of its endpoints is
vulnerable to infection, a process of mitigation and remediation is
triggered. The first step is mitigating the impact of the
vulnerability, perhaps by placing the endpoint into a safe network or
blocking network traffic that could infect the endpoint. The second
step is remediation: fixing the vulnerability. In some cases, these
steps may happen automatically and rapidly. In other cases, they may
require human intervention either to decide what response is most
appropriate or to complete the steps, which are sometimes complex.
These same steps of mitigation and remediation may be used when
Example Corporation discovers that one of its endpoints has become
infected with some malware. Alternatively, the infected endpoint may
simply be monitored or even placed into a honeynet or similar
environment to observe the malware's behavior and lead the attackers
astray.
QUESTION: Is remediation and mitigation within the scope of the WG,
and should the use case be included here?
2.7. Endpoint Information Analysis and Reporting 2.7. Endpoint Information Analysis and Reporting
TODO Freed from the drudgery of manual endpoint compliance monitoring, one
of the security administrators at Example Corporation notices (not
using SACM standards) that five endpoints have been uploading lots of
data to a suspicious server on the Internet. The administrator
queries the SACM database of endpoint posture to see what software is
installed on those endpoints and finds that they all have a
particular program installed. She then searches the database to see
which other endpoints have that program installed. All these
endpoints are monitored carefully (not using SACM standards), which
allows the administrator to detect that the other endpoints are also
infected.
2.8. Others... This is just one example of the useful analysis that a skilled
analyst can do using the database of endpoint posture that SACM can
provide.
2.8. Asynchronous Compliance/Vulnerability Assessment at Ice Station
Zebra
A university team receives a grant to do research at a government
facility in the arctic. The only network communications will be via
an intermittent low-speed high-latency high-cost satellite link.
During their extended expedition they will need to show continue
compliance with the security policies of the university, the
government, and the provider of the satellite network as well as keep
current on vulnerability testing. Interactive assessments are
therefore not reliable, and since the researchers have very limited
funding they need to minimize how much money they spend on network
data.
Prior to departure they register all equipment with an asset
management system owned by the university, which will also initiate
and track assessments.
On a periodic basis -- either after a maximum time delta or when the
content repository has received a threshold level of new
vulnerability definitions -- the university uses the information in
the asset management system to put together a collection request for
all of the deployed assets that encompasses the minimal set of
artifacts necessary to evaluate all three security policies as well
as vulnerability testing.
In the case of new critical vulnerabilities this collection request
consists only of the artifacts necessary for those vulnerabilities
and collection is only initiated for those assets that could
potentially have a new vulnerability.
[Optional] Asset artifacts are cached in a local CMDB. When new
vulnerabilities are reported to the content repository, a request to
the live asset is only done if the artifacts in the CMDB are
incomplete and/or not current enough.
The collection request is queued for the next window of connectivity.
The deployed assets eventually receive the request, fulfill it, and
queue the results for the next return opportunity.
The collected artifacts eventually make it back to the university
where the level of compliance and vulnerability expose is calculated
and asset characteristics are compared to what is in the asset
management system for accuracy and completeness.
2.9. Vulnerable Endpoint Identification
Typically vulnerability reports identify an executable or library
that is vulnerable, or worst case the software that is vulnerable.
This information is used to determine if an organization has one or
more endpoints that have exposure to a vulnerability (i.e., what
endpoints are vulnerable?). It is often necessary to know where you
are running vulnerable code and what configurations are in place on
the endpoint and upstream devices (e.g., IDS, firewall) that may
limit the exposure. All of this information, along with details on
the severity and impact of a vulnerability, is necessary to
prioritize remedies.
2.10. Compromised Endpoint Identification
Along with knowing if one or more endpoints are vulnerable, it is
also important to know if you have been compromised. Indicators of
compromise provide details that can be used to identify malware
(e.g., file hashes), identify malicious activity (e.g. command and
control traffic), presence of unauthorized/malicious configuration
items, and other indicators. While important, this goes beyond
determining organizational exposure.
2.11. Suspicious Endpoint Behavior
This Use Case describes the collaboration between specific
participants in an information security system specific to detecting
a connection attempt to a known-bad Internet host by a botnet zombie
that has made its way onto an organization's Information Technology
systems. The primary human actor is the Security Operations Center
Analyst, and the primary software actor is the configuration
assessment tool. Note, however, the dependencies on other tools,
such as asset management, intrusion detection, and messaging.
2.12. Traditional endpoint assessment with stored results
An external trigger initiates an assessment of an endpoint. The
Controller uses the data in the Datastore to look up authentication
information for the endpoint and passes that along with the
assessment request details to the Evaluator. The Evaluator uses the
Endpoint information to request taxonomy information from the
Collector on the endpoint, which responds with those attributes. The
Evaluator uses that taxonomy information along with the information
in the original request from the Controller to request the
appropriate content from the Content Repository. The Evaluator uses
the content to derive the minimal set of endpoint attributes needed
to perform the assessment and makes that request. The Evaluator uses
the Collector response to do the assessment and returns the results
to the Controller. The Controller puts the results in the Datastore.
2.13. NAC/NAP connection with no stored results using an endpoint
evaluator
A mobile endpoint makes a VPN connection request. The NAC/NAP broker
requests the results of the VPN connection assessment from the
Controller. The Controller requests the VPN attributes from a
Content Repository. The Controller requests an evaluation of the
collected attributes from the Evaluator on the endpoint. The
endpoint performs the assessment and returns the results. The
Controller completes the original assessment request by returning the
results to the NAC/NAP broker, which uses them to set the level of
network access allowed to the endpoint.
QUESTION: I edited these from Gunnar's email of 9/11, to try to
reduce the use of "assessment", to focus on collection and
evaluation, and deal with use cases rather than architecture. I am
not sure I got all the concepts properly identified.
2.14. NAC/NAP connection with no stored results using a third-party
evaluator
A mobile endpoint makes a VPN connection request. The NAC/NAP broker
requests the results of the VPN connection assessment from the
Controller. The Controller requests the VPN attributes from a
Content Repository. The Controller requests an evaluation of the
collected attributes from an Evaluator in the network (rather than
trusting an evaluator on the endpoint). The evaluator performs the
evaluation and returns the results. The Controller completes the
original assessment request by returning the results to the NAC/NAP
broker, which uses them to set the level of network access allowed to
the endpoint.
QUESTION: I edited these from Gunnar's email of 9/11, to try to
reduce the use of "assessment", to focus on collection and
evaluation, and deal with use cases rather than architecture. I am
not sure I got all the concepts properly identified.
2.15. Repository Interaction
Additional use cases will be identified as we work through other
domains.
2.16. Others...
Additional use cases will be identified as we work through other Additional use cases will be identified as we work through other
domains. domains.
3. IANA Considerations 3. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
4. Security Considerations 4. Security Considerations
skipping to change at page 7, line 35 skipping to change at page 12, line 37
security automation. While it is about security, it does not affect security automation. While it is about security, it does not affect
security. security.
5. Acknowledgements 5. Acknowledgements
The National Institute of Standards and Technology (NIST) and/or the The National Institute of Standards and Technology (NIST) and/or the
MITRE Corporation have developed specifications under the general MITRE Corporation have developed specifications under the general
term "Security Automation" including languages, protocols, term "Security Automation" including languages, protocols,
enumerations, and metrics. enumerations, and metrics.
The authors would like to recognize and thank Adam Montville for his Adam Montville edited early versions of this draft.
work on early edits of this draft. Additionally, the authors would
like to thank Kathleen Moriarty and Stephen Hanna for contributing Kathleen Moriarty and Stephen Hanna contributed text describing the
text to this document. The authors would also like to acknowledge scope of the document.
the members of the SACM mailing list for their keen and insightful
feedback on the concepts and text within this document. Steve Hanna provided use cases for Search for Signs of Infection,
Remediation and Mitigation, and Endpoint Information Analysis and
Reporting.
Gunnar Engelbach provided the use case about Ice Station Zebra.
6. Change Log 6. Change Log
6.1. -00- to -01- 6.1. -02- to -03-
Expanded the workflow description based on ML input.
Changed the ambiguous "assess" to better separate data collection
from evaluation.
Added use case for Search for Signs of Infection.
Added use case for Remediation and Mitigation.
Added use case for Endpoint Information Analysis and Reporting.
Added use case for Asynchronous Compliance/Vulnerability Assessment
at Ice Station Zebra.
Added use case for Traditional endpoint assessment with stored
results.
Added use case for NAC/NAP connection with no stored results using an
endpoint evaluator.
Added use case for NAC/NAP connection with no stored results using a
third-party evaluator.
Added use case for Compromised Endpoint Identification.
Added use case for Suspicious Endpoint Behavior.
Added use case for Vulnerable Endpoint Identification.
Updated Acknowledgements
6.2. -01- to -02-
Changed title Changed title
removed section 4, expecting it will be moved into the requirements removed section 4, expecting it will be moved into the requirements
document. document.
removed the list of proposed caabilities from section 3.1 removed the list of proposed caabilities from section 3.1
Added empty sections for Search for Signs of Infection, Remediation Added empty sections for Search for Signs of Infection, Remediation
and Mitigation, and Endpoint Information Analysis and Reporting. and Mitigation, and Endpoint Information Analysis and Reporting.
Removed Requirements Language section and rfc2119 reference. Removed Requirements Language section and rfc2119 reference.
Removed unused references (which ended up being all references). Removed unused references (which ended up being all references).
6.2. -00- to -01- 6.3. -00- to -01-
o Work on this revision has been focused on document content o Work on this revision has been focused on document content
relating primarily to use of asset management data and functions. relating primarily to use of asset management data and functions.
o Made significant updates to section 3 including: o Made significant updates to section 3 including:
* Reworked introductory text. * Reworked introductory text.
* Replaced the single example with multiple use cases that focus * Replaced the single example with multiple use cases that focus
on more discrete uses of asset management data to support on more discrete uses of asset management data to support
skipping to change at page 9, line 10 skipping to change at page 15, line 5
"Deconfliction of Asset Identities". "Deconfliction of Asset Identities".
* Expanded the subsections for: Asset Identification, Asset * Expanded the subsections for: Asset Identification, Asset
Characterization, and Deconfliction of Asset Identities. Characterization, and Deconfliction of Asset Identities.
* Added a new subsection for Asset Targeting. * Added a new subsection for Asset Targeting.
* Moved remaining sections to "Other Unedited Content" for future * Moved remaining sections to "Other Unedited Content" for future
updating. updating.
6.3. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 6.4. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00
o Transitioned from individual I/D to WG I/D based on WG consensus o Transitioned from individual I/D to WG I/D based on WG consensus
call. call.
o Fixed a number of spelling errors. Thank you Erik! o Fixed a number of spelling errors. Thank you Erik!
o Added keywords to the front matter. o Added keywords to the front matter.
o Removed the terminology section from the draft. Terms have been o Removed the terminology section from the draft. Terms have been
moved to: draft-dbh-sacm-terminology-00 moved to: draft-dbh-sacm-terminology-00
skipping to change at page 9, line 49 skipping to change at page 15, line 44
is important. is important.
* Added new sections, partially integrated existing content. * Added new sections, partially integrated existing content.
* Additional text is needed in all of the sub-sections. * Additional text is needed in all of the sub-sections.
o Changed "Security Change Management" to "Endpoint Posture Change o Changed "Security Change Management" to "Endpoint Posture Change
Management". Added new skeletal outline sections for future Management". Added new skeletal outline sections for future
updates. updates.
6.4. -04- to -05- 6.5. waltermire -04- to -05-
o Are we including user activities and behavior in the scope of this o Are we including user activities and behavior in the scope of this
work? That seems to be layer 8 stuff, appropriate to an IDS/IPS work? That seems to be layer 8 stuff, appropriate to an IDS/IPS
application, not Internet stuff. application, not Internet stuff.
o I removed the references to what the WG will do because this o I removed the references to what the WG will do because this
belongs in the charter, not the (potentially long-lived) use cases belongs in the charter, not the (potentially long-lived) use cases
document. I removed mention of charter objectives because the document. I removed mention of charter objectives because the
charter may go through multiple iterations over time; there is a charter may go through multiple iterations over time; there is a
website for hosting the charter; this document is not the correct website for hosting the charter; this document is not the correct
place for that discussion. place for that discussion.
 End of changes. 37 change blocks. 
88 lines changed or deleted 362 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/