Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Nancy Cam-Winget , Brian Ford , Lisa Lorenzin, Ira McDonald , loxx at cisco
Last updated 2014-10-14
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-sacm-architecture-00
SACM                                                  N. Cam-Winget, Ed.
Internet-Draft                                                   B. Ford
Intended status: Informational                             Cisco Systems
Expires: April 16, 2015                                      L. Lorenzin
                                                            Pulse Secure
                                                             I. McDonald
                                                          High North Inc
                                                               A. Woland
                                                           Cisco Systems
                                                        October 13, 2014

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

Abstract

   This document describes 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 April 16, 2015.

Copyright Notice

   Copyright (c) 2014 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

Cam-Winget, et al.       Expires April 16, 2015                 [Page 1]
Internet-Draft              Abbreviated Title               October 2014

   (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.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   3
     2.1.  Posture Assessment Information Consumer . . . . . . . . .   4
     2.2.  Posture Assessment Information Provider . . . . . . . . .   5
     2.3.  Control Plane . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Interfaces between Consumers, Providers and Control Plane   7
   3.  Example mapping to SACM Architecture  . . . . . . . . . . . .   8
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Several data models and protocols 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 describes an architecture to enable standardized
   collection, acquisition, and verification of Posture and Posture
   Assessments.  The architecture will include the components and
   interfaces that can be used to better identify the Information Model,
   type(s) of transport protocols needed for communication, and further,
   provide a model from which requirements can be drawn.

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

Cam-Winget, et al.       Expires April 16, 2015                 [Page 2]
Internet-Draft              Abbreviated Title               October 2014

2.  Architectural Overview

   At a high level, the architecture describes 'How' and 'Where'
   information and assessment of posture may be collected, processed or
   assessed.  The core components are shown in Figure 1.  Three main
   functional components are defined: a Posture Assessment Information
   Consumer (C), a Posture Assessment Information Provider (P) and a
   Control Plane (CP) used to facilitate some of the security functions
   such as authentication and authorization and other metadata
   functions.

Cam-Winget, et al.       Expires April 16, 2015                 [Page 3]
Internet-Draft              Abbreviated Title               October 2014

                       +-----------------------------------+
                       | +-----------------------------------+
                       | | +-----------------------------------+
                       | | |                                   |
                       +-| |      Posture Assessment           |
                         +-|      Information Consumer (C)     |
                           +-----------------------------------+
                             /    \         /   \        /   \
                            /      \       /     \      /     \
                            -      -       -     -      -     -
                           A |    |         || ||B       |   |C
                             |    |         || ||        |   |
                             |    |        -     -      -     -
                             |    |        \     /      \     /
                             |    |         \   /        \   /
                   /|--------|    |------------------------------------------------ |\
                  /   --------------------------------------------------------------  \
                 /    Broker/Proxy/Repository: AuthZ, Directory, metadata/capability   \
                 \                    [Control Plane (CP)]                             /
                  \   --------------------------------------------------------------  /
                   \|--------|    |------------------------------------------------ |/
                           A |    |         || ||B       |   |C
                             |    |         || ||        |   |
                            -      -       -     -      -     -
                            \      /       \     /      \     /
                             \    /         \   /        \   /
                           +-----------------------------------+
                           |                                   |-+
                           |     Posture Assessment            | |
                           |    Information Provider (P)       | |-+
                           |                                   | | |
                           +-----------------------------------+ | |
                             +-----------------------------------+ |
                               +-----------------------------------+

                        Simple Architectural Model

   The functional components in the proposed architecture are further
   described in this section.

2.1.  Posture Assessment Information Consumer

   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

Cam-Winget, et al.       Expires April 16, 2015                 [Page 4]
Internet-Draft              Abbreviated Title               October 2014

   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.  Thus, the architectural
   component to enable such requests is defined as a Posture Assessment
   Information Consumer (C or Consumer).

   The Consumer defines the capabilities and functions that must be
   handled in order to facilitiate a Posture Assessment Information
   Request.  Requests can be either for a single posture attribute or a
   set of posture attributes where those attributes can be the raw
   information or an evaluated or assessed state 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 Posture Assessment Information Provider (P or 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.

   The Control Plane (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.

2.2.  Posture Assessment Information Provider

   The Posture Assessment Information Provider (P or Provider) is the
   component that contributes Posture Assessment Information either
   spontaneously or in response to a request.  A Provider can be a
   Posture Evaluator, Posture Collector, or an application that has
   aggregated Posture Assessment Information that can be shared.

   The Provider defines the capabilities and functions that must be
   handled to share or provide Posture Assessment information.  A
   Provider may provide the information spontaneously, or in response to
   a direct request from a Consumer.  The information may be filtered or
   truncated to honor the request either by the Consumer's request, or
   the Providers's ability to filter (or provide only a subset of the
   requested information) or due to security considerations (e.g.
   authorization restrictions due to domain segregation, privacy, etc.).

Cam-Winget, et al.       Expires April 16, 2015                 [Page 5]
Internet-Draft              Abbreviated Title               October 2014

   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.  It may also choose to advertise its capabilities
   through a metadata abstraction.

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

2.3.  Control Plane

   The Control Plane may be an abstracted component but is distinctly
   defined as a component to execute on some of the security functions
   and overall system functions.  Some of the functions include:

   Authentication:  with use cases where Consumers may request
    information independent of knowing the identities of the Providers
    and Providers may want to share the information unsolicited, the
    architecture must account for an abstraction where a control plane
    or a broker may be defined to affect the authentication of the
    Consumers and Providers independent of the actual information
    sharing communication channel.

   Authorization:  to address security for how Posture Assessment
    Information is shared between the Consumers and Providers, at
    minimum a management function to define those policies are needed.
    However, with the introduction of the control plane with use cases
    where R's may request information independent of knowing the
    identities of the P's and Providers (P's) wanting to share the
    information unsolicited, the architecture must account for an
    abstraction where a control plane or a broker may be defined to
    affect the authentication of the R's and P's independent of the
    actual information sharing communication channel.

   Identity Management:  As typically, Identity Management for
    authentication and authorization policies are best defined through a
    centralized component, the Control Plane also provides those
    services.

   Discovery/Registration:  a discovery mechanism is required to
    facilitate the interaction of Providers that may have different
    Posture Assessment Information and potentially limited (or a rich
    set) of ways in which they can share the information; that is,
    through the discovery mechanism Consumers can have visibility of the
    Providers present and the type(s) of Posture Assessment Information
    that is available and how it can be requested.  Similarly, a

Cam-Winget, et al.       Expires April 16, 2015                 [Page 6]
Internet-Draft              Abbreviated Title               October 2014

    Provider may need to register its "capability" for the Posture
    Assessment Information it can share and how it can share it (e.g.
    protocol or with filtering capabilities).  Enabling this function
    through a broker or control plane also allows for the distinct
    definition of security considerations (e.g. authorized registration
    of capabilities and of Providers) beyond how a Provider may define
    its own capability.

   The Control Plane also helps define how to manage an overall SACM
   system that allows for Consumers to obtain the desired Posture
   Assessment Information without the need to distinctly know and
   establish a one (Consumers) to many (Provider) connections.  Note
   that the Control Plane also allows for the direct discovery and
   connection between a Consumer and Provider.

2.4.  Interfaces between Consumers, Providers and Control Plane

   As shown in Figure 1, communication can proceed with the following
   interfaces and expected functions and behaviors:

   A:  interface "A" shown in Figure 1 demonstrates the ability and
    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 control
    plane component (e.g. the control plane could be a proxy or could be
    embedded in a Consumer or a Provider).

   B:  interface "B" shown in Figure 1 handles the management and
    control functions that are needed to establish, at minimum, a secure
    communication between Consumers and Providers.  The interface must
    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).

   C:  interface "C" 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.

Cam-Winget, et al.       Expires April 16, 2015                 [Page 7]
Internet-Draft              Abbreviated Title               October 2014

3.  Example mapping to SACM Architecture

   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 Provider:  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 many not be present in the
    architecture.

   Posture Assessment Information Consumer:  a Consumer may request or
    recieve 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 that articulates Guidance information which may or many
    not be present in the architecture to be Provided or Consumed.

   Repositories:  a Repository stores 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 2 illustrates an example flow for how posture information may
   flow.

Cam-Winget, et al.       Expires April 16, 2015                 [Page 8]
Internet-Draft              Abbreviated Title               October 2014

                                 +-------------+
                                  |Evaluation   |
                 +-------------+  |Guidance     +--+
                 |Endpoint     |  |Capability   |  |
         +-------+             |  +-------------+  |
         |       |             |                   |
         |       +-------+-----+             +-----v-------+
         | Collection    |                   |Evaluation   |
       +-> Capability +--+--------+          |Capability   |
       | |            |Collection |    +-----------+   +----------+
       | +------------+Producer   |    |           |---|          |
       |              |           |    |Collection |   |Evaluation|
       |              |           |    |Consumer   |   |Producer  |
       |              +----+------+    +----^------+   +---+------+
      ++---------+         |                |              |
      |Collection|   +-----v------+     +---+--------+     |
      |Guidance  |   |            |     |Collection  |     |
      |Capability|   |Collection  |     |Producer    |     |
      |          |   |Consumer    |-----|            |     |
      +----------+   +------------+     +------------+     |
                                | Collection |             |
                                | Repository |             |
                                +------------+             |
                                                           |
          +--------------+           +---------------+     |
          |Evaluation    |           |Evaluation     |     |
          |Results       |           |Consumer       <-----+
          |Producer      |-----------|               |
          +-----+--------+           +---------------+
                |     |Results Reporting|
                |     |Capability       |
                |     +------------^----+
                |                  |
          +-----v--------+    +----+------+
          |Evaluation    |    |Reporting  |
          |Results       |    |Guidance   |
          |Consumer      |    |Repository |
          +---+----------+    +-----------+ +-------------+
              |                             | Results     |
              +-----------------------------> Repository  |
                                            |             |
                                            +-------------+

                     Example Posture Information Flow

Cam-Winget, et al.       Expires April 16, 2015                 [Page 9]
Internet-Draft              Abbreviated Title               October 2014

4.  Acknowledgements

   The authors would like to thank Jessica Fitzgerald-McKay, Trevor
   Freeman, Jim Bieda and Adam Montville for participating in the
   architecture design discussions that lead to this draft.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   TBD.  This section will need to cover the AAA and confidentiality/
   integrity of the data and data transports to be considered.  Also,
   the considerations for the interfaces (which may be covered in
   transports) between the Consumers, Providers, and the Control Plane.

7.  References

7.1.  Normative References

   [I-D.ietf-sacm-terminology]
              Waltermire, D., Montville, A., Harrington, D., and N. Cam-
              Winget, "Terminology for Security Assessment", draft-ietf-
              sacm-terminology-05 (work in progress), August 2014.

   [I-D.ietf-sacm-use-cases]
              Waltermire, D. and D. Harrington, "Endpoint Security
              Posture Assessment - Enterprise Use Cases", draft-ietf-
              sacm-use-cases-07 (work in progress), April 2014.

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

7.2.  Informative References

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444, January
              2003.

   [RFC5209]  Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
              Tardo, "Network Endpoint Assessment (NEA): Overview and
              Requirements", RFC 5209, June 2008.

Cam-Winget, et al.       Expires April 16, 2015                [Page 10]
Internet-Draft              Abbreviated Title               October 2014

Authors' Addresses

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

   Email: ncamwing@cisco.com

   Brian Ford
   Cisco Systems
   5507-10 Nesconset Hwy #242
   Mt Sinai, NY  11766
   US

   Email: brford@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

Cam-Winget, et al.       Expires April 16, 2015                [Page 11]