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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/