draft-ietf-sacm-architecture-04.txt   draft-ietf-sacm-architecture-05.txt 
SACM N. Cam-Winget, Ed. SACM N. Cam-Winget, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Lorenzin Intended status: Informational L. Lorenzin
Expires: January 24, 2016 Pulse Secure Expires: April 18, 2016 Pulse Secure
I. McDonald I. McDonald
High North Inc High North Inc
A. Woland A. Woland
Cisco Systems Cisco Systems
July 23, 2015 October 16, 2015
Secure Automation and Continuous Monitoring (SACM) Architecture Secure Automation and Continuous Monitoring (SACM) Architecture
draft-ietf-sacm-architecture-04 draft-ietf-sacm-architecture-05
Abstract Abstract
This document defines an architecture for standardization of This document defines 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 interfaces defined to enable the architecture, components, and 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 40 skipping to change at page 1, line 40
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 January 24, 2016. This Internet-Draft will expire on April 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3
3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 5 3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Provider . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Provider . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Consumer . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Consumer . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Types of Providers and Controllers . . . . . . . . . 7 3.1.3. Types of Providers and Consumers . . . . . . . . . . 8
3.1.3.1. Collector . . . . . . . . . . . . . . . . . . . . 7 3.1.3.1. Collector . . . . . . . . . . . . . . . . . . . . 8
3.1.3.2. Evaluator . . . . . . . . . . . . . . . . . . . . 8 3.1.3.2. Evaluator . . . . . . . . . . . . . . . . . . . . 9
3.1.3.3. Report Generator . . . . . . . . . . . . . . . . 9 3.1.3.3. Report Generator . . . . . . . . . . . . . . . . 9
3.1.3.4. Data Store . . . . . . . . . . . . . . . . . . . 9 3.1.3.4. Data Store . . . . . . . . . . . . . . . . . . . 9
3.1.4. Controller . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Controller . . . . . . . . . . . . . . . . . . . . . 9
4. Interfaces between Consumers, Providers, and Controllers . . 11 4. Interfaces between Consumers, Providers, and Controllers . . 11
5. Component Functions . . . . . . . . . . . . . . . . . . . . . 12 5. Component Functions . . . . . . . . . . . . . . . . . . . . . 12
5.1. Control Plane Functions . . . . . . . . . . . . . . . . . 12 5.1. Control Plane Functions . . . . . . . . . . . . . . . . . 12
5.2. Data Plane Functions . . . . . . . . . . . . . . . . . . 13 5.2. Data Plane Functions . . . . . . . . . . . . . . . . . . 14
6. Component Capabilities . . . . . . . . . . . . . . . . . . . 13 6. Component Capabilities . . . . . . . . . . . . . . . . . . . 15
7. Example Illustration of Functions and Workflow . . . . . . . 13 7. Example Illustration of Functions and Workflow . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Several data models and protocols (including - but not limited to - Several data models and protocols (including - but not limited to -
NEA, TCG TNC, SCAP, SWIDs, XMPP, etc.) are in use today that allow NEA, TCG TNC, SCAP, SWIDs, XMPP, etc.) 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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
defined in [I-D.ietf-sacm-requirements]. The architecture described defined in [I-D.ietf-sacm-requirements]. The architecture described
enables standardized collection, acquisition, and verification of enables standardized collection, acquisition, and verification of
Posture and Posture Assessments. This architecture includes the Posture and Posture Assessments. This architecture includes the
components and interfaces that can be used to better identify the components and interfaces that can be used to better identify the
Information Model and type(s) of transport protocols needed for Information Model and type(s) of transport protocols needed for
communication. communication.
This document uses terminology defined in This document uses terminology defined in
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
1.1. Requirements Language
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 RFC 2119 [RFC2119].
When the words appear in lower case, their natural language meaning
is used.
2. Problem Statement 2. Problem Statement
Securing information and the systems that store, process, and Securing information and the systems that store, process, and
transmit that information is a challenging task for organizations of transmit that information is a challenging task for organizations of
all sizes, and many security practitioners spend much of their time all sizes, and many security practitioners spend much of their time
on manual processes. Administrators can't get technology from on manual processes. Administrators can't get technology from
disparate sources to work together; they need information to make disparate sources to work together; they need information to make
decisions, but the information is not available. Everyone is decisions, but the information is not available. Everyone is
collecting the same data, but storing it as different information. collecting the same data, but storing it as different information.
Administrators therefore need to collect data and craft their own Administrators therefore need to collect data and craft their own
information, which may not be accurate or interoperable because it's information, which may not be accurate or interoperable because it's
customized by each administrator, not shared. customized by each administrator, not shared.
Security automation and continuous monitoring require a large and Security automation and continuous monitoring require a large and
broad set of mission and business processes; to make the most broad set of mission and business processes; to make the most
effective of use of technology, the same data must support multiple effective use of technology, the same data must support multiple
processes. The need for complex characterization and assessment processes. The need for complex characterization and assessment
necessitates components and functions that interoperate and can build necessitates components and functions that interoperate and can build
off each other to enable far-ranging and/or deep-diving analysis. off each other to enable far-ranging and/or deep-diving analysis.
SACM is standardizing an information model, data models, operations, SACM is standardizing an information model, data models, operations,
and transports that will allow for administrators to share with and transports that will allow for administrators to share with
others and to use data from others interoperably. others and to use data from others interoperably.
3. Architectural Overview 3. Architectural Overview
At a high level, the SACM architecture describes "Where" and "How" At a high level, the SACM architecture describes "Where" and "How"
information and assessment of posture may be collected, processed information and assessment of posture may be collected, processed
(e.g. normalization, translation, aggregation, etc.), assessed, (e.g. normalization, translation, aggregation, etc.), assessed,
exchanged, and/or stored. This section provides an architectural exchanged, and/or stored. This section provides an architectural
overview of 1.) the basic architectural building blocks, which - in overview of
combination - constitute SACM components (the entities, the "where"),
and 2.) the relationships and interaction between these building o the basic architectural building blocks, which - in combination -
blocks on the data plane and control plane (communications and flows constitute SACM components (the entities, the "where"), and
between entities, the "how").
o the relationships and interaction between these building blocks on
the data plane and control plane (communications and flows between
entities, the "how").
The SACM architecture provides the basic means to describe and The SACM architecture provides the basic means to describe and
compose SACM components. Components enable the basic functionality compose SACM components. Components enable the basic functionality
in SACM, such as Endpoint Attribute Collection or Target Endpoint in SACM, such as Endpoint Attribute Collection or Target Endpoint
Posture Assessment. Posture Assessment.
The role(s) a component plays in the SACM architecture are determined The role(s) a component plays in the SACM architecture are determined
by the function(s) that component instantiates. Three main component by the function(s) that component instantiates. Three main component
roles are defined: a Consumer (C), a Provider (P), and a Controller roles are defined: a Consumer (Cs), a Provider (Pr), and a Controller
(Cr) used to facilitate some of the security functions such as (Cr) used to facilitate some of the security functions such as
authentication and authorization and other metadata functions. See authentication and authorization and other metadata functions. See
Section 3.1 for details on roles. Section 3.1 for details on roles.
In SACM, components are composed of functions, the modular building In SACM, components are composed of functions, the modular building
blocks in the SACM architecture. The SACM architecture defines the blocks in the SACM architecture. The SACM architecture defines the
purpose of these functions. Attributes and operations used by purpose of these functions. Attributes and operations used by
component functions are described in other SACM documents. See component functions are described in other SACM documents. See
Section 5 for details on component functions. Section 5 for details on component functions.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
enable SACM components to share information (via publication, query, enable SACM components to share information (via publication, query,
and subscription). Three primary interfaces are defined: an and subscription). Three primary interfaces are defined: an
interface for management and control (A), an interface for data interface for management and control (A), an interface for data
communication between the controller and providers or consumers (B), communication between the controller and providers or consumers (B),
and an interface for data communication directly between a provider and an interface for data communication directly between a provider
and a consumer (C). See Section 4 for details on interfaces. and a consumer (C). See Section 4 for details on interfaces.
Figure 1 illustrates the relationships between component roles and Figure 1 illustrates the relationships between component roles and
interfaces: interfaces:
+--------------------------------------+ +--------------------------------------+
| +--------------------------------------+ | +--------------------------------------+
| | +--------------------------------------+ | | +--------------------------------------+
| | | | | | | |
+-| | Consumer (C) | +-| | Consumer (Cs) |
+-| | +-| |
+--------------------------------------+ +--------------------------------------+
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
- - - d - - - - - - d - - -
|| ||A | a |B | |C || ||A | a |B | |C
|| || | t | | | || || | t | | |
- - - a - | | - - - a - | |
\ / \ / | | \ / \ / | |
\ / \ / | | \ / \ / | |
/|---------------------|\ | | /|---------------------|\ | |
/|----/ \--------| d |--|\ /|----/ \--------| d |--|\
/ / Controller (Cr) \ ctrl | a | \ / / Controller (Cr) \ ctrl | a | \
\ \ / plane | t | / \ \ / plane | t | /
\|----\ /--------| a |--|/ \|----\ /--------| a |--|/
\|---------------------|/ | | \|---------------------|/ | |
/ \ / \ | | / \ / \ | |
/ \ / \ | | / \ / \ | |
- - - d - | | - - - d - | |
|| ||A | a |B | |C || ||A | a |B | |C
|| || | t | | | || || | t | | |
- - - a - - - - - - a - - -
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
+------------------------------------+ +------------------------------------+
| |-+ | |-+
| Provider (P) | | | Provider (Pr | |
| | |-+ | | |-+
+------------------------------------+ | | +------------------------------------+ | |
+------------------------------------+ | +------------------------------------+ |
+------------------------------------+ +------------------------------------+
Figure 1: Simple Architectural Model Figure 1: Simple Architectural Model
3.1. Component Roles 3.1. Component Roles
An endpoint, as defined in [I-D.ietf-sacm-terminology], can operate An endpoint, as defined in [I-D.ietf-sacm-terminology], can operate
in two primary ways: as the target of an assessment, and/or as a in two primary ways: as the target of an assessment, and/or as a
functional component of the SACM architecture that can instantiate functional component of the SACM architecture that can instantiate
one or more functions (see Section 5). In the SACM architecture, one or more functions (see Section 5). In the SACM architecture,
individual endpoints may be a target endpoint, a component, or both individual endpoints may be a target endpoint, a component, or both
simultaneously. An endpoint acting as a component may perform one or simultaneously. An endpoint acting as a component may perform one or
more roles. Components can take on the role(s) of Provider, more roles. Components can take on the role(s) of Provider,
Consumer, and/or Controller. Consumer, and/or Controller.
3.1.1. Provider 3.1.1. Provider
The Provider (P or Provider) is the component that contributes The Provider (Pr) is the component that contributes Posture
Posture Assessment Information and/or Guidance either spontaneously Assessment Information and/or Guidance either spontaneously or in
or in response to a request. A Provider can be a Posture Evaluator, response to a request. A Provider can be a Posture Evaluator,
Posture Collector, Data Store (see Section 3.1.3), or an application Posture Collector, Data Store (see Section 3.1.3), or an application
that has aggregated Posture Assessment Information that can be that has aggregated Posture Assessment Information that can be
shared. shared.
The Provider implements the capabilities and functions that must be The Provider implements the capabilities and functions that must be
handled to share or provide Posture Assessment information. handled to share or provide Posture Assessment information.
A Provider may provide information spontaneously, or in response to a One means by which a Provider shares information, is in response to a
direct request from a Consumer. The information may be filtered or direct request from a Consumer.
truncated to provide a subset of the requested information to honor
the request. This truncation may be performed based on the A Provider may also share information spontaneously. Use cases such
Consumer's request and/or the Provider's ability to filter. The as the change in a posture state require that a Provider be able to
latter case may be due to security considerations (e.g. authorization provide such changes or updates especially to Consumers such as
restrictions due to domain segregation, privacy, etc.). Security Information and Event Management (SIEM) systems; similarly,
SIEM applications that are providing live information require any
such updates or changes to posture information to be provided
spontaneously. Authorization for the enabling for these unsolicited
messages happens through the Controller at the time that both
Provider and Consumers request authorization for (spontaneous)
messages.
The information provided, 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 The Provider may only be able to share the Posture Assessment
Information using a specific data model and protocol. It may use a 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 standard data model and/or protocol, a non-standard data model and/or
protocol, or any combination of standard and non-standard data models protocol, or any combination of standard and non-standard data models
and protocols. However, it must support either one or more standard and protocols. However, it must support either one or more standard
data models, or one or more standard protocols. It may also choose data models, or one or more standard protocols. It may also choose
to advertise its capabilities through a metadata abstraction within to advertise its capabilities through a metadata abstraction within
the data model itself, or through the use of the registration the data model itself, or through the use of the registration
function of the Controller (see Section 3.1.4). function of the Controller (see Section 3.1.4).
The Provider must be authorized to provide the Posture Assessment The Provider must be authorized to provide the Posture Assessment
Information and further, be authorized to do so with specific data Information for specific consumers.
models and protocols and/or for specific consumers.
3.1.2. Consumer 3.1.2. Consumer
The Consumer (C or Consumer) is the component that requests or The Consumer (Cs) is the component that requests or accepts Posture
accepts Posture Assessment Information and/or Guidance. A Consumer Assessment Information and/or Guidance. A Consumer can be a Posture
can be a Posture Evaluator, Report Generator, Data Store (see Evaluator, Report Generator, Data Store (see Section 5.2), or an
Section 5.2), or an application that consumes Posture Assessment application that consumes Posture Assessment Information in order to
Information in order to perform another function. perform another function.
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. The architectural component information about Posture Assessment. The architectural component
performing such requests is a Consumer. performing such requests is a Consumer.
skipping to change at page 7, line 39 skipping to change at page 8, line 5
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 using the to discover the respective capabilities of those Providers using the
discovery function of the Controller (see Section 3.1.4) or may discovery function of the Controller (see Section 3.1.4) or may
request metadata reflecting the capabilities of the Providers. request metadata reflecting the capabilities of the Providers.
The Controller (described below) must authorize a Consumer to acquire The Controller (described below) must authorize a Consumer to acquire
the information it is requesting. The Consumer may also be subject the information it is requesting. The Consumer may also be subject
to limits or constraints on the numbers, types, sizes, and rate of to limits or constraints on the numbers, types, sizes, and rate of
requests. requests.
3.1.3. Types of Providers and Controllers 3.1.3. Types of Providers and Consumers
SACM Providers and Consumers can perform a variety of SACM-related SACM Providers and Consumers can perform a variety of SACM-related
tasks. For example, a Collector can perform Collection tasks; an tasks. For example, a Collector can perform Collection tasks; an
Evaluator can perform Evaluation tasks. A single Provider or Evaluator can perform Evaluation tasks. A single Provider or
Consumer may be able to perform only one task, or multiple tasks. Consumer may be able to perform only one task, or multiple tasks.
SACM defines the following types of Providers/Consumers: SACM defines the following types of Providers/Consumers:
3.1.3.1. Collector 3.1.3.1. Collector
A collector consumes Guidance and/or other Posture Assessment A collector consumes Guidance and/or other Posture Assessment
Information; it provides Posture Assessment Information. Collectors Information; it provides Posture Assessment Information. Collectors
may be internal or external. may be internal or external. As a SACM component, a Collector may be
a Consumer as it may consume guidance information and may also be a
Provider as it may publish the collected information.
3.1.3.1.1. Internal Collector 3.1.3.1.1. Internal Collector
An internal collector is a collector that runs on the endpoint and An internal collector is a collector that runs on the endpoint and
collects posture information locally. collects posture information locally.
3.1.3.1.2. External Collector 3.1.3.1.2. External Collector
An external collector is a collector that observes endpoints from An external collector is a collector that observes endpoints from
outside. These collectors may be configured and operated to manage outside. These collectors may be configured and operated to manage
skipping to change at page 9, line 32 skipping to change at page 9, line 48
It may summarize data continually, as the data arrives. It also may It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query. summarize data in response to an ad hoc query.
3.1.3.4. Data Store 3.1.3.4. Data Store
A data store consumes any data; it provides any data. A data store consumes any data; it provides any data.
3.1.4. Controller 3.1.4. Controller
The Controller (Cr or Controller) is a component defined to The Controller (Cr or Controller) is a component defined to
facilitate information sharing and to execute on security functions facilitate the overall SACM management and control system functions.
and overall SACM management and control system functions. SACM This component is responsible for handling the secure communications
defines three types of Controller: establishment (such as the authentication and authorization) between
Providers and Consumers. In addition, the Controller may also handle
how the data may be routed. While the architecture defines the
Controller as a single component, implementations may implement this
to suit the different deployment and scaling requirements. In
particular, for the data handling, SACM defines three types of
Controller:
Broker: Intermediary negotiating connection between Provider and Broker: Intermediary negotiating connection between Provider and
Consumer. Implements only control plane functions. A Controller Consumer. Implements only control plane functions. A Controller
acting as a Broker: acting as a Broker:
* Receives a request for information from a Consumer and instructs * Receives a request for information from a Consumer and instructs
the Consumer where and how retrieve the requested information. the Consumer where and how retrieve the requested information.
* Receives a publication request from a Provider and instructs the * Receives a publication request from a Provider and instructs the
Provider where and how to deliver the published information. Provider where and how to deliver the published information.
The information itself is neither distributed nor stored by the * The information itself is neither distributed nor stored by the
Controller. Controller.
Proxy: Intermediary negotiating on behalf of a Consumer or Provider. Proxy: Intermediary negotiating on behalf of a Consumer or Provider.
Implements both control and data plane functions. A Controller Implements both control and data plane functions. A Controller
acting as a Proxy: acting as a Proxy:
* Receives a request for information from a Consumer, retrieves the * Receives a request for information from a Consumer, retrieves the
information from the appropriate Providers, and provides the information from the appropriate Providers, and provides the
information to the Consumer. information to the Consumer.
* Receives a publication request from a Provider, accepts the * Receives a publication request from a Provider, accepts the
published information, and distributes it to appropriate published information, and distributes it to appropriate
consumers. consumers.
The information itself is distributed by, but not stored by, the * The information itself is distributed by, but not stored by, the
Controller. Controller.
Repository: Intermediary receiving and storing data from a Provider, Repository: Intermediary receiving and storing data from a Provider,
and providing stored data to a Consumer. Implements both control and providing stored data to a Consumer. Implements both control
and data plane functions. A Controller acting as a Repository: and data plane functions. A Controller acting as a Repository:
* Receives a request for information from a Consumer, retrieves the * Receives a request for information from a Consumer, retrieves the
information from its data stores, and provides the information to information from its data stores, and provides the information to
the Consumer. the Consumer.
* Receives a publication request from a provider, stores the * Receives a publication request from a provider, stores the
published information, and distributes it to appropriate published information, and distributes it to appropriate
Consumers. Consumers.
The information itself is both handled by and stored by the * The information itself is both handled by and stored by the
Controller. Controller.
A single instantiation of a Controller may be a Broker, Proxy, or A single instantiation of a Controller may be a Broker, Proxy, or
Repository, or any combination thereof. Repository, or any combination thereof.
Through the use of a discovery mechanism, Consumers can have Through the use of a discovery mechanism, Consumers can have
visibility into the Providers present, the type(s) of Posture visibility into the Providers present, the type(s) of Posture
Assessment Information available, and how it can be requested. Assessment Information available, and how it can be requested.
Similarly, a Provider may need to publish what Posture Assessment Similarly, a Provider may need to publish what Posture Assessment
Information it can share and how it can share it (e.g. protocol, Information it can share and how it can share it (e.g. protocol,
filtering capabilities, etc.). Enabling this visibility through a filtering capabilities, etc.). Enabling this visibility through a
skipping to change at page 12, line 34 skipping to change at page 13, line 9
5.1. Control Plane Functions 5.1. Control Plane Functions
Control plane functions represent various services offered by the Control plane functions represent various services offered by the
Controller to the Providers and Consumers to facilitate sharing of Controller to the Providers and Consumers to facilitate sharing of
information. Control plane functions include, but are not limited information. Control plane functions include, but are not limited
to: to:
Authentication: The authentication of Consumers and Providers Authentication: The authentication of Consumers and Providers
independent of the actual information-sharing communication channel. independent of the actual information-sharing communication channel.
This supports use cases where: While authentication between peers (e.g. a Consumer and a Provider)
can be achieved directly through peer to peer authentication (using
TLS for instance), there are use cases where:
* Consumers may request information independent of knowing the * Consumers may request information independent of knowing the
identities of the Providers. identities of the Providers.
* Providers may want to share the information without prior * Providers may want to share the information without prior
solicitation. solicitation.
The architecture must account for an abstraction where a Controller To address the above use cases, the architecture must account for an
may be defined to effect the authentication of the Consumers and abstraction where a Controller may be defined to effect the
Providers independent of the actual information-sharing communication authentication of the Consumers and Providers independent of the
channel. actual information-sharing communication channel. Consumers and
Providers that consume or publish information without requiring
knowledge of the Providers and Consumers respectively would function
in a SACM system where the Controller is a distinct entity. As a
distinct SACM component, the Controller would authenticate Providers
and Consumers.
Authorization: The restriction of Posture Assessment Information Authorization: The restriction of Posture Assessment Information
sharing between the Consumers and Providers. At minimum, a sharing between the Consumers and Providers. At minimum, a
management function must define the necessary policies. management function must define the necessary policies to control
what Providers can publish and Consumers to accept. The Controller
is the authority for the type of Posture Information that a Provider
can publish and a Consumer can accept. If a Controller is a Broker,
then it may only grant authorization to the capabilities requested
by the Provider or Consumer. When acting as a Proxy, as part of its
authorization, the Controller may further obscure or block
information being shared by a Provider as it distributes it to a
Consumer. Similarly, a Repository may block information as recieved
by the Provider and pass to the Consumer and to its storage the
resulting authorized information. A Provider may also enforce its
own authorization based upon its connection to a Controller; though,
in the case where an application includes both the Provider and
Controller roles, it can choose to implement all authorization on
the Controller. Similarly, a Consumer may enforce its own
authorization of what data it can receive based on the Controller
(or Provider) it is communicaticating with; in the case where an
application includes both the Consumer and Controller roles, it can
choose to implement all the authorization on the Controller.
Identity Management: Since Identity Management for authentication Identity Management: Since Identity Management for authentication
and authorization policies is best performed via a centralized and authorization policies is best performed via a centralized
component, the Controller also facilitates this function. component, the Controller also facilitates this function.
The Controller needs to be able to identify the endpoints The Controller needs to be able to identify the endpoints
participating as SACM components and the roles that they play. participating as SACM components and the roles that they play.
Similar to how access control may be effected via Authentication, Similar to how access control may be effected via Authentication,
Authorization, and Accounting Systems (e.g. AAA services), the same Authorization, and Accounting Systems (e.g. AAA services), the
principle is defined; as AAA services depend on Identity Management same principle is defined; as AAA services depend on Identity
services, the Controller will need a similar function and interface Management services, the Controller will need a similar function
to Identity Management services. and interface to Identity Management services. Note that
implementations of this function is abstractly centralized, but to
address scalability and the need to manage different resources
(e.g. users, processes and devices) a distributed system that is
centrally coordinated may be used.
Registration/Discovery: The discovery of what Providers are Registration/Discovery: A SACM ecosystem needs to provide the
available, what information a Provider can share, and how it can be ability for devices to discover Providers, Consumers, Controllers
requested / communicated. A discovery mechanism is required to and their respective capabilities. For a Consumer to be able to
facilitate interaction with Providers that may have different obtain the information of interest must either configure itself to
Posture Assessment Information and potentially limited, or a rich know what Providers to communicate with directly (and their known
set of, ways in which they can share the information. capabilities, such as the supported data model and information
provided) or can dynamically discover the information that is
available. Similarly, Providers may need to either be configured to
know who to publish the information to, or can dynamically discover
its Consumers.
In the case where there is a Controller, the capabilities of the
Controller must also be advertised so that Providers and Consumers
may know how the data is being handled as well (e.g. if acting as a
Broker or Repository). The Controller also provides the function of
registering the Providers and Consumers; the registration function
enables the Controller to also affect the authorization afforded to
the Provider or Consumer.
5.2. Data Plane Functions 5.2. Data Plane Functions
Subscription There are three basic functions to facilitate data flow:
Publication Subscription: A Consumer that wants to recieve information from a
specific Provider or from the Controller advertising the
availability of specific information (that may come from more than
one Provider) will effectively subscribe to recieve the information
spontaneously and continuously as new information as subscribed to
becomes available.
Query Publication A Provider being registered through the Controller to
provide specific information, may publish the information either
directly to the Consumers or to the Controller that is acting as the
broker or respository.
Query/Response A Consumer may contact the Provider directly and
request the information through a query operation; and in response,
the Provider would send the information directly to the Consumer.
6. Component Capabilities 6. Component Capabilities
TODO: add a discussion of "capability" as being able to talk a TODO: add a discussion of "capability" as being able to talk a
specific data model, data operations, or SACM transport specific data model, data operations, or SACM transport
TODO: data plane capabilities / control plane capabilities can be TODO: data plane capabilities / control plane capabilities can be
discovered via querying the controller discovered via querying the controller
7. Example Illustration of Functions and Workflow 7. Example Illustration of Functions and Workflow
 End of changes. 31 change blocks. 
114 lines changed or deleted 200 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/