draft-ietf-sacm-arch-06.txt   draft-ietf-sacm-arch-07.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: 14 March 2021 10 September 2020
Security Automation and Continuous Monitoring (SACM) Architecture Security Automation and Continuous Monitoring (SACM) Architecture
draft-ietf-sacm-arch-06 draft-ietf-sacm-arch-07
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 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 November 2020. This Internet-Draft will expire on 14 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
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 . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
3.1. SACM Role-based Architecture . . . . . . . . . . . . . . 5 3.1. SACM Role-based Architecture . . . . . . . . . . . . . . 4
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/Configuration Management Databases
(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 . . . . . . . . . . . . . 8
3.4.2. Evaluation Sub-Architecture . . . . . . . . . . . . . 10 3.4.2. Evaluation Sub-Architecture . . . . . . . . . . . . . 10
4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Interaction Categories . . . . . . . . . . . . . . . . . 12 4.1. Interaction Categories . . . . . . . . . . . . . . . . . 12
4.1.1. Broadcast . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Broadcast . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Directed . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. Directed . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Management Plane Functions . . . . . . . . . . . . . . . 13 4.2. Management Plane Functions . . . . . . . . . . . . . . . 14
4.2.1. Orchestrator Onboarding . . . . . . . . . . . . . . . 13 4.2.1. Orchestrator Onboarding . . . . . . . . . . . . . . . 14
4.2.2. Component Onboarding . . . . . . . . . . . . . . . . 14 4.2.2. Component Onboarding . . . . . . . . . . . . . . . . 15
4.3. Component Interactions . . . . . . . . . . . . . . . . . 15 4.3. Component Interactions . . . . . . . . . . . . . . . . . 16
4.3.1. Initiate Ad-Hoc Collection . . . . . . . . . . . . . 15 4.3.1. Initiate Ad-Hoc Collection . . . . . . . . . . . . . 16
4.3.2. Coordinate Periodic Collection . . . . . . . . . . . 15 4.3.2. Coordinate Periodic Collection . . . . . . . . . . . 16
4.3.3. Coordinate Observational/Event-based 4.3.3. Coordinate Observational/Event-based Collection . . . 17
Collection . . . . . . . . . . . . . . . . . . . . . 16 4.3.4. Persist Collected Posture Attributes . . . . . . . . 18
4.3.4. Persist Collected Posture Attributes . . . . . . . . 16 4.3.5. Initiate Ad-Hoc Evaluation . . . . . . . . . . . . . 18
4.3.5. Initiate Ad-Hoc Evaluation . . . . . . . . . . . . . 16 4.3.6. Coordinate Periodic Evaluation . . . . . . . . . . . 18
4.3.6. Coordinate Periodic Evaluation . . . . . . . . . . . 16 4.3.7. Coordinate Change-based Evaluation . . . . . . . . . 19
4.3.7. Coordinate Change-based Evaluation . . . . . . . . . 16 4.3.8. Queries . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.8. Queries . . . . . . . . . . . . . . . . . . . . . . . 17 5. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Orchestrator Registration . . . . . . . . . . . . . . . . 19
5.1. Orchestrator Registration . . . . . . . . . . . . . . . . 17 5.1.1. Interaction . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. Topic . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Request Payload . . . . . . . . . . . . . . . . . . . 20
5.1.2. Interaction Type . . . . . . . . . . . . . . . . . . 17 5.1.3. Request Processing . . . . . . . . . . . . . . . . . 20
5.1.3. Initiator . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Response Payload . . . . . . . . . . . . . . . . . . 21
5.1.4. Request Payload . . . . . . . . . . . . . . . . . . . 17 5.1.5. Response Processing . . . . . . . . . . . . . . . . . 21
5.1.5. Receiver . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Component Registration . . . . . . . . . . . . . . . . . 21
5.1.6. Process Description . . . . . . . . . . . . . . . . . 17 5.2.1. Interaction . . . . . . . . . . . . . . . . . . . . . 21
5.1.7. Response Payload . . . . . . . . . . . . . . . . . . 18 5.2.2. Request Payload . . . . . . . . . . . . . . . . . . . 21
5.1.8. Response Processing . . . . . . . . . . . . . . . . . 18 5.2.3. Request Processing . . . . . . . . . . . . . . . . . 22
5.2. Component Registration . . . . . . . . . . . . . . . . . 18 5.2.4. Response Payload . . . . . . . . . . . . . . . . . . 22
5.2.1. Topic . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.5. Response Processing . . . . . . . . . . . . . . . . . 23
5.2.2. Interaction Type . . . . . . . . . . . . . . . . . . 18 5.3. Orchestrator-Component Administrative Interface . . . . . 23
5.2.3. Initiator . . . . . . . . . . . . . . . . . . . . . . 18 5.3.1. Capability Advertisement Handshake . . . . . . . . . 23
5.2.4. Request Payload . . . . . . . . . . . . . . . . . . . 18 5.3.2. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 25
5.2.5. Receiver . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Collection . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.6. Process Description . . . . . . . . . . . . . . . . . 19 5.4.1. Ad-Hoc . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.7. Response Payload . . . . . . . . . . . . . . . . . . 19 5.4.2. Periodic . . . . . . . . . . . . . . . . . . . . . . 29
5.2.8. Response Processing . . . . . . . . . . . . . . . . . 19 5.4.3. Observational/Event-based . . . . . . . . . . . . . . 31
5.3. Orchestrator-to-Component Administrative Interface . . . 19 5.5. Evaluation . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. Capability Advertisement Handshake . . . . . . . . . 20 5.5.1. Ad-Hoc . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2. Directed Collection . . . . . . . . . . . . . . . . . 21 5.5.2. Periodic . . . . . . . . . . . . . . . . . . . . . . 32
5.3.3. Directed Evaluation . . . . . . . . . . . . . . . . . 21 5.5.3. Change/Event-based . . . . . . . . . . . . . . . . . 32
5.3.4. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 21 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
5.4. [Taxonomy Name] . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
5.4.1. Topic . . . . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
5.4.2. Interaction Type . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4.3. Initiator . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 32
5.4.4. Request Payload . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 33
5.4.5. Receiver . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Security Domain Workflows . . . . . . . . . . . . . 34
5.4.6. Process Description . . . . . . . . . . . . . . . . . 21 A.1. IT Asset Management . . . . . . . . . . . . . . . . . . . 35
5.4.7. Response Payload . . . . . . . . . . . . . . . . . . 21 A.1.1. Components, Capabilities and Workflow(s) . . . . . . 35
5.4.8. Response Processing . . . . . . . . . . . . . . . . . 22 A.2. Vulnerability Management . . . . . . . . . . . . . . . . 36
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 A.2.1. Components, Capabilities and Workflow(s) . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 A.3. Configuration Management . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 A.3.1. Components, Capabilities and Workflow(s) . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 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 4, line 45 skipping to change at page 4, line 38
+--------------+----------------+ +--------------+----------------+
| |
| |
+-------v--------+ +-------v--------+
| SACM Component | | SACM Component |
| (Consumer) | | (Consumer) |
+----------------+ +----------------+
Figure 1: Basic Architectural Structure Figure 1: Basic Architectural Structure
A provider can be described as an abstraction that refers to an A Provider can be described as an abstraction that refers to an
entity capable of sending SACM-relevant information to one or many entity capable of sending SACM-relevant information to one or many
consumers. Consumers can be described as an abstraction that refers consumers. A Consumer can be described as an abstraction that refers
to an entity capable of receiving SACM-relevant information from one to an entity capable of receiving SACM-relevant information from one
or many providers. Different roles within a cooperative ecosystem or many providers. Different roles within a cooperative ecosystem
may act as both providers and consumers of SACM-relevant information. may act as both providers and consumers of SACM-relevant information.
3.1. SACM Role-based Architecture 3.1. SACM Role-based Architecture
Within the cooperative SACM ecosystem, a number of roles act in Within the cooperative SACM ecosystem, a number of roles act in
coordination to provide relevant policy/guidance, perform data coordination to provide relevant policy/guidance, perform data
collection, storage, evaluation, and support downstream analytics and collection, storage, evaluation, and support downstream analytics and
reporting. reporting.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
ecosystem; known as SACM Components. SACM Components may be composed ecosystem; known as SACM Components. SACM Components may be composed
of other SACM Components, and each SACM Component plays one, or more, of other SACM Components, and each SACM Component plays one, or more,
of several roles relevant to the ecosystem. Roles may act as of several roles relevant to the ecosystem. Roles may act as
providers of information, consumers of information, or both provider providers of information, consumers of information, or both provider
and consumer. Figure 2 depicts a number of SACM components which are and consumer. Figure 2 depicts a number of SACM components which are
architecturally significant and therefore warrant discussion and architecturally significant and therefore warrant discussion and
clarification. clarification.
3.2.1. Orchestrator(s) 3.2.1. Orchestrator(s)
Orchestration components exists to aid in the automation of Orchestrator components exists to aid in the automation of
configuration, coordination, and management for the ecosystem of SACM configuration, coordination, and management for the ecosystem of SACM
components. The Orchestrator performs control-plane operations, components. The Orchestrator performs control-plane operations,
administration of an implementing organization's components administration of an implementing organization's components
(including endpoints, posture collection services, and downstream (including endpoints, posture collection services, and downstream
activities), scheduling of automated tasks, and any ad-hoc activities activities), scheduling of automated tasks, and any ad-hoc activities
such as the initiation of collection or evaluation activities. The such as the initiation of collection or evaluation activities. The
Orchestrator is the key administrative interface into the SACM Orchestrator is the key administrative interface into the SACM
architecture. architecture.
3.2.2. Repositories/CMDBs Topic authorization policies established by the Integration Service
should dictate that only the component acting as the Orchestrator has
access to receive messages on the administrative topic(s) used for
component onboarding (i.e. the "/orchestrator/registration" topic).
3.2.2. Repositories/Configuration Management Databases (CMDBs)
Figure 2 only includes a single reference to "Repositories/CMDBs", Figure 2 only includes a single reference to "Repositories/CMDBs",
but in practice, a number of separate data repositories may exist, but in practice, a number of separate data repositories may exist,
including posture attribute repositories, policy repositories, local including posture attribute repositories, policy repositories, local
vulnerability definition data repositories, and state assessment vulnerability definition data repositories, and state assessment
results repositories. These data repositories may exist separately results repositories. These data repositories may exist separately
or together in a single representation, and the design of these or together in a single representation, and the design of these
repositories may be as distinct as their intended purpose, such as repositories may be as distinct as their intended purpose, such as
the use of relational database management systems or graph/map the use of relational database management systems or graph/map
implementations focused on the relationships between data elements. implementations focused on the relationships between data elements.
Each implementation of a SACM repository should focus on the Each implementation of a SACM repository should focus on the
relationships between data elements and implement the SACM relationships between data elements and implement the SACM
information and data model(s). information and data model(s).
3.2.3. Integration Service 3.2.3. Integration Service
If each SACM component represents a set of capabilities, the If each SACM component represents a set of capabilities, then the
Integration Service represents the "fabric" by which all those Integration Service represents the "fabric" by which SACM components
services are woven together. The Integration Service acts as a are woven together. The Integration Service acts as a message
message broker, combining a set of common message categories and broker, combining a set of common message categories and
infrastructure to allow SACM components to communicate using a shared infrastructure to allow SACM components to communicate using a shared
set of interfaces. The Integration Service's brokering capabilities set of interfaces. The Integration Service's brokering capabilities
enable the exchange of various information payloads, orchestration of enable the exchange of various information payloads, orchestration of
component capabilities, message routing and reliable delivery. The component capabilities, message routing and reliable delivery. The
Integration Service minimizes the dependencies from one system to Integration Service minimizes the dependencies from one system to
another through the loose coupling of applications through messaging. another through the loose coupling of applications through messaging.
SACM components will "attach" to the Integration Service either SACM components will "attach" to the Integration Service either
through native support for the integration implementation, or through through native support for the integration implementation, or through
the use of "adapters" which provide a proxied attachment. the use of "adapters" which provide a proxied attachment.
The Integration Service should provide mechanisms for both The Integration Service should provide mechanisms for both
synchronous and asynchronous "request/response"-style messaging, and synchronous and asynchronous request/response-style messaging, and a
a publish/subscribe mechanism to implement event-based messaging. It publish/subscribe mechanism to implement event-based messaging. It
is the responsibility of the Integration Service to coordinate and is the responsibility of the Integration Service to coordinate and
manage the sending and receiving of messages. The Integration manage the sending and receiving of messages. The Integration
Service should allow components the ability to directly connect and Service should allow components to directly connect and produce or
produce or consume messages, or connect via message translators which consume messages, or connect via message translators which can act as
can act as a proxy, transforming messages from a component format to a proxy, transforming messages from a component format to one
one implementing a SACM data model. implementing a SACM data model.
The Integration Service MUST provide routing capabilities for The Integration Service MUST provide routing capabilities for
payloads between producers and consumers. The Integration Service payloads between producers and consumers. The Integration Service
MAY provide further capabilities within the payload delivery MAY provide further capabilities within the payload delivery
pipeline. Examples of these capabilities include, but are not pipeline. Examples of these capabilities include, but are not
limited to, intermediate processing, message transformation, type limited to, intermediate processing, message transformation, type
conversion, validation, or other enterprise integration patterns. conversion, validation, or other enterprise integration patterns.
3.3. Downstream Uses 3.3. Downstream Uses
skipping to change at page 12, line 42 skipping to change at page 12, line 42
SACM Components are intended to interact with other SACM Components. SACM Components are intended to interact with other SACM Components.
These interactions can be thought of, at the architectural level, as These interactions can be thought of, at the architectural level, as
the combination of interfaces with their supported operations. Each the combination of interfaces with their supported operations. Each
interaction will convey a payload of information. The payload interaction will convey a payload of information. The payload
information is expected to contain sub-domain-specific information is expected to contain sub-domain-specific
characteristics and/or instructions. characteristics and/or instructions.
4.1. Interaction Categories 4.1. Interaction Categories
Two categories of interactions SHOULD be supported by the Integration Two categories of interactions SHOULD be supported by the Integration
Service; broadcast and directed. Service: broadcast and directed. Broadcast interactions are
asynchronous by default, and directed interactions may be invoked
either synchronously or asynchronously. Each interaction category
SHOULD adhere to topic naming conventions described below.
4.1.1. Broadcast 4.1.1. Broadcast
A broadcast interaction, commonly known as "publish/subscribe", A broadcast interaction, commonly known as publish/subscribe, allows
allows for a wider distribution of a message payload. When a payload for a wider distribution of a message payload. When a payload is
is published to a topic on the Integration Service, all subscribers published to a topic on the Integration Service, all subscribers to
to that topic are alerted and may consume the message payload. This that topic are alerted and may consume the message payload. This
category of interaction can also be described as a "unicast" category of interaction can also be described as a "unicast"
interaction when a topic only has a single subscriber. An example of interaction when a topic only has a single subscriber. An example of
a broadcast interaction could be to publish Linux OVAL objects to a a broadcast interaction could be to publish Linux OVAL objects to a
posture collection topic. Subscribing consumers receive the posture collection topic. Subscribing consumers receive the
notification, and proceed to collect endpoint configuration posture notification, and proceed to collect endpoint configuration posture
based on the new content. based on the new content.
When interacting via broadcast, topic naming conventions should
provide an adequate amount of information to be deterministic
regarding the purpose of the interaction. For example, a broadcast
topic named "/collection/oval" would indicate that (a) the payloads
published to the topic are represented as OVAL definitions, and that
(b) subscribers to that topic have advertised capabilities to perform
collection using an OVAL-compliant engine.
4.1.2. Directed 4.1.2. Directed
The intent of a directed interaction is to enable point-to-point The intent of a directed interaction is to enable point-to-point
communications between a producer and consumer, through the standard communications between a producer and consumer, through the standard
interfaces provided by the Integration Service. The provider interfaces provided by the Integration Service. The provider
component indicates which consumer is intended to receive the component indicates which consumer is intended to receive the
payload, and the Integration Service routes the payload directly to payload, and the Integration Service routes the payload directly to
that consumer. Two "styles" of directed interaction exist, differing that consumer. Two "styles" of directed interaction exist, differing
only by the response from the payload consumer. only by the response from the payload consumer.
When interacting via directed messaging, topic naming conventions
should provide an adequate amount of information to be deterministic
regarding the operation(s) to be performed, and the component
performing them. For example, a topic named "/collector-1234/ad-hoc-
collection" would indicate a payload of collection instructions,
provided to a specific component identified as "collector-1234",
directing that component to perform Ad-Hoc Collection.
4.1.2.1. Synchronous 4.1.2.1. Synchronous
Synchronous, request/response style interaction requires that the Synchronous, request/response style interaction requires that the
requesting component block and wait for the receiving component to requesting component block and wait for the receiving component to
respond, or to time out when that response is delayed past a given respond, or to time out when that response is delayed past a given
time threshold. A synchronous interaction example may be querying a time threshold. A synchronous interaction example may be querying a
CMDB for posture attribute information in order to perform an CMDB for posture attribute information in order to perform an
evaluation. evaluation.
4.1.2.2. Asynchronous 4.1.2.2. Asynchronous
skipping to change at page 13, line 48 skipping to change at page 14, line 26
4.2. Management Plane Functions 4.2. Management Plane Functions
Mangement plane functions describe a component's interactions with Mangement plane functions describe a component's interactions with
the ecosystem itself, not necessarily relating to collection, the ecosystem itself, not necessarily relating to collection,
evaluation, or downstream analytical processes. evaluation, or downstream analytical processes.
4.2.1. Orchestrator Onboarding 4.2.1. Orchestrator Onboarding
The Orchestrator component, being a specialized role in the The Orchestrator component, being a specialized role in the
architecture, onboards to the ecosystem in such a manner as to enable architecture, onboards to the SACM ecosystem in such a manner as to
the onboarding and capabilities of the other component roles. The enable the onboarding and capability management of the other
Orchestrator must be enabled with the set of capabilities needed to component roles. The Orchestrator must support the set of
manage the functions of the ecosystem. capabilities needed to manage the functions of the ecosystem.
With this in mind, the Orchestrator must first authenticate to the With this in mind, the Orchestrator must first authenticate to the
Integration Service. Once authentication has succeeded, the Integration Service. Once authentication has succeeded, the
Orchestrator must establish "service handlers" per the Section 5.2. Orchestrator must establish "service handlers" per the component
Once "service handlers" have been established, the Orchestrator is registration taxonomy (Section 5.2). Once "service handlers" have
then equipped to handle component registration, onboarding, been established, the Orchestrator is then equipped to handle
capability discovery, and topic subscription policy. component registration, onboarding, capability discovery, and topic
subscription policy.
The following requirements exist for the Orchestrator to establish The following requirements exist for the Orchestrator to establish
"service handlers" supporting the Section 5.2: - The Orchestrator "service handlers" supporting the component registration taxonomy
MUST enable the capability to receive onboarding requests via the (Section 5.2):
"/orchestrator/registration" topic, - The Orchestrator MUST have the
capability to generate, manage, and persist unique identifiers for * The Orchestrator MUST enable the capability to receive onboarding
all registered components, - The Orchestrator MUST have the requests via the "/orchestrator/registration" topic,
capability to inventory and manage its "roster" (the list of
registered components), - The Orchestrator MUST support making * The Orchestrator MUST have the capability to generate, manage, and
directed requests to registered components over the component's persist unique identifiers for all registered components,
administrative interface, as configured by the
"/orchestrator/[component-unique-identifier]" topic. Administrative * The Orchestrator MUST have the capability to inventory and manage
interface functions are described by their taxonomy, below. its "roster" (the list of registered components),
* The Orchestrator MUST have the capability to manage its roster's
advertised capabilities, including those endpoints to which those
capabilities apply.
In addition to supporting component registration, Orchestrators are
responsible for many of the operational functions of the
architecture, including initiating collection or evaluation, queries
for repository data, or the assembly of information for downstream
use.
* The Orchestrator MUST support making directed requests to
registered components over the component's administrative
interface, as configured by the "/orchestrator/[component-unique-
identifier]" topic. Administrative interface functions are
described by their taxonomy, below.
* The Orchestrator MUST support the publication of broadcast
messages to topics configured by implementations of this
ecosystem.
* The Orchestrator MUST support the subscription to topics
configured by implementations of this ecosystem as needed.
4.2.2. Component Onboarding 4.2.2. Component Onboarding
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 SACM ecosystem; registering with the Orchestrator,
capabilities, establishing its administrative interface, and advertising capabilities, establishing its administrative interface,
subscribing to relevant topics. and subscribing to relevant topics.
The component onboarding workflow involves multiple steps: - The The component onboarding workflow involves multiple steps:
component first authenticates to the Integration Service - The
component then initiates registration with the Orchestrator, per the * The component first authenticates to the Integration Service, and
Section 5.2
* The component initiates registration with the Orchestrator, per
the component registration taxonomy (Section 5.2).
Once the component has onboarded and registered with the Once the component has onboarded and registered with the
Orchestrator, its administrative interface will have been established Orchestrator, its administrative interface will have been established
via the "/orchestrator/[component-unique-identifier]" topic. This via the "/orchestrator/[component-unique-identifier]" topic. This
administrative interface allows the component to advertise its administrative interface allows the component to advertise its
capabilities to the Orchestrator and in return, allow the capabilities to the Orchestrator and in return, allow the
Orchestrator to direct capability-specific topic registration to the Orchestrator to direct capability-specific topic registration to the
component. This is performed using the Section 5.3.1 taxonomy. component. This is performed using the "capability advertisement
Further described below, the "capability advertisement handshake" handshake" (Section 5.3.1) taxonomy. Further described below, the
first assumes the onboarding component has the ability to describe "capability advertisement handshake" first assumes the onboarding
its capabilities so they may be understood by the Orchestrator (TBD component has the ability to describe its capabilities so they may be
on capability advertisement methodology). understood by the Orchestrator (TBD on capability advertisement
methodology).
* The component sends a message with its operational capabilities * The component sends a message with its operational capabilities
over the administrative interface: "/orchestrator/[component- over the administrative interface: "/orchestrator/[component-
unique-identifier]" unique-identifier]"
* The Orchestrator receives the component's capabilities, persists * The Orchestrator receives the component's capabilities, persists
them, and responds with the list of topics to which the component them, and responds with the list of topics to which the component
should subscribe, in order to receive notifications, instructions, should subscribe, in order to receive notifications, instructions,
or other directives intended to invoke the component's supported or other directives intended to invoke the component's supported
capabilities. capabilities.
* The component subscribes to the topics provided by the * The component then subscribes to the topics provided by the
Orchestrator Orchestrator in order to enable receipt of broadcast instructions.
4.3. Component Interactions 4.3. Component Interactions
Component interactions describe functionality between components Component interactions describe functionality between components
relating to collection, evaluation, or other downstream processes. relating to collection, evaluation, or other downstream processes.
4.3.1. Initiate Ad-Hoc Collection 4.3.1. Initiate Ad-Hoc Collection
The Orchestrator supplies a payload of collection instructions to a The Orchestrator supplies a payload of collection instructions to a
topic or set of topics to which Posture Collection Services are topic or set of topics to which Posture Collection Services are
subscribed. The receiving PCS components perform the required subscribed. The receiving PCS components perform the required
collection based on their capabilities. The PCS then forms a payload collection based on their capabilities. Each PCS then forms a
of collected posture attributes (including endpoint identifying payload of collected posture attributes (including endpoint
information) and publishes that payload to the topic(s) to which the identifying information) and publishes that payload to the topic(s)
Posture Attribute Repository is subscribed, for persistence. to which the Posture Attribute Repository is subscribed, for
persistence.
4.3.2. Coordinate Periodic Collection 4.3.2. Coordinate Periodic Collection
Similar to ad-hoc collection, the Orchestrator supplies a payload of Similar to ad-hoc collection, the Orchestrator supplies a payload of
collection instructions containing additional information regarding collection instructions similar to those of ad-hoc collection.
collection periodicity, to the topic or topics to which Posture Additional information elements containing collection identification
Collection Services are subscribed. and periodicity are included.
4.3.2.1. Schedule Periodic Collection 4.3.2.1. Schedule Periodic Collection
Collection instructions include information regarding the schedule To enable operations on periodic collection, the scheduling payload
for collection, for example, every day at Noon, or every hour at 32 MUST include both a unique identifier for the set of collection
minutes past the hour. instructions, as well as a periodicity expression to enable the
collection schedule. An optional "immediate collection" flag will
indicate to the collection component that, upon receipt of the
collection instructions, a collection will automatically be initiated
prior to engagement of the scheduled collection.
4.3.2.2. Cancel Periodic Collection 4.3.2.2. Cancel Periodic Collection
The Orchestrator supplies a payload of instructions to a topic or set The Orchestrator disables the periodic collection of posture
of topics to which Posture Collection Services are subscribed. The attributes by supplying collector(s) the unique identifier of
receiving PCS components cancel the identified periodic collection previously scheduled collection instructions. An optional "final
executing on that PCS. collection" flag will indicate to the collection component that, upon
receipt of the cancellation instructions, a final ad-hoc collection
is to take place.
4.3.3. Coordinate Observational/Event-based Collection 4.3.3. Coordinate Observational/Event-based Collection
In these scenarios, the "observer" acts as the Posture Collection In these scenarios, the Posture Collection Service acts as the
Service. Interactions with the observer could specify a time period "observer". Interactions with the observer could specify a time
of observation and potentially information intended to filter period of observation and potentially information intended to filter
observed posture attributes to aid the PCS in determining those observed posture attributes to aid the PCS in determining those
attributes that are applicable for collection and persistence to the attributes that are applicable for collection and persistence to the
Posture Attribute Repository. Posture Attribute Repository.
4.3.3.1. Initiate Observational/Event-based Collection 4.3.3.1. Initiate Observational/Event-based Collection
The Orchestrator supplies a payload of instructions to a topic or set The Orchestrator supplies a payload of instructions to a topic or set
of topics to which Posture Collection Services (observers) are of topics to which Posture Collection Services (observers) are
subscribed. This payload could include specific instructions based subscribed. This payload could include specific instructions based
on the observer's capabilities to determine specific posture on the observer's capabilities to determine specific posture
attributes to observe and collect. attributes to observe and collect.
4.3.3.2. Cancel Observational/Event-based Collection 4.3.3.2. Cancel Observational/Event-based Collection
The Orchestrator supplies a payload of instructions to a topic or set The Orchestrator supplies a payload of instructions to a topic or set
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 those PCS components.
4.3.4. Persist Collected Posture Attributes 4.3.4. Persist Collected Posture Attributes
[TBD] Normalization? Following successful collection, Posture Collection Services (PCS)
will supply the payload of collected posture attributes to the
interface(s) supporting the persistent storage of those attributes to
the Posture Attribute Repository. Information in this payload should
include identifying information of the computing resource(s) for
which attributes were collected.
4.3.5. Initiate Ad-Hoc Evaluation 4.3.5. Initiate Ad-Hoc Evaluation
[TBD] The Orchestrator supplies a payload of evaluation instructions to a
topic or set of topics to which Posture Evaluation Services (PES) are
subscribed. The receiving PES components perform the required
evaluation based on their capabilities. The PES generates a payload
of posture evaluation results and publishes that payload to the
appropriate topic(s), to which the Evaluation Results Repository is
subscribed, for persistence.
4.3.6. Coordinate Periodic Evaluation 4.3.6. Coordinate Periodic Evaluation
[TBD] Similar to ad-hoc evaluation, the Orchestrator supplies a payload of
evaluation instructions similar to those of ad-hoc evaluation.
Additional information elements containing evaluation identification
and periodicity are included.
4.3.6.1. Schedule 4.3.6.1. Schedule Periodic Evaluation
[TBD] To enable operations on periodic evaluation, the scheduling payload
MUST include both a unique identifier for the set of evaluation
instructions, as well as a periodicity expression to enable the
evaluation schedule. An optional "immediate evaluation" flag will
indicate to the Posture Evaluation Service (PES) that, upon receipt
of the evaluation instructions, an evaluation will automatically be
initiated prior to engagement of the scheduled evaluation.
4.3.6.2. Cancel 4.3.6.2. Cancel Periodic Evaluation
[TBD] The Orchestrator disables the periodic evaluation of posture
attributes by supplying Posture Evaluation Service(s) the unique
identifier of previously scheduled evaluation instructions. An
optional "final evaluation" flag will indicate to the PES that, upon
receipt of the cancellation instructions, a final ad-hoc evaluation
is to take place.
4.3.7. Coordinate Change-based Evaluation 4.3.7. Coordinate Change-based Evaluation
[TBD] i.e. if a posture attribute in the repository is changed, A more fine-grained approach to periodic evaluation may be enabled
trigger an evaluation of particular policy items through the triggering of Posture Evaluation based on changes to
posture attribute values at the time of their collection and
persistence to the Posture Attribute Repository.
4.3.8. Queries 4.3.7.1. Identify Attributes
[TBD] Queries should allow for a "freshness" time period, allowing The Orchestrator enables change-based evaluation through a payload
the requesting entity to determine if/when posture attributes must be published to Posture Attribute Repository component(s). This payload
re-collected prior to performing evaluation. This freshness time includes appropriate information elements describing the posture
period can be "zeroed out" for the purpose of automatically attributes on which changes in value will trigger posture evaluation.
triggering re-collection regardless of the most recent collection.
5. Taxonomy 4.3.7.2. Cancel Change-based Evaluation
5.1. Orchestrator Registration An Orchestrator may disable change-based evaluation through a payload
published to Posture Attribute Repository component(s), including
those information elements necessary to identify those posture
attributes for which change-based evaluation no longer applies.
The Orchestrator Registration taxonomy describes how an Orchestrator 4.3.8. Queries
onboards to the ecosystem, or how it returns from a non-operational
state.
5.1.1. Topic 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.
N/A 5. Taxonomy
5.1.2. Interaction Type The following sections describe a number of operations required to
enable a cooperative ecosystem of posture attribute collection and
evaluation functions.
Directed (Request/Response) 5.1. Orchestrator Registration
5.1.3. Initiator The Orchestrator Registration taxonomy describes how an Orchestrator
onboards to the SACM ecosystem, or how it returns from a non-
operational state.
Orchestrator 5.1.1. Interaction
5.1.4. Request Payload +=====================+=============================+
| Property | Value |
+=====================+=============================+
| Type | Directed (Request/Response) |
+---------------------+-----------------------------+
| Topic | N/A |
+---------------------+-----------------------------+
| Source Component | Orchestrator |
+---------------------+-----------------------------+
| Target Component(s) | N/A |
+---------------------+-----------------------------+
N/A Table 1
5.1.5. Receiver 5.1.2. Request Payload
N/A N/A;
5.1.6. Process Description 5.1.3. Request Processing
Once the Orchestrator has authenticated to the Integration Service, Once the Orchestrator has authenticated to the Integration Service,
it must establish (or re-establish) any service handlers interacting it must establish (or re-establish) any service handlers interacting
with administrative interfaces and/or general operational interfaces. with administrative interfaces and/or general operational interfaces.
For initial registration, the Orchestrator MUST enable capabilities For initial registration, the Orchestrator MUST enable capabilities
to: to:
* Receive onboarding requests via the "/orchestrator/registration" * Receive onboarding requests via the "/orchestrator/registration"
topic, topic,
skipping to change at page 18, line 19 skipping to change at page 21, line 5
components), and components), and
* Support making directed requests to registered components over the * Support making directed requests to registered components over the
component's administrative interface, as configured by the component's administrative interface, as configured by the
"/orchestrator/[component-unique-identifier]" topic. "/orchestrator/[component-unique-identifier]" topic.
Administrative interfaces are to be re-established through the Administrative interfaces are to be re-established through the
inventory of previously registered components, such as Posture inventory of previously registered components, such as Posture
Collection Services, Repositories, or Posture Evaluation Services. Collection Services, Repositories, or Posture Evaluation Services.
5.1.7. Response Payload 5.1.4. Response Payload
N/A N/A
5.1.8. Response Processing 5.1.5. Response Processing
N/A N/A
5.2. Component Registration 5.2. Component Registration
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 SACM ecosystem; registering with the orchestrator,
capabilities, establishing its administrative interface, and advertising capabilities, establishing its administrative interface,
subscribing to relevant topics. and subscribing to relevant topics.
5.2.1. Topic
"/orchestrator/registration" 5.2.1. Interaction
5.2.2. Interaction Type +==============+==============================================+
| Property | Value |
+==============+==============================================+
| Type | Directed (Request/Response) |
+--------------+----------------------------------------------+
| Topic | /orchestrator/registration |
+--------------+----------------------------------------------+
| Source | Any component wishing to join the ecosystem, |
| Component | such as Posture Collection Services, |
| | Repositories (policy, collection content, |
| | posture attribute, evaluation results, |
| | etc.), Posture Evaluation Services and more. |
+--------------+----------------------------------------------+
| Target | Orchestrator |
| Component(s) | |
+--------------+----------------------------------------------+
Directed (Request/Response) Table 2
5.2.3. Initiator 5.2.2. Request Payload
Any component wishing to join the ecosystem, such as Posture When a component registers with the Orchestrator and enters the
Collection Services, Repositories (policy, collection content, ecosystem, it must first identify itself to the Orchestrator.
posture attribute, etc), Posture Evaluation Services and more.
5.2.4. Request Payload component-registration-request:
component-unique-identifier (if re-establishing communication)
#-OR-#
{:component-identification:}
[TBD] Information Elements, such as component-identification:
* identifying-information - component-type (i.e Posture Collection component-type {:component-type:}
Service, Posture Evaluation Service, Repository, etc.) - name - component-name
description component-description (optional)
5.2.5. Receiver component-type:
enumeration:
- posture-collection-service
- posture-evaluation-service
- repository
- orchestrator
- others?
Orchestrator When registering for the first time, the component will send
identifying information including the component type and a name. If
the component is reestablishing communications, for example after a
restart of the component or deployment of a new version, the
component only needs to supply its previously generated unique
identifier.
5.2.6. Process Description 5.2.3. Request Processing
When the Orchestrator receives the component's request for When the Orchestrator receives the component's request for
onboarding, it will: onboarding, it will:
* Generate a unique identifier, "[component-unique-identifier]", for * Generate a unique identifier, "[component-unique-identifier]", for
the onboarding component, the onboarding component,
* Persist required information (TBD probably need more specifics), * Persist required information (TBD probably need more specifics),
including the "[component-unique-identifier]" to its component including the "[component-unique-identifier]" to its component
inventory, enabling an up-to-date roster of components being inventory, enabling an up-to-date roster of components being
orchestrated, orchestrated,
* Establish the administrative interface via the * Establish the administrative interface via the
"/orchestrator/[component-unique-identifier]" topic. "/orchestrator/[component-unique-identifier]" topic.
5.2.7. Response Payload 5.2.4. Response Payload
[TBD] Information Elements The Orchestrator will respond to the component with a payload
including the component's unique identifier. At this point, the
Orchestrator is aware of the component's existence in the ecosystem,
and the component is self-aware by virtue of receiving its unique
identifier.
* component-unique-identifier component-registration-response:
component-unique-identifier: [component-unique-identifier]
5.2.8. Response Processing 5.2.5. 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
5.3. Orchestrator-to-Component Administrative Interface 5.3. Orchestrator-Component Administrative Interface
A number of functions may take place which, instead of being A number of functions may take place which, instead of being
published to a multi-subscriber topic, may require direct interaction published to a multi-subscriber topic, may require direct interaction
between an Orchestrator and a registered component. During component between an Orchestrator and a registered component. During component
onboarding, this direct channel is established first by the onboarding, this direct channel is established first by the
Orchestrator and subsequently complemented by the onboarding Orchestrator and subsequently complemented by the component entering
component. the ecosystem.
5.3.1. Capability Advertisement Handshake 5.3.1. Capability Advertisement Handshake
Capability advertisement, otherwise known as service discovery, is Capability advertisement, otherwise known as service discovery, is
necessary to establish and maintain a cooperative ecosystem of tools. necessary to establish and maintain a cooperative ecosystem of tools
Using this capability advertisement "handshake", the Orchestrator by allowing components to register and maintain supported
becomes knowledgeable of a component's operational capabilities, the capabilities with the orchestrator. Using this capability
endpoints/services with which the component interacts, and advertisement "handshake", the Orchestrator becomes knowledgeable of
establishes a direct mode of contact for invoking those capabilities. a component's operational capabilities, the endpoints/services with
which the component interacts, and establishes a direct mode of
contact for invoking those capabilities. Once initially established,
orchestrators and components can maintain this capability matrix
using the administrative interface.
5.3.1.1. Topic 5.3.1.1. Interaction
"/orchestrator/[component-unique-identifier]" +==================+=============================================+
| Property | Value |
+==================+=============================================+
| Type | Directed (Request/Response) |
+------------------+---------------------------------------------+
| Topic | /orchestrator/[component-unique-identifier] |
+------------------+---------------------------------------------+
| Source Component | Any ecosystem component (minus the |
| | Orchestrator) |
+------------------+---------------------------------------------+
| Target | Orchestrator |
| Component(s) | |
+------------------+---------------------------------------------+
5.3.1.2. Interaction Type Table 3
Directed (Request/Response) 5.3.1.2. Request Payload
5.3.1.3. Initiator capability-advertisement-request:
component-unique-identifier: [component-unique-identifier]
component-type: {:component-type:}
capabilities:
capability-urn: [urn]
capability-urn: [urn]
capability-urn: [urn]
...
Any ecosystem component (minus the Orchestrator) [TBD] Start adding capability URNs to IANA considerations section?
5.3.1.4. Request Payload 5.3.1.3. Request Processing
[TBD] Information Elements Upon receipt of the component's capability advertisement, it SHOULD:
* component-type * Persist the component's capabilities to the Orchestrator's
inventory
* component-unique-identifier * Coordinate, based on the supplied capabilities, a list of topics
to which the component should subscribe
* interaction-type (capability-advertisement): - list of [TBD] What if the component supplies a "capability-urn" that the
capabilities - list of endpoints/services Orchestrator doesn't know about?
5.3.1.5. Receiver 5.3.1.4. Response Payload
Orchestrator When responding, the Orchestrator will indicate to the component,
which capabilities were successfully registered, and the topics to
which those capabilities apply. Any failures to register
capabilities will also be noted per capability URN, including any
relevant error messages.
5.3.1.6. Process Description capability-advertisement-response:
capabilities:
capability:
capability-urn: [urn]
registration-status: (success | failure)
capability-topic: /capability/topic/name
messages: [messages]
capability:
capability-urn: [urn]
registration-status: (success | failure)
capability-topic: /capability/topic/name
messages: [messages]
...
Upon receipt of the component's capability advertisement, it SHOULD: 5.3.1.5. Response Processing
- 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 Once the component has received the response to its capability
advertisement, it should subscribe to the Orchestrator-provided
topics. Once the applicable topics have been subscribed, the
component is considered fully onboarded to the ecosystem.
[TBD] Information Elements 5.3.2. Heartbeat
* a list of topics to which the receiver should subscribe As time passes and ecosystem components which have previously
registered with the ecosystem are brought offline (perhaps for
maintenance or redeployment) and back online, it is important that
the Orchestrator maintains knowledge of all registered component's
current operational status. The heartbeat taxonomy describes the
efforts taken by an Orchestrator to maintain the most up-to-date
inventory of operational components, and to potentially alert users
or other outside systems of unavailable components.
5.3.1.8. Response Processing 5.3.2.1. Interaction
Once the component has received the response to its capability +=====================+=============================================+
advertisement, it should subscribe to the Orchestrator-provided | Property | Value |
topics. +=====================+=============================================+
| Type | Directed (Request/Response) |
+---------------------+---------------------------------------------+
| Topic | /orchestrator/[component-unique-identifier] |
+---------------------+---------------------------------------------+
| Source Component | Orchestrator |
+---------------------+---------------------------------------------+
| Target | Any non-Orchestrator component maintained |
| Component(s) | in the current operational inventory |
+---------------------+---------------------------------------------+
5.3.2. Directed Collection Table 4
5.3.3. Directed Evaluation 5.3.2.2. Request Payload
5.3.4. Heartbeat The request payload defines the hearbeat action to be taken:
5.4. [Taxonomy Name] heartbeat-request:
action: (ping | ping-with-capabilities)
DESCRIPTION OF TAXONOMY 5.3.2.3. Request Processing
5.4.1. Topic When the target component receives the hearbeat request, it will
determine based on action, the processing required. A simple "ping"
request indicates the target component need only respond that it is
operational and connected to the integration service. This is a
simple "Are you listening? Yes, I am" interaction. The heartbeat
request from the Orchestrator should be made with an appropriately
small timeout indicator; only an operational component will be able
to respond to the request, so if that component is offline and cannot
respond, the Orchestrator should not be kept waiting for an extended
amount of time.
"/name/of/topic" When the requested action is "ping-with-capabilities", the receiving
component is instructed to respond that it is operational and to
immediately follow the response with a re-initiation of the
Section 5.3.1 process. This interaction enables an Orchestrator the
ability to perform capability discovery from components.
5.4.2. Interaction Type 5.3.2.4. Response Payload
[Directed (Request/Response) -or- Publish/Subscribe] When responding to the heartbeat request, the initial response
payload will simply indicate success: ~~~~~~ heartbeat-response:
response: success ~~~~~~
5.4.3. Initiator If the "ping-with-capabilities" action was requested, the responding
component will immediately initiate the Section 5.3.1 process.
[Component sending/publishing the payload] 5.3.2.5. Response Processing
5.4.4. Request Payload Upon receipt of the "heartbeat-response" payload, the Orchestrator
will update its inventory of currently operational components with
the timestamp of the receipt. If the Orchestrator originally
requested the component's capabilities as well, further interactions
will initiate and complete the Section 5.3.1 process.
DESCRIPTION OF INFORMATION MODEL OF REQUEST PAYLOAD; i.e. what 5.4. Collection
elements need to be in whatever format in the payload.
5.4.5. Receiver The following sections detail the interactions supporting the
collection of posture attributes from one or many endpoints within
the ecosystem. Collector capabilities will determine both the set of
endpoints each collector from which posture attributes may be
collected, as well as the various methods of collection used by those
collectors.
[Component receiving/subscribed-to the payload] 5.4.1. Ad-Hoc
5.4.6. Process Description Collection components support ad-hoc collection activities when
receiving collection instructions from an Orchestrator and by acting
upon those instructions immediately, collecting posture attributes as
they exist on targeted endpoints at the moment of collection. Ad-Hoc
collection may potentially be invoked by a number of components,
including Orchestrators or even Posture Evaluation Services, and may
be requested of Collectors either directly or through the Collector's
subscription to topics as established by the Section 5.3.1 process.
[What the receiver does with the payload] 5.4.1.1. Interaction
5.4.7. Response Payload +==============+===================================================+
| Property | Value |
+==============+===================================================+
| Type | Directed or Broadcast |
+--------------+---------------------------------------------------+
| Topic | <ul><li>The Orchestrator-Component Administrative |
| | Interface: "/orchestrator/[component-unique- |
| | identifier]",</li><li>Component-specific |
| | Collection topic: "/[component-unique- |
| | identifier]/collect", or</li><li>Through |
| | subscriptions such as "/collection/[collection- |
| | type]"</li></ul> |
+--------------+---------------------------------------------------+
| Source | Orchestrator, Posture Evaluation Service |
| Component | |
+--------------+---------------------------------------------------+
| Target | Collector |
| Component(s) | |
+--------------+---------------------------------------------------+
DESCRIPTION OF INFORMATION MODEL OF RESPONSE PAYLOAD; i.e. what Table 5
elements need to be in whatever format in the payload.
5.4.8. Response Processing 5.4.1.2. Request Payload
[What the initiator does with any response, if there is one] Ad-Hoc collection requests take the form of collection instructions
corresponding to the SACM information model. Collection instruction
payloads MAY be serialized as a specific collection language
supported by the Collector (taking into account any implementation-
specific payload size limitations), as a generic serialization to be
interpreted by the Collector, or as ID references to content
persisted in a Repository.
Instructions MAY include a "response topic" to which collection
results are published/directed. This can allow the requesting
component to direct a Collector (or Collectors) to publish results
directly to a Posture Attribute Repository component, or to simply
respond to the requesting component.
collection-request:
[TBD]
response-topic: [response-topic]
5.4.1.3. Request Processing
Upon receipt of collection instructions, the Collector will need to
determine whether or not any normalization or retrieval of specific
instructions is required. This normalization may be required if
collection instructions are not formatted specifically to the
capabilities of the Collector. For example, if a payload is
delivered containing a set of OVAL "object" IDs, the Collector would
need to retrieve the instructions from the Repository and format them
into a well-formed, valid OVAL definitions serialization for
processing.
Once the collection instructions have been received and any pre-
processing/normalization has occurred, the Collector will perform the
actual retrieval of posture attributes. Once collected, posture
attributes will need to be published back to the topic named in the
request payload. This response topic could represent a callback to
the component invoking collection, or a destination for the posture
attributes to be persisted, i.e. a Repository.
5.4.1.4. Response Payload
The response payload generated by the Collector may take one of 2
forms:
* Collection results using the data model supported by the
collection system indicated in the collection instructions. For
example, if the collection instructions were formatted as OVAL
definitions (or more specifically OVAL objects), then collection
results would be formatted as OVAL system characteristics. Each
collector is responsible for maintaining the capabilities
necessary to produce results formats based on its collection
capabilities.
* Collection results using a "normalized" [TBD] format as defined by
the SACM information model/data models.
5.4.1.5. Response Processing
Handling a payload of collected posture attributes will vary based on
the component receiving that payload:
* Posture Attribute Repository: If collection results are not
"normalized" the Repository component MUST be able to perform
normalization processing prior to persisting the results.
* Non-Repository Components: The receiving component must also be
capable of "normalizing" collected posture attributes
5.4.2. Periodic
Periodic collection builds upon Ad-Hoc collection by allowing
Orchestration of collection activities given a periodicity.
Architecturally, periodic collection is orchestrated through either
the scheduling of collection or canceling an already-existing
schedule. Modifications to a scheduled collection MUST be made by
first canceling the existing schedule and establishing the updated
schedule.
5.4.2.1. Schedule Periodic Collection
Scheduling periodic collection is established by an Orchestrator
delivering collection instructions and the collection periodicity to
a Collector. These instructions may be received by the Collector
through a number of topics, described below.
5.4.2.1.1. Interaction
+==============+===================================================+
| Property | Value |
+==============+===================================================+
| Type | Directed or Broadcast |
+--------------+---------------------------------------------------+
| Topic | <ul><li>The Orchestrator-Component Administrative |
| | Interface: "/orchestrator/[component-unique- |
| | identifier]",</li><li>Component-specific |
| | Collection topic: "/[component-unique- |
| | identifier]/collect", or</li><li>Through |
| | subscriptions such as "/collection/[collection- |
| | type]"</li></ul> |
+--------------+---------------------------------------------------+
| Source | Orchestrator |
| Component | |
+--------------+---------------------------------------------------+
| Target | Collector |
| Component(s) | |
+--------------+---------------------------------------------------+
Table 6
5.4.2.1.2. Request Payload
The request to schedule periodic collection is represented as a
wrapper of the collection instructions used to initiate ad-hoc
collection. Additional elements indicate the establishment of the
schedule, the collection schedule itself, and whether or not to
perform an immediate collection upon receipt of the payload.
periodic-collection:
collection-identifier: 12345
operation: schedule
collection-schedule:
TBD (cron formatted? other scheduling formats?)
collect-upon-acknowledgement: true/false
collection-instructions:
# Formatted per Ad-Hoc Collection taxonomy
5.4.2.1.3. Request Processing
Upon receipt of the request to establish periodic collection, the
Collector must first determine if the "collection-identifier" is
unique. If an existing periodic collection, using the same
identifier, is already present, an error payload MUST be returned to
the Orchestrator. Once the collection identifier has been validated,
the schedule is established within the scope of the Collector
receiving the instructions. If the "collect-upon-acknowledgement"
flag is set to "true", the Collector MUST perform an immediate ad-hoc
collection based on the instructions passed in the payload and the
collected posture attributes are provided to the "response-topic" per
the "collection-instructions".
5.4.2.1.4. Response Payload
Essentially, two payloads could be provided in ##### Response
Processing
5.4.2.2. Cancel Periodic Collection
TBD
5.4.2.2.1. Interaction
+==============+===================================================+
| Property | Value |
+==============+===================================================+
| Type | Directed or Broadcast |
+--------------+---------------------------------------------------+
| Topic | <ul><li>The Orchestrator-Component Administrative |
| | Interface: "/orchestrator/[component-unique- |
| | identifier]",</li><li>Component-specific |
| | Collection topic: "/[component-unique- |
| | identifier]/collect", or</li><li>Through |
| | subscriptions such as "/collection/[collection- |
| | type]"</li></ul> |
+--------------+---------------------------------------------------+
| Source | Orchestrator |
| Component | |
+--------------+---------------------------------------------------+
| Target | Collector |
| Component(s) | |
+--------------+---------------------------------------------------+
Table 7
5.4.2.2.2. Request Payload
periodic-collection:
collection-identifier: 12345
operation: cancel
collect-upon-acknowledgement: true/false
5.4.2.2.3. Request Processing
##### Response Payload ##### Response Processing
5.4.3. Observational/Event-based
5.5. Evaluation
5.5.1. Ad-Hoc
5.5.2. Periodic
5.5.3. Change/Event-based
6. Privacy Considerations 6. Privacy Considerations
[TBD] [TBD]
7. Security Considerations 7. Security Considerations
[TBD] [TBD]
8. IANA Considerations 8. IANA Considerations
skipping to change at page 22, line 42 skipping to change at page 32, line 43
Capabilities Capabilities
* Collection sub-architecture Identification * Collection sub-architecture Identification
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-sacm-ecp] [I-D.ietf-sacm-ecp]
Haynes, D., Fitzgerald-McKay, J., and L. Lorenzin, Haynes, D., Fitzgerald-McKay, J., and L. Lorenzin,
"Endpoint Posture Collection Profile", draft-ietf-sacm- "Endpoint Posture Collection Profile", Work in Progress,
ecp-05 (work in progress), 21 June 2019, Internet-Draft, draft-ietf-sacm-ecp-05, 21 June 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-sacm-ecp- <http://www.ietf.org/internet-drafts/draft-ietf-sacm-ecp-
05.txt>. 05.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and
J. Fitzgerald-McKay, "Software Inventory Message and J. Fitzgerald-McKay, "Software Inventory Message and
skipping to change at page 23, line 20 skipping to change at page 33, line 20
[RFC8600] Cam-Winget, N., Ed., Appala, S., Pope, S., and P. Saint- [RFC8600] Cam-Winget, N., Ed., Appala, S., Pope, S., and P. Saint-
Andre, "Using Extensible Messaging and Presence Protocol Andre, "Using Extensible Messaging and Presence Protocol
(XMPP) for Security Information Exchange", RFC 8600, (XMPP) for Security Information Exchange", RFC 8600,
DOI 10.17487/RFC8600, June 2019, DOI 10.17487/RFC8600, June 2019,
<https://www.rfc-editor.org/info/rfc8600>. <https://www.rfc-editor.org/info/rfc8600>.
9.2. Informative References 9.2. Informative References
[CISCONTROLS] [CISCONTROLS]
"CIS Controls v7.0", May 2020, "CIS Controls v7.1", n.d.,
<https://www.cisecurity.org/controls>. <https://www.cisecurity.org/controls>.
[draft-birkholz-sacm-yang-content] [draft-birkholz-sacm-yang-content]
Birkholz, H. and N. Cam-Winget, "YANG subscribed Birkholz, H. and N. Cam-Winget, "YANG subscribed
notifications via SACM Statements", May 2020, notifications via SACM Statements", n.d.,
<https://tools.ietf.org/html/draft-birkholz-sacm-yang- <https://tools.ietf.org/html/draft-birkholz-sacm-yang-
content-01>. content-01>.
[HACK100] "IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP", [HACK100] "IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP",
May 2020, n.d., <https://www.github.com/sacmwg/vulnerability-
<https://www.github.com/sacmwg/vulnerability-scenario/ scenario/ietf-hackathon>.
ietf-hackathon>.
[HACK101] "IETF 101 Hackathon - Configuration Assessment XMPP", May [HACK101] "IETF 101 Hackathon - Configuration Assessment XMPP",
2020, <https://www.github.com/CISecurity/Integration>. n.d., <https://www.github.com/CISecurity/Integration>.
[HACK102] "IETF 102 Hackathon - YANG Collection on Traditional [HACK102] "IETF 102 Hackathon - YANG Collection on Traditional
Endpoints", May 2020, Endpoints", n.d.,
<https://www.github.com/CISecurity/YANG>. <https://www.github.com/CISecurity/YANG>.
[HACK103] "IETF 103 Hackathon - N/A", May 2020, [HACK103] "IETF 103 Hackathon - N/A", n.d.,
<https://www.ietf.org/how/meetings/103/>. <https://www.ietf.org/how/meetings/103/>.
[HACK104] "IETF 104 Hackathon - A simple XMPP client", May 2020, [HACK104] "IETF 104 Hackathon - A simple XMPP client", n.d.,
<https://github.com/CISecurity/SACM-Architecture>. <https://github.com/CISecurity/SACM-Architecture>.
[HACK105] "IETF 105 Hackathon - A more robust XMPP client including [HACK105] "IETF 105 Hackathon - A more robust XMPP client including
collection extensions", May 2020, collection extensions", n.d.,
<https://github.com/CISecurity/SACM-Architecture>. <https://github.com/CISecurity/SACM-Architecture>.
[HACK99] "IETF 99 Hackathon - Vulnerability Scenario EPCP", May [HACK99] "IETF 99 Hackathon - Vulnerability Scenario EPCP", n.d.,
2020,
<https://www.github.com/sacmwg/vulnerability-scenario/ <https://www.github.com/sacmwg/vulnerability-scenario/
ietf-hackathon>. ietf-hackathon>.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and
A. Montville, "Security Automation and Continuous A. Montville, "Security Automation and Continuous
Monitoring (SACM) Terminology", draft-ietf-sacm- Monitoring (SACM) Terminology", Work in Progress,
terminology-16 (work in progress), 14 December 2018, Internet-Draft, draft-ietf-sacm-terminology-16, 14
<http://www.ietf.org/internet-drafts/draft-ietf-sacm- December 2018, <http://www.ietf.org/internet-drafts/draft-
terminology-16.txt>. ietf-sacm-terminology-16.txt>.
[NIST800126] [NIST800126]
Waltermire, D., Quinn, S., Booth, H., Scarfone, K., and D. Waltermire, D., Quinn, S., Booth, H., Scarfone, K., and D.
Prisaca, "SP 800-126 Rev. 3 - The Technical Specification Prisaca, "SP 800-126 Rev. 3 - The Technical Specification
for the Security Content Automation Protocol (SCAP) - SCAP for the Security Content Automation Protocol (SCAP) - SCAP
Version 1.3", February 2018, Version 1.3", February 2018,
<https://csrc.nist.gov/publications/detail/sp/800-126/rev- <https://csrc.nist.gov/publications/detail/sp/800-126/rev-
3/final>. 3/final>.
[NISTIR7694] [NISTIR7694]
Halbardier, A., Waltermire, D., and M. Johnson, "NISTIR Halbardier, A., Waltermire, D., and M. Johnson, "NISTIR
7694 Specification for Asset Reporting Format 1.1", May 7694 Specification for Asset Reporting Format 1.1", n.d.,
2020,
<https://csrc.nist.gov/publications/detail/nistir/7694/ <https://csrc.nist.gov/publications/detail/nistir/7694/
final>. final>.
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
October 2007, <https://www.rfc-editor.org/info/rfc5023>. October 2007, <https://www.rfc-editor.org/info/rfc5023>.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632, Posture Assessment: Enterprise Use Cases", RFC 7632,
DOI 10.17487/RFC7632, September 2015, DOI 10.17487/RFC7632, September 2015,
skipping to change at page 24, line 49 skipping to change at page 34, line 46
[RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and [RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and
Continuous Monitoring (SACM) Requirements", RFC 8248, Continuous Monitoring (SACM) Requirements", RFC 8248,
DOI 10.17487/RFC8248, September 2017, DOI 10.17487/RFC8248, September 2017,
<https://www.rfc-editor.org/info/rfc8248>. <https://www.rfc-editor.org/info/rfc8248>.
[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
Oriented Lightweight Information Exchange (ROLIE)", Oriented Lightweight Information Exchange (ROLIE)",
RFC 8322, DOI 10.17487/RFC8322, February 2018, RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/info/rfc8322>. <https://www.rfc-editor.org/info/rfc8322>.
[XMPPEXT] "XMPP Extensions", May 2020, [XMPPEXT] "XMPP Extensions", n.d., <https://xmpp.org/extensions/>.
<https://xmpp.org/extensions/>.
Appendix A. Security Domain Workflows Appendix A. Security Domain Workflows
This section describes three primary information security domains This section describes three primary information security domains
from which workflows may be derived: IT Asset Management, from which workflows may be derived: IT Asset Management,
Vulnerability Management, and Configuration Management. Vulnerability Management, and Configuration Management.
A.1. IT Asset Management A.1. IT Asset Management
Information Technology asset management is easier said than done. Information Technology asset management is easier said than done.
 End of changes. 131 change blocks. 
275 lines changed or deleted 692 lines changed or added

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