draft-ietf-sacm-architecture-00.txt   draft-ietf-sacm-architecture-01.txt 
SACM N. Cam-Winget, Ed. SACM N. Cam-Winget, Ed.
Internet-Draft B. Ford Internet-Draft B. Ford
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: April 16, 2015 L. Lorenzin Expires: May 23, 2015 L. Lorenzin
Pulse Secure Pulse Secure
I. McDonald I. McDonald
High North Inc High North Inc
A. Woland A. Woland
Cisco Systems Cisco Systems
October 13, 2014 November 19, 2014
Secure Automation and Continuous Monitoring (SACM) Architecture Secure Automation and Continuous Monitoring (SACM) Architecture
draft-ietf-sacm-architecture-00 draft-ietf-sacm-architecture-01
Abstract Abstract
This document describes an architecture for standardization of This document describes an architecture for standardization of
interfaces, protocols and information models related to security interfaces, protocols and information models related to security
automation and continuous monitoring. It describes the basic automation and continuous monitoring. It describes the basic
architecture, components and their interfaces defined to enable the architecture, components and their interfaces defined to enable the
collection, acquisition and verification of Posture and Posture collection, acquisition and verification of Posture and Posture
Assessments. Assessments.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 16, 2015. This Internet-Draft will expire on May 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Posture Assessment Information Consumer . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3
2.2. Posture Assessment Information Provider . . . . . . . . . 5 3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 4
2.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Posture Assessment Information Provider . . . . . . . 5
2.4. Interfaces between Consumers, Providers and Control Plane 7 3.1.2. Posture Assessment Information Consumer . . . . . . . 5
3. Example mapping to SACM Architecture . . . . . . . . . . . . 8 3.1.3. Controller . . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Interfaces between Consumers, Providers, and Controllers 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Component Capabilities . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.1. Control Plane Capabilities . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Data Plane Capabilities . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 4.2.1. Collector . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10 4.2.1.1. Internal Collector . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1.2. External Collector . . . . . . . . . . . . . . . 9
4.2.1.3. Collector Interactions With Target Endpoints . . 9
4.2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Report Generator . . . . . . . . . . . . . . . . . . 10
4.2.4. Data Store . . . . . . . . . . . . . . . . . . . . . 10
5. Example Illustration of Capabilities and Workflow . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Several data models and protocols are in use today that allow Several data models and protocols are in use today that allow
different applications to perform the collection, acquisition and different applications to perform the collection, acquisition, and
assessment of posture. These applications can vary from being assessment of posture. These applications can vary from being
focused on general system and security management to specialized focused on general system and security management to specialized
configuration, compliance and control systems. With an existing configuration, compliance, and control systems. With an existing
varied set of applications, there is a strong desire to standardize varied set of applications, there is a strong desire to standardize
data models, protocols and interfaces to better allow for the data models, protocols, and interfaces to better allow for the
automation of such data processes. automation of such data processes.
This document describes an architecture to enable standardized This document addresses general and architectural requirements
collection, acquisition, and verification of Posture and Posture defined in [I-D.ietf-sacm-requirements]. This document describes an
Assessments. The architecture will include the components and architecture to enable standardized collection, acquisition, and
interfaces that can be used to better identify the Information Model, verification of Posture and Posture Assessments. This architecture
type(s) of transport protocols needed for communication, and further, includes the components and interfaces that can be used to better
provide a model from which requirements can be drawn. identify the Information Model and type(s) of transport protocols
needed for communication.
This document uses terminology defined in This document uses terminology defined in
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
2. Architectural Overview 2. Problem Statement
Securing information and the systems that store, process, and
transmit that information is a challenging task for organizations of
all sizes, and many security practitioners spend much of their time
on manual processes. Administrators can't get technology from
disparate sources to work together; they need information to make
decisions, but the information is not available. Everyone is
collecting the same data, but storing it as different information.
Administrators therefore need to collect data and craft their own
information, which may not be accurate or interoperable because it's
customized by each administrator, not shared.
Security automation and continuous monitoring require a large and
broad set of mission and business processes; to make the most
effective of use of technology, the same data must support multiple
processes. The need for complex characterization and assessment
necessitates components and functions that interoperate and can build
off each other to enable far-ranging and/or deep-diving analysis.
3. Architectural Overview
At a high level, the architecture describes 'How' and 'Where' At a high level, the architecture describes 'How' and 'Where'
information and assessment of posture may be collected, processed or information and assessment of posture may be collected, processed or
assessed. The core components are shown in Figure 1. Three main assessed. Three main functional components are defined: a Posture
functional components are defined: a Posture Assessment Information Assessment Information Consumer (C), a Posture Assessment Information
Consumer (C), a Posture Assessment Information Provider (P) and a Provider (P), and a Controller (Cr) used to facilitate some of the
Control Plane (CP) used to facilitate some of the security functions security functions such as authentication and authorization and other
such as authentication and authorization and other metadata metadata functions.
functions.
+-----------------------------------+ +--------------------------------------+
| +-----------------------------------+ | +--------------------------------------+
| | +-----------------------------------+ | | +--------------------------------------+
| | | | | | | |
+-| | Posture Assessment | +-| | Posture Assessment |
+-| Information Consumer (C) | +-| Information Consumer (C) |
+-----------------------------------+ +--------------------------------------+
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
- - - - - - - - - d - - -
A | | || ||B | |C || ||A | a |B | |C
| | || || | | || || | t | | |
| | - - - - - - - a - | |
| | \ / \ / \ / \ / | |
| | \ / \ / \ / \ / | |
/|--------| |------------------------------------------------ |\ /|---------------------|\ | |
/ -------------------------------------------------------------- \ /|----/ \--------| d |--|\
/ Broker/Proxy/Repository: AuthZ, Directory, metadata/capability \ / / Controller (Cr) \ ctrl | a | \
\ [Control Plane (CP)] / \ \ [Broker/Proxy/Repository] / plane | t | /
\ -------------------------------------------------------------- / \|----\ /--------| a |--|/
\|--------| |------------------------------------------------ |/ \|---------------------|/ | |
A | | || ||B | |C / \ / \ | |
| | || || | | / \ / \ | |
- - - - - - - - - d - | |
\ / \ / \ / || ||A | a |B | |C
\ / \ / \ / || || | t | | |
+-----------------------------------+ - - - a - - -
| |-+ \ / \ / \ /
| Posture Assessment | | \ / \ / \ /
| Information Provider (P) | |-+ +------------------------------------+
| | | | | |-+
+-----------------------------------+ | | | Posture Assessment | |
+-----------------------------------+ | | Information Provider (P) | |-+
+-----------------------------------+ +------------------------------------+ | |
+------------------------------------+ |
+------------------------------------+
Simple Architectural Model Figure 1: Simple Architectural Model
The functional components in the proposed architecture are further 3.1. Component Roles
described in this section.
2.1. Posture Assessment Information Consumer An endpoint, as defined in [I-D.ietf-sacm-terminology], can function
in two primary ways: as the target of an assessment, and/or as a
functional component of the SACM architecture that can instantiate
one or more capabilities (see Section 4). Individual endpoints may
be a target endpoint, or a component, or both simultaneously.
Components can take on the role of Posture Assessment Information
Provider, Posture Assessment Information Consumer, and/or Controller.
3.1.1. Posture Assessment Information Provider
The Posture Assessment Information Provider (P or Provider) is the
component that contributes Posture Assessment Information and/or
Guidance either spontaneously or in response to a request. A
Provider can be a Posture Evaluator, Posture Collector, or an
application that has aggregated Posture Assessment Information that
can be shared.
The Provider implements the capabilities and functions that must be
handled to share or provide Posture Assessment information.
A Provider may provide information spontaneously, or in response to a
direct request from a Consumer. The information may be filtered or
truncated to provide a subset of the requested information to honor
the request. This truncation may be performed based on the
Consumer's request and/or the Provider's ability to filter. The
latter case may be due to security considerations (e.g. authorization
restrictions due to domain segregation, privacy, etc.).
The Provider may only be able to share the Posture Assessment
Information using a specific data model and protocol. It may use a
standard data model and/or protocol, a non-standard data model and/or
protocol, or any combination of standard and non-standard data models
and protocols. It may also choose to advertise its capabilities
through a metadata abstraction or through the use of the registration
function of the Controller (see Section 3.1.3) [QUESTION: Are these
different?].
The Provider must be authorized to provide the Posture Assessment
Information and further, be authorized to do so with the specific
data models and protocols.
3.1.2. Posture Assessment Information Consumer
As described in Section 2.2 of the SACM Use Cases As described in Section 2.2 of the SACM Use Cases
[I-D.ietf-sacm-use-cases], several usage scenarios are posed with [I-D.ietf-sacm-use-cases], several usage scenarios are posed with
different application types requesting posture assessment different application types requesting posture assessment
information. Whether it is a configuration verification system, a information. Whether it is a configuration verification system; a
checklist verification system, or a system for detecting posture checklist verification system; or a system for detecting posture
deviations, compliance or vulnerabilities, they all need to acquire deviations, compliance or vulnerabilities, they all need to acquire
information about Posture Assessment. Thus, the architectural information about Posture Assessment. Thus, the architectural
component to enable such requests is defined as a Posture Assessment component to enable such requests is defined as a Posture Assessment
Information Consumer (C or Consumer). Information Consumer (C or Consumer).
The Consumer defines the capabilities and functions that must be The Consumer implements the capabilities and functions that must be
handled in order to facilitiate a Posture Assessment Information handled in order to facilitate a Posture Assessment Information
Request. Requests can be either for a single posture attribute or a Request. Requests can be either for a single posture attribute or a
set of posture attributes where those attributes can be the raw set of posture attributes where those attributes can be the raw
information or an evaluated or assessed state based upon that information or an evaluated or assessed state based upon that
information. The Consumer may further choose to query for the information. The Consumer may further choose to query for the
information directly (one-time query), or to request for updates to information directly (one-time query), or to request for updates to
be provided as the Posture Assessment Information changes be provided as the Posture Assessment Information changes
(Subscription). A request could be made directly to an explicitly (subscription). A request could be made directly to an explicitly
identified Posture Assessment Information Provider (P or Provider), identified Posture Assessment Information Provider (P or Provider),
but a Consumer may also desire to obtain the information without but a Consumer may also desire to obtain the information without
having to know the available providers. having to know the available providers.
There may be instances where a Consumer may be requesting information There may be instances where a Consumer may be requesting information
from various Providers and due to its policy or application from various Providers and due to its policy or application
requirements may need to be better informed of the Providers and requirements may need to be better informed of the Providers and
their capabilities. In those use cases, a Consumer may also request their capabilities. In those use cases, a Consumer may also request
to discover the respective capabilities of those Providers. to discover the respective capabilities of those Providers using the
discovery function of the Controller (see Section 3.1.3).
The Control Plane (described below) must authorize a Consumer to The Controller (described below) must authorize a Consumer to acquire
acquire the information it is requesting. The Consumer may also be the information it is requesting. The Consumer may also be subject
subject to limits or constraints on the numbers, types, sizes, and to limits or constraints on the numbers, types, sizes, and rate of
rate of requests. requests.
2.2. Posture Assessment Information Provider 3.1.3. Controller
The Posture Assessment Information Provider (P or Provider) is the The Controller (Cr) may be an independent endpoint, or an abstracted
component that contributes Posture Assessment Information either component running on an endpoint has multiple capabilities. The
spontaneously or in response to a request. A Provider can be a purpose of the Controller is to execute on security functions and
Posture Evaluator, Posture Collector, or an application that has overall system functions including:
aggregated Posture Assessment Information that can be shared.
The Provider defines the capabilities and functions that must be Authentication: The architecture must account for an abstraction
handled to share or provide Posture Assessment information. A where a Controller may be defined to affect the authentication of
Provider may provide the information spontaneously, or in response to Consumers and Providers independent of the actual information
a direct request from a Consumer. The information may be filtered or sharing communication channel. This supports use cases where:
truncated to honor the request either by the Consumer's request, or
the Providers's ability to filter (or provide only a subset of the
requested information) or due to security considerations (e.g.
authorization restrictions due to domain segregation, privacy, etc.).
The Provider may only be able to share the Posture Assessment * Consumers may request information independent of knowing the
Information using a specific data model and protocol. It may use a identities of the Providers.
standard data model and/or protocol, a non-standard data model and/or
protocol, or any combination of standard and non-standard data models
and protocols. It may also choose to advertise its capabilities
through a metadata abstraction.
The Provider must be authorized to provide the Posture Assessment * Providers may want to share the information without prior
Information and further, be authorized to do so with the specific solicitation.
data models and protocols.
2.3. Control Plane Authorization: To restrict how Posture Assessment Information is
shared between the Consumers and Providers. At minimum a management
function must define the necessary policies.
The Control Plane may be an abstracted component but is distinctly The introduction of the Controller supports use cases where:
defined as a component to execute on some of the security functions
and overall system functions. Some of the functions include:
Authentication: with use cases where Consumers may request * Consumer's may request information independent of knowing the
information independent of knowing the identities of the Providers identities of the Provider's
and Providers may want to share the information unsolicited, the
architecture must account for an abstraction where a control plane
or a broker may be defined to affect the authentication of the
Consumers and Providers independent of the actual information
sharing communication channel.
Authorization: to address security for how Posture Assessment * Providers may want to share information unsolicited
Information is shared between the Consumers and Providers, at
minimum a management function to define those policies are needed. The architecture must account for an abstraction where a Controller
However, with the introduction of the control plane with use cases may be defined to affect the authentication of the Consumers and
where R's may request information independent of knowing the Providers independent of the actual information sharing
identities of the P's and Providers (P's) wanting to share the communication channel.
information unsolicited, the architecture must account for an
abstraction where a control plane or a broker may be defined to
affect the authentication of the R's and P's independent of the
actual information sharing communication channel.
Identity Management: As typically, Identity Management for Identity Management: As typically, Identity Management for
authentication and authorization policies are best defined through a authentication and authorization policies are best defined through a
centralized component, the Control Plane also provides those centralized component, the Controller also provides these services.
services.
Discovery/Registration: a discovery mechanism is required to Registration/Discovery: A discovery mechanism is required to
facilitate the interaction of Providers that may have different facilitate the interaction of Providers that may have different
Posture Assessment Information and potentially limited (or a rich Posture Assessment Information and potentially limited (or a rich
set) of ways in which they can share the information; that is, set) of ways in which they can share the information. Through the
through the discovery mechanism Consumers can have visibility of the use of a discovery mechanism, Consumers can have visibility of the
Providers present and the type(s) of Posture Assessment Information Providers present and the type(s) of Posture Assessment Information
that is available and how it can be requested. Similarly, a that is available and how it can be requested. Similarly, a
Provider may need to register its "capability" for the Posture Provider may need to register what Posture Assessment Information it
Assessment Information it can share and how it can share it (e.g. can share and how it can share it (e.g. protocol or with filtering
protocol or with filtering capabilities). Enabling this function capabilities). Enabling this function through a Controller also
through a broker or control plane also allows for the distinct allows for the distinct definition of security considerations (e.g.
definition of security considerations (e.g. authorized registration authorized registration of capabilities and of Providers) beyond how
of capabilities and of Providers) beyond how a Provider may define a Provider may define its own capability.
its own capability.
The Control Plane also helps define how to manage an overall SACM These functions may be provided by a single component, or by multiple
system that allows for Consumers to obtain the desired Posture components. For example, an endpoint acting as a data store may also
Assessment Information without the need to distinctly know and act as its own broker.
establish a one (Consumers) to many (Provider) connections. Note
that the Control Plane also allows for the direct discovery and
connection between a Consumer and Provider.
2.4. Interfaces between Consumers, Providers and Control Plane The Controller also helps define how to manage an overall SACM system
that allows for Consumers to obtain the desired Posture Assessment
Information without the need to distinctly know and establish a one
(Consumer) to many (Provider) connections. Note that the Controller
also allows for the direct discovery and connection between a
Consumer and Provider.
3.2. Interfaces between Consumers, Providers, and Controllers
As shown in Figure 1, communication can proceed with the following As shown in Figure 1, communication can proceed with the following
interfaces and expected functions and behaviors: interfaces and expected functions and behaviors:
A: interface "A" shown in Figure 1 demonstrates the ability and A: interface "A" shown in Figure 1 handles the management and
control functions that are needed to establish, at minimum, a secure
communication between Consumers and Providers. The interface must
also handle the functions to allow for the discovery and
registration of the Providers as well as the ways in which Posture
Assessment Information can be provided (or requested).
B: interface "B" shown in Figure 1 enables Providers to share their
Posture Assessment Information spontaneously; similarly, it enables
Consumers to request information without having to know the
identities (or reachability) of all the Providers that can fulfill
Consumers' requests.
C: interface "C" shown in Figure 1 demonstrates the ability and
desire for Consumers and Providers to be able to communicate desire for Consumers and Providers to be able to communicate
directly when a Provider is sharing Posture Assessment Information directly when a Provider is sharing Posture Assessment Information
directly to a Consumer. The interface allows for the different data directly to a Consumer. The interface allows for the different data
models and protocols to be used between a Consumer and a Provider models and protocols to be used between a Consumer and a Provider
with the expectation that the appropriate authentication and with the expectation that the appropriate authentication and
authorization mechanisms have been employed to establish a secure authorization mechanisms have been employed to establish a secure
communication link between the Consumer and the Provider. communication link between the Consumer and the Provider.
Typically, it is expected that the secure link establishment occurs Typically, it is expected that the secure link establishment occurs
as a management or control function through the abstracted control as a management or control function through the abstracted
plane component (e.g. the control plane could be a proxy or could be Controller role (e.g. the Controller could be a proxy or could be
embedded in a Consumer or a Provider). embedded in a Consumer or a Provider).
B: interface "B" shown in Figure 1 handles the management and TODO - add text around the usage of various protocols for endpoint
control functions that are needed to establish, at minimum, a secure data collection (SNMP, NETCONF, etc.?)
communication between Consumers and Providers. The interface must
also handle the functions to allow for the discovery and
registration of the Providers as well as the ways in which Posture
Assessment Information can be provided (or requested).
C: interface "C" shown in Figure 1 enables Providers to share their 4. Component Capabilities
Posture Assessment Information spontaneously; similarly, it enables
Consumers to request information without having to know the
identities (or reachability) of all the Providers that can fulfill
Consumers' requests.
3. Example mapping to SACM Architecture TODO: Intro text about capabilities
4.1. Control Plane Capabilities
TODO: Intro text about control plane capabilities
TODO: Determine whether broker, proxy, and repository need to be full
subsections or paragraphs in this section.
Broker: Intermediary negotiating connection between provider and
consumer.
Proxy: Intermediary negotiating on behalf of a consumer.
Repository: Intermediary receiving and storing data from a provider,
and providing stored data to a consumer.
4.2. Data Plane Capabilities
TODO: Intro text about data plane capabilities
4.2.1. Collector
A collector consumes Guidance and/or other Posture Assessment
Information; it provides Posture Assessment Information. Collectors
may be internal or external.
4.2.1.1. Internal Collector
TODO
4.2.1.2. External Collector
An external collector is a collector that observes endpoints from
outside. These collectors may be configured and operated to manage
assets for reasons including, but not limited to, posture assessment.
Collectors that are not primarily intended to support posture
assessment (e.g. intrusion detection systems) may still provide
information that speaks to endpoint posture (e.g. behavioral
information).
Examples:
o A RADIUS server whereby an endpoint has logged onto the network
o A network profiling system, which discovers and classifies network
nodes
o A Network Intrusion Detection System (NIDS) sensor
o A vulnerability scanner
o A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine
o A management system that configures and installs software on the
endpoint
4.2.1.3. Collector Interactions With Target Endpoints
TODO
4.2.2. Evaluator
An evaluator consumes Posture Assessment Information, Evaluation
Results, and/or Guidance; it provides Evaluation Results. An
evaluator may consume endpoint attribute assertions, previous
evaluations of posture attributes, or previous reports of Evaluation
Results.
[kkw-i don't think this conflicts with the definition in the
terminology doc re: that evaluation tasks evaluate posture
attributes.]
[cek-I like the change. I think it *does* require a change in the
terminology doc, though.]
Example: a NEA posture validator [RFC5209]
[jmf- a NEA posture validator is not an example of this definition.
A NEA posture assessment is, maybe?]
[cek-Why isn't a NEA posture validator an example?]
4.2.3. Report Generator
A report generator consumes Posture Assessment Information,
Evaluation Results, and/or Guidance; it provides reports. These
reports are based on:
o Endpoint Attribute Assertions, including Evaluation Results
o Other Reports (a weekly report may be created from daily reports)
It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query.
4.2.4. Data Store
A data store consumes any data; it provides any data.
5. Example Illustration of Capabilities and Workflow
TODO: revise all this text
+-------------------------------+
| +-------------------------------+
| | |
+-| Controller (Cr) |
+-------------------------------+
// / \ \\
// / \ \\
A // / \ \\ A
// / \ \\
// / B B \ \\
// / \ \\
+-------------------------------+ +-------------------------------+
| +-------------------------------+ A | +-------------------------------+
| | |===========| | |
| | Posture Assessment |-----------| | Posture Assessment |
+-| Information Consumer (C) | C +-| Information Provider (P) |
+-------------------------------+ +-------------------------------+
Figure 2: Communications Model
SACM's focus is on the automation of collection, verification and SACM's focus is on the automation of collection, verification and
update of system security configurations pertaining to endpoint update of system security configurations pertaining to endpoint
assessment. In order to carry out these tasks, the architectural assessment. In order to carry out these tasks, the architectural
components shown in Figure 1 can be further refined as: components shown in Figure 1 can be further refined as:
Posture Assessment Information Provider: a Provider may be dedicated Posture Assessment Information Providers: a Provider may be
to perform either the collection, aggregation or evaluation of one dedicated to perform either the collection, aggregation or
or more posture attributes whose results can be conveyed to a evaluation of one or more posture attributes whose results can be
Posture Assessment Information Consumer. In this example form of conveyed to a Posture Assessment Information Consumer. In this
the SACM architecture model, these are shown as Collection, example form of the SACM architecture model, these are shown as
Evaluation and Results Providers. Note that there may be posture Collection, Evaluation, and Results Providers. Note that there may
attributes or posture assessment information that articulates be posture attributes or posture assessment information that
Guidance information which may or many not be present in the articulates Guidance information which may or may not be present in
architecture. the architecture.
Posture Assessment Information Consumer: a Consumer may request or Posture Assessment Information Consumers: a Consumer may request or
recieve one or more posture attributes or posture assessment receive one or more posture attributes or posture assessment
information from a Posture Assessment Information Provider for their information from a Posture Assessment Information Provider for their
own use. In this example form of the SACM architecture model, these own use. In this example form of the SACM architecture model, these
are shown as Collection, Evaluation and Results Consumers. Note are shown as Collection, Evaluation, and Results Consumers. Note
that there may be posture attributes or posture assessment that there may be posture attributes or posture assessment
information that articulates Guidance information which may or many information articulating Guidance information which may or may not
not be present in the architecture to be Provided or Consumed. be present in the architecture to be provided or consumed.
Repositories: a Repository stores one or more posture attributes or Data Stores: a Data Store is both a Provider and a Consumer, storing
assessments for endpoints. It should be understood that these one or more posture attributes or assessments for endpoints. It
repositories interface directly to a Provider or Consumer (and should be understood that these repositories interface directly to a
Guidance) but the interfaces used to interact between them is Provider or Consumer (and Guidance) but the interfaces used to
outside the scope of SACM (e.g. no interface arrows are shown in the interact between them is outside the scope of SACM (e.g. no
architecture). interface arrows are shown in the architecture).
Figure 2 illustrates an example flow for how posture information may Figure 3 illustrates an example flow for how Posture Assessment
flow. Information may flow.
+-------------+ +-------------+
|Evaluation | |Evaluation |
+-------------+ |Guidance +--+ +-------------+ |Guidance +--+
|Endpoint | |Capability | | |Endpoint | |Capability | |
+-------+ | +-------------+ | +-------+ | +-------------+ |
| | | | | | | |
| +-------+-----+ +-----v-------+ | +-------+-----+ +-----v-------+
| Collection | |Evaluation | | Collection | |Evaluation |
+-> Capability +--+--------+ |Capability | +-> Capability +--+--------+ |Capability |
| | |Collection | +-----------+ +----------+ | | |Collection | +-----------+ +----------+
| +------------+Producer | | |---| | | +------------+Provider | | |---| |
| | | |Collection | |Evaluation| | | | |Collection | |Evaluation|
| | | |Consumer | |Producer | | | | |Consumer | |Provider |
| +----+------+ +----^------+ +---+------+ | +----+------+ +----^------+ +---+------+
++---------+ | | | ++---------+ | | |
|Collection| +-----v------+ +---+--------+ | |Collection| +-----v------+ +---+--------+ |
|Guidance | | | |Collection | | |Guidance | | | |Collection | |
|Capability| |Collection | |Producer | | |Capability| |Collection | |Provider | |
| | |Consumer |-----| | | | | |Consumer |-----| | |
+----------+ +------------+ +------------+ | +----------+ +------------+ +------------+ |
| Collection | | | Collection | |
| Repository | | | Data Store | |
+------------+ | +------------+ |
| |
+--------------+ +---------------+ | +--------------+ +---------------+ |
|Evaluation | |Evaluation | | |Evaluation | |Evaluation | |
|Results | |Consumer <-----+ |Results | |Consumer <-----+
|Producer |-----------| | |Provider |-----------| |
+-----+--------+ +---------------+ +-----+--------+ +---------------+
| |Results Reporting| | |Results Reporting|
| |Capability | | |Capability |
| +------------^----+ | +------------^----+
| | | |
+-----v--------+ +----+------+ +-----v--------+ +----+------+
|Evaluation | |Reporting | |Evaluation | |Reporting |
|Results | |Guidance | |Results | |Guidance |
|Consumer | |Repository | |Consumer | |Data Store |
+---+----------+ +-----------+ +-------------+ +---+----------+ +-----------+ +-------------+
| | Results | | | Results |
+-----------------------------> Repository | +-----------------------------> Data Store |
| | | |
+-------------+ +-------------+
Example Posture Information Flow Figure 3: Example Posture Information Flow
4. Acknowledgements TODO - add example of / more content around interactions with
endpoint, possible communications patterns
The authors would like to thank Jessica Fitzgerald-McKay, Trevor 6. Acknowledgements
Freeman, Jim Bieda and Adam Montville for participating in the
architecture design discussions that lead to this draft.
5. IANA Considerations The authors would like to thank Jim Bieda, Henk Birkholz, Jessica
Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David
Waltermire for participating in architecture design discussions,
reviewing, and contributing to this draft.
7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
6. Security Considerations 8. Security Considerations
TBD. This section will need to cover the AAA and confidentiality/ TBD. This section will need to cover the AAA and confidentiality/
integrity of the data and data transports to be considered. Also, integrity of the data and data transports to be considered. Also,
the considerations for the interfaces (which may be covered in the considerations for the interfaces (which may be covered in
transports) between the Consumers, Providers, and the Control Plane. transports) between the Consumers, Providers, and the Controller.
7. References 9. References
7.1. Normative References 9.1. Normative References
[I-D.ietf-sacm-requirements]
Cam-Winget, N. and L. Lorenzin, "Secure Automation and
Continuous Monitoring (SACM) Requirements", draft-ietf-
sacm-requirements-02 (work in progress), October 2014.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., and N. Cam- Waltermire, D., Montville, A., Harrington, D., and N. Cam-
Winget, "Terminology for Security Assessment", draft-ietf- Winget, "Terminology for Security Assessment", draft-ietf-
sacm-terminology-05 (work in progress), August 2014. sacm-terminology-05 (work in progress), August 2014.
[I-D.ietf-sacm-use-cases] [I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf- Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-07 (work in progress), April 2014. sacm-use-cases-07 (work in progress), April 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 9.2. Informative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January Information Models and Data Models", RFC 3444, January
2003. 2003.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008. Requirements", RFC 5209, June 2008.
Authors' Addresses Authors' Addresses
 End of changes. 56 change blocks. 
234 lines changed or deleted 428 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/