draft-ietf-sacm-architecture-01.txt   draft-ietf-sacm-architecture-02.txt 
SACM N. Cam-Winget, Ed. SACM N. Cam-Winget, Ed.
Internet-Draft B. Ford Internet-Draft Cisco Systems
Intended status: Informational Cisco Systems Intended status: Informational L. Lorenzin
Expires: May 23, 2015 L. Lorenzin Expires: July 7, 2015 Pulse Secure
Pulse Secure
I. McDonald I. McDonald
High North Inc High North Inc
A. Woland A. Woland
Cisco Systems Cisco Systems
November 19, 2014 January 3, 2015
Secure Automation and Continuous Monitoring (SACM) Architecture Secure Automation and Continuous Monitoring (SACM) Architecture
draft-ietf-sacm-architecture-01 draft-ietf-sacm-architecture-02
Abstract Abstract
This document describes an architecture for standardization of This document defines the SACM reference architecture for
interfaces, protocols and information models related to security standardization of interfaces, protocols and information models
automation and continuous monitoring. It describes the basic related to security automation and continuous monitoring. It
architecture, components and their interfaces defined to enable the describes the basic architecture, components and their interfaces
collection, acquisition and verification of Posture and Posture defined to enable the collection, acquisition and verification of
Assessments. Posture and Posture 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 May 23, 2015. This Internet-Draft will expire on July 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 21 skipping to change at page 2, line 20
Table of Contents Table of Contents
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 7 3.2. Interfaces between Consumers, Providers, and Controllers 8
4. Component Capabilities . . . . . . . . . . . . . . . . . . . 8 4. Component Capabilities . . . . . . . . . . . . . . . . . . . 9
4.1. Control Plane Capabilities . . . . . . . . . . . . . . . 8 4.1. Control Plane Capabilities . . . . . . . . . . . . . . . 9
4.2. Data Plane Capabilities . . . . . . . . . . . . . . . . . 9 4.2. Data Plane Capabilities . . . . . . . . . . . . . . . . . 9
4.2.1. Collector . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Collector . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1.1. Internal Collector . . . . . . . . . . . . . . . 9 4.2.1.1. Internal Collector . . . . . . . . . . . . . . . 9
4.2.1.2. External Collector . . . . . . . . . . . . . . . 9 4.2.1.2. External Collector . . . . . . . . . . . . . . . 9
4.2.1.3. Collector Interactions With Target Endpoints . . 9 4.2.1.3. Collector Interactions With Target Endpoints . . 10
4.2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Report Generator . . . . . . . . . . . . . . . . . . 10 4.2.3. Report Generator . . . . . . . . . . . . . . . . . . 10
4.2.4. Data Store . . . . . . . . . . . . . . . . . . . . . 10 4.2.4. Data Store . . . . . . . . . . . . . . . . . . . . . 11
5. Example Illustration of Capabilities and Workflow . . . . . . 10 5. Example Illustration of Capabilities and Workflow . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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
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 or
assessed. Three main functional components are defined: a Posture assessed. Three main functional components are defined: a Posture
Assessment Information Consumer (C), a Posture Assessment Information Assessment Information Consumer (Cs), a Posture Assessment
Provider (P), and a Controller (Cr) used to facilitate some of the Information Provider (P), and a Controller (Cr) used to facilitate
security functions such as authentication and authorization and other some of the security functions such as authentication and
metadata functions. authorization and other metadata functions.
+--------------------------------------+ +--------------------------------------+
| +--------------------------------------+ | +--------------------------------------+
| | +--------------------------------------+ | | +--------------------------------------+
| | | | | | | |
+-| | Posture Assessment | +-| | Posture Assessment |
+-| Information Consumer (C) | +-| Information Consumer (Cs) |
+--------------------------------------+ +--------------------------------------+
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
- - - d - - - - - - d - - -
|| ||A | a |B | |C || ||A | a |B | |C
|| || | t | | | || || | t | | |
- - - a - | | - - - a - | |
\ / \ / | | \ / \ / | |
\ / \ / | | \ / \ / | |
/|---------------------|\ | | /|---------------------|\ | |
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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 or through the use of the registration through a metadata abstraction within the data model itself, or
function of the Controller (see Section 3.1.3) [QUESTION: Are these through the use of the registration function of the Controller (see
different?]. Section 3.1.3) [QUESTION: Are these different?].
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 the specific
data models and protocols. data models and protocols.
3.1.2. Posture Assessment Information Consumer 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
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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).
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 (Cr) may be an independent endpoint, or an abstracted The Controller is a component defined to facilitate information
component running on an endpoint has multiple capabilities. The brokering or proxing and to execute on security functions and overall
purpose of the Controller is to execute on security functions and SACM management and control system functions including:
overall system functions including:
Authentication: The architecture must account for an abstraction Authentication: The architecture must account for an abstraction
where a Controller may be defined to affect the authentication of where a Controller may be defined to affect the authentication of
Consumers and Providers independent of the actual information Consumers and Providers independent of the actual information
sharing communication channel. 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
skipping to change at page 7, line 33 skipping to change at page 7, line 33
use of a 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 what Posture Assessment Information it Provider may need to register what Posture Assessment Information it
can share and how it can share it (e.g. protocol or with filtering can share and how it can share it (e.g. protocol or with filtering
capabilities). Enabling this function through a Controller also capabilities). Enabling this function through a Controller also
allows for the distinct definition of security considerations (e.g. allows for the distinct definition of security considerations (e.g.
authorized registration of capabilities and of Providers) beyond how authorized registration of capabilities and of Providers) beyond how
a Provider may define its own capability. a Provider may define its own capability.
These functions may be provided by a single component, or by multiple Broker/Proxy: beyond the control and management functions for the
components. For example, an endpoint acting as a data store may also SACM system, a Controller may also provide the proxy or broker (and
act as its own broker. possibly routing) function in the data plane. In the deployment
scenario where Providers do not assert the need to know its
Consumers and/or vice versa, the Controller can provide the
appropriate functions to ensure the Posture Assessment Information
is appropriately communicated from the Providers to the authorized
Consumers.
The Controller also helps define how to manage an overall SACM system Data Store: as a broker, the Controller may also include data stores
that allows for Consumers to obtain the desired Posture Assessment to affect the appropriate buffering, aggregation or filtering as
Information without the need to distinctly know and establish a one required to deliver the data as communicated from the Provider to
(Consumer) to many (Provider) connections. Note that the Controller the Consumer.
also allows for the direct discovery and connection between a
Consumer and Provider. The Controller, acting as a management control plane, 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. Similarly, a Provider may not need to distinctly know
and establish a one (Provider) to many Consumer) connections; e.g.
the Controller enables the means to allow a SACM system to support
many to many connections. Note that the Controller also allows for
the direct discovery and connection between a Consumer and Provider.
As a SACM component, the Controller may be instantiated within the
same system or device acting as a Provider, Consumer (or both) or as
its own distinct Controller entity. In a rich SACM environment, it
is feasible to instantiate a Controller that provides both the
management (and control) functions for SACM as well as provide the
proxying, brokering or routing functions for the actual data, e.g.
Posture Assessment Information flow. Note that Controllers may be
implemented to only provide the management and control functions or
only the data proxy/broker function 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
skipping to change at page 14, line 21 skipping to change at page 14, line 21
Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David
Waltermire for participating in architecture design discussions, Waltermire for participating in architecture design discussions,
reviewing, and contributing to this draft. reviewing, and contributing to this draft.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
TBD. This section will need to cover the AAA and confidentiality/ The SACM architecture defines three main components that interface
integrity of the data and data transports to be considered. Also, with each other both for management and control (in the control
the considerations for the interfaces (which may be covered in plane) and for the sharing of Posture Assessment Information.
transports) between the Consumers, Providers, and the Controller. Considerations for transitivity of trust between a Provider and
Consumer can be made if there is a well understood trust between the
Provider and the Controller and between the Consumer and Controller.
The trust must include strong mutual authentication, at minimum,
between the Provider and Controller and between the Consumer and
Controller.
To address potential Man-in-the-Middle (MiM) attacks, it is also
strongly recommended that the communications be secured to include
replay protection and message integrity (e.g. transport integrity and
if required, data integrity). Similarly, to avoid potential message
tampering, confidentiality should also be provided.
As the Controller provides the security functions for the SACM
system, the Controller should provide strong authorizations based on
either or both business and regulatory policies to ensure that only
authorized Consumers and obtaining Posture Assessment Information
from authorized Providers. It is presumed that once authenticated
and authorized, the Provider, Controller or Consumer is deemed
trustworthy; though note that it is possible that the modules or
devices hosting the SACM components may be compromised as well (e.g.
due to malware or tampering); however, addressing that level of
trustworthiness is out of scope for SACM.
As the data models defined through the interfaces are transport
agnostic, the Posture Assessment Information data in the interfaces
may leverage the transport security properties as the interfaces are
transported between the Provider, Consumer and Controller. However,
there may be other devices, modules or components in the path between
the Provider, Consumer and Controller that may observe the interfaces
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-02 (work in progress), October 2014.
skipping to change at page 15, line 18 skipping to change at page 16, line 4
Authors' Addresses Authors' Addresses
Nancy Cam-Winget (editor) Nancy Cam-Winget (editor)
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
US US
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
Brian Ford
Cisco Systems
5507-10 Nesconset Hwy #242
Mt Sinai, NY 11766
US
Email: brford@cisco.com
Lisa Lorenzin Lisa Lorenzin
Pulse Secure Pulse Secure
2700 Zanker Rd, Suite 200 2700 Zanker Rd, Suite 200
San Jose, CA 95134 San Jose, CA 95134
US US
Email: llorenzin@pulsesecure.net Email: llorenzin@pulsesecure.net
Ira E McDonald Ira E McDonald
High North Inc High North Inc
 End of changes. 19 change blocks. 
57 lines changed or deleted 104 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/