draft-ietf-sacm-arch-00.txt   draft-ietf-sacm-arch-01.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: February 25, 2019 August 24, 2018 Expires: August 26, 2019 February 22, 2019
Security Automation and Continuous Monitoring (SACM) Architecture Security Automation and Continuous Monitoring (SACM) Architecture
draft-ietf-sacm-arch-00 draft-ietf-sacm-arch-01
Abstract Abstract
This memo defines a Security Automation and Continuous Monitoring This memo defines a Security Automation and Continuous Monitoring
(SACM) architecture. This work is built upon (SACM) architecture. This work is built upon
[I-D.ietf-mile-xmpp-grid], and is predicated upon information gleaned [I-D.ietf-mile-xmpp-grid], and is predicated upon information gleaned
from SACM Use Cases and Requirements ([RFC7632] and [RFC8248] from SACM Use Cases and Requirements ([RFC7632] and [RFC8248]
respectively), and terminology as found in respectively), and terminology as found in
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
skipping to change at page 1, line 33 skipping to change at page 1, line 33
that page as well. that page as well.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 February 25, 2019. This Internet-Draft will expire on August 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Open Questions . . . . . . . . . . . . . . . . . . . . . 3 1.1. Open Questions . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
3.1. SACM Roles . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. SACM Roles . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Exploring An XMPP-based Solution . . . . . . . . . . . . 5 3.2. Exploring An XMPP-based Solution . . . . . . . . . . . . 5
4. Components, Capabilities, Interfaces, and Workflows . . . . . 7 3.3. Example Architecture using XMPP-Grid and Endpoint Posture
4.1. Components . . . . . . . . . . . . . . . . . . . . . . . 7 Collection Protocol . . . . . . . . . . . . . . . . . . . 8
4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 8 4. Components, Capabilities, Interfaces, and Workflows . . . . . 10
4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Components . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Workflows . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. IT Asset Management . . . . . . . . . . . . . . . . . 9 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Vulnerability Management . . . . . . . . . . . . . . 10 4.4. Workflows . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.3. Configuration Management . . . . . . . . . . . . . . 12 4.4.1. IT Asset Management . . . . . . . . . . . . . . . . . 12
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 4.4.2. Vulnerability Management . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.4.3. Configuration Management . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Mapping to RFC8248 . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
Appendix B. Example Components . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 16
B.1. Policy Services . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Mapping to RFC8248 . . . . . . . . . . . . . . . . . 18
B.2. Software Inventory . . . . . . . . . . . . . . . . . . . 19 Appendix B. Example Components . . . . . . . . . . . . . . . . . 21
B.3. Datastream Collection . . . . . . . . . . . . . . . . . . 20 B.1. Policy Services . . . . . . . . . . . . . . . . . . . . . 21
B.4. Network Configuration Collection . . . . . . . . . . . . 20 B.2. Software Inventory . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 B.3. Datastream Collection . . . . . . . . . . . . . . . . . . 23
B.4. Network Configuration Collection . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The purpose of this draft is to define an architectural solution for The purpose of this draft is to define an architectural solution for
a SACM Domain. This draft also defines an implementation of the a SACM Domain. This draft also defines an implementation of the
architecutre, built upon [I-D.ietf-mile-xmpp-grid] and architecutre, built upon [I-D.ietf-mile-xmpp-grid] and
[I-D.ietf-sacm-ecp]. These approaches complement each other to more [I-D.ietf-sacm-ecp]. These approaches complement each other to more
completely meet the spirit of [RFC7632] and requirements found in completely meet the spirit of [RFC7632] and requirements found in
[RFC8248]. [RFC8248].
skipping to change at page 4, line 20 skipping to change at page 4, line 20
3. Architectural Overview 3. Architectural Overview
The generic approach proposed herein recognizes the need to obtain The generic approach proposed herein recognizes the need to obtain
information from existing state collection mechanisms, and makes information from existing state collection mechanisms, and makes
every attempt to respect [RFC7632] and [RFC8248]. At the foundation every attempt to respect [RFC7632] and [RFC8248]. At the foundation
of any architecture are entities, or components, that need to of any architecture are entities, or components, that need to
communicate. They communicate by sharing information, where, in a communicate. They communicate by sharing information, where, in a
given flow one or more components are consumers of information and given flow one or more components are consumers of information and
one or more components are providers of information. one or more components are providers of information.
+----------+ +------+ +------------+ +--------------------+
|Repository| |Policy| |Orchestrator| | Feeds/Repositories |
+----^-----+ +--^---+ +----^-------+ +----------------+ | of External Data |
A | B | C | | Downstream Uses| +--------------------+
| | | | +-----------+ | |
+----v---------------v------------v-------+ | |Evaluations| | |
| Message Transfer <-------> +-----------+ | *****************************v**************** Enterprise Boundary ************
+----------------^------------------------+ D | +---------+ | * | *
| | |Analytics| | * +--------------+ | +--------------+ *
| | +---------+ | * | Orchestrator | | | Repositories | *
+-------v--------- | +---------+ | * +------^-------+ | +----^---------+ *
| Transfer System | | |Reporting| | * | | | +----------------+ *
| Connector | | +---------+ | * A | B | C | | Downstream Uses| *
+-------^---------+ +----------------+ * | | | | +-----------+ | *
| * +------v------------------v----------v------+ | |Evaluations| | *
| * | Message Transfer System <-------> +-----------+ | *
+-------v-------+ * +----------------------^--------------------+ D | +-----------+ | *
| Collection | * E | | | Analytics | | *
| System | * | | +-----------+ | *
+---------------+ * +-------------v---------+ | +-----------+ | *
* | Collection Subsystems | | | Reporting | | *
* +-----------------------+ | +-----------+ | *
* +----------------+ *
*******************************************************************************
Figure 1: Notional Architecture Figure 1: Notional Architecture
As shown in Figure 1, the notional SACM architecture consists of some As shown in Figure 1, the notional SACM architecture consists of some
basic SACM Components using a message transfer system to communicate. basic SACM Components using a message transfer system to communicate.
While not depicted, the message transfer system is expected to While not depicted, the message transfer system is expected to
maximally align with the requirements described in [RFC8248], which maximally align with the requirements described in [RFC8248], which
means that the message transfer system will support brokered (i.e. means that the message transfer system will support brokered (i.e.
point-to-point) and proxied data exchange. point-to-point) and proxied data exchange.
Additionally, component-specific interfaces (i.e. such as A, B, C, Additionally, component-specific interfaces (i.e. such as A, B, C, D,
and D in Figure 1) are expected to be specified logically then bound and E in Figure 1) are expected to be specified logically then bound
to one or more specific implementations. This SHOULD be done for to one or more specific implementations. This SHOULD be done for
each capability related to the given SACM Component. each capability related to the given SACM Component.
3.1. SACM Roles 3.1. SACM Roles
This document suggests a variety of players in a cooperative This document suggests a variety of players in a cooperative
ecosystem - we call these players SACM Components. SACM Components ecosystem - we call these players SACM Components. SACM Components
may be composed of other SACM Components, and each SACM Component may be composed of other SACM Components, and each SACM Component
plays one, or more, of several roles relevant to the ecosystem. plays one, or more, of several roles relevant to the ecosystem.
Generally each role is either a consumer of information or a provider Generally each role is either a consumer of information or a provider
of information. The "Components, Capabilities, Interfaces, and of information. The "Components, Capabilities, Interfaces, and
Workflows" section provides more details about SACM Components that Workflows" section provides more details about SACM Components that
play these types of roles. play these types of roles.
3.2. Exploring An XMPP-based Solution 3.2. Exploring An XMPP-based Solution
Figure 2 depicts a more detailed view of the architecture - one that Figure 2 depicts a slightly more detailed view of the architecture
fosters the development of a pluggable ecosystem of cooperative (within the enterprise boundary) - one that fosters the development
tools. Existing collection mechanisms can be brought into this of a pluggable ecosystem of cooperative tools. Existing collection
architecture by specifying the interface of the collector and mechanisms can be brought into this architecture by specifying the
creating the XMPP-Grid Connector binding for that interface. interface of the collector and creating the XMPP-Grid Connector
binding for that interface.
Additionally, while not directly depicted in Figure 2, this Additionally, while not directly depicted in Figure 2, this
architecture does allow point-to-point interfaces. In fact, architecture does allow point-to-point interfaces. In fact,
[I-D.ietf-mile-xmpp-grid] provides brokering capabilities to [I-D.ietf-mile-xmpp-grid] provides brokering capabilities to
facilitate such point-to-point data transfers). Additionally, each facilitate such point-to-point data transfers). Additionally, each
of the SACM Components depicted in Figure 2 may be a provider, a of the SACM Components depicted in Figure 2 may be a provider, a
consumer, or both, depending on the workflow in context. consumer, or both, depending on the workflow in context.
+----------+ +------+ +------------+ +--------------+ +--------------+
|Repository| |Policy| |Orchestrator| | Orchestrator | | Repositories |
+----^-----+ +--^---+ +----^-------+ +------^-------+ +------^-------+
| | | | |
| | | | |
+----v---------------v------------v-----------------+ +-----------------+ +-------v--------------------------v--------+ +-----------------+
| XMPP-Grid+ <-----> Downstream Uses | | XMPP-Grid+ <-----> Downstream Uses |
+-----^-------------^-------------^-------------^---+ +-----------------+ +------------------------^------------------+ +-----------------+
| | | | |
| | | | |
+----v----+ +----v----+ +----v----+ +----v----+ +-------v------+
|XMPP-Grid| |XMPP-Grid| |XMPP-Grid| |XMPP-Grid| | XMPP-Grid |
/~~|Connector|~~~|Connector|~~~|Connector|~~~|Connector|~~\ | Connector(s) |
| +----^----+ +----^----+ +----^----+ +----^----+ | +------^-------+
| | | | | | |
| +----v-----+ +----v-----+ +----v----+ +----v----+ | +------v-------+
| |EPCP/SWIMA| |Datastream| |YANG Push| | IPFIX | | | Collector(s) |
| +----------+ +----------+ +---------+ +---------+ | +--------------+
| Collectors |
\~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
Figure 2: Detailed Architecture Figure 2: XMPP-based Architecture
[I-D.ietf-mile-xmpp-grid] details a number of XMPP extensions (XEPs)
that MUST be utilized to meet the needs of [RFC7632] and [RFC8248]:
o Service Discovery (XEP-0030): Service Discovery allows XMPP
entities to discover information about other XMPP entities. Two
kinds of information can be discovered: the identity and
capabilities of an entity, such as supported features, and items
associated with an entity.
o Publish-Subscribe (XEP-0060): The PubSub extension enables
entities to create nodes (topics) at a PubSub service and publish
information at those nodes. Once published, an event notification
is broadcast to all entities that have subscribed to that node.
At this point, [I-D.ietf-mile-xmpp-grid] specifies fewer features At this point, [I-D.ietf-mile-xmpp-grid] specifies fewer features
than SACM requires, and there are other XMPP extensions (XEPs) we than SACM requires, and there are other XMPP extensions (XEPs) we
need to consider to meet the needs of [RFC7632] and [RFC8248]. In need to consider to meet the needs of [RFC7632] and [RFC8248]. In
Figure 2 we therefore use "XMPP-Grid+" to indicate something more Figure 2 we therefore use "XMPP-Grid+" to indicate something more
than [I-D.ietf-mile-xmpp-grid] alone, even though we are not yet than [I-D.ietf-mile-xmpp-grid] alone, even though we are not yet
fully confident in the exact set of XMPP-related extensions we will fully confident in the exact set of XMPP-related extensions we will
require. The authors propose work to extend (or modify) require. The authors propose work to extend (or modify)
[I-D.ietf-mile-xmpp-grid] to include additional XEPs - possibly the [I-D.ietf-mile-xmpp-grid] to include additional XEPs - possibly the
following: following:
o Entity Capabilities (XEP-0115): May be used to express the o Entity Capabilities (XEP-0115): This extension defines the methods
specific capabilities that a particular client embodies. for broadcasting and dynamically discovering an entities'
capabilities. This information is transported via standard XMPP
presence. Example capabilities that could be discovered could
include support for posture attribute collection, support for
specific types of posture attribute collection such as EPCP,
SWIMA, OVAL, or YANG. Other capabilities are still to be
determined.
o Form Discovery and Publishing (XEP-0346): May be used for o Ad Hoc Commands (XEP-0050): This extension allows an XMPP entity
datastream examples requiring some expression of a request to advertise and execute application-specific commands. Typically
followed by an expected response. the commands contain data forms (XEP-0004) in order to structure
the information exchange. This extension may be usable for simple
orchestration (i.e. "do assessment").
o Ad Hoc Commands (XEP-0050): May be usable for simple orchestration o HTTP File Upload (XEP-0363): The HTTP File Upload extension allows
(i.e. "do assessment"). for large data sets to be published to a specific path on an HTTP
server, and receive a URL from which that file can later be
downloaded again. XMPP messages and IQs are meant to be compact,
and large data sets, such as collected posture attributes, may
exceed a message size threshold. Usage of this XEP allows those
larger data sets to be persisted, thus necessitating only the
download URL to be passed via XMPP messages.
o File Repository and Sharing (XEP-0214): Appears to be needed for o Personal Eventing Protocol (XEP-0163): The Personal Eventing
handling large amounts of data (if not fragmenting). Protocol can be thought of as a virtual PubSub service, allowing
an XMPP account to publish events only to their roster instead of
a generic PubSub topic. This XEP may be useful in the cases when
collection requests or queries are only intended for a subset of
endpoints and not an entire subscriber set.
o Publishing Stream Initiation Requests (XEP-0137): Provides ability o File Repository and Sharing (XEP-0214): This extension defines a
to stream information between two XMPP entities. method for XMPP entities to designate a set of file available for
retrieval by other users of their choosing, and is based on PubSub
Collections.
o PubSub Collection Nodes (XEP-0248): Nested topics for o Easy User Onboarding (XEP-401): The goal of this extension is
specialization to the leaf node level. simplified client registration, and may be useful when adding new
endpoints or SACM components to the ecosystem.
o Security Labels In Pub/Sub (XEP-0314): Enables tagging data with o Bidirectional-streams Over Synchronous HTTP (BOSH) (XEP-0124):
classification categories. BOSH emulates the semantics of a long-lived, bidirectional TCP
connection between two entities (aka "long polling"). Consider a
SACM component that is updated dynamically, i.e. an internal
vulnerability definition repository ingesting data from a Feed/
Repository of External Data, and a second SACM component such as
an Orchestrator. Using BOSH, the Orchestrator can effectively
continuously poll the vulnerability definition repository for
changes/updates.
o PubSub Since (XEP-0312): Persists published items, which may be o PubSub Collection Nodes (XEP-0248): Effectively an extension to
useful in intermittent connection scenarios XEP-0060 (Publish-Subscribe), PubSub Collections aim to simplify
an entities' subscription to multiple related topics, and
establishes a "node graph" relating parent nodes to its
descendents. An example "node graph" could be rooted in a
"vulnerability definitions" topic, and contain descendent topics
for OS family-level vulnerability definitions (i.e. Windows), and
further for OS family version-level definitions (i.e. Windows 10
or Windows Server 2016).
o PubSub Chaining (XEP-0253): Federation of publishing nodes o PubSub Since (XEP-0312): This extension enables a subscriber to
enabling a publish node of one server to be a subscriber to a automatically receive PubSub and Personal Eventing Protocol (PEP)
publishing node of another server notifications since its last logout time. This extension may be
useful in intermittent connection scenarios, or when entities
disconnect and reconnect to the ecosystem.
o Easy User Onboarding (XEP-401): Simplified client registration o PubSub Chaining (XEP-0253): This extension describes the
federation of publishing nodes, enabling a publish node of one
server to be a subscriber to a publishing node of another server.
3.3. Example Architecture using XMPP-Grid and Endpoint Posture
Collection Protocol
Figure 3 depicts a further detailed view of the architecture
including the Endpoint Posture Collection Protocol as the collection
subsystem, illustrating the idea of a pluggable ecosystem of
cooperative tools.
+--------------------+
| Feeds/Repositories |
| of External Data |
+--------------------+
|
********************v************************* Enterprise Boundary ************
* | *
* +--------------+ | +-------------------+ +-------------+ *
* | Orchestrator | | | Posture Attr Repo | | Policy Repo | *
* +------^-------+ | +---------^---------+ +---^---------+ *
* | | | | +----------------+ *
* | | | | | Downstream Uses| *
* | | | | | +-----------+ | *
* +------v---------v-----------v---------------v--+ | |Evaluations| | *
* | XMPP-Grid <-------> +-----------+ | *
* +----------------^-------------------^----------+ | +-----------+ | *
* | | | | Analytics | | *
* | | | +-----------+ | *
* | +-----v--------+ | +-----------+ | *
* | | Results Repo | | | Reporting | | *
* | +--------------+ | +-----------+ | *
* | +----------------+ *
* +---------v-----------+ *
* | XMPP-Grid Connector | *
* +---------^-----------+ *
* | *
* +-----------------v-------------------------------------------------------+ *
* | | *
* | +--Posture Collection Manager------------------------------------------+| *
* | |+-----------------------+ +----------------+ +----------------------+ || *
* | || Communications Server | | Posture Server | | Posture Validator(s) | || *
* | |+----------^------------+ +----------------+ +----------------------+ || *
* | +-----------|----------------------------------------------------------+| *
* | | | *
* | +-----------|-------------------------Endpoint or Endpoint Proxy-------+| *
* | |+----------v------------+ +----------------+ +----------------------+ || *
* | || Communications Client | | Posture Client | | Posture Collector(s) | || *
* | |+-----------------------+ +----------------+ +----------------------+ || *
* | +----------------------------------------------------------------------+| *
* +-----------------Endpoint Posture Collection Profile---------------------+ *
* *
*******************************************************************************
Figure 3: XMPP-based Architecture including EPCP
4. Components, Capabilities, Interfaces, and Workflows 4. Components, Capabilities, Interfaces, and Workflows
The SACM Architecture consists of a variety of SACM Components, and The SACM Architecture consists of a variety of SACM Components, and
named components are intended to embody one or more specific named components are intended to embody one or more specific
capabilities. Interacting with these capabilities will require at capabilities. Interacting with these capabilities will require at
least two levels of interface specification. The first is a logical least two levels of interface specification. The first is a logical
interface specification, and the second is at least one binding to a interface specification, and the second is at least one binding to a
specific transfer mechanism. An example transfer mechanism is XMPP- specific transfer mechanism. An example transfer mechanism is XMPP-
Grid+. Grid+.
skipping to change at page 12, line 13 skipping to change at page 14, line 52
this case, it might be useful to re-configure the endpoint management this case, it might be useful to re-configure the endpoint management
capabilities to no longer collect this information to reduce network capabilities to no longer collect this information to reduce network
and processing overhead. Instead, a new Collection Task can be and processing overhead. Instead, a new Collection Task can be
triggered to gather this data on the rare occasions when it is triggered to gather this data on the rare occasions when it is
needed. needed.
4.4.3. Configuration Management 4.4.3. Configuration Management
Configuration management involves configuration assessment, which Configuration management involves configuration assessment, which
requires state assessment (TODO: Tie to SACM use cases). The requires state assessment (TODO: Tie to SACM use cases). The
[CISCONTROLS] specify two high-level controls conerning configuration [CISCONTROLS] specify two high-level controls concerning
managment (Control 5 for non-network devices and Control 11 for configuration management (Control 5 for non-network devices and
network devices). As an aside, these controls are listed separately Control 11 for network devices). As an aside, these controls are
because many enterprises have different organizations for managing listed separately because many enterprises have different
network infrastructure and workload endpoints. Merging the two organizations for managing network infrastructure and workload
controls results in a requirement to: "Establish, implement, and endpoints. Merging the two controls results in a requirement to:
actively manage (track, report on, correct) the security "Establish, implement, and actively manage (track, report on,
configuration of (endpoints) using a rigorous configuration correct) the security configuration of (endpoints) using a rigorous
management and change control process in order to prevent attackers configuration management and change control process in order to
from exploiting vulnerable services and settings." prevent attackers from exploiting vulnerable services and settings."
Typically, an enterprise will use configuration guidance from a Typically, an enterprise will use configuration guidance from a
reputable source, and from time to time they may tailor the guidance reputable source, and from time to time they may tailor the guidance
from that source prior to adopting it as part of their enterprise from that source prior to adopting it as part of their enterprise
standard. The enterprise standard is then provided to the standard. The enterprise standard is then provided to the
appropriate configuration assessment tools and they assess endpoints appropriate configuration assessment tools and they assess endpoints
and/or appropriate endpoint information. A preferred flow follows: and/or appropriate endpoint information. A preferred flow follows:
o Reputable source publishes new or updated configuration guidance o Reputable source publishes new or updated configuration guidance
skipping to change at page 13, line 34 skipping to change at page 16, line 26
o Associations of SACM Components (and versions) to specific o Associations of SACM Components (and versions) to specific
Capabilities Capabilities
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mile-xmpp-grid] [I-D.ietf-mile-xmpp-grid]
Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre,
"Using XMPP for Security Information Exchange", draft- "Using XMPP for Security Information Exchange", draft-
ietf-mile-xmpp-grid-06 (work in progress), June 2018. ietf-mile-xmpp-grid-09 (work in progress), December 2018.
[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", draft-ietf-sacm-
ecp-02 (work in progress), July 2018. ecp-04 (work in progress), February 2019.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
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
Attributes (SWIMA) for PA-TNC", RFC 8412, Attributes (SWIMA) for PA-TNC", RFC 8412,
DOI 10.17487/RFC8412, July 2018, <https://www.rfc- DOI 10.17487/RFC8412, July 2018,
editor.org/info/rfc8412>. <https://www.rfc-editor.org/info/rfc8412>.
8.2. Informative References 8.2. Informative References
[CISCONTROLS] [CISCONTROLS]
"CIS Controls v7.0", n.d., <https://www.cisecurity.org/ "CIS Controls v7.0", n.d.,
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", n.d., notifications via SACM Statements", n.d.,
<https://tools.ietf.org/html/draft-birkholz-sacm-yang- <https://tools.ietf.org/html/
content-01>. draft-birkholz-sacm-yang-content-01>.
[HACK100] "IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP", [HACK100] "IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP",
n.d., <https://www.github.com/sacmwg/vulnerability- n.d., <https://www.github.com/sacmwg/vulnerability-
scenario/ietf-hackathon>. scenario/ietf-hackathon>.
[HACK101] "IETF 101 Hackathon - Configuration Assessment XMPP", [HACK101] "IETF 101 Hackathon - Configuration Assessment XMPP",
n.d., <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", n.d., <https://www.github.com/CISecurity/ Endpoints", n.d.,
YANG>. <https://www.github.com/CISecurity/YANG>.
[HACK99] "IETF 99 Hackathon - Vulnerability Scenario EPCP", n.d., [HACK99] "IETF 99 Hackathon - Vulnerability Scenario EPCP", n.d.,
<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", draft-ietf-sacm-
terminology-15 (work in progress), June 2018. terminology-16 (work in progress), December 2018.
[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]
skipping to change at page 15, line 11 skipping to change at page 18, line 7
7694 Specification for Asset Reporting Format 1.1", n.d., 7694 Specification for Asset Reporting Format 1.1", n.d.,
<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, <https://www.rfc- DOI 10.17487/RFC7632, September 2015,
editor.org/info/rfc7632>. <https://www.rfc-editor.org/info/rfc7632>.
[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, <https://www.rfc- DOI 10.17487/RFC8248, September 2017,
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", n.d., <https://xmpp.org/extensions/>. [XMPPEXT] "XMPP Extensions", n.d., <https://xmpp.org/extensions/>.
Appendix A. Mapping to RFC8248 Appendix A. Mapping to RFC8248
skipping to change at page 19, line 43 skipping to change at page 22, line 40
Evaluator Repository | | | | | | Evaluator Repository | | | | | |
+------+ +--------+ | +-----------+ |<-------| +-----------+ | +------+ +--------+ | +-----------+ |<-------| +-----------+ |
| | | | | | Posture | | report | | Posture | | | | | | | | Posture | | report | | Posture | |
| | | | | | Collection| | | | Collection| | | | | | | | Collection| | | | Collection| |
| |<-----> | |<-----| | Manager | | query | | Engine | | | |<-----> | |<-----| | Manager | | query | | Engine | |
| |request/| | store| +-----------+ |------->| +-----------+ | | |request/| | store| +-----------+ |------->| +-----------+ |
| |respond | | | | | | | |respond | | | | | |
| | | | | | | | | | | | | | | |
+------+ +--------+ +---------------+ +---------------+ +------+ +--------+ +---------------+ +---------------+
Figure 3: EPCP Collection Architecture Figure 4: EPCP Collection Architecture
In Figure 3, any of the communications between the Posture Manager In Figure 4, any of the communications between the Posture Manager
and EPCP components to its left could be performed directly or and EPCP components to its left could be performed directly or
indirectly using a given message transfer mechanism. For example, indirectly using a given message transfer mechanism. For example,
the pub/sub interface between the Orchestrator and the Posture the pub/sub interface between the Orchestrator and the Posture
Manager could be using a proprietary method or using Manager could be using a proprietary method or using
[I-D.ietf-mile-xmpp-grid] or some other pub/sub mechanism. [I-D.ietf-mile-xmpp-grid] or some other pub/sub mechanism.
Similarly, the store connection from the Posture Manager to the Similarly, the store connection from the Posture Manager to the
Repository could be performed internally to a given implementation, Repository could be performed internally to a given implementation,
via a RESTful API invocation over HTTPS, or even over a pub/sub via a RESTful API invocation over HTTPS, or even over a pub/sub
mechanism. mechanism.
 End of changes. 35 change blocks. 
125 lines changed or deleted 236 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/