draft-ietf-sacm-architecture-02.txt   draft-ietf-sacm-architecture-03.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: July 7, 2015 Pulse Secure Expires: September 10, 2015 Pulse Secure
I. McDonald I. McDonald
High North Inc High North Inc
A. Woland A. Woland
Cisco Systems Cisco Systems
January 3, 2015 March 9, 2015
Secure Automation and Continuous Monitoring (SACM) Architecture Secure Automation and Continuous Monitoring (SACM) Architecture
draft-ietf-sacm-architecture-02 draft-ietf-sacm-architecture-03
Abstract Abstract
This document defines the SACM reference architecture for This document defines a reference architecture for standardization of
standardization of interfaces, protocols and information models interfaces, protocols, and information models related to security
related to security automation and continuous monitoring. It automation and continuous monitoring. It describes the basic
describes the basic architecture, components and their interfaces architecture, components, and their interfaces defined to enable the
defined to enable the collection, acquisition and verification of collection, acquisition, and verification of Posture and Posture
Posture and Posture Assessments. Assessments.
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 July 7, 2015. This Internet-Draft will expire on September 10, 2015.
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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3
3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 4 3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Posture Assessment Information Provider . . . . . . . 5 3.1.1. Posture Assessment Information Provider . . . . . . . 5
3.1.2. Posture Assessment Information Consumer . . . . . . . 5 3.1.2. Posture Assessment Information Consumer . . . . . . . 5
3.1.3. Controller . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Controller . . . . . . . . . . . . . . . . . . . . . 6
3.2. Interfaces between Consumers, Providers, and Controllers 8 3.2. Interfaces between Consumers, Providers, and Controllers 8
4. Component Capabilities . . . . . . . . . . . . . . . . . . . 9 4. Component Capabilities . . . . . . . . . . . . . . . . . . . 9
4.1. Control Plane Capabilities . . . . . . . . . . . . . . . 9 4.1. Control Plane Capabilities . . . . . . . . . . . . . . . 9
4.2. Data Plane Capabilities . . . . . . . . . . . . . . . . . 9 4.2. Data Plane Capabilities . . . . . . . . . . . . . . . . . 10
4.2.1. Collector . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Collector . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Internal Collector . . . . . . . . . . . . . . . 9 4.2.1.1. Internal Collector . . . . . . . . . . . . . . . 10
4.2.1.2. External Collector . . . . . . . . . . . . . . . 9 4.2.1.2. External Collector . . . . . . . . . . . . . . . 10
4.2.1.3. Collector Interactions With Target Endpoints . . 10 4.2.1.3. Collector Interactions With Target Endpoints . . 11
4.2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Report Generator . . . . . . . . . . . . . . . . . . 10 4.2.3. Report Generator . . . . . . . . . . . . . . . . . . 11
4.2.4. Data Store . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. Data Store . . . . . . . . . . . . . . . . . . . . . 12
5. Example Illustration of Capabilities and Workflow . . . . . . 11 5. Example Illustration of Capabilities and Workflow . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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 of 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.
[NCW]This is a very broad problem statement that am not sure belongs
in the Architecture specification. Why does the charter not suffice?
What is the purpose of inserting this section in this draft?
3. Architectural Overview 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,
assessed. Three main functional components are defined: a Posture assessed, exchanged, and/or stored. Three main functional components
Assessment Information Consumer (Cs), a Posture Assessment are defined: a Posture Assessment Information Consumer (Cs), a
Information Provider (P), and a Controller (Cr) used to facilitate Posture Assessment Information Provider (P), and a Controller (Cr)
some of the security functions such as authentication and used to facilitate some of the security functions such as
authorization and other metadata functions. authentication and authorization and other metadata functions.
+--------------------------------------+ +--------------------------------------+
| +--------------------------------------+ | +--------------------------------------+
| | +--------------------------------------+ | | +--------------------------------------+
| | | | | | | |
+-| | Posture Assessment | +-| | Posture Assessment |
+-| Information Consumer (Cs) | +-| Information Consumer (Cs) |
+--------------------------------------+ +--------------------------------------+
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
skipping to change at page 4, line 49 skipping to change at page 4, line 49
+------------------------------------+ | +------------------------------------+ |
+------------------------------------+ +------------------------------------+
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 function 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 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 capabilities (see Section 4). Individual endpoints may one or more capabilities (see Section 4). In the SACM architecture,
be a target endpoint, or a component, or both simultaneously. individual endpoints may be a target endpoint, or a component, or
Components can take on the role of Posture Assessment Information both simultaneously. An endpoint acting as a component may perform
Provider, Posture Assessment Information Consumer, and/or Controller. one or more roles. Components can take on the role(s) of Posture
Assessment Information Provider, Posture Assessment Information
Consumer, and/or Controller.
3.1.1. Posture Assessment Information Provider 3.1.1. Posture Assessment Information Provider
The Posture Assessment Information Provider (P or Provider) is the The Posture Assessment Information Provider (P or Provider) is the
component that contributes Posture Assessment Information and/or component that contributes Posture Assessment Information and/or
Guidance either spontaneously or in response to a request. A Guidance either spontaneously or in response to a request. A
Provider can be a Posture Evaluator, Posture Collector, or an Provider can be a Posture Evaluator, Posture Collector, Data Store
application that has aggregated Posture Assessment Information that (see Section 4.2), or an application that has aggregated Posture
can be shared. Assessment Information that can be 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 A Provider may provide information spontaneously, or in response to a
direct request from a Consumer. The information may be filtered or direct request from a Consumer. The information may be filtered or
truncated to provide a subset of the requested information to honor truncated to provide a subset of the requested information to honor
the request. This truncation may be performed based on the the request. This truncation may be performed based on the
Consumer's request and/or the Provider's ability to filter. The Consumer's request and/or the Provider's ability to filter. The
latter case may be due to security considerations (e.g. authorization latter case may be due to security considerations (e.g. authorization
restrictions due to domain segregation, privacy, etc.). 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. It may also choose to advertise its capabilities and protocols. It may also choose to advertise its capabilities
through a metadata abstraction within the data model itself, or through a metadata abstraction within the data model itself, or
through the use of the registration function of the Controller (see through the use of the registration function of the Controller (see
Section 3.1.3) [QUESTION: Are these different?]. Section 3.1.3).
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 the specific Information and further, be authorized to do so with specific data
data models and protocols. models and protocols and/or for specific consumers.
3.1.2. Posture Assessment Information Consumer 3.1.2. Posture Assessment Information Consumer
The Posture Assessment Information Consumer (C or Consumer) is the
component that requests or accepts Posture Assessment Information
and/or Guidance. A Consumer can be a Posture Evaluator, Report
Generator, Data Store (see Section 4.2), or an application that
consumes Posture Assessment Information in order to 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. Thus, the architectural information about Posture Assessment. The architectural component
component to enable such requests is defined as a Posture Assessment performing such requests is a Consumer.
Information Consumer (C or Consumer).
The Consumer implements the capabilities and functions that must be The Consumer implements the capabilities and functions that must be
handled in order to facilitate 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; 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 Provider, but a Consumer may also desire to obtain the
but a Consumer may also desire to obtain the information without 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 using the to discover the respective capabilities of those Providers using the
discovery function of the Controller (see Section 3.1.3). discovery function of the Controller (see Section 3.1.3) or may
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. Controller 3.1.3. Controller
The Controller is a component defined to facilitate information The Controller (Cr or Controller) is a component defined to
brokering or proxing and to execute on security functions and overall facilitate information sharing and to execute on security functions
SACM management and control system functions including: and overall SACM management and control system functions including:
Authentication: The architecture must account for an abstraction Authentication: The authentication of Consumers and Providers
where a Controller may be defined to affect the authentication of independent of the actual information-sharing communication channel.
Consumers and Providers independent of the actual information This supports use cases where:
sharing communication channel. This supports 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.
Authorization: To restrict how Posture Assessment Information is The architecture must account for an abstraction where a Controller
shared between the Consumers and Providers. At minimum a management may be defined to effect the authentication of the Consumers and
function must define the necessary policies. Providers independent of the actual information-sharing
communication channel.
The introduction of the Controller supports use cases where:
* Consumer's may request information independent of knowing the Authorization: The restriction of Posture Assessment Information
identities of the Provider's sharing between the Consumers and Providers. At minimum, a
management function must define the necessary policies.
* Providers may want to share information unsolicited Identity Management: Since Identity Management for authentication
and authorization policies is best performed via a centralized
component, the Controller also facilitates this function.
The architecture must account for an abstraction where a Controller The Controller needs to be able to identify the endpoints
may be defined to affect the authentication of the Consumers and participating as SACM components and the roles that they play.
Providers independent of the actual information sharing Similar to how access control may be effected via Authentication,
communication channel. Authorization, and Accounting Systems (e.g. AAA services), the same
principle is defined; as AAA services depend on Identity Management
services, the Controller will need a similar function and interface
to Identity Management services.
Identity Management: As typically, Identity Management for Registration/Discovery: The discovery of what Providers are
authentication and authorization policies are best defined through a available, what information a Provider can share, and how it can be
centralized component, the Controller also provides these services. requested / communicated. A discovery mechanism is required to
facilitate interaction with Providers that may have different
Posture Assessment Information and potentially limited, or a rich
set of, ways in which they can share the information.
Registration/Discovery: A discovery mechanism is required to Through the use of a discovery mechanism, Consumers can have
facilitate the interaction of Providers that may have different visibility into the Providers present, the type(s) of Posture
Posture Assessment Information and potentially limited (or a rich Assessment Information available, and how it can be requested.
set) of ways in which they can share the information. Through the Similarly, a Provider may need to publish what Posture Assessment
use of a discovery mechanism, Consumers can have visibility of the Information it can share and how it can share it (e.g. protocol,
Providers present and the type(s) of Posture Assessment Information filtering capabilities, etc.). Enabling this function through a
that is available and how it can be requested. Similarly, a Controller or through metadata publication also allows for the
Provider may need to register what Posture Assessment Information it distinct definition of security considerations (e.g. authorized
can share and how it can share it (e.g. protocol or with filtering registration / publication of capabilities by Providers) beyond how
capabilities). Enabling this function through a Controller also
allows for the distinct definition of security considerations (e.g.
authorized registration of capabilities and of Providers) beyond how
a Provider may define its own capability. a Provider may define its own capability.
Broker/Proxy: beyond the control and management functions for the Beyond the control and management functions for the SACM system, a
SACM system, a Controller may also provide the proxy or broker (and Controller may also provide proxy or broker or repository (and
possibly routing) function in the data plane. In the deployment possibly routing) capabilities in the data plane (see Section 4.1).
scenario where Providers do not assert the need to know its In the deployment scenario where Providers do not assert the need to
Consumers and/or vice versa, the Controller can provide the know their Consumers and/or vice versa, the Controller can thus
appropriate functions to ensure the Posture Assessment Information provide the appropriate functions to ensure the Posture Assessment
is appropriately communicated from the Providers to the authorized Information is appropriately communicated from the Providers to the
Consumers. authorized Consumers.
Data Store: as a broker, the Controller may also include data stores
to affect the appropriate buffering, aggregation or filtering as
required to deliver the data as communicated from the Provider to
the Consumer.
The Controller, acting as a management control plane, helps define The Controller, acting as a management control plane, helps define
how to manage an overall SACM system that allows for Consumers to how to manage an overall SACM system that allows for Consumers to
obtain the desired Posture Assessment Information without the need to obtain the desired Posture Assessment Information without the need to
distinctly know and establish a one (Consumer) to many (Provider) distinctly know and establish one (Consumer) to many (Provider)
connections. Similarly, a Provider may not need to distinctly know connections. Similarly, a Provider may not need to distinctly know
and establish a one (Provider) to many Consumer) connections; e.g. and establish one (Provider) to many (Consumer) connections; e.g. the
Controller enables the means to allow a SACM system to support many
the Controller enables the means to allow a SACM system to support to many connections. Note that the Controller also allows for the
many to many connections. Note that the Controller also allows for direct discovery and connection between a Consumer and Provider.
the direct discovery and connection between a Consumer and Provider.
As a SACM component, the Controller may be instantiated within the As a SACM component, the Controller may be instantiated within a
same system or device acting as a Provider, Consumer (or both) or as system or device acting as a Provider or a Consumer (or both), or as
its own distinct Controller entity. In a rich SACM environment, it its own distinct Controller entity. In a rich SACM environment, it
is feasible to instantiate a Controller that provides both the is feasible to instantiate a Controller that provides both the
management (and control) functions for SACM as well as provide the management (and control) functions for SACM as well as provide the
proxying, brokering or routing functions for the actual data, e.g. proxying, brokering, and/or repository capabilities for the actual
Posture Assessment Information flow. Note that Controllers may be data, e.g. Posture Assessment Information flow. Note that
implemented to only provide the management and control functions or Controllers may be implemented to only provide the management and
only the data proxy/broker function or both. control functions or only the data flow capabilities or both.
3.2. Interfaces between Consumers, Providers, and Controllers 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 handles the management and A: interface "A" shown in Figure 1 handles the management and
control functions that are needed to establish, at minimum, a secure control functions that are needed to establish, at minimum, a secure
communication between Consumers and Providers. The interface must communication between Consumers and Providers. The interface must
also handle the functions to allow for the discovery and also handle the functions to allow for the discovery and
registration of the Providers as well as the ways in which Posture registration of the Providers as well as the ways in which Posture
Assessment Information can be provided (or requested). Assessment Information can be provided (or requested).
B: interface "B" shown in Figure 1 enables Providers to share their B: interface "B" shown in Figure 1 enables Providers to share their
Posture Assessment Information spontaneously; similarly, it enables Posture Assessment Information spontaneously; similarly, it enables
Consumers to request information without having to know the Consumers to request information without having to know the
identities (or reachability) of all the Providers that can fulfill identities (or reachability) of all the Providers that can fulfill
Consumers' requests. Consumers' requests.
C: interface "C" shown in Figure 1 demonstrates the ability and C: interface "C" shown in Figure 1 illustrates 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 as a management or control function through the abstracted
Controller role (e.g. the Controller could be a proxy or could be Controller role (e.g. the Controller could be a broker or could be
embedded in a Consumer or a Provider). embedded in a Consumer or a Provider).
TODO - add text around the usage of various protocols for endpoint A variety of protocols, such as SNMP, NETCONF, NEA protocols
data collection (SNMP, NETCONF, etc.?) [RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. Those interfaces are outside the scope of SACM.
4. Component Capabilities 4. Component Capabilities
TODO: Intro text about capabilities SACM components offer a variety of capabilities which may be
instantiated on a single endpoint or on separate standalone endpoints
providing various roles.
4.1. Control Plane Capabilities 4.1. Control Plane Capabilities
TODO: Intro text about control plane capabilities Control plane capabilities represent various services offered by the
Controller to the Providers and Consumers to facilitate sharing of
information. A Controller may have Broker, Proxy, or Repository
capabilities, or any combination thereof.
TODO: Determine whether broker, proxy, and repository need to be full Broker: Intermediary negotiating connection between Provider and
subsections or paragraphs in this section. Consumer. A Controller acting as a Broker:
Broker: Intermediary negotiating connection between provider and * Receives a request for information from a Consumer and instructs
consumer. the Consumer where and how retrieve the requested information.
Proxy: Intermediary negotiating on behalf of a consumer. * Receives a publication request from a Provider and instructs the
Provider where and how to deliver the published information.
Repository: Intermediary receiving and storing data from a provider, The information itself is neither distributed nor stored by the
and providing stored data to a consumer. Controller.
Proxy: Intermediary negotiating on behalf of a Consumer or Provider.
A Controller acting as a Proxy:
* Receives a request for information from a Consumer, retrieves the
information from the appropriate Providers, and provides the
information to the Consumer.
* Receives a publication request from a Provider, accepts the
published information, and distributes it to appropriate
consumers.
The information itself is distributed by, but not stored by, the
Controller.
Repository: Intermediary receiving and storing data from a Provider,
and providing stored data to a Consumer. A Controller acting as a
Repository:
* Receives a request for information from a Consumer, retrieves the
information from its data stores, and provides the information to
the Consumer.
* Receives a publication request from a provider, stores the
published information, and distributes it to appropriate
Consumers.
The information itself is both handled by and stored by the
Controller.
4.2. Data Plane Capabilities 4.2. Data Plane Capabilities
TODO: Intro text about data plane capabilities Data plane capabilities represent the ability of a Provider or
Consumer to perform a SACM-related task. For example, the Collector
capability indicates that a Provider can perform Collection tasks;
the Evaluator capability indicates that a Consumer can perform
Evaluation tasks.
4.2.1. Collector 4.2.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.
4.2.1.1. Internal Collector 4.2.1.1. Internal Collector
TODO An internal collector is a collector that runs on the endpoint and
collects posture information locally.
4.2.1.2. External Collector 4.2.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
assets for reasons including, but not limited to, posture assessment. assets for reasons including, but not limited to, posture assessment.
Collectors that are not primarily intended to support posture Collectors that are not primarily intended to support posture
assessment (e.g. intrusion detection systems) may still provide assessment (e.g. intrusion detection systems) may still provide
information that speaks to endpoint posture (e.g. behavioral information that speaks to endpoint posture (e.g. behavioral
information). information).
Examples: Examples:
o A RADIUS server whereby an endpoint has logged onto the network o A RADIUS server, which collects information about which endpoints
o A network profiling system, which discovers and classifies network have logged onto the network
nodes
o A Network Intrusion Detection System (NIDS) sensor o A network profiling system, which collects information by
discovering and classifying network nodes
o A vulnerability scanner o A Network Intrusion Detection System (NIDS) sensor, which collects
information about endpoint behavior by observing network traffic
o A hypervisor that peeks into the endpoint, the endpoint being a o A vulnerability scanner, which collects information about endpoint
virtual machine configuration by scanning endpoints
o A hypervisor, which collects information about endpoints running
as virtual guests in its host environment
o A management system that configures and installs software on the o A management system that configures and installs software on the
endpoint endpoint, which collects information based on its provisioning
activities
4.2.1.3. Collector Interactions With Target Endpoints 4.2.1.3. Collector Interactions With Target Endpoints
TODO TODO - examples of endpoint interactions with local internal
collector (e.g. NEA client), endpoint with remote internal collector
(SNMP query), and external collector (sensor)
4.2.2. Evaluator 4.2.2. Evaluator
An evaluator consumes Posture Assessment Information, Evaluation An evaluator consumes Posture Assessment Information, Evaluation
Results, and/or Guidance; it provides Evaluation Results. An Results, and/or Guidance; it provides Evaluation Results. An
evaluator may consume endpoint attribute assertions, previous evaluator may consume endpoint attribute assertions, previous
evaluations of posture attributes, or previous reports of Evaluation evaluations of posture attributes, or previous reports of Evaluation
Results. Results.
[kkw-i don't think this conflicts with the definition in the TODO: update the terminology doc to reflect this definition
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] Example: a NEA posture validator [RFC5209]
[jmf- a NEA posture validator is not an example of this definition. [jmf- a NEA posture validator is not an example of this definition.
A NEA posture assessment is, maybe?] A NEA posture assessment is, maybe?]
[cek-Why isn't a NEA posture validator an example?] [cek-Why isn't a NEA posture validator an example?]
4.2.3. Report Generator 4.2.3. Report Generator
A report generator consumes Posture Assessment Information, A report generator consumes Posture Assessment Information,
Evaluation Results, and/or Guidance; it provides reports. These Evaluation Results, and/or Guidance; it provides reports. These
reports are based on: reports are based on:
o Endpoint Attribute Assertions, including Evaluation Results o Endpoint Attribute Assertions, including Evaluation Results
o Other Reports (a weekly report may be created from daily reports) o Other Reports (e.g., a weekly report may be created from daily
reports)
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.
4.2.4. Data Store 4.2.4. Data Store
A data store consumes any data; it provides any data. A data store consumes any data; it provides any data.
5. Example Illustration of Capabilities and Workflow 5. Example Illustration of Capabilities and Workflow
TODO: revise all this text TODO: once the group reaches consensus on content for the previous
sections, revise all this text based upon the agreed-upon
architecture
+-------------------------------+ +-------------------------------+
| +-------------------------------+ | +-------------------------------+
| | | | | |
+-| Controller (Cr) | +-| Controller (Cr) |
+-------------------------------+ +-------------------------------+
// / \ \\ // / \ \\
// / \ \\ // / \ \\
A // / \ \\ A A // / \ \\ A
// / \ \\ // / \ \\
// / B B \ \\ // / B B \ \\
// / \ \\ // / \ \\
+-------------------------------+ +-------------------------------+ +------------------------+ +------------------------+
| +-------------------------------+ A | +-------------------------------+ | +----------------------+ A | +------------------------+
| | |===========| | | | | |===========| | |
| | Posture Assessment |-----------| | Posture Assessment | | | Consumer (C) |-----------| | Provider (P) |
+-| Information Consumer (C) | C +-| Information Provider (P) | +-| | C +-| |
+-------------------------------+ +-------------------------------+ +---------------------+ +------------------------+
Figure 2: Communications Model 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 Providers: a Provider may be Posture Assessment Information Providers: a Provider may be
dedicated to perform either the collection, aggregation or dedicated to perform either the collection, aggregation or
skipping to change at page 13, line 5 skipping to change at page 14, line 5
Data Stores: a Data Store is both a Provider and a Consumer, storing Data Stores: a Data Store is both a Provider and a Consumer, storing
one or more posture attributes or assessments for endpoints. It one or more posture attributes or assessments for endpoints. It
should be understood that these repositories interface directly to a should be understood that these repositories interface directly to a
Provider or Consumer (and Guidance) but the interfaces used to Provider or Consumer (and Guidance) but the interfaces used to
interact between them is outside the scope of SACM (e.g. no interact between them is outside the scope of SACM (e.g. no
interface arrows are shown in the architecture). interface arrows are shown in the architecture).
Figure 3 illustrates an example flow for how Posture Assessment Figure 3 illustrates an example flow for how Posture Assessment
Information may flow. Information may flow.
+-------------+ +-------------+
|Evaluation | |Evaluation |
+-------------+ |Guidance +--+ +-------------+ |Guidance +--+
|Endpoint | |Capability | | |Endpoint | |Capability | |
+-------+ | +-------------+ | +-------+ | +-------------+ |
| | | | | | | |
| +-------+-----+ +-----v-------+ | +-------+-----+ +-----v-------+
| Collection | |Evaluation | | Collection | |Evaluation |
+-> Capability +--+--------+ |Capability | +-> Capability +--+--------+ |Capability |
| | |Collection | +-----------+ +----------+ | | |Collection | +-----------+ +----------+
| +------------+Provider | | |---| | | +------------+Provider | | |---| |
| | | |Collection | |Evaluation| | | | |Collection | |Evaluation|
| | | |Consumer | |Provider | | | | |Consumer | |Provider |
| +----+------+ +----^------+ +---+------+ | +----+------+ +----^------+ +---+------+
++---------+ | | | ++---------+ | | |
|Collection| +-----v------+ +---+--------+ | |Collection| +-----v------+ +---+--------+ |
|Guidance | | | |Collection | | |Guidance | | | |Collection | |
|Capability| |Collection | |Provider | | |Capability| |Collection | |Provider | |
| | |Consumer |-----| | | | | |Consumer |-----| | |
+----------+ +------------+ +------------+ | +----------+ +------------+ +------------+ |
| Collection | | | Collection | |
| Data Store | | | Data Store | |
+------------+ | +------------+ |
| |
+--------------+ +---------------+ | +--------------+ +---------------+ |
|Evaluation | |Evaluation | | |Evaluation | |Evaluation | |
|Results | |Consumer <-----+ |Results | |Consumer <-----+
|Provider |-----------| | |Provider |-----------| |
+-----+--------+ +---------------+ +-----+--------+ +---------------+
| |Results Reporting| | |Results Reporting|
| |Capability | | |Capability |
| +------------^----+ | +------------^----+
| | | |
+-----v--------+ +----+------+ +-----v--------+ +----+------+
|Evaluation | |Reporting | |Evaluation | |Reporting |
|Results | |Guidance | |Results | |Guidance |
|Consumer | |Data Store | |Consumer | |Data Store |
+---+----------+ +-----------+ +-------------+ +---+----------+ +-----------+ +-------------+
| | Results | | | Results |
+-----------------------------> Data Store | +-----------------------------> Data Store |
| | | |
+-------------+ +-------------+
Figure 3: Example Posture Information Flow Figure 3: Example Posture Information Flow
TODO - add example of / more content around interactions with TODO - add example of / more content around interactions with
endpoint, possible communications patterns endpoint, possible communications patterns
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Jim Bieda, Henk Birkholz, Jessica The authors would like to thank Jim Bieda, Henk Birkholz, Jessica
Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David
skipping to change at page 14, line 31 skipping to change at page 15, line 31
The SACM architecture defines three main components that interface The SACM architecture defines three main components that interface
with each other both for management and control (in the control with each other both for management and control (in the control
plane) and for the sharing of Posture Assessment Information. plane) and for the sharing of Posture Assessment Information.
Considerations for transitivity of trust between a Provider and Considerations for transitivity of trust between a Provider and
Consumer can be made if there is a well understood trust between the Consumer can be made if there is a well understood trust between the
Provider and the Controller and between the Consumer and Controller. Provider and the Controller and between the Consumer and Controller.
The trust must include strong mutual authentication, at minimum, The trust must include strong mutual authentication, at minimum,
between the Provider and Controller and between the Consumer and between the Provider and Controller and between the Consumer and
Controller. Controller.
To address potential Man-in-the-Middle (MiM) attacks, it is also To address potential Man-in-the-Middle (MitM) attacks, it is also
strongly recommended that the communications be secured to include strongly recommended that the communications be secured to include
replay protection and message integrity (e.g. transport integrity and replay protection and message integrity (e.g. transport integrity and
if required, data integrity). Similarly, to avoid potential message if required, data integrity). Similarly, to avoid potential message
tampering, confidentiality should also be provided. tampering, confidentiality should also be provided.
As the Controller provides the security functions for the SACM As the Controller provides the security functions for the SACM
system, the Controller should provide strong authorizations based on system, the Controller should provide strong authorizations based on
either or both business and regulatory policies to ensure that only either or both business and regulatory policies to ensure that only
authorized Consumers and obtaining Posture Assessment Information authorized Consumers and obtaining Posture Assessment Information
from authorized Providers. It is presumed that once authenticated from authorized Providers. It is presumed that once authenticated
skipping to change at page 15, line 14 skipping to change at page 16, line 14
the Provider, Consumer and Controller that may observe the interfaces the Provider, Consumer and Controller that may observe the interfaces
flowing through them. flowing through them.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-sacm-requirements] [I-D.ietf-sacm-requirements]
Cam-Winget, N. and L. Lorenzin, "Secure Automation and Cam-Winget, N. and L. Lorenzin, "Secure Automation and
Continuous Monitoring (SACM) Requirements", draft-ietf- Continuous Monitoring (SACM) Requirements", draft-ietf-
sacm-requirements-02 (work in progress), October 2014. sacm-requirements-03 (work in progress), January 2015.
[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., Cam-Winget,
Winget, "Terminology for Security Assessment", draft-ietf- N., Lu, J., Ford, B., and M. Kaeo, "Terminology for
sacm-terminology-05 (work in progress), August 2014. Security Assessment", draft-ietf-sacm-terminology-06 (work
in progress), February 2015.
[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-08 (work in progress), February 2015.
[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.
9.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.
 End of changes. 58 change blocks. 
201 lines changed or deleted 252 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/