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]