SACM                                                  N. Cam-Winget, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Informational                               L. Lorenzin
Expires: September 10, 2015 January 24, 2016                                   Pulse Secure
                                                             I. McDonald
                                                          High North Inc
                                                               A. Woland
                                                           Cisco Systems
                                                           March 9,
                                                           July 23, 2015

    Secure Automation and Continuous Monitoring (SACM) Architecture
                    draft-ietf-sacm-architecture-03
                    draft-ietf-sacm-architecture-04

Abstract

   This document defines a reference an architecture for standardization of
   interfaces, protocols, and information models related to security
   automation and continuous monitoring.  It describes the basic
   architecture, components, and their interfaces defined to enable the
   collection, acquisition, and verification of Posture and Posture
   Assessments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2015. January 24, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Component Roles . . . . . . . . . . . . . . . . . . . . .   4   5
       3.1.1.  Posture Assessment Information  Provider  . . . . . . .   5
       3.1.2.  Posture Assessment Information Consumer . . . . . . .   5
       3.1.3.  Controller . . . . . . . .   6
       3.1.2.  Consumer  . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Interfaces between Consumers, Providers,
       3.1.3.  Types of Providers and Controllers    8
   4.  Component Capabilities  . . . . . . . . .   7
         3.1.3.1.  Collector . . . . . . . . . .   9
     4.1.  Control Plane Capabilities . . . . . . . . . .   7
         3.1.3.2.  Evaluator . . . . .   9
     4.2.  Data Plane Capabilities . . . . . . . . . . . . . . .   8
         3.1.3.3.  Report Generator  . .  10
       4.2.1.  Collector . . . . . . . . . . . . . .   9
         3.1.3.4.  Data Store  . . . . . . . .  10
         4.2.1.1.  Internal Collector . . . . . . . . . . .   9
       3.1.4.  Controller  . . . .  10
         4.2.1.2.  External Collector . . . . . . . . . . . . . . .  10
         4.2.1.3.  Collector Interactions With Target Endpoints . .  11
       4.2.2.  Evaluator   9
   4.  Interfaces between Consumers, Providers, and Controllers  . .  11
   5.  Component Functions . . . . . . . . . . . . . . . . . . . .  11
       4.2.3.  Report Generator .  12
     5.1.  Control Plane Functions . . . . . . . . . . . . . . . . .  11
       4.2.4.  12
     5.2.  Data Store Plane Functions  . . . . . . . . . . . . . . . . . .  13
   6.  Component Capabilities  . . . . .  12
   5. . . . . . . . . . . . . . .  13
   7.  Example Illustration of Capabilities Functions and Workflow  . . . . . .  12
   6. .  13
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   7.  17
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   8.  17
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  17
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  18
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     9.2.  18
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16  18

1.  Introduction

   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
   assessment of posture.  These applications can vary from being
   focused on general system and security management to specialized
   configuration, compliance, and control systems.  With an existing
   varied set of applications, there is a strong desire to standardize
   data models, protocols, and interfaces to better allow for the
   automation of such data processes.

   This document addresses general and architectural requirements
   defined in [I-D.ietf-sacm-requirements].  This document describes an  The architecture to enable described
   enables standardized collection, acquisition, and verification of
   Posture and Posture Assessments.  This architecture includes the
   components and interfaces that can be used to better identify the
   Information Model and type(s) of transport protocols needed for
   communication.

   This document uses terminology defined in
   [I-D.ietf-sacm-terminology].

2.  Problem Statement

   Securing information and the systems that store, process, and
   transmit that information is a challenging task for organizations of
   all sizes, and many security practitioners spend much of their time
   on manual processes.  Administrators can't get technology from
   disparate sources to work together; they need information to make
   decisions, but the information is not available.  Everyone is
   collecting the same data, but storing it as different information.
   Administrators therefore need to collect data and craft their own
   information, which may not be accurate or interoperable because it's
   customized by each administrator, not shared.

   Security automation and continuous monitoring require a large and
   broad set of mission and business processes; to make the most
   effective of use of technology, the same data must support multiple
   processes.  The need for complex characterization and assessment
   necessitates components and functions that interoperate and can build
   off each other to enable far-ranging and/or deep-diving analysis.
   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

   At a high level, the SACM architecture describes 'How' "Where" and 'Where' "How"
   information and assessment of posture may be collected, processed, processed
   (e.g. normalization, translation, aggregation, etc.), assessed,
   exchanged, and/or stored.  This section provides an architectural
   overview of 1.) the basic architectural building blocks, which - in
   combination - constitute SACM components (the entities, the "where"),
   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.

   The role(s) a component plays in the SACM architecture are determined
   by the function(s) that component instantiates.  Three main functional components component
   roles are defined: a Posture Assessment Information Consumer (Cs), (C), a
   Posture Assessment Information Provider (P), and a Controller
   (Cr) used to facilitate some of the security functions such as
   authentication and authorization and other metadata functions.

                         +--------------------------------------+
                         | +--------------------------------------+
                         | | +--------------------------------------+
                         | | |                                      |
                         +-|  See
   Section 3.1 for details on roles.

   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
   Section 5 for details on component functions.

   Functions use SACM interfaces for communications between components.
   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
   interface for management and control (A), an interface for data
   communication between the controller and providers or consumers (B),
   and an interface for data communication directly between a provider
   and a consumer (C).  See Section 4 for details on interfaces.

   Figure 1 illustrates the relationships between component roles and
   interfaces:

                        +--------------------------------------+
                        | +--------------------------------------+
                        | | +--------------------------------------+
                        | | |      Posture Assessment                                      |
                        +-|      Information |            Consumer (Cs) (C)              |
                          +-|                                      |
                            +--------------------------------------+
                              /   \         /   \            /   \
                             /     \       /     \          /     \
                             -     -       -  d  -          -     -
                              || ||A        | a  |B          |   |C
                              || ||         | t  |           |   |
                             -     -       -  a  -           |   |
                             \     /       \     /           |   |
                              \   /         \   /            |   |
                           /|---------------------|\         |   |
                    /|----/                         \--------| d |--|\
                   /     /      Controller (Cr)      \ ctrl  | a |    \
                   \     \ [Broker/Proxy/Repository]                           / plane | t |    /
                    \|----\                         /--------| a |--|/
                           \|---------------------|/         |   |
                              /   \         /   \            |   |
                             /     \       /     \           |   |
                             -     -       -  d  -           |   |
                              || ||A        | a |B           |   |C
                              || ||         | t |            |   |
                             -     -       -  a  -          -     -
                             \     /       \     /          \     /
                              \   /         \   /            \   /
                            +------------------------------------+
                            |                                    |-+
                            |     Posture Assessment            Provider (P)             | |
                            |    Information Provider (P)                                      | |-+
                            +------------------------------------+ | |
                              +------------------------------------+ |
                                +------------------------------------+

                   Figure 1: Simple Architectural Model

3.1.  Component Roles

   An endpoint, as defined in [I-D.ietf-sacm-terminology], can function operate
   in two primary ways: as the target of an assessment, and/or as a
   functional component of the SACM architecture that can instantiate
   one or more capabilities functions (see Section 4). 5).  In the SACM architecture,
   individual endpoints may be a target endpoint, or a component, or both
   simultaneously.  An endpoint acting as a component may perform 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

   The Posture Assessment Information Provider (P or Provider) is the component that contributes
   Posture Assessment Information and/or Guidance either spontaneously
   or in response to a request.  A Provider can be a Posture Evaluator,
   Posture Collector, Data Store (see Section 4.2), 3.1.3), or an application
   that has aggregated Posture Assessment Information that can be
   shared.

   The Provider implements the capabilities and functions that must be
   handled to share or provide Posture Assessment information.

   A Provider may provide information spontaneously, or in response to a
   direct request from a Consumer.  The information may be filtered or
   truncated to provide a subset of the requested information to honor
   the request.  This truncation may be performed based on the
   Consumer's request and/or the Provider's ability to filter.  The
   latter case may be due to security considerations (e.g. authorization
   restrictions due to domain segregation, privacy, etc.).

   The Provider may only be able to share the Posture Assessment
   Information using a specific data model and protocol.  It may use a
   standard data model and/or protocol, a non-standard data model and/or
   protocol, or any combination of standard and non-standard data models
   and protocols.  However, it must support either one or more standard
   data models, or one or more standard protocols.  It may also choose
   to advertise its capabilities through a metadata abstraction within
   the data model itself, or through the use of the registration
   function of the Controller (see Section 3.1.3). 3.1.4).

   The Provider must be authorized to provide the Posture Assessment
   Information and further, be authorized to do so with specific data
   models and protocols and/or for specific consumers.

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), 5.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
   [I-D.ietf-sacm-use-cases], several usage scenarios are posed with
   different application types requesting posture assessment
   information.  Whether it is a configuration verification system; a
   checklist verification system; or a system for detecting posture
   deviations, compliance or vulnerabilities, they all need to acquire
   information about Posture Assessment.  The architectural component
   performing such requests is a Consumer.

   The Consumer implements the capabilities and functions that must be
   handled in order to facilitate enable a Posture Assessment Information Request.
   Requests can be either for a single posture attribute or a set of
   posture attributes; those attributes can be the raw information, or
   an evaluated or assessed state evaluation result based upon that information.  The Consumer may
   further choose to query for the information directly (one-time
   query), or to request for updates to be provided as the Posture
   Assessment Information changes (subscription).  A request could be
   made directly to an explicitly identified Provider, but a Consumer
   may also desire to obtain the information without having to know the
   available Providers.

   There may be instances where a Consumer may be requesting information
   from various Providers and, due to its policy or application
   requirements, may need to be better informed of the Providers and
   their capabilities.  In those use cases, a Consumer may also request
   to discover the respective capabilities of those Providers using the
   discovery function of the Controller (see Section 3.1.3) 3.1.4) or may
   request metadata reflecting the capabilities of the Providers.

   The Controller (described below) must authorize a Consumer to acquire
   the information it is requesting.  The Consumer may also be subject
   to limits or constraints on the numbers, types, sizes, and rate of
   requests.

3.1.3.  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 including:

   Authentication:  The authentication  Types of Consumers Providers and Controllers

   SACM Providers
    independent of the actual information-sharing communication channel.
    This supports use cases where:

    * and Consumers may request information independent of knowing the
       identities can perform a variety of the Providers.

    *  Providers may want to share the information without prior
       solicitation.

    The architecture must account for an abstraction where SACM-related
   tasks.  For example, a Controller Collector can perform Collection tasks; an
   Evaluator can perform Evaluation tasks.  A single Provider or
   Consumer may be defined able to effect the authentication of the Consumers and
    Providers independent of perform only one task, or multiple tasks.
   SACM defines the actual information-sharing
    communication channel.

   Authorization:  The restriction following types of Providers/Consumers:

3.1.3.1.  Collector

   A collector consumes Guidance and/or other Posture Assessment Information
    sharing between the Consumers and Providers.  At minimum,
   Information; it provides Posture Assessment Information.  Collectors
   may be internal or external.

3.1.3.1.1.  Internal Collector

   An internal collector is a
    management function must define collector that runs on the necessary policies.

   Identity Management:  Since Identity Management for authentication endpoint and authorization policies
   collects posture information locally.

3.1.3.1.2.  External Collector

   An external collector is best performed via a centralized
    component, the Controller also facilitates this function.

    The Controller needs to be able to identify the endpoints
    participating as SACM components and the roles collector that they play.
    Similar to how access control observes endpoints from
   outside.  These collectors 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 configured and interface operated to Identity Management services.

   Registration/Discovery:  The discovery of what Providers manage
   assets for reasons including, but not limited to, posture assessment.
   Collectors that are
    available, what information a Provider can share, and how it can be
    requested / communicated.  A discovery mechanism is required not primarily intended to
    facilitate interaction with Providers that support posture
   assessment (e.g. intrusion detection systems) may still provide
   information that speaks to endpoint posture (e.g. behavioral
   information).

   Examples:

   o  A RADIUS server, which collects information about which endpoints
      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
    visibility into logged onto the Providers present, network

   o  A network profiling system, which collects information by
      discovering and classifying network nodes

   o  A Network Intrusion Detection System (NIDS) sensor, which collects
      information about endpoint behavior by observing network traffic

   o  A vulnerability scanner, which collects information about endpoint
      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 type(s)
      endpoint, which collects information based on its provisioning
      activities

3.1.3.1.3.  Collector Interactions With Target Endpoints

   TODO - examples of endpoint interactions with local internal
   collector (e.g.  NEA client), endpoint with remote internal collector
   (SNMP query), and external collector (sensor)

3.1.3.2.  Evaluator

   An evaluator consumes Posture Assessment Information available, and how Information, Evaluation
   Results, and/or Guidance; it can be requested.
    Similarly, a Provider provides Evaluation Results.  An
   evaluator may need consume endpoint attribute assertions, previous
   evaluations of posture attributes, or previous reports of Evaluation
   Results.

   TODO: update the terminology doc to publish what reflect this definition

   Example: a NEA posture validator [RFC5209]

3.1.3.3.  Report Generator

   A report generator consumes Posture Assessment
    Information it can share and how it can share Information,
   Evaluation Results, and/or Guidance; it (e.g. protocol,
    filtering capabilities, etc.).  Enabling this function through provides reports.  These
   reports are based on:

   o  Endpoint Attribute Assertions, including Evaluation Results

   o  Other Reports (e.g., 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 weekly report may define its own capability.

   Beyond the control and management functions for the SACM system, a
   Controller be created from daily
      reports)

   It may also provide proxy or broker or repository (and
   possibly routing) capabilities in the summarize data plane (see Section 4.1).
   In the deployment scenario where Providers do not assert continually, as the need data arrives.  It also may
   summarize data in response to
   know their Consumers and/or vice versa, the an ad hoc query.

3.1.3.4.  Data Store

   A data store consumes any data; it provides any data.

3.1.4.  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 Controller (Cr or Controller) is a management control plane, helps define
   how component defined to manage an
   facilitate information sharing and to execute on security functions
   and overall SACM management and control system that allows functions.  SACM
   defines three types of Controller:

   Broker:  Intermediary negotiating connection between Provider and
    Consumer.  Implements only control plane functions.  A Controller
    acting as a Broker:

    *  Receives a request for Consumers to
   obtain the desired Posture Assessment Information without information from a Consumer and instructs
       the need to
   distinctly know Consumer where and establish one (Consumer) to many (Provider)
   connections.  Similarly, how retrieve the requested information.

    *  Receives a publication request from a Provider may not need to distinctly know and establish one (Provider) instructs the
       Provider where and how to many (Consumer) connections; e.g. deliver the
   Controller enables published information.

   The information itself is neither distributed nor stored by the means to allow
   Controller.

   Proxy:  Intermediary negotiating on behalf of a SACM system to support many
   to many connections.  Note that the Consumer or Provider.
    Implements both control and data plane functions.  A Controller also allows
    acting as a Proxy:

    *  Receives a request for information from a Consumer, retrieves the
   direct discovery
       information from the appropriate Providers, and connection between provides the
       information to the Consumer.

    *  Receives a Consumer and Provider.

   As publication request from a SACM component, Provider, accepts the Controller may be instantiated within
       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
   system or device Provider,
    and providing stored data to a Consumer.  Implements both control
    and data plane functions.  A Controller acting as a Provider or Repository:

    *  Receives a Consumer (or both), or as request for information from a Consumer, retrieves the
       information from its own distinct Controller entity.  In data stores, and provides the information to
       the Consumer.

    *  Receives a rich SACM environment, publication request from a provider, stores the
       published information, and distributes it
   is feasible to instantiate appropriate
       Consumers.

   The information itself is both handled by and stored by the
   Controller.

   A single instantiation of a Controller that provides both may be a Broker, Proxy, or
   Repository, or any combination thereof.

   Through the
   management (and control) functions for SACM as well as provide use of a discovery mechanism, Consumers can have
   visibility into the
   proxying, brokering, and/or repository capabilities for Providers present, the actual
   data, e.g. type(s) of Posture
   Assessment Information flow.  Note that
   Controllers may available, and how it can be implemented requested.
   Similarly, a Provider may need to only provide the management publish what Posture Assessment
   Information it can share and
   control functions how it can share it (e.g. protocol,
   filtering capabilities, etc.).  Enabling this visibility through a
   Controller or only through metadata publication also allows for the data flow
   distinct definition of security considerations (e.g. authorized
   registration / publication of capabilities or both.

3.2.  Interfaces between Consumers, Providers, and Controllers

   As shown in Figure 1, communication can proceed with by Providers) beyond how a
   Provider may define its own capability.

   Beyond the following
   interfaces and expected functions control and behaviors:

   A:  interface "A" shown in Figure 1 handles the management and
    control functions that are needed to establish, at minimum, for the SACM system, a secure
    communication between Consumers and Providers.  The interface must
   Controller may also handle provide proxy or broker or repository (and
   possibly routing) services in the functions data plane.  In the deployment
   scenario where Providers do not assert the need to allow for know their
   Consumers and/or vice versa, the discovery and
    registration of Controller can thus provide the Providers as well as
   appropriate services to ensure the ways in which Posture Assessment Information can be provided (or requested).

   B:  interface "B" shown in Figure 1 enables is
   appropriately communicated from the Providers to share their the authorized
   Consumers.

   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 spontaneously; similarly, it enables
    Consumers to request information without having the need to
   distinctly 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
    desire for Consumers and Providers to be able establish one (Consumer) to communicate
    directly when many (Provider)
   connections.  Similarly, a Provider is sharing Posture Assessment Information
    directly may not need to a Consumer.  The interface allows for the different data
    models distinctly know
   and protocols establish one (Provider) to be used between a Consumer and a Provider
    with many (Consumer) connections; e.g. the expectation that
   Controller enables the appropriate authentication and
    authorization mechanisms have been employed means to establish allow a secure
    communication link between SACM system to support many
   to many connections.  Note that the Controller also allows for the
   direct discovery and connection between a Consumer and the Provider.
    Typically, it is expected that the secure link establishment occurs
    as

   As a management or control function through the abstracted
    Controller role (e.g. SACM component, the Controller could may be instantiated within a broker
   system or could be
    embedded in device acting as a Consumer Provider or a Provider).

   A variety of protocols, such Consumer (or both), or as SNMP, NETCONF, NEA protocols
   [RFC5209], and other similar interfaces, may be used
   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 collection
   of data from SACM as well as providing the target endpoints by
   data plane services for the actual data, e.g.  Posture Assessment
   Information
   Provider.  Those interfaces are outside the scope of SACM.

4.  Component Capabilities

   SACM components offer a variety of capabilities which flow.  Note that Controllers may be
   instantiated on a single endpoint implemented to only
   provide control plane functions (broker), or on separate standalone endpoints
   providing various roles.

4.1.  Control Plane Capabilities

   Control both control plane capabilities represent various services offered by the
   Controller to the Providers
   functions and Consumers to facilitate sharing of
   information.  A Controller may have Broker, Proxy, or Repository
   capabilities, data plane services (proxy or any combination thereof.

   Broker:  Intermediary negotiating connection repository).

4.  Interfaces between Provider Consumers, Providers, and
    Consumer. Controllers

   A Controller acting as a Broker:

    *  Receives SACM interface is a request for information from transport carrying operations (e.g. publication
   via a Consumer and instructs RESTful API).  As shown in Figure 1, communication can proceed
   with the Consumer where following interfaces and how retrieve the requested information.

    *  Receives a publication request from a Provider expected functions and instructs behaviors:

   A:  interface "A" shown in Figure 1 handles the
       Provider where management and how
    control functions that are needed to deliver the published information. establish, at minimum, a secure
    communication between Consumers and Providers.  The information itself is neither distributed nor stored by interface must
    also handle the
    Controller.

   Proxy:  Intermediary negotiating on behalf of a Consumer or Provider.
    A Controller acting as a Proxy:

    *  Receives a request functions to allow for information from a Consumer, retrieves the
       information from the appropriate Providers, discovery and provides the
       information to
    registration of the Consumer.

    *  Receives a publication request from a Provider, accepts Providers as well as the
       published information, and distributes ways in which Posture
    Assessment Information can be provided (or requested).

   B:  interface "B" shown in Figure 1 enables Providers to share their
    Posture Assessment Information spontaneously; similarly, it enables
    Consumers to appropriate
       consumers.

    The request information itself is distributed by, but not stored by, without having to know the
    Controller.

   Repository:  Intermediary receiving and storing data from a Provider,
    identities (or reachability) of all the Providers that can fulfill
    Consumers' requests.

   C:  interface "C" shown in Figure 1 illustrates the ability and providing stored data
    desire for Consumers and Providers to be able to communicate
    directly when a Consumer.  A Controller acting as a
    Repository:

    *  Receives Provider is sharing Posture Assessment Information
    directly to a request Consumer.  The interface allows for information from a Consumer, retrieves the
       information from its different data stores,
    models and provides the information protocols to
       the Consumer.

    *  Receives be used between a publication request from Consumer and a provider, stores Provider
    with the
       published information, expectation that the appropriate authentication and distributes it
    authorization mechanisms have been employed to appropriate
       Consumers.

    The information itself is both handled by establish a secure
    communication link between the Consumer and stored by the
    Controller.

4.2.  Data Plane Capabilities

   Data plane capabilities represent Provider.
    Typically, it is expected that the ability of secure link establishment occurs
    as a Provider management or
   Consumer to perform a SACM-related task.  For example, control function through the Collector
   capability indicates that a Provider can perform Collection tasks; abstracted
    Controller role (e.g. the Evaluator capability indicates that Controller could be a Consumer can perform
   Evaluation tasks.

4.2.1.  Collector

   A collector consumes Guidance and/or other Posture Assessment
   Information; it provides Posture Assessment Information.  Collectors
   may broker or could be internal
    embedded in a Consumer or external.

4.2.1.1.  Internal Collector

   An internal collector is a collector that runs on the endpoint Provider).

   A variety of protocols, such as SNMP, NETCONF, NEA protocols
   [RFC5209], and
   collects posture information locally.

4.2.1.2.  External Collector

   An external collector is a collector that observes endpoints from
   outside.  These collectors other similar interfaces, may be configured and operated to manage
   assets used for reasons including, but not limited to, posture assessment.
   Collectors that are not primarily intended to support posture
   assessment (e.g. intrusion detection systems) may still provide
   information that speaks to endpoint posture (e.g. behavioral
   information).

   Examples:

   o  A RADIUS server, which collects information about which endpoints
      have logged onto collection
   of data from the network

   o  A network profiling system, which collects information by
      discovering and classifying network nodes

   o  A Network Intrusion Detection System (NIDS) sensor, which collects
      information about endpoint behavior target endpoints by observing network traffic

   o  A vulnerability scanner, the Posture Information
   Provider.  Those interfaces are outside the scope of SACM.

5.  Component Functions

   SACM components are composed of a variety of functions, which collects information about may be
   instantiated on a single endpoint
      configuration by scanning or on separate standalone endpoints

   o
   providing various roles.  An endpoint MUST implement one or more of
   these functions to be considered a SACM component.  A hypervisor, which collects information about endpoints running
      as virtual guests SACM solution
   offers a set of functions across a set of SACM components.

   The functions described here are the minimum set that is mandatory to
   implement in its host environment

   o a SACM solution.  A management system that configures SACM solution MAY implement
   additional functions.

5.1.  Control Plane Functions

   Control plane functions represent various services offered by the
   Controller to the Providers and installs software on Consumers to facilitate sharing of
   information.  Control plane functions include, but are not limited
   to:

   Authentication:  The authentication of Consumers and Providers
    independent of the
      endpoint, which collects actual information-sharing communication channel.
    This supports use cases where:

    *  Consumers may request information based on its provisioning
      activities

4.2.1.3.  Collector Interactions With Target Endpoints

   TODO - examples independent 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

   An evaluator consumes Posture Assessment Information, Evaluation
   Results, and/or Guidance; it provides Evaluation Results.  An
   evaluator knowing the
       identities of the Providers.

    *  Providers may consume endpoint attribute assertions, previous
   evaluations want to share the information without prior
       solicitation.

   The architecture must account for an abstraction where a Controller
   may be defined to effect the authentication of posture attributes, or previous reports the Consumers and
   Providers independent of Evaluation
   Results.

   TODO: update the terminology doc actual information-sharing communication
   channel.

   Authorization:  The restriction of Posture Assessment Information
    sharing between the Consumers and Providers.  At minimum, a
    management function must define the necessary policies.

   Identity Management:  Since Identity Management for authentication
    and authorization policies is best performed via a centralized
    component, the Controller also facilitates this function.

   The Controller needs to be able to identify the endpoints
   participating as SACM components and the roles that they play.
   Similar to reflect this definition

   Example: a NEA posture validator [RFC5209]

   [jmf- a NEA posture validator how access control may be effected via Authentication,
   Authorization, and Accounting Systems (e.g.  AAA services), the same
   principle is not an example 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 this definition.
   A NEA posture assessment is, maybe?]

   [cek-Why isn't what Providers are
    available, what information a NEA posture validator an example?]

4.2.3.  Report Generator Provider can share, and how it can be
    requested / communicated.  A report generator consumes discovery mechanism is required to
    facilitate interaction with Providers that may have different
    Posture Assessment Information,
   Evaluation Results, and/or Guidance; it provides reports.  These
   reports are based on:

   o  Endpoint Attribute Assertions, including Evaluation Results

   o  Other Reports (e.g., Information and potentially limited, or a weekly report may be created from daily
      reports)

   It may summarize data continually, as rich
    set of, ways in which they can share the information.

5.2.  Data Plane Functions

   Subscription

   Publication

   Query

6.  Component Capabilities

   TODO: add a discussion of "capability" as being able to talk a
   specific data arrives.  It also may
   summarize model, data in response to an ad hoc query.

4.2.4.  Data Store

   A operations, or SACM transport

   TODO: data store consumes any data; it provides any data.

5. plane capabilities / control plane capabilities can be
   discovered via querying the controller

7.  Example Illustration of Capabilities Functions and Workflow

   TODO: once the group reaches consensus on content for the previous
   sections, revise all this text based upon the agreed-upon
   architecture
                      +-------------------------------+
                     | +-------------------------------+
                     | |                               |
                     +-|        Controller (Cr)        |
                       +-------------------------------+
                          //   /            \   \\
                         //   /              \   \\
                      A //   /                \   \\ A
                       //   /                  \   \\
                      //   /  B             B   \   \\
                     //   /                      \   \\
    +------------------------+           +------------------------+
    | +----------------------+     A     | +------------------------+
    | |                      |===========| |                        |
    | |    Consumer (C)      |-----------| |      Provider (P)      |
    +-|                      |     C     +-|                        |
       +---------------------+             +------------------------+

                      Figure 2: Communications Model

   SACM's focus is on the automation of collection, verification and
   update of system security configurations pertaining to endpoint
   assessment.  In order to carry out these tasks, the architectural
   components shown in Figure 1 can be further refined as:

   Posture Assessment Information

   Providers:  a Provider may be dedicated to perform either the
    collection, aggregation or evaluation of one or more posture
    attributes whose results can be conveyed to a Posture Assessment Information Consumer.  In this
    example form of the SACM architecture model, these are shown as
    Collection, Evaluation, and Results Providers.  Note that there may
    be posture attributes or posture assessment information that
    articulates Guidance information which may or may not be present in
    the architecture.

   Posture Assessment Information

   Consumers:  a Consumer may request or receive one or more posture
    attributes or posture assessment information from a Posture Assessment Information Provider for
    their own use.  In this example form of the SACM architecture model,
    these are shown as Collection, Evaluation, and Results Consumers.
    Note that there may be posture attributes or posture assessment
    information articulating Guidance information which may or may not
    be present in the architecture to be provided or consumed.

   Data Stores:  a Data Store is both a Provider and a Consumer, storing
    one or more posture attributes or assessments for endpoints.  It
    should be understood that these repositories interface directly to a
    Provider or Consumer (and Guidance) but the interfaces used to
    interact between them is outside the scope of SACM (e.g. no
    interface arrows are shown in the architecture).

   Figure 3 illustrates an example flow for how Posture Assessment
   Information may flow.

                                   +-------------+
                                    |Evaluation   |
                   +-------------+  |Guidance     +--+
                   |Endpoint     |  |Capability  |Function     |  |
           +-------+             |  +-------------+  |
           |       |             |                   |
           |       +-------+-----+             +-----v-------+
           | Collection    |                   |Evaluation   |
         +-> Capability Function   +--+--------+          |Capability          |Function     |
         | |            |Collection |    +-----------+   +----------+
         | +------------+Provider   |    |           |---|          |
         |              |           |    |Collection |   |Evaluation|
         |              |           |    |Consumer   |   |Provider  |
         |              +----+------+    +----^------+   +---+------+
        ++---------+         |                |              |
        |Collection|   +-----v------+     +---+--------+     |
        |Guidance  |   |            |     |Collection  |     |
        |Capability|
        |Function  |   |Collection  |     |Provider    |     |
        |          |   |Consumer    |-----|            |     |
        +----------+   +------------+     +------------+     |
                                  | Collection |             |
                                  | Data Store |             |
                                  +------------+             |
                                                             |
            +--------------+           +---------------+     |
            |Evaluation    |           |Evaluation     |     |
            |Results       |           |Consumer       <-----+
            |Provider      |-----------|               |
            +-----+--------+           +---------------+
                  |     |Results Reporting|
                  |     |Capability     |Function         |
                  |     +------------^----+
                  |                  |
            +-----v--------+    +----+------+
            |Evaluation    |    |Reporting  |
            |Results       |    |Guidance   |
            |Consumer      |    |Data Store |
            +---+----------+    +-----------+ +-------------+
                |                             | Results     |
                +-----------------------------> Data Store  |
                                              |             |
                                              +-------------+

                Figure 3: Example Posture Information Flow

   TODO - add example of / more content around interactions with
   endpoint, possible communications patterns

6.

8.  Acknowledgements

   The authors would like to thank Jim Bieda, Henk Birkholz, Jessica
   Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David
   Waltermire for participating in architecture design discussions,
   reviewing, and contributing to this draft.

7.

9.  IANA Considerations

   This memo includes no request to IANA.

8.

10.  Security Considerations

   The SACM architecture defines three main components that interface
   with each other both for management and control (in the control
   plane) and for the sharing of Posture Assessment Information.
   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 (MitM) 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,
   disclosure (e.g. where privacy may be needed), 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.

11.  References

9.1.

11.1.  Normative References

   [I-D.ietf-sacm-requirements]
              Cam-Winget, N. and L. Lorenzin, "Secure Automation and
              Continuous Monitoring (SACM) Requirements", draft-ietf-
              sacm-requirements-03
              sacm-requirements-08 (work in progress), January July 2015.

   [I-D.ietf-sacm-terminology]
              Waltermire, D., Montville, A., Harrington, D., Cam-Winget,
              N., Lu, J., Ford, B., and M. Kaeo, "Terminology for
              Security Assessment", draft-ietf-sacm-terminology-06
              Birkholz, H., "Secure Automation and Continuous Monitoring
              (SACM) Terminology", draft-ietf-sacm-terminology-07 (work
              in progress), February July 2015.

   [I-D.ietf-sacm-use-cases]
              Waltermire, D. and D. Harrington, "Endpoint Security
              Posture Assessment - Enterprise Use Cases", draft-ietf-
              sacm-use-cases-08
              sacm-use-cases-10 (work in progress), February July 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997.

9.2. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

11.2.  Informative References

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              DOI 10.17487/RFC3444, January
              2003. 2003,
              <http://www.rfc-editor.org/info/rfc3444>.

   [RFC5209]  Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
              Tardo, "Network Endpoint Assessment (NEA): Overview and
              Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008. 2008,
              <http://www.rfc-editor.org/info/rfc5209>.

Authors' Addresses
   Nancy Cam-Winget (editor)
   Cisco Systems
   3550 Cisco Way
   San Jose, CA  95134
   US

   Email: ncamwing@cisco.com

   Lisa Lorenzin
   Pulse Secure
   2700 Zanker Rd, Suite 200
   San Jose, CA  95134
   US

   Email: llorenzin@pulsesecure.net

   Ira E McDonald
   High North Inc
   PO Box 221
   Grand Marais, MI  49839
   US

   Email: blueroofmusic@gmail.com

   Aaron Woland
   Cisco Systems
   1900 South Blvd. Suite 200
   Charlotte, NC  28203
   US

   Email: loxx@cisco.com