idnits 2.17.1 draft-ietf-sacm-arch-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 32 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-sacm-terminology], [RFC7632], [RFC8248]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 July 2021) is 1020 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5792' is mentioned on line 193, but not defined == Missing Reference: 'TBD' is mentioned on line 1777, but not defined == Missing Reference: 'MORE' is mentioned on line 1795, but not defined == Unused Reference: 'I-D.ietf-sacm-ecp' is defined on line 1830, but no explicit reference was found in the text == Unused Reference: 'RFC8412' is defined on line 1846, but no explicit reference was found in the text == Unused Reference: 'RFC8600' is defined on line 1852, but no explicit reference was found in the text == Unused Reference: 'HACK100' is defined on line 1870, but no explicit reference was found in the text == Unused Reference: 'HACK101' is defined on line 1874, but no explicit reference was found in the text == Unused Reference: 'HACK102' is defined on line 1877, but no explicit reference was found in the text == Unused Reference: 'HACK103' is defined on line 1881, but no explicit reference was found in the text == Unused Reference: 'HACK104' is defined on line 1884, but no explicit reference was found in the text == Unused Reference: 'HACK105' is defined on line 1887, but no explicit reference was found in the text == Unused Reference: 'HACK99' is defined on line 1891, but no explicit reference was found in the text == Unused Reference: 'NIST800126' is defined on line 1913, but no explicit reference was found in the text == Unused Reference: 'NISTIR7694' is defined on line 1921, but no explicit reference was found in the text == Unused Reference: 'RFC3444' is defined on line 1927, but no explicit reference was found in the text == Unused Reference: 'RFC5023' is defined on line 1936, but no explicit reference was found in the text == Unused Reference: 'RFC6192' is defined on line 1945, but no explicit reference was found in the text == Unused Reference: 'RFC8322' is defined on line 1959, but no explicit reference was found in the text == Unused Reference: 'XMPPEXT' is defined on line 1964, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 21 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group A. Montville 3 Internet-Draft B. Munyan 4 Intended status: Standards Track CIS 5 Expires: 10 January 2022 9 July 2021 7 Security Automation and Continuous Monitoring (SACM) Architecture 8 draft-ietf-sacm-arch-13 10 Abstract 12 This document defines an architecture enabling a cooperative Security 13 Automation and Continuous Monitoring (SACM) ecosystem. This work is 14 predicated upon information gleaned from SACM Use Cases and 15 Requirements ([RFC7632] and [RFC8248] respectively), and terminology 16 as found in [I-D.ietf-sacm-terminology]. 18 WORKING GROUP: The source for this draft is maintained in GitHub. 19 Suggested changes should be submitted as pull requests at 20 https://github.com/sacmwg/ietf-mandm-sacm-arch/. Instructions are on 21 that page as well. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 10 January 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 58 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 59 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 60 3.1. Producer . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2. Consumer . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3. Integration Service . . . . . . . . . . . . . . . . . . . 9 63 3.4. Payload/Message . . . . . . . . . . . . . . . . . . . . . 10 64 3.5. Payload Categorization . . . . . . . . . . . . . . . . . 10 65 3.5.1. Topic-centric . . . . . . . . . . . . . . . . . . . . 10 66 3.5.2. Payload-centric . . . . . . . . . . . . . . . . . . . 11 67 3.6. Capabilities . . . . . . . . . . . . . . . . . . . . . . 11 68 3.7. Interaction Categories . . . . . . . . . . . . . . . . . 12 69 3.7.1. Broadcast . . . . . . . . . . . . . . . . . . . . . . 12 70 3.7.2. Directed . . . . . . . . . . . . . . . . . . . . . . 12 71 4. SACM Role-based Architecture . . . . . . . . . . . . . . . . 13 72 4.1. Architectural Roles/Components . . . . . . . . . . . . . 14 73 4.1.1. Manager . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1.2. Orchestrator(s) . . . . . . . . . . . . . . . . . . . 14 75 4.1.3. Repositories . . . . . . . . . . . . . . . . . . . . 15 76 4.1.4. Integration Service . . . . . . . . . . . . . . . . . 15 77 4.2. Downstream Uses . . . . . . . . . . . . . . . . . . . . . 16 78 4.2.1. Reporting . . . . . . . . . . . . . . . . . . . . . . 16 79 4.2.2. Analytics . . . . . . . . . . . . . . . . . . . . . . 16 80 4.3. Sub-Architectures . . . . . . . . . . . . . . . . . . . . 16 81 4.3.1. Collection Sub-Architecture . . . . . . . . . . . . . 16 82 4.3.2. Evaluation Sub-Architecture . . . . . . . . . . . . . 19 83 5. Ecosystem Interactions . . . . . . . . . . . . . . . . . . . 21 84 5.1. Manager . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 5.2. Component Registration . . . . . . . . . . . . . . . . . 22 86 5.3. Administrative Interface . . . . . . . . . . . . . . . . 23 87 5.3.1. Capability Advertisement Handshake . . . . . . . . . 23 88 5.3.2. Health Check . . . . . . . . . . . . . . . . . . . . 23 89 5.3.3. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 23 90 5.3.4. Capability-specific Requests . . . . . . . . . . . . 24 91 5.4. Status Notifications . . . . . . . . . . . . . . . . . . 24 92 5.5. Component Interactions . . . . . . . . . . . . . . . . . 24 93 5.5.1. Initiate Ad-Hoc Collection . . . . . . . . . . . . . 24 94 5.5.2. Coordinate Periodic Collection . . . . . . . . . . . 24 95 5.5.3. Coordinate Observational/Event-based Collection . . . 25 96 5.5.4. Persist Collected Posture Attributes . . . . . . . . 26 97 5.5.5. Initiate Ad-Hoc Evaluation . . . . . . . . . . . . . 26 98 5.5.6. Coordinate Periodic Evaluation . . . . . . . . . . . 26 99 5.5.7. Coordinate Change-based Evaluation . . . . . . . . . 27 100 5.5.8. Queries . . . . . . . . . . . . . . . . . . . . . . . 27 101 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 6.1. Component Registration . . . . . . . . . . . . . . . . . 27 103 6.1.1. Request Payload . . . . . . . . . . . . . . . . . . . 28 104 6.1.2. Request Processing . . . . . . . . . . . . . . . . . 28 105 6.1.3. Response Payload . . . . . . . . . . . . . . . . . . 29 106 6.1.4. Response Processing . . . . . . . . . . . . . . . . . 29 107 6.2. Administrative Interface . . . . . . . . . . . . . . . . 29 108 6.2.1. Capability Advertisement Handshake . . . . . . . . . 29 109 6.2.2. Health Check . . . . . . . . . . . . . . . . . . . . 31 110 6.2.3. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 32 111 6.3. Status Notification . . . . . . . . . . . . . . . . . . . 33 112 6.3.1. Request Payload . . . . . . . . . . . . . . . . . . . 34 113 6.3.2. Request Processing . . . . . . . . . . . . . . . . . 34 114 6.3.3. Response Payload . . . . . . . . . . . . . . . . . . 34 115 6.3.4. Response Processing . . . . . . . . . . . . . . . . . 34 116 6.4. Initiate Ad-Hoc Collection . . . . . . . . . . . . . . . 34 117 6.4.1. SACM Producer to Orchestrator . . . . . . . . . . . . 36 118 6.4.2. Orchestrator to Posture Collection Service . . . . . 36 119 6.4.3. Posture Collection Service to Posture Attribute 120 Repository . . . . . . . . . . . . . . . . . . . . . 38 121 6.5. Initiate Ad-Hoc Evaluation . . . . . . . . . . . . . . . 39 122 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 123 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 125 9.1. Component Types . . . . . . . . . . . . . . . . . . . . . 39 126 9.2. Component Capabilities . . . . . . . . . . . . . . . . . 40 127 9.2.1. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 40 128 9.2.2. Status Notification (Publish) . . . . . . . . . . . . 40 129 9.2.3. Status Notification (Subscribe) . . . . . . . . . . . 40 130 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 131 10.1. Normative References . . . . . . . . . . . . . . . . . . 40 132 10.2. Informative References . . . . . . . . . . . . . . . . . 41 133 Appendix A. Security Domain Workflows . . . . . . . . . . . . . 43 134 A.1. IT Asset Management . . . . . . . . . . . . . . . . . . . 43 135 A.1.1. Components, Capabilities and Workflow(s) . . . . . . 44 136 A.2. Vulnerability Management . . . . . . . . . . . . . . . . 44 137 A.2.1. Components, Capabilities and Workflow(s) . . . . . . 45 138 A.3. Configuration Management . . . . . . . . . . . . . . . . 46 139 A.3.1. Components, Capabilities and Workflow(s) . . . . . . 47 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 142 1. Introduction 144 The purpose of this draft is to define an architectural approach for 145 a SACM Domain, based on the spirit of use cases found in [RFC7632] 146 and requirements found in [RFC8248]. This approach gains the most 147 advantage by supporting a variety of collection systems, and intends 148 to enable a cooperative ecosystem of tools from disparate sources 149 with minimal operator configuration. 151 1.1. Requirements notation 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in RFC 156 2119, BCP 14 [RFC2119]. 158 2. Terms and Definitions 160 Assessment: Defined in [RFC5209] as "the process of collecting 161 posture for a set of capabilities on the endpoint (e.g., host- 162 based firewall) such that the appropriate validators may evaluate 163 the posture against compliance policy." 165 Asset: Is a system resource, as defined in [RFC4949], that may be 166 composed of other assets. 168 Examples of Assets include: Endpoints, Software, Guidance, or 169 X.509 public key certificates. An asset is not necessarily owned 170 by an organization. 172 Asset Management: The IT process by which assets are provisioned, 173 updated, maintained and deprecated. 175 Attribute: Is a data element, as defined in [RFC5209], that is 176 atomic. 178 In the context of SACM, attributes are "atomic" information 179 elements and an equivalent to attribute-value-pairs. Attributes 180 can be components of Subjects. 182 Capability: A set of features that are available from a SACM 183 Component. 185 See also "capability" in [I-D.ietf-i2nsf-terminology]. 187 Collector: A piece of software that acquires information about one 188 or more target endpoints by conducting collection tasks. 190 A collector can be distributed across multiple endpoints, e.g. 191 across a target endpoint and a SACM component. The separate parts 192 of the collector can communicate with a specialized protocol, such 193 as PA-TNC [RFC5792]. At least one part of a distributed collector 194 has to take on the role of a provider of information by providing 195 SACM interfaces to propagate capabilities and to provide SACM 196 content in the form of collection results. 198 Configuration: A non-volatile subset of the endpoint attributes of a 199 endpoint that is intended to be unaffected by a normal reboot- 200 cycle. 202 Configuration is a type of imperative guidance that is stored in 203 files (files dedicated to contain configuration and/ or files that 204 are software components), directly on block devices, or on 205 specific hardware components that can be accessed via 206 corresponding software components. Modification of configuration 207 can be conducted manually or automatically via management (plane) 208 interfaces that support management protocols, such as SNMP or WMI. 209 A change of configuration can occur during both run-time and down- 210 time of an endpoint. It is common practice to scheduled a change 211 of configuration during or directly after the completion of a 212 boot-cycle via corresponding software components located on the 213 target endpoint itself. 215 Consumer: A SACM Role that requires a SACM Component to include SACM 216 Functions enabling it to receive information from other SACM 217 Components. 219 Endpoint: Defined in [RFC5209] as "any computing device that can be 220 connected to a network." 222 Additional Information - The [RFC5209] definition continues, "Such 223 devices normally are associated with a particular link layer 224 address before joining the network and potentially an IP address 225 once on the network. This includes: laptops, desktops, servers, 226 cell phones, or any device that may have an IP address." 228 To further clarify the [RFC5209] definition, an endpoint is any 229 physical or virtual device that may have a network address. Note 230 that, network infrastructure devices (e.g. switches, routers, 231 firewalls), which fit the definition, are also considered to be 232 endpoints within this document. 234 Physical endpoints are always composites that are composed of 235 hardware components and software components. Virtual endpoints 236 are composed entirely of software components and rely on software 237 components that provide functions equivalent to hardware 238 components. 240 The SACM architecture differentiates two essential categories of 241 endpoints: Endpoints whose security posture is intended to be 242 assessed (target endpoints) and endpoints that are specifically 243 excluded from endpoint posture assessment (excluded endpoints). 245 Based on the definition of an asset, an endpoint is a type of 246 asset. 248 Endpoint Attribute: Is a discreet endpoint characteristic that is 249 computably observable. 251 Endpoint Attributes typically constitute Attributes that can be 252 bundled into Subject (e.g. information about a specific network 253 interface can be represented via a set of multiple AVP). 255 Endpoint Characteristics: The state, configuration and composition 256 of the software components and (virtual) hardware components a 257 target endpoint is composed of, including observable behavior, 258 e.g. sys-calls, log-files, or PDU emission on a network. 260 In SACM work-flows, (Target) Endpoint Characteristics are 261 represented via Information Elements. 263 Posture: Defined in [RFC5209] as "configuration and/or status of 264 hardware or software on an endpoint as it pertains to an 265 organization's security policy." 267 This term is used within the scope of SACM to represent the 268 configuration and state information that is collected from a 269 target endpoint in the form of endpoint attributes (e.g. software/ 270 hardware inventory, configuration settings, dynamically assigned 271 addresses). This information may constitute one or more posture 272 attributes. 274 Posture Attributes: Defined in [RFC5209] as "attributes describing 275 the configuration or status (posture) of a feature of the 276 endpoint. A Posture Attribute represents a single property of an 277 observed state. For example, a Posture Attribute might describe 278 the version of the operating system installed on the system." 280 Within this document this term represents a specific assertion 281 about endpoint configuration or state (e.g. configuration setting, 282 installed software, hardware) represented via endpoint attributes. 283 The phrase "features of the endpoint" highlighted above refers to 284 installed software or software components. 286 Provider: A provider is a SACM role assigned to a SACM component 287 that provides role-specific functions to provide information to 288 other SACM components. 290 Repository: A repository is a controller that contains functions to 291 consume, store and provide information of a particular kind. 293 Such information is typically data transported on the data plane, 294 but potentially also data and metadata from the control and 295 management plane. A single repository may provide the functions 296 of more than one specific repository type (i.e. configuration 297 baseline repository, assessment results repository, etc.) 299 Security Automation: The process of which security alerts can be 300 automated through the use of different components to monitor, 301 analyze and assess endpoints and network traffic for the purposes 302 of detecting misconfigurations, misbehaviors or threats. 304 Security Automation is intended to identify target endpoints that 305 cannot be trusted (see "trusted" in [RFC4949]. This goal is 306 achieved by creating and processing evidence (assessment 307 statements) that a target endpoint is not a trusted system 308 [RFC4949]. 310 SIEM: TBD 312 SOAR: TBD 314 State: A volatile set of endpoint attributes of a (target) endpoint 315 that is affected by a reboot-cycle. 317 Local state is created by the interaction of components with other 318 components via the control plane, via processing data plane 319 payload, or via the functional properties of local hardware and 320 software components. Dynamic configuration (e.g. IP address 321 distributed dynamically via an address distribution and management 322 services, such as DHCP) is considered state that is the result of 323 the interaction with another component (e.g. provided by a DHCP 324 server with a specific configuration). 326 Target Endpoint: Is an endpoint that is under assessment at some 327 point in, or region of, time. 329 Every endpoint that is not specifically designated as an excluded 330 endpoint is a target endpoint. A target endpoint is not part of a 331 SACM domain unless it contains a SACM component (e.g. a SACM 332 component that publishes collection results coming from an 333 internal collector). 335 A target endpoint is similar to a device that is a Target of 336 Evaluation (TOE) as defined in Common Criteria and as referenced 337 by [RFC4949]. 339 Vulnerability Assessment: An assessment specifically tailored to 340 determining whether a set of endpoints is vulnerable according to 341 the information contained in the vulnerability description 342 information. 344 Workflow: A workflow is a modular composition of tasks that can 345 contain loops, conditionals, multiple starting points and multiple 346 endpoints. 348 The most prominent workflow in SACM is the assessment workflow. 350 --> 352 3. Architectural Overview 354 The generic approach proposed herein recognizes the need to obtain 355 information from existing and future state collection systems, and 356 makes every attempt to respect [RFC7632] and [RFC8248]. At the 357 foundation of any architecture are entities, or components, that need 358 to communicate. They communicate by sharing information, where, in a 359 given flow, one or more components are consumers of information and 360 one or more components are providers of information. Different roles 361 within a cooperative ecosystem may act as both Producers and 362 Consumers of SACM-relevant information. 364 +----------------+ 365 | SACM Component | 366 | (Producer) | 367 +-------+--------+ 368 | 369 | 370 +--------------v----------------+ 371 | Integration Service | 372 +--------------+----------------+ 373 | 374 | 375 +-------v--------+ 376 | SACM Component | 377 | (Consumer) | 378 +----------------+ 380 Figure 1: Basic Architectural Structure 382 3.1. Producer 384 A Producer can be described as an abstraction that refers to an 385 entity capable of sending SACM-relevant information to one or many 386 Consumers. In general, information (a "payload") is produced to a 387 particular topic, subscribed to by one or more Consumers. Producers 388 need not be concerned about any specifics of the payload it is 389 providing to a given topic. A Producer may, for example, publish 390 posture collection instructions to collector topics. 392 3.2. Consumer 394 A Consumer can be described as an abstraction that refers to an 395 entity capable of receiving SACM-relevant information from one or 396 many Producers. A Consumer acts as a subscriber to a given topic (or 397 set of topics), enabling it to receive event notifications when a 398 Producer provides a payload to that topic or topics. Consumers 399 receive payloads and act upon them according to their capabilities. 400 A Consumer may, for example, subscribe to a posture collection topic 401 to receive and act upon, collection instructions. 403 3.3. Integration Service 405 The Integration Service acts as the broker between Producers and 406 Consumers; acting as the destination for Producers to publish 407 payloads, and as the source for Consumers subscribing to those 408 payloads. 410 SACM Components are intended to interact with other SACM Components. 411 These interactions can be thought of, at the architectural level, as 412 the combination of interfaces with their supported operations. Each 413 interaction will convey a classified payload of information. This 414 classification of payload information allows Consumers to subscribe 415 to only the classifications to which they are capable of handling. 416 The payload information should contain subdomain-specific 417 characteristics and/or instructions. 419 3.4. Payload/Message 421 The payload (sometimes referred to as a "message" or "message 422 payload") is the unit of data involved in any given interaction 423 between two SACM components. The payload MAY be used to convey the 424 semantic meaning of the operation to be performed. Protocols such as 425 [RFC6120] achieves this meaning through XML namespace identification 426 within a "" or "" stanza. Topic-centric protocols 427 such as [MQTT] convey the meaning of payloads through topic naming 428 techniques. Both methods require connected components to verify 429 message payloads according to their respective capabilities. 431 With respect to the Integration Service, the payload is simply an 432 array of bytes, so the data contained within it is not required to 433 convey a specific format or meaning to the Integration Service. The 434 serialization of the payload combined with the payload categorization 435 provides meaning within the SACM context. 437 3.5. Payload Categorization 439 Within the SACM ecosystem, categorization of payloads and their 440 transport provide the context through which various capabilities are 441 achieved. Two types of payload categorization can be described. 443 3.5.1. Topic-centric 445 Topic-centric payload categorization allows for a broad spectrum of 446 payloads by characterizing those payloads through the Integration 447 Service topic. In this categorization, the topic name becomes a 448 label attached to the payload to which the Integration Service 449 matches against known subscriptions. The topic becomes the 450 operational context for the payload. Topic-centric categorization 451 allows for any payload to be sent to any topic, but requires that 452 SACM consumers parse the payloads to determine whether or not they 453 have the capability to act on those payloads. 455 When interacting using a topic-centric payload categorization, topic 456 naming conventions SHOULD provide an adequate amount of information 457 to be deterministic regarding the purpose of the interaction. For 458 example, a topic named "/notification/collection/oval" would indicate 459 that (a) the topic is a broadcast/notification (publish/subscribe) 460 topic, (b) subscribers to this topic are performing a "collection" 461 action, and (c) the payloads published to the topic are represented 462 using the OVAL serialization format. 464 3.5.2. Payload-centric 466 Payload-centric categorization encapsulates the intent of an 467 interaction within the message payload itself, using an identifying 468 token, tag, or namespace identifier. This method allows for the 469 limitation of message types, and therefore increases the 470 extensibility of message payloads. 472 Payload-centric categorization allows for modularization and 473 specification of extensions, and for plugin-based support of 474 capabilities based the categorization. XMPP is an example of 475 utilization of payload-centric categorization, allowing only three 476 distinct "stanzas" ("", "", and ""), using 477 payloads defined by the various extension protocols maintained by the 478 XMPP standards foundation. 480 3.6. Capabilities 482 SACM components interact with each other based on their capacity to 483 perform specific actions. In advertising its capabilities, a SACM 484 component indicates its competence to understand message payloads, 485 perform any payload translation or normalization, and act upon that 486 message. For example, an Orchestration component receives a message 487 to initiate posture attribute collection. The Orchestrator may then 488 normalize those instructions to a particular collection system's 489 serialization. The normalized instructions are then published to the 490 Integration Service, notifying the appropriate subscribers. 492 Capabilities are described using Uniform Resource Names (URNs), which 493 will be maintained and enhanced via IANA tables (IANA 494 Considerations). Using topic-centric categorization of message 495 payloads, capability URNs SHOULD be associated with Integration 496 Service topics to which publishers, subscribers, and service 497 handlers, will interact. Topic naming conventions are considered 498 implementation details and are not considered for standardization. 499 Given a payload-centric categorization of message payloads, 500 capability URNs SHOULD be used as the identifying token, tag, or 501 namespace in order to distinguish specific payloads. 503 3.7. Interaction Categories 505 Two categories of interactions SHOULD be supported by the Integration 506 Service: broadcast and directed. Broadcast interactions are 507 asynchronous by default, and directed interactions may be invoked 508 either synchronously or asynchronously. 510 3.7.1. Broadcast 512 A broadcast interaction, commonly referred to as publish/subscribe, 513 allows for a wider distribution of a message payload. When a payload 514 is published to the Integration Service, all subscribers to that 515 payload are alerted and may consume the message payload. This 516 category of interaction can also be described as a "unicast" 517 interaction when only a single subscriber exists. An example of a 518 broadcast interaction could be to publish Linux OVAL objects to a 519 posture collection topic. Subscribing consumers receive the 520 notification, and proceed to collect endpoint configuration posture 521 based on the supplied message payload. 523 3.7.2. Directed 525 The intent of a directed interaction is to enable point-to-point 526 communications between a producer and consumer, through the standard 527 interfaces provided by the Integration Service. The provider 528 component indicates which consumer is intended to receive the 529 payload, and the Integration Service routes the payload directly to 530 that consumer. Two "styles" of directed interaction exist, differing 531 only by the response from the consumer. 533 3.7.2.1. Synchronous 535 Synchronous, request/response style interaction requires that the 536 requesting component block and wait for the receiving component to 537 respond, or to time out when that response is delayed past a given 538 time threshold. A synchronous interaction example may be querying a 539 CMDB for posture attribute information in order to perform an 540 evaluation. 542 3.7.2.2. Asynchronous 544 An asynchronous interaction involves the payload producer directing 545 the message to a consumer, but not blocking or waiting for an 546 immediate response. This style of interaction allows the producer to 547 continue on to other activities without the need to wait for 548 responses. This style is particularly useful when the interaction 549 payload invokes a potentially long-running task, such as data 550 collection, report generation, or policy evaluation. The receiving 551 component may reply later via callbacks or further interactions, but 552 it is not mandatory. 554 4. SACM Role-based Architecture 556 Within the cooperative SACM ecosystem, a number of roles act in 557 coordination to provide relevant policy/guidance, perform data 558 collection, storage, evaluation, and support downstream analytics and 559 reporting. 561 +-------------------------------------------+ 562 | Manager | 563 +-------------------^-----------------------+ 564 | 565 +-----------------+ | +--------------------+ 566 | Orchestrator(s) | | | Repository(-ies) | 567 +---------^-------+ | +----------^---------+ 568 | | | +--------------------+ 569 | | | | Downstream Uses | 570 | | | | +----------------+ | 571 +---------v---------v-------------v---------+ | | Analytics | | 572 | Integration Service <------> +----------------+ | 573 +-----------^--------------------------^----+ | +----------------+ | 574 | | | | Reporting | | 575 | | | +----------------+ | 576 +-----------v-------------------+ | +--------------------+ 577 | Collection Sub-Architecture | | 578 +-------------------------------+ | 579 +---------------v---------------+ 580 | Evaluation Sub-Architecture | 581 +-------------------------------+ 583 Figure 2: Notional Role-based Architecture 585 As shown in Figure 2, the SACM role-based architecture consists of 586 some basic SACM Components communicating using an integration 587 service. The integration service is expected to maximally align with 588 the requirements described in [RFC8248], which means that the 589 integration service will support brokered (i.e. point-to-point) and 590 proxied data exchange. 592 4.1. Architectural Roles/Components 594 This document suggests a variety of players in a cooperative 595 ecosystem; known as SACM Components. SACM Components may be composed 596 of other SACM Components, and each SACM Component plays one, or more, 597 of several roles relevant to the ecosystem. Roles may act as 598 providers of information, consumers of information, or both provider 599 and consumer. Figure 2 depicts a number of SACM components which are 600 architecturally significant and therefore warrant discussion and 601 clarification. Each role depicted in Figure 2 represents the 602 interface to the component(s) fulfilling that role, not necessarily 603 any specific implementation. For example, the "Repository" figure 604 represents the interface to persistent storage, and not any 605 particular persistent storage mechanism. 607 4.1.1. Manager 609 The Manager acts as the control plane for the SACM ecosystem; a sort 610 of high level component capable of coordinating the actions, 611 notifications, and events between components. The manager controls 612 the administrative interfaces with the various components of the 613 ecosystem, acting as the central point to which all other components 614 will register and advertise their capabilities. It is the 615 responsibility of the manager to control a component's access to the 616 ecosystem, maintain an inventory of components attached to the 617 ecosystem, and to initiate the various workflows involved in the 618 collection and/or evaluation of posture attributes. 620 The manager should maintain the master set of capabilities that can 621 be supported within the ecosystem. These are the various collection, 622 evaluation, and persistence capabilities with which components may 623 register. The manager MAY be responsible for assigning topics for 624 each of the capabilities that are supported, as registering 625 components subsequently subscribe to, or configure service handlers 626 for, those topics. 628 The manager may act as the user interface to the ecosystem, providing 629 user dashboards, inventories, component management, or operational 630 controls within the boundary of responsibility. 632 4.1.2. Orchestrator(s) 634 Orchestration components provide the manager with resources for 635 delegating work across the SACM ecosystem. Orchestrators are 636 responsible for receiving messages from the manager, e.g. posture 637 attribute collection instructions, and routing those messages to the 638 appropriate "actions". For example, an orchestrator may support the 639 capability of translating posture collection instructions using the 640 Open Vulnerability and Assessment Language (OVAL) and providing those 641 instructions to OVAL collectors. An orchestrator may support the 642 capability of initiating policy evaluation. Where the Manager is 643 configured to ask a particular set of questions, those questions are 644 delegated to Orchestrators, who are then capable of asking those 645 questions using specific dialects. 647 4.1.3. Repositories 649 Figure 2 only includes a single reference to "Repository(-ies)", but 650 in practice, a number of separate data repositories may exist, 651 including posture attribute repositories, policy repositories, local 652 vulnerability definition data repositories, and state assessment 653 results repositories. The diagrammed notion of a repository within 654 the SACM context represents an interface in which payloads are 655 provided (based on the capabilities of the producer), normalized, and 656 persisted. 658 These data repositories may exist separately or together in a single 659 representation, and the design of these repositories may be as 660 distinct as their intended purpose, such as the use of relational 661 database management systems (RDBMS), filesystem-based storage, or 662 graph/map implementations. Each implementation of a SACM repository 663 should focus on the relationships between data elements and implement 664 the SACM information and data model(s). 666 4.1.4. Integration Service 668 If each SACM component represents a set of capabilities, then the 669 Integration Service represents the "fabric" by which SACM components 670 are woven together. The Integration Service acts as a message 671 broker, combining a set of common message categories and 672 infrastructure to allow SACM components to communicate using a shared 673 set of interfaces. The Integration Service's brokering capabilities 674 enable the exchange of various information payloads, orchestration of 675 component capabilities, message routing and reliable delivery. The 676 Integration Service minimizes the dependencies from one system to 677 another through the loose coupling of applications through messaging. 678 SACM components will "attach" to the Integration Service either 679 through native support for the integration implementation, or through 680 the use of "adapters" which provide a proxied attachment. 682 The Integration Service should provide mechanisms for both 683 synchronous and asynchronous request/response-style messaging, and a 684 publish/subscribe mechanism to implement an event-based architecture. 685 It is the responsibility of the Integration Service to coordinate and 686 manage the sending and receiving of messages. The Integration 687 Service should allow components to directly connect and produce or 688 consume messages, or connect via message translators which can act as 689 a proxy, transforming messages from a component format to one 690 implementing a SACM data model. 692 The Integration Service MUST provide routing capabilities for 693 payloads between producers and consumers. The Integration Service 694 MAY provide further capabilities within the payload delivery 695 pipeline. Examples of these capabilities include, but are not 696 limited to, intermediate processing, message transformation, type 697 conversion, validation, or other enterprise integration patterns. 699 4.2. Downstream Uses 701 As depicted by Figure 2, a number of downstream uses exist in the 702 cooperative ecosystem. Each notional SACM component represents 703 distinct sub-architectures which will exchange information via the 704 integration services, using interactions described in this draft. 706 4.2.1. Reporting 708 The Reporting component represents capabilities outside of the SACM 709 architecture scope dealing with the query and retrieval of collected 710 posture attribute information, evaluation results, etc. in various 711 display formats that are useful to a wide range of stakeholders. 713 4.2.2. Analytics 715 The Analytics component represents capabilities outside of the SACM 716 architecture scope dealing with the discovery, interpretation, and 717 communication of any meaningful patterns of data in order to inform 718 effective decision making within the organization. 720 4.3. Sub-Architectures 722 Figure 2 shows two components representing sub-architectural roles 723 involved in a cooperative ecosystem of SACM components for the 724 purpose of posture assessment: Collection and Evaluation. 726 4.3.1. Collection Sub-Architecture 728 The Collection sub-architecture is, in a SACM context, the mechanism 729 by which posture attributes are collected from applicable endpoints 730 and persisted to a repository, such as a configuration management 731 database (CMDB). Control plane functions initiated by the Manager 732 will coordinate the necessary orchestration components, who will 733 choreograph endpoint data collection via defined interactions, using 734 the Integration Service as a message broker. Instructions to perform 735 endpoint data collection are directed to a Posture Collection Service 736 capable of performing collection activities utilizing any number of 737 protocols, such as SNMP, NETCONF/RESTCONF, SCAP, SSH, WinRM, packet 738 capture, or host-based. Instructions are orchestrated with the 739 appropriate Posture Collection Services using serializations 740 supported according to the collector's capabilities. 742 +----------------------------------------------------------+ 743 | Manager | 744 +-----------+----------------------------------------------+ 745 | 746 Orchestrate 747 Collection 748 | 749 +-----------v-------------+ +------------------------------+ 750 | Orchestrator(s) | | Posture Attribute Repository | 751 +-----------+-------------+ +--------------^---------------+ 752 | | 753 Perform | 754 Collection Collected Data 755 | ^ 756 | | 757 +-----------v------------------------------+---------------+ 758 | Integration Service | 759 +----+------------------^------------------------------^---+ 760 | | | | 761 v + v | 762 Perform Collected Perform Collected 763 Collection Data Collection Data 764 | ^ | ^ 765 | | | | 766 +----v-----------------------+ +------------------------------+ 767 | Posture Collection Service | | | Endpoint | | 768 +---^------------------------+ | +--v------------------+----+ | 769 | | | |Posture Collection Service| | 770 | | | +--------------------------+ | 771 Events Queries +------------------------------+ 772 ^ | (PCS resides on Endpoint) 773 | | 774 +---+-------------------v----+ 775 | Endpoint | 776 +----------------------------+ 777 (PCS does not reside on Endpoint) 779 Figure 3: Decomposed Collection Sub-Architecture 781 4.3.1.1. Posture Collection Service 783 The Posture Collection Service (PCS) is a SACM component responsible 784 for the collection of posture attributes from an endpoint or set of 785 endpoints. A single PCS MAY be responsible for management of posture 786 attribute collection from many endpoints. The PCS will interact with 787 the Integration Service to receive collection instructions, and to 788 provide collected posture attributes for persistence to one or more 789 Posture Attribute Repositories. Collection instructions may be 790 supplied in a variety of forms, including subscription to a publish/ 791 subscribe topic to which the Integration Service has published 792 instructions, or via request/response-style messaging (either 793 synchronous or asynchronous). 795 Four classifications of posture collections MAY be supported. 797 4.3.1.1.1. Ad-Hoc 799 Ad-Hoc collection is defined as a single colletion of posture 800 attributes, collected at a particular time. An example of ad-hoc 801 collection is the single collection of a specific registry key. 803 4.3.1.1.2. Continuous/Scheduled 805 Continuous/Scheduled collection is defined as the ongoing, periodic 806 collection of posture attributes. An example of scheduled collection 807 is the collection of a specific registry key value every day at a 808 given time. 810 4.3.1.1.3. Observational 812 This classification of collection is triggered by the observation, 813 external to an endpoint, of information asserting posture attribute 814 values for that endpoint. An example of observational collection is 815 examination of netflow data for particular packet captures and/or 816 specific information within those captures. 818 4.3.1.1.4. Event-based 820 Event-based collection may be triggered either internally or 821 externally to the endpoint. Internal event-based collection is 822 triggered when a posture attribute of interest is added, removed, or 823 modified on an endpoint. This modification indicates a change in the 824 current state of the endpoint, potentially affecting its adherence to 825 some defined policy. Modification of the endpoint's minimum password 826 length is an example of an attribute change which could trigger 827 collection. 829 External event-based collection can be described as a collector being 830 subscribed to an external source of information, receiving events 831 from that external source on a periodic or continuous basis. An 832 example of event-based collection is subscription to YANG Push 833 notifications. 835 4.3.1.2. Endpoint 837 Building upon [I-D.ietf-sacm-terminology], the SACM Collection Sub- 838 Architecture augments the definition of an Endpoint as a component 839 within an organization's management domain from which a Posture 840 Collection Service will collect relevant posture attributes. 842 4.3.1.3. Posture Attribute Repository 844 The Posture Attribute Repository is a SACM component responsible for 845 the persistent storage of posture attributes collected via 846 interactions between the Posture Collection Service and Endpoints. 848 4.3.1.4. Posture Collection Workflow 850 Posture collection may be triggered from a number of components, but 851 commonly begin either via event-based triggering on an endpoint or 852 through manual orchestration, both illustrated in Figure 3 above. 853 Once orchestration has provided the directive to perform collection, 854 posture collection services consume the directives. Posture 855 collection is invoked for those endpoints overseen by the respective 856 posture collection services. Collected data is then provided to the 857 Integration Service, with a directive to store that information in an 858 appropriate repository. 860 4.3.2. Evaluation Sub-Architecture 862 The Evaluation Sub-Architecture, in the SACM context, is the 863 mechanism by which policy, expressed in the form of expected state, 864 is compared with collected posture attributes to yield an evaluation 865 result, that result being contextually dependent on the policy being 866 evaluated. 868 +------------------+ 869 | Manager | 870 +-------+----------+ 871 | 872 Orchestrate +------------------+ 873 Evaluation | Collection | +-------------------------------+ 874 | | Sub+Architecture | | Evaluation Results Repository | 875 +------v----------+ +--------^---------+ +-----------------^-------------+ 876 | Orchestrator(s) | | | 877 +------+----------+ (Potentially) | 878 | Perform Store Evaluation Results 879 Perform Collection | 880 Evaluation | | 881 | | | 882 +------v----------------------v--------------------------------+-------------+ 883 | Integration Service | 884 +--------^----------------------^-----------------------^--------------------+ 885 | | | 886 | | | 887 | Retrieve Posture Perform 888 Retrieve Policy Attributes Evaluation 889 | | | 890 | | | 891 +------v-----+ +-----v------+ +--------v-------------------+ 892 | Policy | | Posture | | Posture Evaluation Service | 893 | Repository | | Attribute | +----------------------------+ 894 +------------+ | Repository | 895 +------------+ 897 Figure 4: Decomposed Evaluation Sub-Architecture 899 4.3.2.1. Posture Evaluation Service 901 The Posture Evaluation Service (PES) represents the SACM component 902 responsible for coordinating the policy to be evaluated and the 903 collected posture attributes relevant to that policy, as well as the 904 comparison engine responsible for correctly determining compliance 905 with the expected state. 907 4.3.2.2. Policy Repository 909 The Policy Repository represents a persistent storage mechanism for 910 the policy to be assessed against collected posture attributes to 911 determine if an endpoint meets the desired expected state. Examples 912 of information contained in a Policy Repository would be 913 Vulnerability Definition Data or configuration recommendations as 914 part of a CIS Benchmark or DISA STIG. 916 4.3.2.3. Evaluation Results Repository 918 The Evaluation Results Repository persists the information 919 representing the results of a particular posture assessment, 920 indicating those posture attributes collected from various endpoints 921 which either meet or do not meet the expected state defined by the 922 assessed policy. Consideration should be made for the context of 923 individual results. For example, meeting the expected state for a 924 configuration attribute indicates a correct configuration of the 925 endpoint, whereas meeting an expected state for a vulnerable software 926 version indicates an incorrect configuration. 928 4.3.2.4. Posture Evaluation Workflow 930 Posture evaluation is orchestrated through the Integration Service to 931 the appropriate Posture Evaluation Service (PES). The PES will, 932 using interactions defined by the applicable taxonomy, query both the 933 Posture Attribute Repository and the Policy Repository to obtain 934 relevant state data for comparison. If necessary, the PES may be 935 required to invoke further posture collection. Once all relevant 936 posture information has been collected, it is compared to expected 937 state based on applicable policy. Comparison results are then 938 persisted to an evaluation results repository for further downstream 939 use and analysis. 941 5. Ecosystem Interactions 943 Ecosystem interactions describe the various functions between SACM 944 components, including manager requirements, the onboarding of 945 components, capability advertisement, administrative actions, and 946 status updates, among others. The Manager component acts as the 947 administrative "lead" for the SACM ecosystem, and must maintain 948 records of registered components, manage capabilities, and more. 950 5.1. Manager 952 The Manager, being a specialized role in the architecture, enables 953 the onboarding and capability management of the various SACM 954 component roles. The Manager must support the set of capabilities 955 needed to operate the SACM ecosystem. 957 With this in mind, the Manager must first authenticate to the 958 Integration Service. Once authentication has succeeded, the Manager 959 MUST establish a service handler capable of performing SACM component 960 registration/onboarding activities (Component Registration 961 Operation). The Manager MUST also establish a subscription to an 962 ecosystem-wide status notification mechanism, in order to receive 963 published status updates from other SACM components. 965 The following requirements exist for the Manager to establish service 966 handlers supporting the component registration taxonomy (Component 967 Registration Operation): 969 * The Manager MUST enable the capability to receive onboarding 970 requests, 972 * The Manager MUST have the capability to generate, manage, and 973 persist unique identifiers for all registered components, 975 * The Manager MUST maintain the relationships between capabilities 976 and payload categorizations (such as topic names or specific 977 payload identifiers), 979 * The Manager MUST have the capability to inventory and manage its 980 "roster" (the list of registered components), 982 * The Manager MUST have the capability to manage its roster's 983 advertised capabilities, including those endpoints to which those 984 capabilities apply. 986 * In addition to supporting component registration, the Manager is 987 responsible for many of the operational functions of the 988 architecture, including initiating collection or evaluation, 989 queries for repository data, or the assembly of information for 990 downstream use. 992 * The Manager MUST support making directed requests to registered 993 components over the component's administrative interface. 994 Administrative interface functions are described by their 995 taxonomy, below. 997 * The Manager MUST support each of the interaction categories as 998 described above. 1000 5.2. Component Registration 1002 Component registration describes how an individual component becomes 1003 part of the SACM ecosystem; authenticating to the Integration 1004 Service, registering and establishing its administrative interface 1005 with, the Manager. 1007 The component onboarding workflow involves multiple steps: 1009 * The component first authenticates to the Integration Service. 1011 * The component initiates registration with the Manager, per the 1012 component registration operation (Component Registration 1013 Operation). 1015 * The component handles the response from the Manager to configure a 1016 service handler allowing the component to receive directed 1017 messages over the administrative interface with the Manager. 1019 5.3. Administrative Interface 1021 The administrative interface represents a direct communication 1022 channel between the Manager and any registered Component. This 1023 interface allows the Manager to make directed requests to a component 1024 in order to perform specific actions. 1026 5.3.1. Capability Advertisement Handshake 1028 Capability Advertisement is the mechanism by which components 1029 initially indicate their capabilities to the Manager. This handshake 1030 is completed using the administrative interface with the Manager. It 1031 becomes the Manager's responsibility to persist component/capability 1032 relationships, and to provide the component the information necessary 1033 to receive and process message payloads specific to the supported 1034 capabilities. 1036 5.3.2. Health Check 1038 The administrative "health check" is a mechanism by which the Manager 1039 queries for the "liveness" of its roster of components, and to 1040 possibly alert users or other systems when components are no longer 1041 present. The Manager MAY enable a periodic message to each component 1042 to determine if that component is still listening to the 1043 Administrative Interface. The Health Check interaction MAY include a 1044 request for "Capability Refresh", to reinitiate the Capability 1045 Advertisement Handshake. This interaction is similar to the 1046 "Heartbeat" interaction, but is initiated by the Manager. 1048 5.3.3. Heartbeat 1050 The administrative "heartbeat" is a mechanism by which a Component 1051 indicates to the Manager that the Component remains connected to the 1052 ecosystem. The Heartbeat differs from the Health Check interaction 1053 in that the Component initiates the interaction, and that no response 1054 from the Manager is required. 1056 5.3.4. Capability-specific Requests 1058 Any number of capability-specific requests can be enabled through the 1059 administrative interface that allow the Manager to direct actions to 1060 be performed by a specific component. Utilizing the interface from a 1061 component to the Manager, this interface can be used to indicate a 1062 component has come back online, or to provide an updated capability 1063 advertisement, potentially resulting in updates to subscriptions or 1064 service handlers. 1066 5.4. Status Notifications 1068 A generic status notifications mechanism SHOULD be configured to 1069 which (a) the Manager is subscribed, and (b) all onboarded components 1070 can publish. Status notifications may be used by the Manager to 1071 update user interfaces, to provide notification of the start, finish, 1072 success or failure of ecosystem operations, or as events to trigger 1073 subsequent activities. 1075 5.5. Component Interactions 1077 Component interactions describe functionality between components 1078 relating to collection, evaluation, or other downstream processes. 1079 The following component interactions begin with the Manager providing 1080 a set of instructions to an Orchestrator or set of Orchestrators that 1081 have registered with the SACM ecosystem indicating the appropriate 1082 capabilities, such as collection or evaluation. Subscribing 1083 Orchestrator(s) MAY translate, manipulate, filter, augment, or 1084 otherwise transform the Manager's instructions into content supported 1085 through the Orchestrator's capabilities. 1087 5.5.1. Initiate Ad-Hoc Collection 1089 The Orchestrator supplies a payload of collection instructions to a 1090 Posture Collection Service either through direct or broadcast 1091 mechanisms. The receiving PCS components perform the required 1092 collection based on their capabilities. Each PCS then forms a 1093 payload of collected posture attributes (including endpoint 1094 identifying information) and provides that payload to the Posture 1095 Attribute Repository interface, for persistence. 1097 5.5.2. Coordinate Periodic Collection 1099 Similar to ad-hoc collection, the Orchestrator supplies a payload of 1100 collection instructions similar to those of ad-hoc collection. 1101 Additional information elements containing collection identification 1102 and periodicity are included. 1104 5.5.2.1. Schedule Periodic Collection 1106 To enable operations on periodic collection, the scheduling payload 1107 MUST include both a unique identifier for the set of collection 1108 instructions, as well as a periodicity expression to enable the 1109 collection schedule. An optional "immediate collection" flag will 1110 indicate to the collection component that, upon receipt of the 1111 collection instructions, a collection will automatically be initiated 1112 prior to engagement of the scheduled collection. 1114 5.5.2.2. Cancel Periodic Collection 1116 The Orchestrator disables the periodic collection of posture 1117 attributes by supplying collector(s) the unique identifier of 1118 previously scheduled collection instructions. An optional "final 1119 collection" flag will indicate to the collection component that, upon 1120 receipt of the cancellation instructions, a final ad-hoc collection 1121 is to take place. 1123 5.5.3. Coordinate Observational/Event-based Collection 1125 In these scenarios, the Posture Collection Service acts as the 1126 "observer". Interactions with the observer could specify a time 1127 period of observation and potentially information intended to filter 1128 observed posture attributes to aid the PCS in determining those 1129 attributes that are applicable for collection and persistence to the 1130 Posture Attribute Repository. 1132 5.5.3.1. Initiate Observational/Event-based Collection 1134 The Orchestrator supplies a payload of instructions to a topic or set 1135 of topics to which Posture Collection Services (observers) are 1136 subscribed. This payload could include specific instructions based 1137 on the observer's capabilities to determine specific posture 1138 attributes to observe and collect. 1140 5.5.3.2. Cancel Observational/Event-based Collection 1142 The Orchestrator supplies a payload of instructions to a topic or set 1143 of topics to which Posture Collection Services are subscribed. The 1144 receiving PCS components cancel the identified observational/event- 1145 based collection executing on those PCS components. 1147 5.5.4. Persist Collected Posture Attributes 1149 Following successful collection, Posture Collection Services (PCS) 1150 will supply the payload of collected posture attributes to the 1151 interface(s) supporting the persistent storage of those attributes to 1152 the Posture Attribute Repository. Information in this payload should 1153 include identifying information of the computing resource(s) for 1154 which attributes were collected. 1156 5.5.5. Initiate Ad-Hoc Evaluation 1158 The Orchestrator supplies a payload of evaluation instructions to a 1159 Posture Evaluation Services (PES) either through direct or broadcast 1160 mechanisms. The receiving PES components perform the required 1161 evaluation based on their capabilities. The PES generates a payload 1162 of posture evaluation results and publishes that payload to the 1163 Evaluation Results Repository interface, for persistence. 1165 5.5.6. Coordinate Periodic Evaluation 1167 Similar to ad-hoc evaluation, the Orchestrator supplies a payload of 1168 evaluation instructions similar to those of ad-hoc evaluation. 1169 Additional information elements containing evaluation identification 1170 and periodicity are included. 1172 5.5.6.1. Schedule Periodic Evaluation 1174 To enable operations on periodic evaluation, the scheduling payload 1175 MUST include both a unique identifier for the set of evaluation 1176 instructions, as well as a periodicity expression to enable the 1177 evaluation schedule. An optional "immediate evaluation" flag will 1178 indicate to the Posture Evaluation Service (PES) that, upon receipt 1179 of the evaluation instructions, an evaluation will automatically be 1180 initiated prior to engagement of the scheduled evaluation. 1182 5.5.6.2. Cancel Periodic Evaluation 1184 The Orchestrator disables the periodic evaluation of posture 1185 attributes by supplying Posture Evaluation Service(s) the unique 1186 identifier of previously scheduled evaluation instructions. An 1187 optional "final evaluation" flag will indicate to the PES that, upon 1188 receipt of the cancellation instructions, a final ad-hoc evaluation 1189 is to take place. 1191 5.5.7. Coordinate Change-based Evaluation 1193 A more fine-grained approach to periodic evaluation may be enabled 1194 through the triggering of Posture Evaluation based on changes to 1195 posture attribute values at the time of their collection and 1196 persistence to the Posture Attribute Repository. 1198 5.5.7.1. Identify Attributes 1200 The Orchestrator enables change-based evaluation through a payload 1201 published to Posture Attribute Repository component(s). This payload 1202 includes appropriate information elements describing the posture 1203 attributes on which changes in value will trigger posture evaluation. 1205 5.5.7.2. Cancel Change-based Evaluation 1207 An Orchestrator may disable change-based evaluation through a payload 1208 published to Posture Attribute Repository component(s), including 1209 those information elements necessary to identify those posture 1210 attributes for which change-based evaluation no longer applies. 1212 5.5.8. Queries 1214 Queries should allow for a "freshness" time period, allowing the 1215 requesting entity to determine if/when posture attributes must be re- 1216 collected prior to performing evaluation. This freshness time period 1217 can be "zeroed out" for the purpose of automatically triggering re- 1218 collection regardless of the most recent collection. 1220 6. Operations 1222 The following sections describe a number of operations required to 1223 enable a cooperative ecosystem of posture attribute collection and 1224 evaluation functions. 1226 6.1. Component Registration 1228 Component registration describes how an individual component becomes 1229 part of the SACM ecosystem; registering with the Manager, and 1230 establishing the administrative interface. 1232 * Interaction Type: Directed (Request/Response) 1234 * Source Component: Any component wishing to join the ecosystem, 1235 such as Posture Collection Services, Repository Interfaces, 1236 Posture Evaluation Services and more. 1238 * Target Component(s): Manager 1240 6.1.1. Request Payload 1242 When a component onboards with the ecosystem, it must identify itself 1243 to the Manager, using either descriptive information or an already- 1244 existing component unique identifier. 1246 component-registration-request: 1247 {:component-identification:} 1249 component-identification: 1250 component-unique-identifier (if re-establishing communication) 1251 #-OR-# 1252 component-type {:component-type:} 1253 component-name 1254 component-description (optional) 1256 component-type: 1257 enumeration: 1258 - posture-collection-service 1259 - posture-evaluation-service 1260 - repository-interface 1261 - orchestrator 1262 - others? 1264 When registering for the first time, the component will send 1265 identifying information including the component type and a name. If 1266 the component is re-establishing communications, for example after a 1267 restart of the component or deployment of a new version, the 1268 component only needs to supply its previously generated (and 1269 persisted) [component-unique-identifier]. 1271 6.1.2. Request Processing 1273 When the Manager receives the component's request for onboarding, it 1274 will: 1276 * Generate a unique identifier, "[component-unique-identifier]", for 1277 the onboarding component, 1279 * Persist identifying information, including the "[component-unique- 1280 identifier]" to its component inventory, enabling an up-to-date 1281 roster of components being managed, 1283 * Establish the administrative interface to the onboarded component 1284 by enabling a service handler to listen for directed messages from 1285 the component. 1287 6.1.3. Response Payload 1289 The Manager will respond to the component with a payload including 1290 the component's unique identifier. At this point, the Manager is 1291 aware of the component's existence in the ecosystem, and the 1292 component can self-identify by virtue of receiving its unique 1293 identifier. 1295 component-registration-response: 1296 component-unique-identifier: [component-unique-identifier] 1298 6.1.4. Response Processing 1300 Successful receipt of the Manager's response, including the 1301 "[component-unique-identifier]", indicates the component is onboarded 1302 to the ecosystem. Using the response payload, the component can then 1303 establish it's end of the administrative interface with the Manager. 1304 The component must then persist it's unique identifier for use when 1305 re-establishing communication with the Manager after failure recovery 1306 or restart. 1308 6.2. Administrative Interface 1310 A number of functions may take place which, instead of being 1311 published to multiple subscribers, may require direct interaction 1312 between the Manager and a registered component (and vice-versa). 1313 During component onboarding, this direct channel, known as the 1314 Administrative Interface, is established first by the Manager and 1315 subsequently complemented by the component onboarding the SACM 1316 ecosystem. Three operations are defined for the administrative 1317 interface, but any number of application or capability-specific 1318 operations MAY be enabled using the directed messaging provided by 1319 this interface. 1321 6.2.1. Capability Advertisement Handshake 1323 Capability advertisement represents the ability of any registered 1324 component to inform the Manager of that component's capacity for 1325 performing certain operations. For example, a Posture Collection 1326 Service component may advertise its capability to perform collection 1327 using a particular collection system/serialization. This capability 1328 advertisement is important for the Manager to persist in order for 1329 the Manager to correctly classify components registered within the 1330 SACM ecosystem, and therefore provide the ability to publish messages 1331 to components in accordance with their capabilities. 1333 * Interaction Type: Directed (Request/Response) 1334 * Source Component: Any registered component, such as Posture 1335 Collection Services, Repository Interfaces, Posture Evaluation 1336 Services and more. 1338 * Target Component(s): Manager 1340 6.2.1.1. Request Payload 1342 The component's capability advertisement request payload will include 1343 a list of "Capability URNs" (TBD IANA SECTION) that represent it's 1344 supported operational capabilities. 1346 capability-advertisement: 1347 capabilities: 1348 capability-urn: [urn] 1349 capability-urn: [urn] 1350 capability-urn: [urn] 1351 ... 1353 6.2.1.2. Request Processing 1355 Upon receipt of the component's capability advertisement, the Manager 1356 SHOULD: 1358 * Persist the component's capabilities to the Manager's inventory 1360 * Coordinate, based on the supplied capabilities, the service 1361 handlers (for directed messages) and/or event listeners (for 1362 broadcast messages) to which the component should support. 1364 6.2.1.3. Response Payload 1366 The response payload delivered to the component should include the 1367 appropriate service handling/event listening information required for 1368 the component to handle further interactions based on each advertised 1369 capability. If a capability was not registered successfully, 1370 appropriate error messages SHOULD be supplied to inform the component 1371 of the failure(s). 1373 capability-advertisement-response: 1374 capabilities: 1375 capability: 1376 capability-urn: [urn] 1377 registration-status: (success | failure) 1378 service-handler-or-event-listener: [info] 1379 messages: [messages] 1380 capability: 1381 capability-urn: [urn] 1382 registration-status: (success | failure) 1383 service-handler-or-event-listener: [info] 1384 messages: [messages] 1386 6.2.1.4. Response Processing 1388 Once the component has received the response to its capability 1389 advertisement, it should configure the capability-specific service 1390 handler(s) or event listener(s). Once these handlers/listeners have 1391 been configured, the component is considered fully onboarded to the 1392 SACM ecosystem. 1394 6.2.2. Health Check 1396 As time passes, it is important that the Manager maintains knowledge 1397 of all registered component's current operational status. The health 1398 check operation describes the efforts taken by the Manager to 1399 maintain the most up-to-date inventory of it's component roster, and 1400 to potentially trigger events to users or outside systems (e.g. a 1401 SIEM or SOAR) indicating unavailable components. 1403 * Interaction Type: Directed (Request/Response) 1405 * Source Component: Manager 1407 * Target Component(s): Any registered component, such as Posture 1408 Collection Services, Repository Interfaces, Posture Evaluation 1409 Services and more. 1411 6.2.2.1. Request Payload 1413 The request for the health check is a simple "ping". 1415 health-check-request: 1416 action: ping 1418 6.2.2.2. Request Processing 1420 When the target component receives the health check request, the 1421 target component need only respond that it is operational and 1422 connected to the integration service. This is a simple "Hello 1423 component, are you listening? Yes, I am" interaction. The health 1424 check request from the Manager should be made with an appropriately 1425 small timeout indicator; only an operational component will be able 1426 to respond to the request, so if that component is offline and cannot 1427 respond, the Manager should not be kept waiting for an extended 1428 amount of time. 1430 6.2.2.3. Response Payload 1432 When responding to the health check request, the response payload 1433 will simply indicate success: ~~~~~~ health-check-response: response: 1434 success ~~~~~~ 1436 6.2.2.4. Response Processing 1438 Upon receipt of the "health-check-response" payload, the Manager will 1439 update its inventory of currently operational components with the 1440 timestamp of the receipt. Manager implementations may raise alerts, 1441 inform users, or take other actions when health checks are 1442 unsuccessful, at their discretion. 1444 6.2.3. Heartbeat 1446 As time passes and SACM ecosystem components which have previously 1447 registered are brought offline (perhaps for maintenance or 1448 redeployment) and back online, it is important that registered 1449 components maintain administrative contact with the Manager. The 1450 heartbeat operation describes the efforts taken by a registered 1451 component to determine the status of contact with the Manager, and to 1452 take appropriate action if such contact cannot be made. 1454 * Interaction Type: Directed (Request/Response) 1456 * Source Component: Any registered component, such as Posture 1457 Collection Services, Repository Interfaces, Posture Evaluation 1458 Services and more. 1460 * Target Component(s): Manager 1462 6.2.3.1. Request Payload 1464 The request payload simply defines the hearbeat action: 1466 heartbeat-request: 1467 action: pulse 1469 6.2.3.2. Request Processing 1471 When the Manager receives the heartbeat request, it need only respond 1472 that it is operational and connected to the integration service. 1473 This is a simple "Hello Manager, are you listening? Yes, I am" 1474 interaction. The heartbeat request from the component should be made 1475 with an appropriately small timeout indicator; only an operational 1476 Manager will be able to respond to the request, so if it is offline 1477 and cannot respond, the component should not be kept waiting for an 1478 extended amount of time. 1480 6.2.3.3. Response Payload 1482 When responding to the heartbeat request, the response payload will 1483 simply indicate success: ~~~~~~ heartbeat-response: response: success 1484 ~~~~~~ 1486 6.2.3.4. Response Processing 1488 Upon receipt of the "heartbeat-response" payload, the component may 1489 reset its heartbeat timer and continue normal operations, awaiting 1490 incoming message payloads. Component implementations may raise 1491 alerts, inform users, or take other actions when heartbeat requests 1492 are unsuccessful (potentially indicating a downed Manager), at their 1493 discretion. 1495 6.3. Status Notification 1497 From time to time during the performance of any given operation, a 1498 component may need to supply status information to the Manager (or 1499 any other concerned component), for use in display to users, or to 1500 trigger other events within the SACM ecosystem. The status 1501 notification operation is designed to allow any component to 1502 broadcast status message payloads to any subscribers with the need to 1503 know. For example, a collection component could broadcast to the 1504 Manager that it has initiated collection, subsequent collection 1505 progress updates, and finally completion or error conditions. 1507 * Interaction Type: Broadcast (Publish/Subscribe) 1509 * Source Component: Any registered component, such as Posture 1510 Collection Services, Repository Interfaces, Posture Evaluation 1511 Services and more. 1513 * Target Component(s): Typically the Manager, but any registered 1514 component may subscribe to status notifications. 1516 6.3.1. Request Payload 1518 At a minimum, the payload broadcast for a status notification MUST 1519 include the status message and the publishing component's "component- 1520 unique-identifier". Further identifying information, such as status 1521 codes, operation indicators, etc., MAY be provided by implementing 1522 components. 1524 status-notification: 1525 publisher: [component-unique-identifier] 1526 message: [message] 1527 [additional information] 1529 6.3.2. Request Processing 1531 When subscribers are notified of the status message, respective 1532 components may act upon them in component/application-specific ways, 1533 including persisting those messages to repositories, forwarding to 1534 log aggregation tools, displaying on user interfaces, and so on. 1535 Potential for use of component status notifications is only limited 1536 by application implementations. 1538 6.3.3. Response Payload 1540 N/A 1542 6.3.4. Response Processing 1544 N/A 1546 6.4. Initiate Ad-Hoc Collection 1548 The Ad-hoc collection workflow MAY be initiated by the Manager, via 1549 user interaction, or through a Posture Evaluation Service, and 1550 represents a single, point-in-time operation to collect posture 1551 attributes from applicable endpoints. The SACM Producer initiates a 1552 message payload, either through directed channels (such as the 1553 administrative interface) or through broadcast notifications to 1554 multiple subscribers, to Orchestrator components. Orchestrators MAY 1555 manipulate the Manager's collection instructions according to various 1556 collection capabilities, prior to providing those instructions to 1557 Posture Collection Service (PCS) components. Once collection 1558 instructions are received by the PCS, it will collect the requested 1559 posture attributes from the designated endpoints, using its 1560 advertised collection capabilities. The following diagram 1561 illustrates this workflow with the Manager as the initiating SACM 1562 Producer: 1564 +-----------+ +------------------------------+ 1565 | Manager | | Posture Collection Service | 1566 +-+-----^---+ +---^----------+----------+----+ 1567 | | | | | 1568 1.| (S) 4.| (S) 5.| 1569 | | | | | 1570 | | | | | 1571 +-v-----+-----------------------------------------v----------v----+ 1572 | Integration Service | 1573 +-+-----^------^----------------------------------^----------+----+ 1574 | | | | | 1575 2.| (S) |3. (S) |6. 1576 | | | | | 1577 | | | | | 1578 +-v-----+------+-+ +----------------+----------v----+ 1579 | Orchestrator | | Posture Attribute Repository | 1580 +----------------+ +--------------------------------+ 1582 1. The Manager initiates a request to one or more Orchestrators to 1583 perform collection, 1585 2. The Orchestrator receives collection instructions and potentially 1586 manipulates them according to one or more collection 1587 capabilities, 1589 3. The Orchestrator publishes a notification to subscribed Posture 1590 Collection Service components, indicating the posture attributes 1591 to be collected, 1593 4. The Posture Collection Service receives the collection 1594 instructions and performs the actual collection of posture 1595 attributes from an endpoint or endpoints. 1597 5. The Posture Collection Service publishes a notification(s) 1598 containing the collected posture attributes to be persisted to 1599 the Posture Attribute Repository, 1601 6. The Posture Attribute Repository persists the collected posture 1602 attributes, potentially performing normalization of the data as 1603 part of its process. 1605 Interactions labeled (S) indicate the capability of each component to 1606 publish status notifications, subscribed to by the Manager. 1608 6.4.1. SACM Producer to Orchestrator 1610 The Ad-hoc collection workflow MAY be initiated by a number of SACM 1611 components, such as the Manager, a Posture Evaluation Service, or 1612 other events outside the scope of this document. 1614 * Interaction Type: Directed (Request/Response) or Broadcast 1615 (Publish/Subscribe) 1617 * Source Component: Various 1619 * Target Component(s): Orchestrator 1621 6.4.1.1. Request Payload 1623 A request to orchestrate posture attribute collection MUST include 1624 enough information to describe those attributes being collected, and 1625 MAY include endpoint targeting information. 1627 collection-instructions: 1628 TBD 1630 6.4.1.2. Request Processing 1632 When the Orchestrator receives the collection instructions, it may be 1633 required to manipulate them according to the capabilities it's 1634 collector(s) support. For example, generic collection instructions 1635 could be transformed to the appropriate OVAL serialization for 1636 collection via OVAL-compliant collectors. 1638 6.4.1.3. Response Payload 1640 Orchestrators have the option to provide broadcast status update 1641 messages to indicate success, failure, or other error messages when 1642 receiving posture collection orchestration payloads. 1644 6.4.1.4. Response Processing 1646 N/A 1648 6.4.2. Orchestrator to Posture Collection Service 1650 Once the Orchestrator has received collection instructions from the 1651 initiating SACM component, and has performed any manipulation of the 1652 instructions to conform to it's capabilities, it will provide those 1653 instructions to relevant Posture Collection Services. 1655 * Interaction Type: Directed (Request/Response) or Broadcast 1656 (Publish/Subscribe) 1658 * Source Component: Orchestrator 1660 * Target Component(s): Posture Collection Service 1662 6.4.2.1. Request Payload 1664 The payload exchanged between the Orchestrator and it's associated 1665 Posture Collection Services will be collection instructions adhering 1666 to a data model supported by the PCS based on its advertised 1667 capabilities. 1669 collection-instructions: 1670 TBD 1672 6.4.2.2. Request Processing 1674 Upon receipt of the payload containing collection instructions, the 1675 Posture Collection Service should parse and validate them, indicating 1676 any errors in the process. If the payload does not conform to any 1677 serialization or data model to which the PCS' capabilities 1678 correspond, status messages indicating such nonconformance SHOULD be 1679 provided to both the Orchestrator and the initiating SACM producer. 1681 Once successfully parsed and validated, the PCS MUST perform 1682 collection of posture attributes according to the collection 1683 instructions, from any endpoint to which the PCS has access, or from 1684 the list of endpoints described in any targeting information included 1685 in the collection instructions. 1687 6.4.2.3. Response Payload 1689 Posture Collection Service components will respond using the generic 1690 status update mechanisms to indicate success, failure, or any errors 1691 that occur. Errors may occur parsing collection instructions, 1692 verifying them, targeting indicated endpoints, or from the act of 1693 collecting the indicated posture attributes. 1695 6.4.2.4. Response Processing 1697 Any messages received by components regarding the success, failure, 1698 or errors involved in the collection of posture attributes MAY be 1699 processed according to the receiving components' capabilities. 1701 6.4.3. Posture Collection Service to Posture Attribute Repository 1703 Upon completion of posture attribute collection, the PCS constructs 1704 the payload of collected attributes based on its advertised 1705 capabilities, e.g. OVAL system characteristics. This payload is 1706 provided to either a specific posture attribute repository via 1707 directed messages or to subscribed repository interfaces via 1708 broadcast messages. 1710 * Interaction Type: Directed (Request/Response) or Broadcast 1711 (Publish/Subscribe) 1713 * Source Component: Posture Collection Service 1715 * Target Component(s): Posture Attribute Repository 1717 6.4.3.1. Request Payload 1719 The payload supplied by the Posture Collection Service SHOULD conform 1720 to information and data models supported by its advertised 1721 capabilities. These data models, at a minimum, SHOULD include name/ 1722 value pairs for each collected attribute. 1724 collection-results: 1725 [ 1726 attribute-name, 1727 attribute-value 1728 ] 1730 6.4.3.2. Request Processing 1732 As the Posture Attribute Repository interface receives the payload of 1733 collected posture attributes, some data normalization MAY occur in 1734 order to persist the information most efficiently based on the 1735 persistence technology. This normalization is dependent on the 1736 implementation of the repository interface as well as the persistence 1737 technology. For example, OVAL system characteristics, an XML 1738 payload, could be normalized to a property graph representation when 1739 persisted to a Neo4j database. 1741 6.4.3.3. Response Payload 1743 Once the Posture Attribute Repository has received, it MAY respond to 1744 the Posture Collection Service that it has successfully received the 1745 collected posture attributes. This response would only be applicable 1746 when receiving payloads via directed requests. If payloads are 1747 received via broadcast interactions, there may not be a PCS to which 1748 a response can be sent. The Posture Attribute Repository MAY utilize 1749 the generic status update interactions to provide response messages 1750 to appropriate subscribers. 1752 6.4.3.4. Response Processing 1754 Any messages received by components regarding the success, failure, 1755 or errors involved in the persistence of collected posture attributes 1756 MAY be processed according to the receiving components' capabilities. 1757 For example, a generic status update message could be processed by a 1758 Manager component, correlated with the initial posture collection 1759 instructions in order to "close the loop" on the posture attribute 1760 collection workflow. 1762 6.5. Initiate Ad-Hoc Evaluation 1764 ### Manager to Orchestrator ### Orchestrator to Evaluator ### 1765 Evaluator to Posture Evaluation Repository 1767 7. Privacy Considerations 1769 [TBD] 1771 8. Security Considerations 1773 [TBD] 1775 9. IANA Considerations 1777 [TBD] Some boilerplate code... 1779 9.1. Component Types 1781 URI: "urn:ietf:sacm:component-type" Description: The allowed 1782 enumeration of the various component types permitted to utilize the 1783 SACM ecosystem. 1785 * Manager 1787 * Orchestrator 1789 * Collector 1791 * Evaluator 1793 * Repository Interface 1795 * [MORE] 1797 9.2. Component Capabilities 1799 ### Health Check A URN representing a component's capability to 1800 initiate Health Check operations and to process any provided response 1801 payloads. 1803 URN: "urn:ietf:sacm:capability:action:health-check" 1805 9.2.1. Heartbeat 1807 A URN representing a component's capability to initiate Heartbeat 1808 operations and to process any provided response payloads. 1810 URN: "urn:ietf:sacm:capability:action:heartbeat" 1812 9.2.2. Status Notification (Publish) 1814 A URN representing a component's capability to publish status 1815 notifications. 1817 URN: "urn:ietf:sacm:capability:publish:status-notification" 1819 9.2.3. Status Notification (Subscribe) 1821 A URN representing a component's capability to subscribe to status 1822 notification events. 1824 URN: "urn:ietf:sacm:capability:subscribe:status-notification" 1826 10. References 1828 10.1. Normative References 1830 [I-D.ietf-sacm-ecp] 1831 Haynes, D., Fitzgerald-McKay, J., and L. Lorenzin, 1832 "Endpoint Posture Collection Profile", Work in Progress, 1833 Internet-Draft, draft-ietf-sacm-ecp-05, 21 June 2019, 1834 . 1837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1838 Requirement Levels", BCP 14, RFC 2119, 1839 DOI 10.17487/RFC2119, March 1997, 1840 . 1842 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1843 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1844 March 2011, . 1846 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1847 J. Fitzgerald-McKay, "Software Inventory Message and 1848 Attributes (SWIMA) for PA-TNC", RFC 8412, 1849 DOI 10.17487/RFC8412, July 2018, 1850 . 1852 [RFC8600] Cam-Winget, N., Ed., Appala, S., Pope, S., and P. Saint- 1853 Andre, "Using Extensible Messaging and Presence Protocol 1854 (XMPP) for Security Information Exchange", RFC 8600, 1855 DOI 10.17487/RFC8600, June 2019, 1856 . 1858 10.2. Informative References 1860 [CISCONTROLS] 1861 "CIS Controls v7.1", n.d., 1862 . 1864 [draft-birkholz-sacm-yang-content] 1865 Birkholz, H. and N. Cam-Winget, "YANG subscribed 1866 notifications via SACM Statements", n.d., 1867 . 1870 [HACK100] "IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP", 1871 n.d., . 1874 [HACK101] "IETF 101 Hackathon - Configuration Assessment XMPP", 1875 n.d., . 1877 [HACK102] "IETF 102 Hackathon - YANG Collection on Traditional 1878 Endpoints", n.d., 1879 . 1881 [HACK103] "IETF 103 Hackathon - N/A", n.d., 1882 . 1884 [HACK104] "IETF 104 Hackathon - A simple XMPP client", n.d., 1885 . 1887 [HACK105] "IETF 105 Hackathon - A more robust XMPP client including 1888 collection extensions", n.d., 1889 . 1891 [HACK99] "IETF 99 Hackathon - Vulnerability Scenario EPCP", n.d., 1892 . 1895 [I-D.ietf-i2nsf-terminology] 1896 Hares, S., Strassner, J., Lopez, D. R., Xia, L., and H. 1897 Birkholz, "Interface to Network Security Functions (I2NSF) 1898 Terminology", Work in Progress, Internet-Draft, draft- 1899 ietf-i2nsf-terminology-08, 5 July 2019, 1900 . 1903 [I-D.ietf-sacm-terminology] 1904 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 1905 A. Montville, "Security Automation and Continuous 1906 Monitoring (SACM) Terminology", Work in Progress, 1907 Internet-Draft, draft-ietf-sacm-terminology-16, 14 1908 December 2018, . 1911 [MQTT] "MQTT", n.d., . 1913 [NIST800126] 1914 Waltermire, D., Quinn, S., Booth, H., Scarfone, K., and D. 1915 Prisaca, "SP 800-126 Rev. 3 - The Technical Specification 1916 for the Security Content Automation Protocol (SCAP) - SCAP 1917 Version 1.3", February 2018, 1918 . 1921 [NISTIR7694] 1922 Halbardier, A., Waltermire, D., and M. Johnson, "NISTIR 1923 7694 Specification for Asset Reporting Format 1.1", n.d., 1924 . 1927 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1928 Information Models and Data Models", RFC 3444, 1929 DOI 10.17487/RFC3444, January 2003, 1930 . 1932 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1933 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1934 . 1936 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 1937 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 1938 October 2007, . 1940 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1941 Tardo, "Network Endpoint Assessment (NEA): Overview and 1942 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1943 . 1945 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1946 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1947 March 2011, . 1949 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 1950 Posture Assessment: Enterprise Use Cases", RFC 7632, 1951 DOI 10.17487/RFC7632, September 2015, 1952 . 1954 [RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and 1955 Continuous Monitoring (SACM) Requirements", RFC 8248, 1956 DOI 10.17487/RFC8248, September 2017, 1957 . 1959 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 1960 Oriented Lightweight Information Exchange (ROLIE)", 1961 RFC 8322, DOI 10.17487/RFC8322, February 2018, 1962 . 1964 [XMPPEXT] "XMPP Extensions", n.d., . 1966 Appendix A. Security Domain Workflows 1968 This section describes three primary information security domains 1969 from which workflows may be derived: IT Asset Management, 1970 Vulnerability Management, and Configuration Management. 1972 A.1. IT Asset Management 1974 Information Technology asset management is easier said than done. 1975 The [CISCONTROLS] have two controls dealing with IT asset management. 1976 Control 1, Inventory and Control of Hardware Assets, states, 1977 "Actively manage (inventory, track, and correct) all hardware devices 1978 on the network so that only authorized devices are given access, and 1979 unauthorized and unmanaged devices are found and prevented from 1980 gaining access." Control 2, Inventory and Control of Software 1981 Assets, states, "Actively manage (inventory, track, and correct) all 1982 software on the network so that only authorized software is installed 1983 and can execute, and that unauthorized and unmanaged software is 1984 found and prevented from installation or execution." 1985 In spirit, this covers all of the processing entities on your network 1986 (as opposed to things like network cables, dongles, adapters, etc.), 1987 whether physical or virtual, on-premises or in the cloud. 1989 A.1.1. Components, Capabilities and Workflow(s) 1991 TBD 1993 A.1.1.1. Components 1995 TBD 1997 A.1.1.2. Capabilities 1999 An IT asset management capability needs to be able to: 2001 * Identify and catalog new assets by executing Target Endpoint 2002 Discovery Tasks 2004 * Provide information about its managed assets, including uniquely 2005 identifying information (for that enterprise) 2007 * Handle software and/or hardware (including virtual assets) 2009 * Represent cloud hybrid environments 2011 A.1.1.3. Workflow(s) 2013 TBD 2015 A.2. Vulnerability Management 2017 Vulnerability management is a relatively established process. To 2018 paraphrase the [CISCONTROLS], continuous vulnerability management is 2019 the act of continuously acquiring, assessing, and taking subsequent 2020 action on new information in order to identify and remediate 2021 vulnerabilities, therefore minimizing the window of opportunity for 2022 attackers. 2024 A vulnerability assessment (i.e. vulnerability detection) is 2025 performed in two steps: 2027 * Endpoint information collected by the endpoint management 2028 capabilities is examined by the vulnerability management 2029 capabilities through Evaluation Tasks. 2031 * If the data possessed by the endpoint management capabilities is 2032 insufficient, a Collection Task is triggered and the necessary 2033 data is collected from the target endpoint. 2035 Vulnerability detection relies on the examination of different 2036 endpoint information depending on the nature of a specific 2037 vulnerability. Common endpoint information used to detect a 2038 vulnerability includes: 2040 * A specific software version is installed on the endpoint 2042 * File system attributes 2044 * Specific state attributes 2046 In some cases, the endpoint information needed to determine an 2047 endpoint's vulnerability status will have been previously collected 2048 by the endpoint management capabilities and available in a 2049 Repository. However, in other cases, the necessary endpoint 2050 information will not be readily available in a Repository and a 2051 Collection Task will be triggered to perform collection from the 2052 target endpoint. Of course, some implementations of endpoint 2053 management capabilities may prefer to enable operators to perform 2054 this collection even when sufficient information can be provided by 2055 the endpoint management capabilities (e.g. there may be freshness 2056 requirements for information). 2058 A.2.1. Components, Capabilities and Workflow(s) 2060 TBD 2062 A.2.1.1. Components 2064 TBD 2066 A.2.1.2. Capabilities 2068 TBD 2070 A.2.1.3. Workflow(s) 2072 TBD 2074 A.3. Configuration Management 2076 Configuration management involves configuration assessment, which 2077 requires state assessment. The [CISCONTROLS] specify two high-level 2078 controls concerning configuration management (Control 5 for non- 2079 network devices and Control 11 for network devices). As an aside, 2080 these controls are listed separately because many enterprises have 2081 different organizations for managing network infrastructure and 2082 workload endpoints. Merging the two controls results in the 2083 following paraphrasing: Establish, implement, and actively manage 2084 (track, report on, correct) the security configuration of systems 2085 using a rigorous configuration management and change control process 2086 in order to prevent attackers from exploiting vulnerable services and 2087 settings. 2089 Typically, an enterprise will use configuration guidance from a 2090 reputable source, and from time to time they may tailor the guidance 2091 from that source prior to adopting it as part of their enterprise 2092 standard. The enterprise standard is then provided to the 2093 appropriate configuration assessment tools and they assess endpoints 2094 and/or appropriate endpoint information. 2096 A preferred flow follows: 2098 * Reputable source publishes new or updated configuration guidance 2100 * Enterprise configuration assessment capability retrieves 2101 configuration guidance from reputable source 2103 * Optional: Configuration guidance is tailored for enterprise- 2104 specific needs 2106 * Configuration assessment tool queries asset inventory repository 2107 to retrieve a list of affected endpoints 2109 * Configuration assessment tool queries configuration state 2110 repository to evaluate compliance 2112 * If information is stale or unavailable, configuration assessment 2113 tool triggers an ad hoc assessment 2115 The SACM architecture needs to support varying deployment models to 2116 accommodate the current state of the industry, but should strongly 2117 encourage event-driven approaches to monitoring configuration. 2119 A.3.1. Components, Capabilities and Workflow(s) 2121 This section provides more detail about the components and 2122 capabilities required when considering the aforementioned 2123 configuration management workflow. 2125 A.3.1.1. Components 2127 The following is a minimal list of SACM Components required to 2128 implement the aforementioned configuration assessment workflow. 2130 * Configuration Policy Feed: An external source of authoritative 2131 configuration recommendations. 2133 * Configuration Policy Repository: An internal repository of 2134 enterprise standard configurations. 2136 * Configuration Assessment Orchestrator: A component responsible for 2137 orchestrating assessments. 2139 * Posture Attribute Collection Subsystem: A component responsible 2140 for collection of posture attributes from systems. 2142 * Posture Attribute Repository: A component used for storing system 2143 posture attribute values. 2145 * Configuration Assessment Evaluator: A component responsible for 2146 evaluating system posture attribute values against expected 2147 posture attribute values. 2149 * Configuration Assessment Results Repository: A component used for 2150 storing evaluation results. 2152 A.3.1.2. Capabilities 2154 Per [RFC8248], solutions MUST support capability negotiation. 2155 Components implementing specific interfaces and operations (i.e. 2156 interactions) will need a method of describing their capabilities to 2157 other components participating in the ecosystem; for example, "As a 2158 component in the ecosystem, I can assess the configuration of 2159 Windows, MacOS, and AWS using OVAL". 2161 A.3.1.3. Configuration Assessment Workflow 2163 This section describes the components and interactions in a basic 2164 configuration assessment workflow. For simplicity, error conditions 2165 are recognized as being necessary and are not depicted. When one 2166 component messages another component, the message is expected to be 2167 handled appropriately unless there is an error condition, or other 2168 notification, messaged in return. 2170 +-------------+ +----------------+ +------------------+ +------------+ 2171 | Policy Feed | | Orchestrator | | Evaluation | | Evaluation | 2172 +------+------+ +-------+--------+ | Sub-Architecture | | Results | 2173 | | +---^----------+---+ | Repository | 2174 | | | | +------^-----+ 2175 | | | | | 2176 1.| 3.| 8.| 9.| 10.| 2177 | | | | | 2178 | | | | | 2179 +------v-----------------v---------------+----------v-------------+-----+ 2180 | Integration Service | 2181 +-----+----------------------------------+----------^---------+------^--+ 2182 | | | | | 2183 | | | | | 2184 2.| 4.| 5.| 6.| 7.| 2185 | | | | | 2186 | | | | | 2187 +-----v------+ +---v----------+---+ +--v------+--+ 2188 | Policy | | Collection | | Posture | 2189 | Repository | | Sub-Architecture | | Attribute | 2190 +------------+ +------------------+ | Repository | 2191 +------------+ 2193 Figure 5: Configuration Assessment Component Interactions 2195 Figure 5 depicts configuration assessment components and their 2196 interactions, which are further described below. 2198 1. A policy feed provides a configuration assessment policy payload 2199 to the Integration Service. 2201 2. The Policy Repository, a consumer of Policy Feed information, 2202 receives and persists the Policy Feed's payload. 2204 3. Orchestration component(s), either manually invoked, scheduled, 2205 or event-based, publish a payload to begin the configuration 2206 assessment process. 2208 4. If necessary, Collection Sub-Architecture components may be 2209 invoked to collect neeeded posture attribute information. 2211 5. If necessary, the Collection Sub-Architecture will provide 2212 collected posture attributes to the Integration Service for 2213 persistence to the Posture Attribute Repository. 2215 6. The Posture Attribute Repository will consume a payload querying 2216 for relevant posture attribute information. 2218 7. The Posture Attribute Repository will provide the requested 2219 information to the Integration Service, allowing further 2220 orchestration payloads requesting the Evaluation Sub- 2221 Architecture perform evaluation tasks. 2223 8. The Evaluation Sub-Architecture consumes the evaluation payload 2224 and performs component-specific state comparison operations to 2225 produce evaluation results. 2227 9. A payload containing evaluation results are provided by the 2228 Evaluation Sub-Architecture to the Integration Service 2230 10. Evaluation results are consumed by/persisted to the Evaluation 2231 Results Repository 2233 In the above flow, the payload information is expected to convey the 2234 context required by the receiving component for the action being 2235 taken under different circumstances. For example, a directed message 2236 sent from an Orchestrator to a Collection sub-architecture might be 2237 telling that Collector to watch a specific posture attribute and 2238 report only specific detected changes to the Posture Attribute 2239 Repository, or it might be telling the Collector to gather that 2240 posture attribute immediately. Such details are expected to be 2241 handled as part of that payload, not as part of the architecture 2242 described herein. 2244 Authors' Addresses 2246 Adam W. Montville 2247 Center for Internet Security 2248 31 Tech Valley Drive 2249 East Greenbush, NY 12061 2250 United States of America 2252 Email: adam.montville.sdo@gmail.com 2253 Bill Munyan 2254 Center for Internet Security 2255 31 Tech Valley Drive 2256 East Greenbush, NY 12061 2257 United States of America 2259 Email: bill.munyan.ietf@gmail.com