--- 1/draft-ietf-sacm-arch-05.txt 2020-05-11 13:13:21.195040427 -0700 +++ 2/draft-ietf-sacm-arch-06.txt 2020-05-11 13:13:21.255041962 -0700 @@ -1,18 +1,18 @@ SACM Working Group A. Montville Internet-Draft B. Munyan Intended status: Standards Track CIS Expires: 12 November 2020 11 May 2020 Security Automation and Continuous Monitoring (SACM) Architecture - draft-ietf-sacm-arch-05 + draft-ietf-sacm-arch-06 Abstract This document defines an architecture enabling a cooperative Security Automation and Continuous Monitoring (SACM) ecosystem. This work is predicated upon information gleaned from SACM Use Cases and Requirements ([RFC7632] and [RFC8248] respectively), and terminology as found in [I-D.ietf-sacm-terminology]. WORKING GROUP: The source for this draft is maintained in GitHub. @@ -47,24 +47,24 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 - 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 + 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 - 3.1. SACM Role-based Architecture . . . . . . . . . . . . . . 4 + 3.1. SACM Role-based Architecture . . . . . . . . . . . . . . 5 3.2. Architectural Roles/Components . . . . . . . . . . . . . 5 3.2.1. Orchestrator(s) . . . . . . . . . . . . . . . . . . . 6 3.2.2. Repositories/CMDBs . . . . . . . . . . . . . . . . . 6 3.2.3. Integration Service . . . . . . . . . . . . . . . . . 6 3.3. Downstream Uses . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Reporting . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Analytics . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Sub-Architectures . . . . . . . . . . . . . . . . . . . . 7 3.4.1. Collection Sub-Architecture . . . . . . . . . . . . . 7 3.4.2. Evaluation Sub-Architecture . . . . . . . . . . . . . 10 @@ -75,59 +75,70 @@ 4.2. Management Plane Functions . . . . . . . . . . . . . . . 13 4.2.1. Orchestrator Onboarding . . . . . . . . . . . . . . . 13 4.2.2. Component Onboarding . . . . . . . . . . . . . . . . 14 4.3. Component Interactions . . . . . . . . . . . . . . . . . 15 4.3.1. Initiate Ad-Hoc Collection . . . . . . . . . . . . . 15 4.3.2. Coordinate Periodic Collection . . . . . . . . . . . 15 4.3.3. Coordinate Observational/Event-based Collection . . . . . . . . . . . . . . . . . . . . . 16 4.3.4. Persist Collected Posture Attributes . . . . . . . . 16 4.3.5. Initiate Ad-Hoc Evaluation . . . . . . . . . . . . . 16 - 4.3.6. Queries . . . . . . . . . . . . . . . . . . . . . . . 16 - 5. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.3.6. Coordinate Periodic Evaluation . . . . . . . . . . . 16 + 4.3.7. Coordinate Change-based Evaluation . . . . . . . . . 16 + 4.3.8. Queries . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Orchestrator Registration . . . . . . . . . . . . . . . . 17 5.1.1. Topic . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Interaction Type . . . . . . . . . . . . . . . . . . 17 5.1.3. Initiator . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Request Payload . . . . . . . . . . . . . . . . . . . 17 5.1.5. Receiver . . . . . . . . . . . . . . . . . . . . . . 17 5.1.6. Process Description . . . . . . . . . . . . . . . . . 17 5.1.7. Response Payload . . . . . . . . . . . . . . . . . . 18 5.1.8. Response Processing . . . . . . . . . . . . . . . . . 18 5.2. Component Registration . . . . . . . . . . . . . . . . . 18 5.2.1. Topic . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. Interaction Type . . . . . . . . . . . . . . . . . . 18 5.2.3. Initiator . . . . . . . . . . . . . . . . . . . . . . 18 5.2.4. Request Payload . . . . . . . . . . . . . . . . . . . 18 - 5.2.5. Receiver . . . . . . . . . . . . . . . . . . . . . . 18 + 5.2.5. Receiver . . . . . . . . . . . . . . . . . . . . . . 19 5.2.6. Process Description . . . . . . . . . . . . . . . . . 19 5.2.7. Response Payload . . . . . . . . . . . . . . . . . . 19 5.2.8. Response Processing . . . . . . . . . . . . . . . . . 19 5.3. Orchestrator-to-Component Administrative Interface . . . 19 - 5.3.1. Capability Advertisement Handshake . . . . . . . . . 19 - 5.3.2. Directed Collection . . . . . . . . . . . . . . . . . 20 - 5.4. [Taxonomy Name] . . . . . . . . . . . . . . . . . . . . . 20 + 5.3.1. Capability Advertisement Handshake . . . . . . . . . 20 + 5.3.2. Directed Collection . . . . . . . . . . . . . . . . . 21 + 5.3.3. Directed Evaluation . . . . . . . . . . . . . . . . . 21 + 5.3.4. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 21 + 5.4. [Taxonomy Name] . . . . . . . . . . . . . . . . . . . . . 21 5.4.1. Topic . . . . . . . . . . . . . . . . . . . . . . . . 21 - 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 9.2. Informative References . . . . . . . . . . . . . . . . . 22 - Appendix A. Security Domain Workflows . . . . . . . . . . . . . 24 - A.1. IT Asset Management . . . . . . . . . . . . . . . . . . . 24 - A.1.1. Components, Capabilities and Workflow(s) . . . . . . 24 - A.2. Vulnerability Management . . . . . . . . . . . . . . . . 25 - A.2.1. Components, Capabilities and Workflow(s) . . . . . . 26 - A.3. Configuration Management . . . . . . . . . . . . . . . . 26 - A.3.1. Components, Capabilities and Workflow(s) . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + 5.4.2. Interaction Type . . . . . . . . . . . . . . . . . . 21 + 5.4.3. Initiator . . . . . . . . . . . . . . . . . . . . . . 21 + 5.4.4. Request Payload . . . . . . . . . . . . . . . . . . . 21 + 5.4.5. Receiver . . . . . . . . . . . . . . . . . . . . . . 21 + 5.4.6. Process Description . . . . . . . . . . . . . . . . . 21 + 5.4.7. Response Payload . . . . . . . . . . . . . . . . . . 21 + 5.4.8. Response Processing . . . . . . . . . . . . . . . . . 22 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 9.2. Informative References . . . . . . . . . . . . . . . . . 23 + Appendix A. Security Domain Workflows . . . . . . . . . . . . . 25 + A.1. IT Asset Management . . . . . . . . . . . . . . . . . . . 25 + A.1.1. Components, Capabilities and Workflow(s) . . . . . . 25 + A.2. Vulnerability Management . . . . . . . . . . . . . . . . 26 + A.2.1. Components, Capabilities and Workflow(s) . . . . . . 27 + A.3. Configuration Management . . . . . . . . . . . . . . . . 27 + A.3.1. Components, Capabilities and Workflow(s) . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction The purpose of this draft is to define an architectural approach for a SACM Domain, based on the spirit of use cases found in [RFC7632] and requirements found in [RFC8248]. This approach gains the most advantage by supporting a variety of collection systems, and intends to enable a cooperative ecosystem of tools from disparate sources with minimal operator configuration. @@ -701,34 +712,49 @@ of topics to which Posture Collection Services are subscribed. The receiving PCS components cancel the identified observational/event- based collection executing on that PCS. 4.3.4. Persist Collected Posture Attributes [TBD] Normalization? 4.3.5. Initiate Ad-Hoc Evaluation - [TBD] ### Coordinate Periodic Evaluation [TBD] #### Schedule [TBD] - #### Cancel [TBD] ### Coordinate Change-based Evaluation [TBD] i.e. - if a posture attribute in the repository is changed, trigger an - evaluation of particular policy items + [TBD] -4.3.6. Queries +4.3.6. Coordinate Periodic Evaluation + + [TBD] + +4.3.6.1. Schedule + + [TBD] + +4.3.6.2. Cancel + + [TBD] + +4.3.7. Coordinate Change-based Evaluation + + [TBD] i.e. if a posture attribute in the repository is changed, + trigger an evaluation of particular policy items + +4.3.8. Queries [TBD] Queries should allow for a "freshness" time period, allowing the requesting entity to determine if/when posture attributes must be re-collected prior to performing evaluation. This freshness time period can be "zeroed out" for the purpose of automatically triggering re-collection regardless of the most recent collection. 5. Taxonomy + 5.1. Orchestrator Registration The Orchestrator Registration taxonomy describes how an Orchestrator onboards to the ecosystem, or how it returns from a non-operational state. 5.1.1. Topic N/A @@ -786,55 +812,62 @@ Component onboarding describes how an individual component becomes part of the ecosystem; registering with the orchestrator, advertising capabilities, establishing its administrative interface, and subscribing to relevant topics. 5.2.1. Topic "/orchestrator/registration" - "[component-type]" includes "pcs", "repository", "pes", and MORE TBD - 5.2.2. Interaction Type Directed (Request/Response) 5.2.3. Initiator Any component wishing to join the ecosystem, such as Posture Collection Services, Repositories (policy, collection content, posture attribute, etc), Posture Evaluation Services and more. 5.2.4. Request Payload - [TBD] Information Elements, such as - identifying-information - - component-type (pcs, pes, repository, etc) - name - description + [TBD] Information Elements, such as + * identifying-information - component-type (i.e Posture Collection + Service, Posture Evaluation Service, Repository, etc.) - name - + description 5.2.5. Receiver Orchestrator 5.2.6. Process Description When the Orchestrator receives the component's request for - onboarding, it will: - Generate a unique identifier, "[component- - unique-identifier]", for the onboarding component, - Persist required - information (TBD probably need more specifics), including the - "[component-unique-identifier]" to its component inventory, enabling - an up-to-date roster of components being orchestrated, - Establish - the administrative interface via the "/orchestrator/[component- - unique-identifier]" topic. + onboarding, it will: + + * Generate a unique identifier, "[component-unique-identifier]", for + the onboarding component, + + * Persist required information (TBD probably need more specifics), + including the "[component-unique-identifier]" to its component + inventory, enabling an up-to-date roster of components being + orchestrated, + + * Establish the administrative interface via the + "/orchestrator/[component-unique-identifier]" topic. 5.2.7. Response Payload - [TBD] Information Elements - component-unique-identifier + [TBD] Information Elements + + * component-unique-identifier 5.2.8. Response Processing Successful receipt of the Orchestrator's response, including the "[component-unique-identifier]" indicates the component is onboarded to the ecosystem. Using the response payload, the component can then establish its end of the administrative interface with the Orchestrator, using the "/orchestrator/[component-unique-identifier]" topic. Given this administrative interface, the component can then initiate the Section 5.3.1 @@ -864,65 +897,95 @@ 5.3.1.2. Interaction Type Directed (Request/Response) 5.3.1.3. Initiator Any ecosystem component (minus the Orchestrator) 5.3.1.4. Request Payload - [TBD] Information Elements - component-type - component-unique- - identifier - interaction-type (capability-advertisement): - list of + [TBD] Information Elements + + * component-type + + * component-unique-identifier + + * interaction-type (capability-advertisement): - list of capabilities - list of endpoints/services 5.3.1.5. Receiver Orchestrator 5.3.1.6. Process Description Upon receipt of the component's capability advertisement, it SHOULD: - Persist the component's capabilities to the Orchestrator's inventory - Coordinate, based on the supplied capabilities, a list of topics to which the component should subscribe 5.3.1.7. Response Payload - [TBD] Information Elements - list of topics to subscribe + [TBD] Information Elements + + * a list of topics to which the receiver should subscribe 5.3.1.8. Response Processing Once the component has received the response to its capability advertisement, it should subscribe to the Orchestrator-provided topics. 5.3.2. Directed Collection - ### Directed Evaluation ### Heartbeat +5.3.3. Directed Evaluation + +5.3.4. Heartbeat 5.4. [Taxonomy Name] DESCRIPTION OF TAXONOMY 5.4.1. Topic - "/name/of/topic" ### Interaction Type [Directed (Request/Response) - -or- Publish/Subscribe] ### Initiator [Component sending/publishing - the payload] ### Request Payload DESCRIPTION OF INFORMATION MODEL OF - REQUEST PAYLOAD; i.e. what elements need to be in whatever format in - the payload. ### Receiver [Component receiving/subscribed-to the - payload] ### Process Description [What the receiver does with the - payload] ### Response Payload DESCRIPTION OF INFORMATION MODEL OF - RESPONSE PAYLOAD; i.e. what elements need to be in whatever format in - the payload. ### Response Processing [What the initiator does with - any response, if there is one] + "/name/of/topic" + +5.4.2. Interaction Type + + [Directed (Request/Response) -or- Publish/Subscribe] + +5.4.3. Initiator + + [Component sending/publishing the payload] + +5.4.4. Request Payload + + DESCRIPTION OF INFORMATION MODEL OF REQUEST PAYLOAD; i.e. what + elements need to be in whatever format in the payload. + +5.4.5. Receiver + + [Component receiving/subscribed-to the payload] + +5.4.6. Process Description + + [What the receiver does with the payload] + +5.4.7. Response Payload + + DESCRIPTION OF INFORMATION MODEL OF RESPONSE PAYLOAD; i.e. what + elements need to be in whatever format in the payload. + +5.4.8. Response Processing + + [What the initiator does with any response, if there is one] 6. Privacy Considerations [TBD] 7. Security Considerations [TBD] 8. IANA Considerations