diff --git a/.travis.yml b/.travis.yml index 3698226..abd071b 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,4 +1,7 @@ language: python +python: +- 2.7 +sudo: required rvm: - 2.2.0 before_install: @@ -7,7 +10,10 @@ before_install: install: - deactivate - sudo pip install xml2rfc -script: +- ruby --version +- gem install kramdown-rfc2629 +script: +- ls - make ghpages env: global: diff --git a/Makefile b/Makefile index ff34367..37fd7ad 100644 --- a/Makefile +++ b/Makefile @@ -33,7 +33,7 @@ ps2pdf ?= ps2pdf ## Work out what to build -draft := $(basename $(lastword $(sort $(wildcard draft-*.xml)) $(sort $(wildcard draft-*.org)))) +draft := $(basename $(lastword $(sort $(wildcard draft-*.md)) $(sort $(wildcard draft-*.xml)) $(sort $(wildcard draft-*.org)))) ifeq (,$(draft)) $(warning No file named draft-*.md or draft-*.xml or draft-*.org) diff --git a/draft-ietf-sacm-architecture.txt b/draft-ietf-sacm-architecture.txt deleted file mode 100644 index e895f59..0000000 --- a/draft-ietf-sacm-architecture.txt +++ /dev/null @@ -1,1064 +0,0 @@ - - - - -SACM N. Cam-Winget, Ed. -Internet-Draft Cisco Systems -Intended status: Informational L. Lorenzin -Expires: January 2, 2016 Pulse Secure - I. McDonald - High North Inc - A. Woland - Cisco Systems - July 2015 - - - Secure Automation and Continuous Monitoring (SACM) Architecture - draft-ietf-sacm-architecture-latest - -Abstract - - This document defines an architecture for standardization of - interfaces, protocols, and information models related to security - automation and continuous monitoring. It describes the basic - architecture, components, and 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 January 2, 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 - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 1] - -Internet-Draft SACM Architecture July 2015 - - - 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 . . . . . . . . . . . . . . . . . . . . . 5 - 3.1.1. Provider . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.2. Consumer . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.3. Types of Providers and Controllers . . . . . . . . . 7 - 3.1.3.1. Collector . . . . . . . . . . . . . . . . . . . . 7 - 3.1.3.2. Evaluator . . . . . . . . . . . . . . . . . . . . 8 - 3.1.3.3. Report Generator . . . . . . . . . . . . . . . . 9 - 3.1.3.4. Data Store . . . . . . . . . . . . . . . . . . . 9 - 3.1.4. Controller . . . . . . . . . . . . . . . . . . . . . 9 - 4. Interfaces between Consumers, Providers, and Controllers . . 11 - 5. Component Functions . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. Control Plane Functions . . . . . . . . . . . . . . . . . 12 - 5.2. Data Plane Functions . . . . . . . . . . . . . . . . . . 13 - 6. Component Capabilities . . . . . . . . . . . . . . . . . . . 13 - 7. Example Illustration of Functions and Workflow . . . . . . . 13 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 11.2. Informative References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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. - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 2] - -Internet-Draft SACM Architecture July 2015 - - - This document addresses general and architectural requirements - defined in [I-D.ietf-sacm-requirements]. The architecture 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 "Where" and "How" - information and assessment of posture may be collected, 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 - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 3] - -Internet-Draft SACM Architecture July 2015 - - - 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 component - roles are defined: a Consumer (C), a 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: - - - - - - - - - - - - - - - - - - - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 4] - -Internet-Draft SACM Architecture July 2015 - - - +--------------------------------------+ - | +--------------------------------------+ - | | +--------------------------------------+ - | | | | - +-| | Consumer (C) | - +-| | - +--------------------------------------+ - / \ / \ / \ - / \ / \ / \ - - - - d - - - - || ||A | a |B | |C - || || | t | | | - - - - a - | | - \ / \ / | | - \ / \ / | | - /|---------------------|\ | | - /|----/ \--------| d |--|\ - / / Controller (Cr) \ ctrl | a | \ - \ \ / plane | t | / - \|----\ /--------| a |--|/ - \|---------------------|/ | | - / \ / \ | | - / \ / \ | | - - - - d - | | - || ||A | a |B | |C - || || | t | | | - - - - a - - - - \ / \ / \ / - \ / \ / \ / - +------------------------------------+ - | |-+ - | Provider (P) | | - | | |-+ - +------------------------------------+ | | - +------------------------------------+ | - +------------------------------------+ - - - - - Figure 1: Simple Architectural Model - -3.1. Component Roles - - An endpoint, as defined in [I-D.ietf-sacm-terminology], can operate - in two primary ways: as the target of an assessment, and/or as a - functional component of the SACM architecture that can instantiate - one or more functions (see Section 5). In the SACM architecture, - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 5] - -Internet-Draft SACM Architecture July 2015 - - - individual endpoints may be a target endpoint, 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 Provider, - Consumer, and/or Controller. - -3.1.1. Provider - - The 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 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.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. Consumer - - The 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 5.2), or an application that consumes Posture Assessment - Information in order to perform another function. - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 6] - -Internet-Draft SACM Architecture July 2015 - - - 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 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 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.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. Types of Providers and Controllers - - SACM Providers and Consumers can perform a variety of SACM-related - tasks. For example, a Collector can perform Collection tasks; an - Evaluator can perform Evaluation tasks. A single Provider or - Consumer may be able to perform only one task, or multiple tasks. - SACM defines the following types of Providers/Consumers: - -3.1.3.1. Collector - - A collector consumes Guidance and/or other Posture Assessment - Information; it provides Posture Assessment Information. Collectors - may be internal or external. - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 7] - -Internet-Draft SACM Architecture July 2015 - - -3.1.3.1.1. Internal Collector - - An internal collector is a collector that runs on the endpoint and - collects posture information locally. - -3.1.3.1.2. External Collector - - An external collector is a collector that observes endpoints from - outside. These collectors may be configured and operated to manage - assets for reasons including, but not limited to, posture assessment. - Collectors that are not primarily intended to support posture - assessment (e.g. intrusion detection systems) may still provide - information that speaks to endpoint posture (e.g. behavioral - information). - - Examples: - - o A RADIUS server, which collects information about which endpoints - have logged onto 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 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 - 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, Evaluation - Results, and/or Guidance; it provides Evaluation Results. An - evaluator may consume endpoint attribute assertions, previous - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 8] - -Internet-Draft SACM Architecture July 2015 - - - evaluations of posture attributes, or previous reports of Evaluation - Results. - - TODO: update the terminology doc to reflect this definition - - Example: a NEA posture validator [RFC5209] - -3.1.3.3. Report Generator - - A report generator consumes 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., a weekly report may be created from daily - reports) - - It may summarize data continually, as the data arrives. It also may - summarize data in response to an ad hoc query. - -3.1.3.4. Data Store - - A data store consumes any data; it provides any data. - -3.1.4. Controller - - The Controller (Cr or Controller) is a component defined to - facilitate information sharing and to execute on security functions - and overall SACM management and control system functions. SACM - defines three types of Controller: - - Broker: Intermediary negotiating connection between Provider and - Consumer. Implements only control plane functions. A Controller - acting as a Broker: - - o Receives a request for information from a Consumer and instructs - the Consumer where and how retrieve the requested information. - - o Receives a publication request from a Provider and instructs the - Provider where and how to deliver the published information. - - The information itself is neither distributed nor stored by the - Controller. - - Proxy: Intermediary negotiating on behalf of a Consumer or Provider. - Implements both control and data plane functions. A Controller - acting as a Proxy: - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 9] - -Internet-Draft SACM Architecture July 2015 - - - o Receives a request for information from a Consumer, retrieves the - information from the appropriate Providers, and provides the - information to the Consumer. - - o Receives a publication request from a Provider, accepts the - 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 Provider, - and providing stored data to a Consumer. Implements both control - and data plane functions. A Controller acting as a Repository: - - o Receives a request for information from a Consumer, retrieves the - information from its data stores, and provides the information to - the Consumer. - - o Receives a publication request from a provider, stores the - published information, and distributes it to appropriate - Consumers. - - The information itself is both handled by and stored by the - Controller. - - A single instantiation of a Controller may be a Broker, Proxy, or - Repository, or any combination thereof. - - Through the use of a discovery mechanism, Consumers can have - visibility into the Providers present, the type(s) of Posture - Assessment Information available, and how it can be requested. - Similarly, a Provider may need to publish what Posture Assessment - Information it can share and how it can share it (e.g. protocol, - filtering capabilities, etc.). Enabling this visibility through a - Controller or through metadata publication also allows for the - distinct definition of security considerations (e.g. authorized - registration / publication of capabilities by Providers) beyond how a - Provider may define its own capability. - - Beyond the control and management functions for the SACM system, a - Controller may also provide proxy or broker or repository (and - possibly routing) services in the data plane. In the deployment - scenario where Providers do not assert the need to know their - Consumers and/or vice versa, the Controller can thus provide the - appropriate services to ensure the Posture Assessment Information is - appropriately communicated from the Providers to the authorized - Consumers. - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 10] - -Internet-Draft SACM Architecture July 2015 - - - The Controller, acting as a management control plane, helps define - how to manage an overall SACM system that allows for Consumers to - obtain the desired Posture Assessment Information without the need to - distinctly know and establish one (Consumer) to many (Provider) - connections. Similarly, a Provider may not need to distinctly know - and establish one (Provider) to many (Consumer) connections; e.g. the - Controller enables the means to allow a SACM system to support many - to many connections. Note that the Controller also allows for the - direct discovery and connection between a Consumer and Provider. - - As a SACM component, the Controller may be instantiated within a - system or device acting as a Provider or a Consumer (or both), or as - its own distinct Controller entity. In a rich SACM environment, it - is feasible to instantiate a Controller that provides both the - management (and control) functions for SACM as well as providing the - data plane services for the actual data, e.g. Posture Assessment - Information flow. Note that Controllers may be implemented to only - provide control plane functions (broker), or both control plane - functions and data plane services (proxy or repository). - -4. Interfaces between Consumers, Providers, and Controllers - - A SACM interface is a transport carrying operations (e.g. publication - via a RESTful API). As shown in Figure 1, communication can proceed - with the following interfaces and expected functions and behaviors: - - A: interface "A" 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). - - B: interface "B" shown in Figure 1 enables Providers to share their - Posture Assessment Information spontaneously; similarly, it enables - Consumers to request information without having to know the - identities (or reachability) of all the Providers that can fulfill - Consumers' requests. - - C: interface "C" shown in Figure 1 illustrates 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 - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 11] - -Internet-Draft SACM Architecture July 2015 - - - as a management or control function through the abstracted - Controller role (e.g. the Controller could be a broker or could be - embedded in a Consumer or a Provider). - - A variety of protocols, such as SNMP, NETCONF, NEA protocols - [RFC5209], and other similar interfaces, may be used for collection - of data from the target endpoints by the Posture Information - Provider. Those interfaces are outside the scope of SACM. - -5. Component Functions - - SACM components are composed of a variety of functions, which may be - instantiated on a single endpoint or on separate standalone endpoints - providing various roles. An endpoint MUST implement one or more of - these functions to be considered a SACM component. A SACM solution - offers a set of functions across a set of SACM components. - - The functions described here are the minimum set that is mandatory to - implement in a SACM solution. A 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 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 actual information-sharing communication channel. - This supports use cases where: - - o Consumers may request information independent of knowing the - identities of the Providers. - - o Providers may 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 the Consumers and - Providers independent of the 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. - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 12] - -Internet-Draft SACM Architecture July 2015 - - - 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 how access control may be effected via Authentication, - Authorization, and Accounting Systems (e.g. AAA services), the same - principle is defined; as AAA services depend on Identity Management - services, the Controller will need a similar function and interface - to Identity Management services. - - Registration/Discovery: The discovery of what Providers are - available, what information a Provider can share, and how it can be - requested / communicated. A discovery mechanism is required to - facilitate interaction with Providers that may have different - Posture Assessment Information and potentially limited, or a rich - set of, ways in which they can share the information. - -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 model, data operations, or SACM transport - - TODO: data plane capabilities / control plane capabilities can be - discovered via querying the controller - -7. Example Illustration of Functions and Workflow - - TODO: once the group reaches consensus on content for the previous - sections, revise all this text based upon the agreed-upon - architecture - - - - - - - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 13] - -Internet-Draft SACM Architecture July 2015 - - - +-------------------------------+ - | +-------------------------------+ - | | | - +-| 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: - - 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 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. - - Consumers: a Consumer may request or receive one or more posture - attributes or posture assessment information from a 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 - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 14] - -Internet-Draft SACM Architecture July 2015 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 15] - -Internet-Draft SACM Architecture July 2015 - - - +-------------+ - |Evaluation | - +-------------+ |Guidance +--+ - |Endpoint | |Function | | - +-------+ | +-------------+ | - | | | | - | +-------+-----+ +-----v-------+ - | Collection | |Evaluation | - +-> Function +--+--------+ |Function | - | | |Collection | +-----------+ +----------+ - | +------------+Provider | | |---| | - | | | |Collection | |Evaluation| - | | | |Consumer | |Provider | - | +----+------+ +----^------+ +---+------+ - ++---------+ | | | - |Collection| +-----v------+ +---+--------+ | - |Guidance | | | |Collection | | - |Function | |Collection | |Provider | | - | | |Consumer |-----| | | - +----------+ +------------+ +------------+ | - | Collection | | - | Data Store | | - +------------+ | - | - +--------------+ +---------------+ | - |Evaluation | |Evaluation | | - |Results | |Consumer <-----+ - |Provider |-----------| | - +-----+--------+ +---------------+ - | |Results Reporting| - | |Function | - | +------------^----+ - | | - +-----v--------+ +----+------+ - |Evaluation | |Reporting | - |Results | |Guidance | - |Consumer | |Data Store | - +---+----------+ +-----------+ +-------------+ - | | Results | - +-----------------------------> Data Store | - | | - +-------------+ - - - - - Figure 3: Example Posture Information Flow - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 16] - -Internet-Draft SACM Architecture July 2015 - - - TODO - add example of / more content around interactions with - endpoint, possible communications patterns - -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. - -9. IANA Considerations - - This memo includes no request to IANA. - -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 - 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, - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 17] - -Internet-Draft SACM Architecture July 2015 - - - 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. - -11. References - -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-09 (work in progress), July 2015. - - [I-D.ietf-sacm-terminology] - Birkholz, H., "Secure Automation and Continuous Monitoring - (SACM) Terminology", draft-ietf-sacm-terminology-07 (work - in progress), 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-10 (work in progress), 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, - . - -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, - . - - [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, - . - -Authors' Addresses - - - - - - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 18] - -Internet-Draft SACM Architecture July 2015 - - - 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 - - - - - - - - - - - - - - - - - -Cam-Winget, et al. Expires January 2, 2016 [Page 19] diff --git a/draft-ietf-sacm-architecture.xml b/draft-ietf-sacm-architecture.xml deleted file mode 100644 index 6a06f9e..0000000 --- a/draft-ietf-sacm-architecture.xml +++ /dev/null @@ -1,986 +0,0 @@ - - - - - - - - - - - - - - - - - - Secure Automation and Continuous Monitoring (SACM) Architecture - - - Cisco Systems -
- - 3550 Cisco Way - San Jose - CA - 95134 - US - - ncamwing@cisco.com -
- - - Pulse Secure -
- - 2700 Zanker Rd, Suite 200 - San Jose - CA - 95134 - US - - llorenzin@pulsesecure.net -
- - - High North Inc -
- - PO Box 221 - Grand Marais - MI - 49839 - US - - blueroofmusic@gmail.com -
- - - Cisco Systems -
- - 1900 South Blvd. Suite 200 - Charlotte - NC - 28203 - US - - loxx@cisco.com -
- - - - - Security - SACM - template - - - - -This document defines an architecture for standardization of interfaces, -protocols, and information -models related to security automation and continuous monitoring. It describes -the basic architecture, components, and interfaces defined to enable the -collection, acquisition, -and verification of Posture -and Posture Assessments. - - - - - - - - - - - -
- -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 . -The architecture 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 . - -
-
- -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. - -
-
- -At a high level, the SACM architecture describes “Where” and “How” information -and assessment of posture may be collected, 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 component roles are -defined: a Consumer (C), a Provider (P), and a Controller (Cr) used to facilitate -some of the security functions such as authentication and authorization and -other metadata functions. See 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 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 for details on interfaces. - - illustrates the relationships between component roles and interfaces: - -
- -
- -An endpoint, as defined in , can 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 functions (see ). -In the SACM architecture, individual endpoints may be a target endpoint, -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 Provider, Consumer, and/or Controller. - -
- -The 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 ), 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 ). - -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. - -
-
- -The 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 ), -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 , -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 -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 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 ) 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. - -
-
- -SACM Providers and Consumers can perform a variety of SACM-related tasks. -For example, a Collector can perform Collection tasks; an Evaluator can -perform Evaluation tasks. A single Provider or Consumer may be able to perform -only one task, or multiple tasks. SACM defines the following types of Providers/Consumers: - -
- -A collector consumes Guidance and/or other Posture Assessment Information; -it provides Posture Assessment Information. Collectors may be internal or -external. - -
- -An internal collector is a collector that runs on the endpoint and collects -posture information locally. - -
-
- -An external collector is a collector that observes endpoints from outside. -These collectors may be configured and operated to manage assets for reasons -including, but not limited to, posture assessment. Collectors that are not -primarily intended to support posture assessment (e.g. intrusion detection -systems) may still provide information that speaks to endpoint posture (e.g. -behavioral information). - -Examples: - - - A RADIUS server, which collects information about which endpoints have logged -onto the network - A network profiling system, which collects information by discovering and -classifying network nodes - A Network Intrusion Detection System (NIDS) sensor, which collects information -about endpoint behavior by observing network traffic - A vulnerability scanner, which collects information about endpoint configuration -by scanning endpoints - A hypervisor, which collects information about endpoints running as virtual -guests in its host environment - A management system that configures and installs software on the endpoint, -which collects information based on its provisioning activities - - -
-
- -TODO - examples of endpoint interactions with local internal collector (e.g. -NEA client), endpoint with remote internal collector (SNMP query), and external -collector (sensor) - -
-
-
- -An evaluator consumes Posture Assessment Information, Evaluation Results, -and/or Guidance; it provides Evaluation Results. An evaluator may consume -endpoint attribute assertions, previous evaluations of posture attributes, -or previous reports of Evaluation Results. - -TODO: update the terminology doc to reflect this definition - -Example: a NEA posture validator - -
-
- -A report generator consumes Posture Assessment Information, Evaluation Results, -and/or Guidance; it provides reports. These reports are based on: - - - Endpoint Attribute Assertions, including Evaluation Results - Other Reports (e.g., a weekly report may be created from daily reports) - - -It may summarize data continually, as the data arrives. It also may summarize -data in response to an ad hoc query. - -
-
- -A data store consumes any data; it provides any data. - -
-
-
- -The Controller (Cr or Controller) is a component defined to facilitate information -sharing and -to execute on security functions and overall SACM management and control -system functions. SACM defines three types of Controller: - - - - Intermediary negotiating connection between Provider and Consumer. Implements -only control plane functions. A Controller -acting as a Broker: - - - - Receives a request for information from a Consumer and instructs the Consumer -where and how -retrieve the requested information. - Receives a publication request from a Provider and instructs the Provider -where and how to -deliver the published information. - - -The information itself is neither distributed nor stored by the Controller. - - - - Intermediary negotiating on behalf of a Consumer or Provider. Implements -both control and data plane functions. A Controller -acting -as a Proxy: - - - - Receives a request for information from a Consumer, retrieves the information -from the -appropriate Providers, and provides the information to the Consumer. - Receives a publication request from a Provider, accepts the published information, -and -distributes it to appropriate consumers. - - -The information itself is distributed by, but not stored by, the Controller. - - - - Intermediary receiving and storing data from a Provider, and providing stored -data to a Consumer. Implements both control and data plane functions. A -Controller acting as a Repository: - - - - Receives a request for information from a Consumer, retrieves the information -from its data -stores, and provides the information to the Consumer. - Receives a publication request from a provider, stores the published information, -and -distributes it to appropriate Consumers. - - -The information itself is both handled by and stored by the Controller. - -A single instantiation of a Controller may be a Broker, Proxy, or Repository, -or any combination thereof. - -Through the use of a discovery mechanism, Consumers can have visibility into -the Providers -present, the type(s) of Posture Assessment Information available, and how -it can be requested. -Similarly, a Provider may need to publish what Posture Assessment Information -it can share and -how it can share it (e.g. protocol, filtering capabilities, etc.). Enabling -this visibility -through a Controller or through metadata publication also allows for the -distinct definition of -security considerations (e.g. authorized registration / publication of capabilities -by Providers) -beyond how a Provider may define its own capability. - -Beyond the control and management functions for the SACM system, a Controller -may also provide -proxy or broker or repository (and possibly routing) services in the -data plane. In the deployment -scenario where Providers do not assert the need to know their Consumers and/or -vice versa, the -Controller can thus provide the appropriate services to ensure the Posture -Assessment Information -is appropriately communicated from the Providers to the authorized Consumers. - -The Controller, acting as a management control plane, helps define how to -manage an overall SACM -system that allows for Consumers to obtain the desired Posture Assessment -Information without the need -to distinctly know and establish one (Consumer) to many (Provider) connections. -Similarly, a Provider -may not need to distinctly know and establish one (Provider) to many (Consumer) -connections; e.g. the -Controller enables the means to allow a SACM system to support many to many -connections. Note that the -Controller also allows for the direct discovery and connection between a -Consumer and Provider. - -As a SACM component, the Controller may be instantiated within a system or -device acting as a -Provider or a Consumer (or both), or as its own distinct Controller entity. -In a rich SACM environment, -it is feasible to instantiate a Controller that provides both the management -(and control) functions for -SACM as well as providing the data plane services for the actual data, -e.g. Posture Assessment Information flow. Note that Controllers may be implemented -to only provide control plane functions (broker), or both control plane functions -and data plane services (proxy or repository). - -
-
-
-
- -A SACM interface is a transport carrying operations (e.g. publication via -a RESTful API). As shown in , communication can proceed with -the following interfaces and expected functions and behaviors: - - - - interface “A” shown in 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). - - interface “B” shown in 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. - - interface “C” shown in illustrates 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 Controller role (e.g. the Controller -could be -a broker or could be embedded in a Consumer or a Provider). - - -A variety of protocols, such as SNMP, NETCONF, NEA protocols , and other similar interfaces, -may be used for collection of data from the target endpoints by the Posture -Information Provider. -Those interfaces are outside the scope of SACM. - -
-
- -SACM components are composed of a variety of functions, which may be instantiated -on a single endpoint or on separate standalone endpoints providing various -roles. An endpoint MUST implement one or more of these functions to be considered -a SACM component. A SACM solution offers a set of functions across a set -of SACM components. - -The functions described here are the minimum set that is mandatory to implement -in a SACM solution. A SACM solution MAY implement additional functions. - -
- -Control plane functions represent various services offered by the Controller -to the Providers -and Consumers to facilitate sharing of information. Control plane functions -include, but are not limited to: - - - - The authentication of Consumers and Providers -independent of the actual information-sharing communication channel. This -supports -use cases where: - - - - Consumers may request information independent of knowing the identities of -the -Providers. - Providers may 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 the Consumers and Providers independent of -the -actual information-sharing communication channel. - - - - The restriction of Posture Assessment Information sharing -between the Consumers and Providers. At minimum, a management function must -define -the necessary policies. - - 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 how access control may be effected -via Authentication, -Authorization, and Accounting Systems (e.g. AAA services), the same principle -is defined; as -AAA services depend on Identity Management services, the Controller will -need a similar function -and interface to Identity Management services. - - - - The discovery of what Providers are available, what -information a Provider can share, and how it can be requested / communicated. -A discovery -mechanism is required to facilitate interaction with Providers that may have -different -Posture Assessment Information and potentially limited, or a rich set of, -ways in which -they can share the information. - - -
-
- -Subscription - -Publication - -Query - -
-
-
- -TODO: add a discussion of “capability” as being able to talk a specific data -model, data operations, or SACM transport - -TODO: data plane capabilities / control plane capabilities can be discovered -via querying the controller - -
-
- -TODO: once the group reaches consensus on content for the previous sections, -revise all this text based upon the agreed-upon 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 can be further refined as: - - - - 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 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. - - a Consumer may request or receive one or more posture attributes or posture -assessment information from a 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. - - 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). - - - illustrates an example flow for how Posture Assessment Information may flow. - -
Function +--+--------+ |Function | - | | |Collection | +-----------+ +----------+ - | +------------+Provider | | |---| | - | | | |Collection | |Evaluation| - | | | |Consumer | |Provider | - | +----+------+ +----^------+ +---+------+ - ++---------+ | | | - |Collection| +-----v------+ +---+--------+ | - |Guidance | | | |Collection | | - |Function | |Collection | |Provider | | - | | |Consumer |-----| | | - +----------+ +------------+ +------------+ | - | Collection | | - | Data Store | | - +------------+ | - | - +--------------+ +---------------+ | - |Evaluation | |Evaluation | | - |Results | |Consumer <-----+ - |Provider |-----------| | - +-----+--------+ +---------------+ - | |Results Reporting| - | |Function | - | +------------^----+ - | | - +-----v--------+ +----+------+ - |Evaluation | |Reporting | - |Results | |Guidance | - |Consumer | |Data Store | - +---+----------+ +-----------+ +-------------+ - | | Results | - +-----------------------------> Data Store | - | | - +-------------+ - - - -]]>
- -TODO - add example of / more content around interactions with endpoint, possible -communications patterns - -
-
- -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. - -
-
- -This memo includes no request to IANA. - -
-
- -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 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. - -
- - - - - - - - - - - - - - -Key words for use in RFCs to Indicate Requirement Levels - - -In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. - - - - - - - - - - -Endpoint Security Posture Assessment - Enterprise Use Cases - - - - - - - - - - - -This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture. - - - - - - - - - - - -Secure Automation and Continuous Monitoring (SACM) Requirements - - - - - - - - - - - -This document defines the scope and set of requirements for the Secure Automation and Continuous Monitoring (SACM) architecture, data model and transport protocols. The requirements and scope are based on the agreed upon use cases. - - - - - - - - - - - -Secure Automation and Continuous Monitoring (SACM) Terminology - - - - - - - -This memo documents terminology used in the documents produced by SACM (Security Automation and Continuous Monitoring). - - - - - - - - - - - - - - - - - - - - -Network Endpoint Assessment (NEA): Overview and Requirements - - - - - - -This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. This memo provides information for the Internet community. - - - - - - - - - -On the Difference between Information Models and Data Models - - - -There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. - - - - - - - - - - - - - - -