draft-ietf-sacm-architecture-03.txt   draft-ietf-sacm-architecture-04.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: September 10, 2015 Pulse Secure Expires: January 24, 2016 Pulse Secure
I. McDonald I. McDonald
High North Inc High North Inc
A. Woland A. Woland
Cisco Systems Cisco Systems
March 9, 2015 July 23, 2015
Secure Automation and Continuous Monitoring (SACM) Architecture Secure Automation and Continuous Monitoring (SACM) Architecture
draft-ietf-sacm-architecture-03 draft-ietf-sacm-architecture-04
Abstract Abstract
This document defines a reference 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 their 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.
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 September 10, 2015. This Internet-Draft will expire on January 24, 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3
3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 4 3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Posture Assessment Information Provider . . . . . . . 5 3.1.1. Provider . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Posture Assessment Information Consumer . . . . . . . 5 3.1.2. Consumer . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Controller . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Types of Providers and Controllers . . . . . . . . . 7
3.2. Interfaces between Consumers, Providers, and Controllers 8 3.1.3.1. Collector . . . . . . . . . . . . . . . . . . . . 7
4. Component Capabilities . . . . . . . . . . . . . . . . . . . 9 3.1.3.2. Evaluator . . . . . . . . . . . . . . . . . . . . 8
4.1. Control Plane Capabilities . . . . . . . . . . . . . . . 9 3.1.3.3. Report Generator . . . . . . . . . . . . . . . . 9
4.2. Data Plane Capabilities . . . . . . . . . . . . . . . . . 10 3.1.3.4. Data Store . . . . . . . . . . . . . . . . . . . 9
4.2.1. Collector . . . . . . . . . . . . . . . . . . . . . . 10 3.1.4. Controller . . . . . . . . . . . . . . . . . . . . . 9
4.2.1.1. Internal Collector . . . . . . . . . . . . . . . 10 4. Interfaces between Consumers, Providers, and Controllers . . 11
4.2.1.2. External Collector . . . . . . . . . . . . . . . 10 5. Component Functions . . . . . . . . . . . . . . . . . . . . . 12
4.2.1.3. Collector Interactions With Target Endpoints . . 11 5.1. Control Plane Functions . . . . . . . . . . . . . . . . . 12
4.2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Data Plane Functions . . . . . . . . . . . . . . . . . . 13
4.2.3. Report Generator . . . . . . . . . . . . . . . . . . 11 6. Component Capabilities . . . . . . . . . . . . . . . . . . . 13
4.2.4. Data Store . . . . . . . . . . . . . . . . . . . . . 12 7. Example Illustration of Functions and Workflow . . . . . . . 13
5. Example Illustration of Capabilities and Workflow . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Several data models and protocols are in use today that allow Several data models and protocols (including - but not limited to -
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
data models, protocols, and interfaces to better allow for the data models, protocols, and interfaces to better allow for the
automation of such data processes. automation of such data processes.
This document addresses general and architectural requirements This document addresses general and architectural requirements
defined in [I-D.ietf-sacm-requirements]. This document describes an defined in [I-D.ietf-sacm-requirements]. The architecture described
architecture to enable standardized collection, acquisition, and enables standardized collection, acquisition, and verification of
verification of Posture and Posture Assessments. This architecture Posture and Posture Assessments. This architecture includes the
includes the components and interfaces that can be used to better components and interfaces that can be used to better identify the
identify the Information Model and type(s) of transport protocols Information Model and type(s) of transport protocols needed for
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].
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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
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 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.
SACM is standardizing an information model, data models, operations,
and transports that will allow for administrators to share with
others and to use data from others interoperably.
3. Architectural Overview 3. Architectural Overview
At a high level, the architecture describes 'How' and 'Where' 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
assessed, exchanged, and/or stored. Three main functional components (e.g. normalization, translation, aggregation, etc.), assessed,
are defined: a Posture Assessment Information Consumer (Cs), a exchanged, and/or stored. This section provides an architectural
Posture Assessment Information Provider (P), and a Controller (Cr) overview of 1.) the basic architectural building blocks, which - in
used to facilitate some of the security functions such as combination - constitute SACM components (the entities, the "where"),
authentication and authorization and other metadata functions. and 2.) 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
| +--------------------------------------+ compose SACM components. Components enable the basic functionality
| | +--------------------------------------+ in SACM, such as Endpoint Attribute Collection or Target Endpoint
| | | | Posture Assessment.
+-| | Posture Assessment |
+-| Information Consumer (Cs) | The role(s) a component plays in the SACM architecture are determined
+--------------------------------------+ by the function(s) that component instantiates. Three main component
/ \ / \ / \ roles are defined: a Consumer (C), a Provider (P), and a Controller
/ \ / \ / \ (Cr) used to facilitate some of the security functions such as
- - - d - - - authentication and authorization and other metadata functions. See
|| ||A | a |B | |C Section 3.1 for details on roles.
|| || | t | | |
- - - a - | | In SACM, components are composed of functions, the modular building
\ / \ / | | blocks in the SACM architecture. The SACM architecture defines the
\ / \ / | | purpose of these functions. Attributes and operations used by
/|---------------------|\ | | component functions are described in other SACM documents. See
/|----/ \--------| d |--|\ Section 5 for details on component functions.
/ / Controller (Cr) \ ctrl | a | \
\ \ [Broker/Proxy/Repository] / plane | t | / Functions use SACM interfaces for communications between components.
\|----\ /--------| a |--|/ Interfaces handle management and control functions (such as
\|---------------------|/ | | authentication, authorization, registration, and discovery), and
/ \ / \ | | enable SACM components to share information (via publication, query,
/ \ / \ | | and subscription). Three primary interfaces are defined: an
- - - d - | | interface for management and control (A), an interface for data
|| ||A | a |B | |C communication between the controller and providers or consumers (B),
|| || | t | | | and an interface for data communication directly between a provider
- - - a - - - and a consumer (C). See Section 4 for details on interfaces.
\ / \ / \ /
\ / \ / \ / Figure 1 illustrates the relationships between component roles and
+------------------------------------+ interfaces:
| |-+
| Posture Assessment | | +--------------------------------------+
| Information Provider (P) | |-+ | +--------------------------------------+
+------------------------------------+ | | | | +--------------------------------------+
+------------------------------------+ | | | | |
+------------------------------------+ +-| | Consumer (C) |
+-| |
+--------------------------------------+
/ \ / \ / \
/ \ / \ / \
- - - d - - -
|| ||A | a |B | |C
|| || | t | | |
- - - a - | |
\ / \ / | |
\ / \ / | |
/|---------------------|\ | |
/|----/ \--------| d |--|\
/ / Controller (Cr) \ ctrl | a | \
\ \ / plane | t | /
\|----\ /--------| a |--|/
\|---------------------|/ | |
/ \ / \ | |
/ \ / \ | |
- - - d - | |
|| ||A | a |B | |C
|| || | t | | |
- - - a - - -
\ / \ / \ /
\ / \ / \ /
+------------------------------------+
| |-+
| Provider (P) | |
| | |-+
+------------------------------------+ | |
+------------------------------------+ |
+------------------------------------+
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 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 capabilities (see Section 4). In the SACM architecture, one or more functions (see Section 5). In the SACM architecture,
individual endpoints may be a target endpoint, or a component, or individual endpoints may be a target endpoint, a component, or both
both simultaneously. An endpoint acting as a component may perform simultaneously. An endpoint acting as a component may perform one or
one or more roles. Components can take on the role(s) of Posture more roles. Components can take on the role(s) of Provider,
Assessment Information Provider, Posture Assessment Information
Consumer, and/or Controller. Consumer, and/or Controller.
3.1.1. Posture Assessment Information Provider 3.1.1. Provider
The Posture Assessment Information Provider (P or Provider) is the The Provider (P or Provider) is the component that contributes
component that contributes Posture Assessment Information and/or Posture Assessment Information and/or Guidance either spontaneously
Guidance either spontaneously or in response to a request. A or in response to a request. A Provider can be a Posture Evaluator,
Provider can be a Posture Evaluator, Posture Collector, Data Store Posture Collector, Data Store (see Section 3.1.3), or an application
(see Section 4.2), or an application that has aggregated Posture that has aggregated Posture Assessment Information that can be
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 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. However, it must support either one or more standard
through a metadata abstraction within the data model itself, or data models, or one or more standard protocols. It may also choose
through the use of the registration function of the Controller (see to advertise its capabilities through a metadata abstraction within
Section 3.1.3). the data model itself, or through the use of the registration
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 and further, be authorized to do so with specific data
models and protocols and/or for specific consumers. models and protocols and/or for specific consumers.
3.1.2. Posture Assessment Information Consumer 3.1.2. Consumer
The Posture Assessment Information Consumer (C or Consumer) is the The Consumer (C or Consumer) is the component that requests or
component that requests or accepts Posture Assessment Information accepts Posture Assessment Information and/or Guidance. A Consumer
and/or Guidance. A Consumer can be a Posture Evaluator, Report can be a Posture Evaluator, Report Generator, Data Store (see
Generator, Data Store (see Section 4.2), or an application that Section 5.2), or an application that consumes Posture Assessment
consumes Posture Assessment Information in order to perform another Information in order to perform another function.
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.
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 enable a Posture Assessment Information Request.
Request. Requests can be either for a single posture attribute or a Requests can be either for a single posture attribute or a set of
set of posture attributes; those attributes can be the raw posture attributes; those attributes can be the raw information, or
information, or an evaluated or assessed state based upon that an evaluation result based upon that information. The Consumer may
information. The Consumer may further choose to query for the further choose to query for the information directly (one-time
information directly (one-time query), or to request for updates to query), or to request for updates to be provided as the Posture
be provided as the Posture Assessment Information changes Assessment Information changes (subscription). A request could be
(subscription). A request could be made directly to an explicitly made directly to an explicitly identified Provider, but a Consumer
identified Provider, but a Consumer may also desire to obtain the may also desire to obtain the information without having to know the
information without having to know the available Providers. 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) 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. Controller 3.1.3. Types of Providers and Controllers
The Controller (Cr or Controller) is a component defined to SACM Providers and Consumers can perform a variety of SACM-related
facilitate information sharing and to execute on security functions tasks. For example, a Collector can perform Collection tasks; an
and overall SACM management and control system functions including: Evaluator can perform Evaluation tasks. A single Provider or
Consumer may be able to perform only one task, or multiple tasks.
SACM defines the following types of Providers/Consumers:
Authentication: The authentication of Consumers and Providers 3.1.3.1. Collector
independent of the actual information-sharing communication channel.
This supports use cases where:
* Consumers may request information independent of knowing the A collector consumes Guidance and/or other Posture Assessment
identities of the Providers. Information; it provides Posture Assessment Information. Collectors
may be internal or external.
* Providers may want to share the information without prior 3.1.3.1.1. Internal Collector
solicitation.
The architecture must account for an abstraction where a Controller An internal collector is a collector that runs on the endpoint and
may be defined to effect the authentication of the Consumers and collects posture information locally.
Providers independent of the actual information-sharing
communication channel.
Authorization: The restriction of Posture Assessment Information 3.1.3.1.2. External Collector
sharing between the Consumers and Providers. At minimum, a
management function must define the necessary policies.
Identity Management: Since Identity Management for authentication An external collector is a collector that observes endpoints from
and authorization policies is best performed via a centralized outside. These collectors may be configured and operated to manage
component, the Controller also facilitates this function. assets for reasons including, but not limited to, posture assessment.
Collectors that are not primarily intended to support posture
assessment (e.g. intrusion detection systems) may still provide
information that speaks to endpoint posture (e.g. behavioral
information).
The Controller needs to be able to identify the endpoints Examples:
participating as SACM components and the roles that they play.
Similar to how access control may be effected via Authentication,
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.
Registration/Discovery: The discovery of what Providers are o A RADIUS server, which collects information about which endpoints
available, what information a Provider can share, and how it can be have logged onto the network
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.
Through the use of a discovery mechanism, Consumers can have o A network profiling system, which collects information by
visibility into the Providers present, the type(s) of Posture discovering and classifying network nodes
Assessment Information available, and how it can be requested.
Similarly, a Provider may need to publish what Posture Assessment
Information it can share and how it can share it (e.g. protocol,
filtering capabilities, etc.). Enabling this function through a
Controller or through metadata publication also allows for the
distinct definition of security considerations (e.g. authorized
registration / publication of capabilities by Providers) beyond how
a Provider may define its own capability.
Beyond the control and management functions for the SACM system, a o A Network Intrusion Detection System (NIDS) sensor, which collects
Controller may also provide proxy or broker or repository (and information about endpoint behavior by observing network traffic
possibly routing) capabilities in the data plane (see Section 4.1).
In the deployment scenario where Providers do not assert the need to
know their Consumers and/or vice versa, the Controller can thus
provide the appropriate functions to ensure the Posture Assessment
Information is appropriately communicated from the Providers to the
authorized Consumers.
The Controller, acting as a management control plane, helps define o A vulnerability scanner, which collects information about endpoint
how to manage an overall SACM system that allows for Consumers to configuration by scanning endpoints
obtain the desired Posture Assessment Information without the need to
distinctly know and establish one (Consumer) to many (Provider)
connections. Similarly, a Provider may not need to distinctly know
and establish 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 a o A hypervisor, which collects information about endpoints running
system or device acting as a Provider or a Consumer (or both), or as as virtual guests in its host environment
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, and/or repository capabilities 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 flow capabilities or both.
3.2. Interfaces between Consumers, Providers, and Controllers o A management system that configures and installs software on the
endpoint, which collects information based on its provisioning
activities
As shown in Figure 1, communication can proceed with the following 3.1.3.1.3. Collector Interactions With Target Endpoints
interfaces and expected functions and behaviors:
A: interface "A" shown in Figure 1 handles the management and TODO - examples of endpoint interactions with local internal
control functions that are needed to establish, at minimum, a secure collector (e.g. NEA client), endpoint with remote internal collector
communication between Consumers and Providers. The interface must (SNMP query), and external collector (sensor)
also handle the functions to allow for the discovery and
registration of the Providers as well as the ways in which Posture
Assessment Information can be provided (or requested).
B: interface "B" shown in Figure 1 enables Providers to share their 3.1.3.2. Evaluator
Posture Assessment Information spontaneously; similarly, it enables
Consumers to request information without having to know the
identities (or reachability) of all the Providers that can fulfill
Consumers' requests.
C: interface "C" shown in Figure 1 illustrates the ability and An evaluator consumes Posture Assessment Information, Evaluation
desire for Consumers and Providers to be able to communicate Results, and/or Guidance; it provides Evaluation Results. An
directly when a Provider is sharing Posture Assessment Information evaluator may consume endpoint attribute assertions, previous
directly to a Consumer. The interface allows for the different data evaluations of posture attributes, or previous reports of Evaluation
models and protocols to be used between a Consumer and a Provider Results.
with the expectation that the appropriate authentication and
authorization mechanisms have been employed to establish a secure
communication link between the Consumer and the Provider.
Typically, it is expected that the secure link establishment occurs
as a management or control function through the abstracted
Controller role (e.g. the Controller could be a broker or could be
embedded in a Consumer or a Provider).
A variety of protocols, such as SNMP, NETCONF, NEA protocols TODO: update the terminology doc to reflect this definition
[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 Example: a NEA posture validator [RFC5209]
SACM components offer a variety of capabilities which may be 3.1.3.3. Report Generator
instantiated on a single endpoint or on separate standalone endpoints
providing various roles.
4.1. Control Plane Capabilities A report generator consumes Posture Assessment Information,
Evaluation Results, and/or Guidance; it provides reports. These
reports are based on:
Control plane capabilities represent various services offered by the o Endpoint Attribute Assertions, including Evaluation Results
Controller to the Providers and Consumers to facilitate sharing of
information. A Controller may have Broker, Proxy, or Repository o Other Reports (e.g., a weekly report may be created from daily
capabilities, or any combination thereof. reports)
It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query.
3.1.3.4. Data Store
A data store consumes any data; it provides any data.
3.1.4. Controller
The Controller (Cr or Controller) is a component defined to
facilitate information sharing and to execute on security functions
and overall SACM management and control system functions. SACM
defines three types of Controller:
Broker: Intermediary negotiating connection between Provider and Broker: Intermediary negotiating connection between Provider and
Consumer. A Controller acting as a Broker: Consumer. Implements only control plane functions. A Controller
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.
A Controller acting as a Proxy: Implements both control and data plane functions. A Controller
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. A Controller acting as a and providing stored data to a Consumer. Implements both control
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.
4.2. Data Plane Capabilities A single instantiation of a Controller may be a Broker, Proxy, or
Repository, or any combination thereof.
Data plane capabilities represent the ability of a Provider or Through the use of a discovery mechanism, Consumers can have
Consumer to perform a SACM-related task. For example, the Collector visibility into the Providers present, the type(s) of Posture
capability indicates that a Provider can perform Collection tasks; Assessment Information available, and how it can be requested.
the Evaluator capability indicates that a Consumer can perform Similarly, a Provider may need to publish what Posture Assessment
Evaluation tasks. Information it can share and how it can share it (e.g. protocol,
filtering capabilities, etc.). Enabling this visibility through a
Controller or through metadata publication also allows for the
distinct definition of security considerations (e.g. authorized
registration / publication of capabilities by Providers) beyond how a
Provider may define its own capability.
4.2.1. Collector Beyond the control and management functions for the SACM system, a
Controller may also provide proxy or broker or repository (and
possibly routing) services in the data plane. In the deployment
scenario where Providers do not assert the need to know their
Consumers and/or vice versa, the Controller can thus provide the
appropriate services to ensure the Posture Assessment Information is
appropriately communicated from the Providers to the authorized
Consumers.
A collector consumes Guidance and/or other Posture Assessment The Controller, acting as a management control plane, helps define
Information; it provides Posture Assessment Information. Collectors how to manage an overall SACM system that allows for Consumers to
may be internal or external. obtain the desired Posture Assessment Information without the need to
distinctly know and establish one (Consumer) to many (Provider)
connections. Similarly, a Provider may not need to distinctly know
and establish 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.
4.2.1.1. Internal Collector As a SACM component, the Controller may be instantiated within a
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
is feasible to instantiate a Controller that provides both the
management (and control) functions for SACM as well as providing the
data plane services for the actual data, e.g. Posture Assessment
Information flow. Note that Controllers may be implemented to only
provide control plane functions (broker), or both control plane
functions and data plane services (proxy or repository).
An internal collector is a collector that runs on the endpoint and 4. Interfaces between Consumers, Providers, and Controllers
collects posture information locally.
4.2.1.2. External Collector A SACM interface is a transport carrying operations (e.g. publication
via a RESTful API). As shown in Figure 1, communication can proceed
with the following interfaces and expected functions and behaviors:
An external collector is a collector that observes endpoints from A: interface "A" shown in Figure 1 handles the management and
outside. These collectors may be configured and operated to manage control functions that are needed to establish, at minimum, a secure
assets for reasons including, but not limited to, posture assessment. communication between Consumers and Providers. The interface must
Collectors that are not primarily intended to support posture also handle the functions to allow for the discovery and
assessment (e.g. intrusion detection systems) may still provide registration of the Providers as well as the ways in which Posture
information that speaks to endpoint posture (e.g. behavioral Assessment Information can be provided (or requested).
information).
Examples: B: interface "B" shown in Figure 1 enables Providers to share their
Posture Assessment Information spontaneously; similarly, it enables
Consumers to request information without having to know the
identities (or reachability) of all the Providers that can fulfill
Consumers' requests.
o A RADIUS server, which collects information about which endpoints C: interface "C" shown in Figure 1 illustrates the ability and
have logged onto the network desire for Consumers and Providers to be able to communicate
directly when a Provider is sharing Posture Assessment Information
directly to a Consumer. The interface allows for the different data
models and protocols to be used between a Consumer and a Provider
with the expectation that the appropriate authentication and
authorization mechanisms have been employed to establish a secure
communication link between the Consumer and the Provider.
Typically, it is expected that the secure link establishment occurs
as a management or control function through the abstracted
Controller role (e.g. the Controller could be a broker or could be
embedded in a Consumer or a Provider).
o A network profiling system, which collects information by A variety of protocols, such as SNMP, NETCONF, NEA protocols
discovering and classifying network nodes [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.
o A Network Intrusion Detection System (NIDS) sensor, which collects 5. Component Functions
information about endpoint behavior by observing network traffic
o A vulnerability scanner, which collects information about endpoint SACM components are composed of a variety of functions, which may be
configuration by scanning endpoints instantiated on a single endpoint or on separate standalone endpoints
providing various roles. An endpoint MUST implement one or more of
these functions to be considered a SACM component. A SACM solution
offers a set of functions across a set of SACM components.
o A hypervisor, which collects information about endpoints running The functions described here are the minimum set that is mandatory to
as virtual guests in its host environment implement in a SACM solution. A SACM solution MAY implement
additional functions.
o A management system that configures and installs software on the 5.1. Control Plane Functions
endpoint, which collects information based on its provisioning
activities
4.2.1.3. Collector Interactions With Target Endpoints Control plane functions represent various services offered by the
Controller to the Providers and Consumers to facilitate sharing of
information. Control plane functions include, but are not limited
to:
TODO - examples of endpoint interactions with local internal Authentication: The authentication of Consumers and Providers
collector (e.g. NEA client), endpoint with remote internal collector independent of the actual information-sharing communication channel.
(SNMP query), and external collector (sensor) This supports use cases where:
4.2.2. Evaluator * Consumers may request information independent of knowing the
identities of the Providers.
An evaluator consumes Posture Assessment Information, Evaluation * Providers may want to share the information without prior
Results, and/or Guidance; it provides Evaluation Results. An solicitation.
evaluator may consume endpoint attribute assertions, previous
evaluations of posture attributes, or previous reports of Evaluation
Results.
TODO: update the terminology doc to reflect this definition The architecture must account for an abstraction where a Controller
may be defined to effect the authentication of the Consumers and
Providers independent of the actual information-sharing communication
channel.
Example: a NEA posture validator [RFC5209] Authorization: The restriction of Posture Assessment Information
sharing between the Consumers and Providers. At minimum, a
management function must define the necessary policies.
[jmf- a NEA posture validator is not an example of this definition. Identity Management: Since Identity Management for authentication
A NEA posture assessment is, maybe?] and authorization policies is best performed via a centralized
component, the Controller also facilitates this function.
[cek-Why isn't a NEA posture validator an example?] The Controller needs to be able to identify the endpoints
participating as SACM components and the roles that they play.
Similar to how access control may be effected via Authentication,
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.
4.2.3. Report Generator Registration/Discovery: The discovery of what Providers are
available, what information a Provider can share, and how it can be
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.
A report generator consumes Posture Assessment Information, 5.2. Data Plane Functions
Evaluation Results, and/or Guidance; it provides reports. These
reports are based on:
o Endpoint Attribute Assertions, including Evaluation Results Subscription
o Other Reports (e.g., a weekly report may be created from daily Publication
reports)
It may summarize data continually, as the data arrives. It also may Query
summarize data in response to an ad hoc query.
4.2.4. Data Store 6. Component Capabilities
A data store consumes any data; it provides any data. TODO: add a discussion of "capability" as being able to talk a
specific data model, data operations, or SACM transport
5. Example Illustration of Capabilities and Workflow TODO: data plane capabilities / control plane capabilities can be
discovered via querying the controller
7. Example Illustration of Functions and Workflow
TODO: once the group reaches consensus on content for the previous TODO: once the group reaches consensus on content for the previous
sections, revise all this text based upon the agreed-upon sections, revise all this text based upon the agreed-upon
architecture architecture
+-------------------------------+ +-------------------------------+
| +-------------------------------+ | +-------------------------------+
| | | | | |
+-| Controller (Cr) | +-| Controller (Cr) |
+-------------------------------+ +-------------------------------+
// / \ \\ // / \ \\
// / \ \\ // / \ \\
A // / \ \\ A A // / \ \\ A
// / \ \\ // / \ \\
// / B B \ \\ // / B B \ \\
skipping to change at page 12, line 48 skipping to change at page 14, line 29
+-| | C +-| | +-| | 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 Providers: a Provider may be dedicated to perform either the
dedicated to perform either the collection, aggregation or collection, aggregation or evaluation of one or more posture
evaluation of one or more posture attributes whose results can be attributes whose results can be conveyed to a Consumer. In this
conveyed to a Posture Assessment Information Consumer. In this
example form of the SACM architecture model, these are shown as example form of the SACM architecture model, these are shown as
Collection, Evaluation, and Results Providers. Note that there may Collection, Evaluation, and Results Providers. Note that there may
be posture attributes or posture assessment information that be posture attributes or posture assessment information that
articulates Guidance information which may or may not be present in articulates Guidance information which may or may not be present in
the architecture. the architecture.
Posture Assessment Information Consumers: a Consumer may request or Consumers: a Consumer may request or receive one or more posture
receive one or more posture attributes or posture assessment attributes or posture assessment information from a Provider for
information from a Posture Assessment Information Provider for their their own use. In this example form of the SACM architecture model,
own use. In this example form of the SACM architecture model, these these are shown as Collection, Evaluation, and Results Consumers.
are shown as Collection, Evaluation, and Results Consumers. Note Note that there may be posture attributes or posture assessment
that there may be posture attributes or posture assessment
information articulating Guidance information which may or may not information articulating Guidance information which may or may not
be present in the architecture to be provided or consumed. be present in the architecture to be provided or consumed.
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 | |Function | |
+-------+ | +-------------+ | +-------+ | +-------------+ |
| | | | | | | |
| +-------+-----+ +-----v-------+ | +-------+-----+ +-----v-------+
| Collection | |Evaluation | | Collection | |Evaluation |
+-> Capability +--+--------+ |Capability | +-> Function +--+--------+ |Function |
| | |Collection | +-----------+ +----------+ | | |Collection | +-----------+ +----------+
| +------------+Provider | | |---| | | +------------+Provider | | |---| |
| | | |Collection | |Evaluation| | | | |Collection | |Evaluation|
| | | |Consumer | |Provider | | | | |Consumer | |Provider |
| +----+------+ +----^------+ +---+------+ | +----+------+ +----^------+ +---+------+
++---------+ | | | ++---------+ | | |
|Collection| +-----v------+ +---+--------+ | |Collection| +-----v------+ +---+--------+ |
|Guidance | | | |Collection | | |Guidance | | | |Collection | |
|Capability| |Collection | |Provider | | |Function | |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 | | |Function |
| +------------^----+ | +------------^----+
| | | |
+-----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 8. 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
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 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 10. Security Considerations
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 (MitM) 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. disclosure (e.g. where privacy may be needed), 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
and authorized, the Provider, Controller or Consumer is deemed and authorized, the Provider, Controller or Consumer is deemed
trustworthy; though note that it is possible that the modules or trustworthy; though note that it is possible that the modules or
devices hosting the SACM components may be compromised as well (e.g. devices hosting the SACM components may be compromised as well (e.g.
due to malware or tampering); however, addressing that level of due to malware or tampering); however, addressing that level of
trustworthiness is out of scope for SACM. trustworthiness is out of scope for SACM.
As the data models defined through the interfaces are transport As the data models defined through the interfaces are transport
agnostic, the Posture Assessment Information data in the interfaces agnostic, the Posture Assessment Information data in the interfaces
may leverage the transport security properties as the interfaces are may leverage the transport security properties as the interfaces are
transported between the Provider, Consumer and Controller. However, transported between the Provider, Consumer and Controller. However,
there may be other devices, modules or components in the path between there may be other devices, modules or components in the path between
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 11. References
9.1. Normative References 11.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-03 (work in progress), January 2015. sacm-requirements-08 (work in progress), July 2015.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., Cam-Winget, Birkholz, H., "Secure Automation and Continuous Monitoring
N., Lu, J., Ford, B., and M. Kaeo, "Terminology for (SACM) Terminology", draft-ietf-sacm-terminology-07 (work
Security Assessment", draft-ietf-sacm-terminology-06 (work in progress), July 2015.
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-08 (work in progress), February 2015. sacm-use-cases-10 (work in progress), July 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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 11.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,
2003. DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008. Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>.
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
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. 104 change blocks. 
328 lines changed or deleted 388 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/