idnits 2.17.1 draft-ietf-sacm-arch-04.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 84 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 (October 29, 2019) is 1641 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8412' is defined on line 837, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: May 1, 2020 October 29, 2019 7 Security Automation and Continuous Monitoring (SACM) Architecture 8 draft-ietf-sacm-arch-04 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 May 1, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 59 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 60 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 61 3.1. SACM Role-based Architecture . . . . . . . . . . . . . . 4 62 3.2. Architectural Roles/Components . . . . . . . . . . . . . 5 63 3.2.1. Orchestrator(s) . . . . . . . . . . . . . . . . . . . 5 64 3.2.2. Repositories/CMDBs . . . . . . . . . . . . . . . . . 5 65 3.2.3. Integration Service . . . . . . . . . . . . . . . . . 5 66 3.3. Downstream Uses . . . . . . . . . . . . . . . . . . . . . 6 67 3.3.1. Reporting . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3.2. Analytics . . . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Sub-Architectures . . . . . . . . . . . . . . . . . . . . 7 70 3.4.1. Collection Sub-Architecture . . . . . . . . . . . . . 7 71 3.4.2. Evaluation Sub-Architecture . . . . . . . . . . . . . 9 72 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Domain Workflows . . . . . . . . . . . . . . . . . . 12 74 5.1. IT Asset Management . . . . . . . . . . . . . . . . . . . 12 75 5.1.1. Components, Capabilities and Workflow(s) . . . . . . 13 76 5.2. Vulnerability Management . . . . . . . . . . . . . . . . 13 77 5.2.1. Components, Capabilities and Workflow(s) . . . . . . 14 78 5.3. Configuration Management . . . . . . . . . . . . . . . . 15 79 5.3.1. Components, Capabilities and Workflow(s) . . . . . . 16 80 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 85 9.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Appendix A. Mapping to RFC8248 . . . . . . . . . . . . . . . . . 21 87 Appendix B. Example Components . . . . . . . . . . . . . . . . . 24 88 B.1. Policy Services . . . . . . . . . . . . . . . . . . . . . 24 89 B.2. Software Inventory . . . . . . . . . . . . . . . . . . . 25 90 B.3. Datastream Collection . . . . . . . . . . . . . . . . . . 26 91 B.4. Network Configuration Collection . . . . . . . . . . . . 26 92 Appendix C. Exploring An XMPP-based Solution . . . . . . . . . . 27 93 C.1. Example Architecture using XMPP-Grid and Endpoint Posture 94 Collection Protocol . . . . . . . . . . . . . . . . . . . 30 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 97 1. Introduction 99 The purpose of this draft is to define an architectural approach for 100 a SACM Domain, based on the spirit of use cases found in [RFC7632] 101 and requirements found in [RFC8248]. This approach gains the most 102 advantage by supporting a variety of collection systems, and intends 103 to enable a cooperative ecosystem of tools from disparate sources 104 with minimal operator configuration. 106 1.1. Requirements notation 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in RFC 111 2119, BCP 14 [RFC2119]. 113 2. Terms and Definitions 115 This draft defers to [I-D.ietf-sacm-terminology] for terms and 116 definitions. 118 3. Architectural Overview 120 The generic approach proposed herein recognizes the need to obtain 121 information from existing and future state collection systems, and 122 makes every attempt to respect [RFC7632] and [RFC8248]. At the 123 foundation of any architecture are entities, or components, that need 124 to communicate. They communicate by sharing information, where, in a 125 given flow, one or more components are consumers of information and 126 one or more components are providers of information. 128 +----------------+ 129 | SACM Component | 130 | (Provider) | 131 +-------+--------+ 132 | 133 | 134 +--------------v----------------+ 135 | Integration Service | 136 +--------------+----------------+ 137 | 138 | 139 +-------v--------+ 140 | SACM Component | 141 | (Consumer) | 142 +----------------+ 144 Figure 1: Basic Architectural Structure 146 A provider can be described as an abstraction that refers to an 147 entity capable of sending SACM-relevant information to one or many 148 consumers. Consumers can be described as an abstraction that refers 149 to an entity capable of receiving SACM-relevant information from one 150 or many providers. Different roles within a cooperative ecosystem 151 may act as both providers and consumers of SACM-relevant information. 153 3.1. SACM Role-based Architecture 155 Within the cooperative SACM ecosystem, a number of roles act in 156 coordination to provide relevant policy/guidance, perform data 157 collection, storage, evaluation, and support downstream analytics and 158 reporting. 160 +--------------------+ 161 | Feeds/Repositories | 162 | of External Data | 163 +---------+----------+ 164 | 165 ******************************************* Boundary of Responsibility ****** 166 | 167 +-----------------+ | +--------------------+ 168 | Orchestrator(s) | | | Repositories/CMDBs | 169 +---------^-------+ | +----------^---------+ 170 | | | +--------------------+ 171 | | | | Downstream Uses | 172 | | | | +----------------+ | 173 +-----------v----------v-------------v------+ | | Analytics | | 174 | Integration Service <------> +----------------+ | 175 +-----------^--------------------------^----+ | +----------------+ | 176 | | | | Reporting | | 177 | | | +----------------+ | 178 +-----------v-------------------+ | +--------------------+ 179 | Collection Sub-Architecture | | 180 +-------------------------------+ | 181 +---------------v---------------+ 182 | Evaluation Sub-Architecture | 183 +-------------------------------+ 185 Figure 2: Notional Role-based Architecture 187 As shown in Figure 2, the SACM role-based architecture consists of 188 some basic SACM Components communicating using an integration 189 service. The integration service is expected to maximally align with 190 the requirements described in [RFC8248], which means that the 191 integration service will support brokered (i.e. point-to-point) and 192 proxied data exchange. 194 The boundary of responsibility is not intended to imply a physical 195 boundary. Rather, it is intended to be inclusive of various cloud/ 196 virtualized environments, BYOD and vendor-provided services in 197 addition to any physical systems the enterprise operates. 199 3.2. Architectural Roles/Components 201 This document suggests a variety of players in a cooperative 202 ecosystem; these players are known as SACM Components. SACM 203 Components may be composed of other SACM Components, and each SACM 204 Component plays one, or more, of several roles relevant to the 205 ecosystem. Roles may act as providers of information, consumers of 206 information, or both provider and consumer. Figure 2 depicts a 207 number of SACM components which are architecturally significant and 208 therefore warrant discussion and clarification. 210 3.2.1. Orchestrator(s) 212 Orchestration components exists to aid in the automation of 213 configuration, coordination, and management for the ecosystem of SACM 214 components. The Orchestrator performs control-plane operations, 215 administration of an implementing organization's components 216 (including endpoints, posture collection services, and downstream 217 activities), scheduling of automated tasks, and any ad-hoc activities 218 such as the initiation of collection or evaluation activities. The 219 Orchestrator is the key administrative interface into the SACM 220 architecture. 222 3.2.2. Repositories/CMDBs 224 Figure 2 only includes a single reference to "Repositories/CMDBs", 225 but in practice, a number of separate data repositories may exist, 226 including posture attribute repositories, policy repositories, local 227 vulnerability definition data repositories, and state assessment 228 results repositories. These data repositories may exist separately 229 or together in a single representation, and the design of these 230 repositories may be as distinct as their intended purpose, such as 231 the use of relational database management systems or graph/map 232 implementations focused on the relationships between data elements. 233 Each implementation of a SACM repository should focus on the 234 relationships between data elements and implement the SACM 235 information and data model(s). 237 3.2.3. Integration Service 239 If each SACM component represents a set of capabilities, the 240 Integration Service represents the "fabric" by which all those 241 services are woven together. The Integration Service acts as a 242 message broker, combining a set of common message categories and 243 infrastructure to allow SACM components to communicate using a shared 244 set of interfaces. The Integration Service's brokering capabilities 245 enable the exchange of various information payloads, orchestration of 246 component capabilities, message routing and reliable delivery. The 247 Integration Service minimizes the dependencies from one system to 248 another through the loose coupling of applications through messaging. 249 SACM components will "attach" to the Integration Service either 250 through native support for the integration implementation, or through 251 the use of "adapters" which provide a proxied attachment. 253 The Integration Service should provide mechanisms for synchronous 254 "request/response"-style messaging, asynchronous "send and forget" 255 messaging, or publish/subscribe. It is the responsibility of the 256 Integration Service to coordinate and manage the sending and 257 receiving of messages. The Integration Service should allow 258 components the ability to directly connect and produce or consume 259 messages, or connect via message translators which can act as a 260 proxy, transforming messages from a component format to one 261 implementing a SACM data model. 263 The Integration Service MUST provide routing capabilities for 264 payloads between producers and consumers. The Integration Service 265 MAY provide further capabilities within the payload delivery 266 pipeline. Examples of these capabilities include, but are not 267 limited to, intermediate processing, message transformation, type 268 conversion, validation, etc. 270 3.3. Downstream Uses 272 As depicted by Figure 2, a number of downstream uses exist in the 273 cooperative ecosystem. Each notional SACM component represents 274 distinct sub-architectures which will exchange information via the 275 integration services, using interactions described in this draft. 277 3.3.1. Reporting 279 The Reporting component represents capabilities outside of the SACM 280 architecture scope dealing with the query and retrieval of collected 281 posture attribute information, evaluation results, etc. in various 282 display formats that are useful to a wide range of stakeholders. 284 3.3.2. Analytics 286 The Analytics component represents capabilities outside of the SACM 287 architecture scope dealing with the discovery, interpretation, and 288 communication of any meaningful patterns of data in order to inform 289 effective decision making within the organization. 291 3.4. Sub-Architectures 293 Figure 2 shows two components representing sub-architectural roles 294 involved in a cooperative ecosystem of SACM components: Collection 295 and Evaluation. 297 3.4.1. Collection Sub-Architecture 299 The Collection sub-architecture, in a SACM context, is the mechanism 300 by which posture attributes are collected from applicable endpoints 301 and persisted to a repository, such as a configuration management 302 database (CMDB). Orchestration components will choreograph endpoint 303 data collection via interactions using the Integration Service as a 304 message broker. Instructions to perform endpoint data collection are 305 directed to a Posture Collection Service capable of performing 306 collection activities utilizing any number of methods, such as SNMP, 307 NETCONF/RESTCONF, SSH, WinRM, or host-based. 309 +----------------------------------------------------------+ 310 | Orchestrator(s) | 311 +-----------+----------------------------------------------+ 312 | +------------------------------+ 313 | | Posture Attribute Repository | 314 | +--------------^---------------+ 315 Perform | 316 Collection | 317 | Collected Data 318 | ^ 319 | | 320 +-----------v------------------------------+---------------+ 321 | Integration Service | 322 +----+------------------^-----------+------------------^---+ 323 | | | | 324 v | v | 325 Perform Collected Perform Collected 326 Collection Data Collection Data 327 | ^ | ^ 328 | | | | 329 +----v-----------------------+ +----v------------------+------+ 330 | Posture Collection Service | | Endpoint | 331 +---^------------------------+ | +--------------------------+ | 332 | | | |Posture Collection Service| | 333 | v | +--------------------------+ | 334 Events Queries +------------------------------+ 335 ^ | 336 | | 337 +---+-------------------v----+ 338 | Endpoint | 339 +----------------------------+ 341 Figure 3: Decomposed Collection Sub-Architecture 343 3.4.1.1. Posture Collection Service 345 The Posture Collection Service (PCS) is the SACM component 346 responsible for the collection of posture attributes from an endpoint 347 or set of endpoints. A single PCS may be responsible for management 348 of posture attribute collection from many endpoints. The PCS will 349 interact with the Integration Service to receive collection 350 instructions and to provide collected posture data for persistence to 351 the Posture Attribute Repository. Collection instructions may be 352 supplied in a variety of forms, including subscription to a publish/ 353 subscribe topic to which the Integration Service has published 354 instructions, via request/response-style synchronous messaging, or 355 via asynchronous "send-and-forget" messaging. Collected posture 356 information may then be supplied to the Integration Service via 357 similar channels. The various interaction types are discussed later 358 in this draft (TBD). 360 3.4.1.2. Endpoint 362 Building upon [I-D.ietf-sacm-terminology], the SACM Collection Sub- 363 Architecture augments the definition of an Endpoint as a component 364 within an organization's management domain from which a Posture 365 Collection Service will collect relevant posture attributes. 367 3.4.1.3. Posture Attribute Repository 369 The Posture Attribute Repository is a SACM component responsible for 370 the persistent storage of posture attributes collected via 371 interactions between the Posture Collection Service and Endpoints. 373 3.4.1.4. Posture Collection Workflow 375 Posture collection may be triggered from a number of components, but 376 commonly begin either via event-based triggering on an endpoint or 377 through manual orchestration, both illustrated in Figure 3 above. 378 Once orchestration has provided the directive to perform collection, 379 posture collection services consume the directives. Posture 380 collection is invoked for those endpoints overseen by the respective 381 posture collection services. Collected data is then provided to the 382 Integration Service, with a directive to store that information in an 383 appropriate repository. 385 3.4.2. Evaluation Sub-Architecture 387 The Evaluation Sub-Architecture, in the SACM context, is the 388 mechanism by which policy, expressed in the form of expected state, 389 is compared with collected posture attributes to yield an evaluation 390 result, that result being contextually dependent on the policy being 391 evaluated. 393 +------------------+ 394 | Collection | +-------------------------------+ 395 | Sub-Architecture | | Evaluation Results Repository | 396 +--------------+ +--------^---------+ +-----------------^-------------+ 397 | Orchestrator | | | 398 +------+-------+ | | 399 | Perform Store Evaluation Results 400 Perform Collection | 401 Evaluation | | 402 | | | 403 +------v----------------------v--------------------------------+-------------+ 404 | Integration Service | 405 +--------+----------------------------^----------------------^---------------+ 406 | | | 407 | | | 408 Perform Retrieve Posture | 409 Evaluation Attributes Retrieve Policy 410 | | | 411 | | | 412 +--------v-------------------+ +-----v------+ +------v-----+ 413 | Posture Evaluation Service | | Posture | | Policy | 414 +----------------------------+ | Attribute | | Repository | 415 | Repository | +------------+ 416 +------------+ 418 Figure 4: Decomposed Evaluation Sub-Architecture 420 3.4.2.1. Posture Evaluation Service 422 The Posture Evaluation Service (PES) represents the SACM component 423 responsible for coordinating the policy to be evaluated and the 424 collected posture attributes relevant to that policy, as well as the 425 comparison engine responsible for correctly determining compliance 426 with the expected state. 428 3.4.2.2. Policy Repository 430 The Policy Repository represents a persistent storage mechanism for 431 the policy to be assessed against collected posture attributes to 432 determine if an endpoint meets the defined expected state. Examples 433 of information contained in a Policy Repository would be 434 Vulnerability Definition Data or configuration recommendations as 435 part of a CIS Benchmark or DISA STIG. 437 3.4.2.3. Evaluation Results Repository 439 The Evaluation Results Repository persists the information 440 representing the results of a particular posture assessment, 441 indicating those posture attributes collected from various endpoints 442 which either meet or do not meet the expected state defined by the 443 assessed policy. Consideration should be made for the context of 444 individual results. For example, meeting the expected state for a 445 configuration attribute indicates a correct configuration of the 446 endpoint, whereas meeting an expected state for a vulnerable software 447 version indicates an incorrect and therefore vulnerable 448 configuration. 450 3.4.2.4. Posture Evaluation Workflow 452 Posture evaluation is orchestrated through the Integration Service to 453 the appropriate Posture Evaluation Service. The PES will, through 454 coordination with the Integration Service, query both the Posture 455 Attribute Repository and the Policy Repository to obtain relevant 456 state data for comparison. If necessary, the PES may be required to 457 invoke further posture collection. Once all relevant posture 458 information has been collected, it is compared to expected state 459 based on applicable policy. Comparison results are then persisted to 460 an evaluation results repository for further downstream use and 461 analysis. 463 4. Interactions 465 SACM Components are intended to interact with other SACM Components. 466 These interactions can be thought of, at the architectural level, as 467 the combination of interfaces with their supported operations. Each 468 interaction will convey a payload of information. The payload 469 information is expected to contain sub-domain-specific 470 characteristics and instructions. 472 Two categories of interactions SHOULD be supported by the Integration 473 Service; broadcast interactions, and directed interactions. 475 o *Broadcast*: A broadcast interaction, commonly known as "publish/ 476 subscribe", allows for a wider distribution of a message payload. 477 When a payload is published to a topic on the Integration Service, 478 all subscribers to that topic are alerted and may consume the 479 message payload. A broadcast interaction may also simulate a 480 "directed" interaction when a topic only has a single subscriber. 481 An example of a broadcast interaction could be to publish to a 482 topic that new configuration assessment content is available. 483 Subscribing consumers receive the notification, and proceed to 484 collect endpoint configuration posture based on the new content. 486 o *Directed*: The intent of a directed interaction is to enable 487 point-to-point communications between a producer and consumer, 488 through the standard interfaces provided by the Integration 489 Service. The provider component indicates which consumer is 490 intended to receive the payload, and the Integration Service 491 routes the payload directly to that consumer. Two "styles" of 492 directed interaction exist, differing only by the response from 493 the payload consumer: 495 * *Synchronous (Request/Response)*: Synchronous, request/response 496 style interaction requires that the requesting component block 497 and wait for the receiving component to respond, or to time out 498 when that response is delayed past a given time threshold. A 499 synchronous interaction example may be querying a CMDB for 500 posture attribute information in order to perform an 501 evaluation. 503 * *Asynchronous (Fire-and-Forget)*: An asynchronous interaction 504 involves the payload producer directing the message to a 505 consumer, but not blocking or waiting for a response. This 506 style of interaction allows the producer to continue on to 507 other activities without the need to wait for responses. This 508 style is particularly useful when the interaction payload 509 invokes a potentially long-running task, such as data 510 collection, report generation, or policy evaluation. The 511 receiving component may reply later via callbacks or further 512 interactions, but it is not mandatory. 514 Each interaction will convey a payload of information. The payload 515 is expected to contain specific characteristics and instructions to 516 be interpreted by receiving components. 518 5. Security Domain Workflows 520 This section describes three primary information security domains 521 from which workflows may be derived: IT Asset Management, 522 Vulnerability Management, and Configuration Management. 524 5.1. IT Asset Management 526 Information Technology asset management is easier said than done. 527 The [CISCONTROLS] have two controls dealing with IT asset management. 528 Control 1, Inventory and Control of Hardware Assets, states, 529 "Actively manage (inventory, track, and correct) all hardware devices 530 on the network so that only authorized devices are given access, and 531 unauthorized and unmanaged devices are found and prevented from 532 gaining access." Control 2, Inventory and Control of Software 533 Assets, states, "Actively manage (inventory, track, and correct) all 534 software on the network so that only authorized software is installed 535 and can execute, and that unauthorized and unmanaged software is 536 found and prevented from installation or execution." 538 In spirit, this covers all of the processing entities on your network 539 (as opposed to things like network cables, dongles, adapters, etc.), 540 whether physical or virtual, on-premises or in the cloud. 542 5.1.1. Components, Capabilities and Workflow(s) 544 TBD 546 5.1.1.1. Components 548 TBD 550 5.1.1.2. Capabilities 552 An IT asset management capability needs to be able to: 554 o Identify and catalog new assets by executing Target Endpoint 555 Discovery Tasks 557 o Provide information about its managed assets, including uniquely 558 identifying information (for that enterprise) 560 o Handle software and/or hardware (including virtual assets) 562 o Represent cloud hybrid environments 564 5.1.1.3. Workflow(s) 566 TBD 568 5.2. Vulnerability Management 570 Vulnerability management is a relatively established process. To 571 paraphrase the [CISCONTROLS], continuous vulnerability management is 572 the act of continuously acquiring, assessing, and taking subsequent 573 action on new information in order to identify and remediate 574 vulnerabilities, therefore minimizing the window of opportunity for 575 attackers. 577 A vulnerability assessment (i.e. vulnerability detection) is 578 performed in two steps: 580 o Endpoint information collected by the endpoint management 581 capabilities is examined by the vulnerability management 582 capabilities through Evaluation Tasks. 584 o If the data possessed by the endpoint management capabilities is 585 insufficient, a Collection Task is triggered and the necessary 586 data is collected from the target endpoint. 588 Vulnerability detection relies on the examination of different 589 endpoint information depending on the nature of a specific 590 vulnerability. Common endpoint information used to detect a 591 vulnerability includes: 593 o A specific software version is installed on the endpoint 595 o File system attributes 597 o Specific state attributes 599 In some cases, the endpoint information needed to determine an 600 endpoint's vulnerability status will have been previously collected 601 by the endpoint management capabilities and available in a 602 Repository. However, in other cases, the necessary endpoint 603 information will not be readily available in a Repository and a 604 Collection Task will be triggered to perform collection from the 605 target endpoint. Of course, some implementations of endpoint 606 management capabilities may prefer to enable operators to perform 607 this collection even when sufficient information can be provided by 608 the endpoint management capabilities (e.g. there may be freshness 609 requirements for information). 611 5.2.1. Components, Capabilities and Workflow(s) 613 TBD 615 5.2.1.1. Components 617 TBD 619 5.2.1.2. Capabilities 621 TBD 623 5.2.1.3. Workflow(s) 625 TBD 627 5.3. Configuration Management 629 Configuration management involves configuration assessment, which 630 requires state assessment. The [CISCONTROLS] specify two high-level 631 controls concerning configuration management (Control 5 for non- 632 network devices and Control 11 for network devices). As an aside, 633 these controls are listed separately because many enterprises have 634 different organizations for managing network infrastructure and 635 workload endpoints. Merging the two controls results in the 636 following paraphrasing: Establish, implement, and actively manage 637 (track, report on, correct) the security configuration of systems 638 using a rigorous configuration management and change control process 639 in order to prevent attackers from exploiting vulnerable services and 640 settings. 642 Typically, an enterprise will use configuration guidance from a 643 reputable source, and from time to time they may tailor the guidance 644 from that source prior to adopting it as part of their enterprise 645 standard. The enterprise standard is then provided to the 646 appropriate configuration assessment tools and they assess endpoints 647 and/or appropriate endpoint information. 649 A preferred flow follows: 651 o Reputable source publishes new or updated configuration guidance 653 o Enterprise configuration assessment capability retrieves 654 configuration guidance from reputable source 656 o Optional: Configuration guidance is tailored for enterprise- 657 specific needs 659 o Configuration assessment tool queries asset inventory repository 660 to retrieve a list of affected endpoints 662 o Configuration assessment tool queries configuration state 663 repository to evaluate compliance 665 o If information is stale or unavailable, configuration assessment 666 tool triggers an ad hoc assessment 668 The SACM architecture needs to support varying deployment models to 669 accommodate the current state of the industry, but should strongly 670 encourage event-driven approaches to monitoring configuration. 672 5.3.1. Components, Capabilities and Workflow(s) 674 This section provides more detail about the components and 675 capabilities required when considering the aforementioned 676 configuration management workflow. 678 5.3.1.1. Components 680 The following is a minimal list of SACM Components required to 681 implement the aforementioned configuration assessment workflow. 683 o Configuration Policy Feed: An external source of authoritative 684 configuration recommendations. 686 o Configuration Policy Repository: An internal repository of 687 enterprise standard configurations. 689 o Configuration Assessment Orchestrator: A component responsible for 690 orchestrating assessments. 692 o Posture Attribute Collection Subsystem: A component responsible 693 for collection of posture attributes from systems. 695 o Posture Attribute Repository: A component used for storing system 696 posture attribute values. 698 o Configuration Assessment Evaluator: A component responsible for 699 evaluating system posture attribute values against expected 700 posture attribute values. 702 o Configuration Assessment Results Repository: A component used for 703 storing evaluation results. 705 5.3.1.2. Capabilities 707 Per [RFC8248], solutions MUST support capability negotiation. 708 Components implementing specific interfaces and operations (i.e. 709 interactions) will need a method of describing their capabilities to 710 other components participating in the ecosystem; for example, "As a 711 component in the ecosystem, I can assess the configuration of 712 Windows, MacOS, and AWS using OVAL". 714 5.3.1.3. Configuration Assessment Workflow 716 This section describes the components and interactions in a basic 717 configuration assessment workflow. For simplicity, error conditions 718 are recognized as being necessary and are not depicted. When one 719 component messages another component, the message is expected to be 720 handled appropriately unless there is an error condition, or other 721 notification, messaged in return. 723 +-------------+ +----------------+ +------------------+ +------------+ 724 | Policy Feed | | Orchestrator | | Evaluation | | Evaluation | 725 +------+------+ +-------+--------+ | Sub-Architecture | | Results | 726 | | +---^----------+---+ | Repository | 727 | | | | +------^-----+ 728 | | | | | 729 1.| 3.| 8.| 9.| 10.| 730 | | | | | 731 | | | | | 732 +------v-----------------v---------------+----------v-------------+-----+ 733 | Integration Service | 734 +-----+----------------------------------+----------^---------+------^--+ 735 | | | | | 736 | | | | | 737 2.| 4.| 5.| 6.| 7.| 738 | | | | | 739 | | | | | 740 +-----v------+ +---v----------+---+ +--v------+--+ 741 | Policy | | Collection | | Posture | 742 | Repository | | Sub-Architecture | | Attribute | 743 +------------+ +------------------+ | Repository | 744 +------------+ 746 Figure 5: Configuration Assessment Component Interactions 748 Figure 5 depicts configuration assessment components and their 749 interactions, which are further described below. 751 1. A policy feed provides a configuration assessment policy payload 752 to the Integration Service. 754 2. The Policy Repository, a consumer of Policy Feed information, 755 receives and persists the Policy Feed's payload. 757 3. Orchestration component(s), either manually invoked, scheduled, 758 or event-based, publish a payload to begin the configuration 759 assessment process. 761 4. If necessary, Collection Sub-Architecture components may be 762 invoked to collect neeeded posture attribute information. 764 5. If necessary, the Collection Sub-Architecture will provide 765 collected posture attributes to the Integration Service for 766 persistence to the Posture Attribute Repository. 768 6. The Posture Attribute Repository will consume a payload querying 769 for relevant posture attribute information. 771 7. The Posture Attribute Repository will provide the requested 772 information to the Integration Service, allowing further 773 orchestration payloads requesting the Evaluation Sub- 774 Architecture perform evaluation tasks. 776 8. The Evaluation Sub-Architecture consumes the evaluation payload 777 and performs component-specific state comparison operations to 778 produce evaluation results. 780 9. A payload containing evaluation results are provided by the 781 Evaluation Sub-Architecture to the Integration Service 783 10. Evaluation results are consumed by/persisted to the Evaluation 784 Results Repository 786 In the above flow, the payload information is expected to convey the 787 context required by the receiving component for the action being 788 taken under different circumstances. For example, a directed message 789 sent from an Orchestrator to a Collection sub-architecture might be 790 telling that Collector to watch a specific posture attribute and 791 report only specific detected changes to the Posture Attribute 792 Repository, or it might be telling the Collector to gather that 793 posture attribute immediately. Such details are expected to be 794 handled as part of that payload, not as part of the architecture 795 described herein. 797 6. Privacy Considerations 799 TODO 801 7. Security Considerations 803 TODO 805 8. IANA Considerations 807 TODO: Revamp this section after the configuration assessment workflow 808 is fleshed out. 810 IANA tables can probably be used to make life a little easier. We 811 would like a place to enumerate: 813 o Capability/operation semantics 815 o SACM Component implementation identifiers 816 o SACM Component versions 818 o Associations of SACM Components (and versions) to specific 819 Capabilities 821 o Collection sub-architecture Identification 823 9. References 825 9.1. Normative References 827 [I-D.ietf-sacm-ecp] 828 Haynes, D., Fitzgerald-McKay, J., and L. Lorenzin, 829 "Endpoint Posture Collection Profile", draft-ietf-sacm- 830 ecp-05 (work in progress), June 2019. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, 834 DOI 10.17487/RFC2119, March 1997, 835 . 837 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 838 J. Fitzgerald-McKay, "Software Inventory Message and 839 Attributes (SWIMA) for PA-TNC", RFC 8412, 840 DOI 10.17487/RFC8412, July 2018, 841 . 843 [RFC8600] Cam-Winget, N., Ed., Appala, S., Pope, S., and P. Saint- 844 Andre, "Using Extensible Messaging and Presence Protocol 845 (XMPP) for Security Information Exchange", RFC 8600, 846 DOI 10.17487/RFC8600, June 2019, 847 . 849 9.2. Informative References 851 [CISCONTROLS] 852 "CIS Controls v7.0", n.d., 853 . 855 [draft-birkholz-sacm-yang-content] 856 Birkholz, H. and N. Cam-Winget, "YANG subscribed 857 notifications via SACM Statements", n.d., 858 . 861 [HACK100] "IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP", 862 n.d., . 865 [HACK101] "IETF 101 Hackathon - Configuration Assessment XMPP", 866 n.d., . 868 [HACK102] "IETF 102 Hackathon - YANG Collection on Traditional 869 Endpoints", n.d., 870 . 872 [HACK103] "IETF 103 Hackathon - N/A", n.d., 873 . 875 [HACK104] "IETF 104 Hackathon - A simple XMPP client", n.d., 876 . 878 [HACK105] "IETF 105 Hackathon - A more robust XMPP client including 879 collection extensions", n.d., 880 . 882 [HACK99] "IETF 99 Hackathon - Vulnerability Scenario EPCP", n.d., 883 . 886 [I-D.ietf-sacm-terminology] 887 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 888 A. Montville, "Security Automation and Continuous 889 Monitoring (SACM) Terminology", draft-ietf-sacm- 890 terminology-16 (work in progress), December 2018. 892 [NIST800126] 893 Waltermire, D., Quinn, S., Booth, H., Scarfone, K., and D. 894 Prisaca, "SP 800-126 Rev. 3 - The Technical Specification 895 for the Security Content Automation Protocol (SCAP) - SCAP 896 Version 1.3", February 2018, 897 . 900 [NISTIR7694] 901 Halbardier, A., Waltermire, D., and M. Johnson, "NISTIR 902 7694 Specification for Asset Reporting Format 1.1", n.d., 903 . 906 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 907 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 908 October 2007, . 910 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 911 Posture Assessment: Enterprise Use Cases", RFC 7632, 912 DOI 10.17487/RFC7632, September 2015, 913 . 915 [RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and 916 Continuous Monitoring (SACM) Requirements", RFC 8248, 917 DOI 10.17487/RFC8248, September 2017, 918 . 920 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 921 Oriented Lightweight Information Exchange (ROLIE)", 922 RFC 8322, DOI 10.17487/RFC8322, February 2018, 923 . 925 [XMPPEXT] "XMPP Extensions", n.d., . 927 Appendix A. Mapping to RFC8248 929 TODO: Consider removing or placing in a separate solution draft. 931 This section provides a mapping of XMPP and XMPP Extensions to the 932 relevant requirements from [RFC8248]. In the table below, the ID and 933 Name columns provide the ID and Name of the requirement directly out 934 of [RFC8248]. The Supported By column may contain one of several 935 values: 937 o N/A: The requirement is not applicable to this architectural 938 exploration 940 o Architecture: This architecture (possibly assuming some 941 components) should meet the requirement 943 o XMPP: The set of XMPP Core specifications and the collection of 944 applicable extensions, deployment, and operational considerations. 946 o XMPP-Core: The requirement is satisfied by a core XMPP feature 948 o XEP-nnnn: The requirement is satisfied by a numbered XMPP 949 extension (see [XMPPEXT]) 951 o Operational: The requirement is an operational concern or can be 952 addressed by an operational deployment 954 o Implementation: The requirement is an implementation concern 956 If there is no entry in the Supported By column, then there is a gap 957 that must be filled. 959 +----------+----------------------------------------+---------------+ 960 | ID | Name | Supported By | 961 +----------+----------------------------------------+---------------+ 962 | G-001 | Solution Extensibility | XMPP-Core | 963 | | | | 964 | G-002 | Interoperability | XMPP | 965 | | | | 966 | G-003 | Scalability | XMPP | 967 | | | | 968 | G-004 | Versatility | XMPP-Core | 969 | | | | 970 | G-005 | Information Extensibility | XMPP-Core | 971 | | | | 972 | G-006 | Data Protection | Operational | 973 | | | | 974 | G-007 | Data Partitioning | Operational | 975 | | | | 976 | G-008 | Versioning and Backward Compatibility | XEP-0115/0030 | 977 | | | | 978 | G-009 | Information Discovery | XEP-0030 | 979 | | | | 980 | G-010 | Target Endpoint Discovery | XMPP-Core | 981 | | | | 982 | G-011 | Push and Pull Access | XEP-0060/0312 | 983 | | | | 984 | G-012 | SACM Component Interface | N/A | 985 | | | | 986 | G-013 | Endpoint Location and Network Topology | | 987 | | | | 988 | G-014 | Target Endpoint Identity | XMPP-Core | 989 | | | | 990 | G-015 | Data Access Control | | 991 | | | | 992 | ARCH-001 | Component Functions | XMPP | 993 | | | | 994 | ARCH-002 | Scalability | XMPP-Core | 995 | | | | 996 | ARCH-003 | Flexibility | XMPP-Core | 997 | | | | 998 | ARCH-004 | Separation of Data and Management | | 999 | | Functions | | 1000 | | | | 1001 | ARCH-005 | Topology Flexibility | XMPP-Core | 1002 | | | | 1003 | ARCH-006 | Capability Negotiation | XEP-0115/0030 | 1004 | | | | 1005 | ARCH-007 | Role-Based Authorization | XMPP-Core | 1006 | | | | 1007 | ARCH-008 | Context-Based Authorization | | 1008 | | | | 1009 | ARCH-009 | Time Synchronization | Operational | 1010 | | | | 1011 | IM-001 | Extensible Attribute Vocabulary | N/A | 1012 | | | | 1013 | IM-002 | Posture Data Publication | N/A | 1014 | | | | 1015 | IM-003 | Data Model Negotiation | N/A | 1016 | | | | 1017 | IM-004 | Data Model Identification | N/A | 1018 | | | | 1019 | IM-005 | Data Lifetime Management | N/A | 1020 | | | | 1021 | IM-006 | Singularity and Modularity | N/A | 1022 | | | | 1023 | DM-001 | Element Association | N/A | 1024 | | | | 1025 | DM-002 | Data Model Structure | N/A | 1026 | | | | 1027 | DM-003 | Search Flexibility | N/A | 1028 | | | | 1029 | DM-004 | Full vs. Partial Updates | N/A | 1030 | | | | 1031 | DM-005 | Loose Coupling | N/A | 1032 | | | | 1033 | DM-006 | Data Cardinality | N/A | 1034 | | | | 1035 | DM-007 | Data Model Negotiation | N/A | 1036 | | | | 1037 | DM-008 | Data Origin | N/A | 1038 | | | | 1039 | DM-009 | Origination Time | N/A | 1040 | | | | 1041 | DM-010 | Data Generation | N/A | 1042 | | | | 1043 | DM-011 | Data Source | N/A | 1044 | | | | 1045 | DM-012 | Data Updates | N/A | 1046 | | | | 1047 | DM-013 | Multiple Collectors | N/A | 1048 | | | | 1049 | DM-014 | Attribute Extensibility | N/A | 1050 | | | | 1051 | DM-015 | Solicited vs. Unsolicited Updates | N/A | 1052 | | | | 1053 | DM-016 | Transfer Agnostic | N/A | 1054 | | | | 1055 | OP-001 | Time Synchronization | | 1056 | | | | 1057 | OP-002 | Collection Abstraction | | 1058 | | | | 1059 | OP-003 | Collection Composition | | 1060 | | | | 1061 | OP-004 | Attribute-Based Query | | 1062 | | | | 1063 | OP-005 | Information-Based Query with Filtering | | 1064 | | | | 1065 | OP-006 | Operation Scalability | | 1066 | | | | 1067 | OP-007 | Data Abstraction | | 1068 | | | | 1069 | OP-008 | Provider Restriction | | 1070 | | | | 1071 | T-001 | Multiple Transfer Protocol Support | Architecture | 1072 | | | | 1073 | T-002 | Data Integrity | Operational | 1074 | | | | 1075 | T-003 | Data Confidentiality | Operational | 1076 | | | | 1077 | T-004 | Transfer Protection | | 1078 | | | | 1079 | T-005 | Transfer Reliability | | 1080 | | | | 1081 | T-006 | Transfer-Layer Requirements | | 1082 | | | | 1083 | T-007 | Transfer Protocol Adoption | Architecture | 1084 +----------+----------------------------------------+---------------+ 1086 Appendix B. Example Components 1088 TODO: Consider removing. 1090 B.1. Policy Services 1092 Consider a policy server conforming to [RFC8322]. [RFC8322] 1093 describes a RESTful way based on the ATOM Publishing Protocol 1094 ([RFC5023]) to find specific data collections. While this represents 1095 a specific binding (i.e. RESTful API based on [RFC5023]), there is a 1096 more abstract way to look at ROLIE. 1098 ROLIE provides notional workspaces and collections, and provides the 1099 concept of information categories and links. Strictly speaking, 1100 these are logical concepts independent of the RESTful binding ROLIE 1101 specifies. In other words, ROLIE binds a logical interface (i.e. 1103 GET workspace, GET collection, SET entry, and so on) to a specific 1104 mechanism (namely an ATOM Publication Protocol extension). 1106 It is not inconceivable to believe there could be a different 1107 interface mechanism, or a connector, providing these same operations 1108 using XMPP-Grid as the transfer mechanism. 1110 Even if a [RFC8322] server were external to an organization, there 1111 would be a need for a policy source inside the organization as well, 1112 and it may be preferred for such a policy source to be connected 1113 directly to the ecosystem's communication infrastructure. 1115 B.2. Software Inventory 1117 The SACM working group has accepted work on the Endpoint Posture 1118 Collection Profile [I-D.ietf-sacm-ecp], which describes a collection 1119 architecture and may be viewed as a collector coupled with a 1120 collection-specific repository. 1122 Posture Manager Endpoint 1123 Orchestrator +---------------+ +---------------+ 1124 +--------+ | | | | 1125 | | | +-----------+ | | +-----------+ | 1126 | |<---->| | Posture | | | | Posture | | 1127 | | pub/ | | Validator | | | | Collector | | 1128 | | sub | +-----------+ | | +-----------+ | 1129 +--------+ | | | | | | 1130 | | | | | | 1131 Evaluator Repository | | | | | | 1132 +------+ +--------+ | +-----------+ |<-------| +-----------+ | 1133 | | | | | | Posture | | report | | Posture | | 1134 | | | | | | Collection| | | | Collection| | 1135 | |<-----> | |<-----| | Manager | | query | | Engine | | 1136 | |request/| | store| +-----------+ |------->| +-----------+ | 1137 | |respond | | | | | | 1138 | | | | | | | | 1139 +------+ +--------+ +---------------+ +---------------+ 1141 Figure 6: EPCP Collection Architecture 1143 In Figure 6, any of the communications between the Posture Manager 1144 and EPCP components to its left could be performed directly or 1145 indirectly using a given message transfer mechanism. For example, 1146 the pub/sub interface between the Orchestrator and the Posture 1147 Manager could be using a proprietary method or using [RFC8600] or 1148 some other pub/sub mechanism. Similarly, the store connection from 1149 the Posture Manager to the Repository could be performed internally 1150 to a given implementation, via a RESTful API invocation over HTTPS, 1151 or even over a pub/sub mechanism. 1153 Our assertion is that the Evaluator, Repository, Orchestrator, and 1154 Posture Manager all have the potential to represent SACM Components 1155 with specific capability interfaces that can be logically specified, 1156 then bound to one or more specific transfer mechanisms (i.e. RESTful 1157 API, [RFC8322], [RFC8600], and so on). 1159 B.3. Datastream Collection 1161 [NIST800126], also known as SCAP 1.3, provides the technical 1162 specifications for a "datastream collection". The specification 1163 describes the "datastream collection" as being "composed of SCAP data 1164 streams and SCAP source components". A "datastream" provides an 1165 encapsulation of the SCAP source components required to, for example, 1166 perform configuration assessment on a given endpoint. These source 1167 components include XCCDF checklists, OVAL Definitions, and CPE 1168 Dictionary information. A single "datastream collection" may 1169 encapsulate multiple "datastreams", and reference any number of SCAP 1170 components. Datastream collections were intended to provide an 1171 envelope enabling transfer of SCAP data more easily. 1173 The [NIST800126] specification also defines the "SCAP result data 1174 stream" as being conformant to the Asset Reporting Format 1175 specification, defined in [NISTIR7694]. The Asset Reporting Format 1176 provides an encapsulation of the SCAP source components, Asset 1177 Information, and SCAP result components, such as system 1178 characteristics and state evaluation results. 1180 What [NIST800126]did not do is specify the interface for finding or 1181 acquiring source datastream information, nor an interface for 1182 publishing result information. Discovering the actual resources for 1183 this information could be done via ROLIE, as described in the Policy 1184 Services section above, but other repositories of SCAP data exist as 1185 well. 1187 B.4. Network Configuration Collection 1189 [draft-birkholz-sacm-yang-content] illustrates a SACM Component 1190 incorporating a YANG Push client function and an XMPP-grid publisher 1191 function. [draft-birkholz-sacm-yang-content] further states "the 1192 output of the YANG Push client function is encapsulated in a SACM 1193 Content Element envelope, which is again encapsulated in a SACM 1194 statement envelope" which are published, essentially, via an XMPP- 1195 Grid Connector for SACM Components also part of the XMPP-Grid. 1197 This is a specific example of an existing collection mechanism being 1198 adapted to the XMPP-Grid message transfer system. 1200 Appendix C. Exploring An XMPP-based Solution 1202 TODO: Consider removing or placing in a separate draft. 1204 Ongoing work has been taking place around and during IETF hackathons. 1205 The list of hackathon efforts follows: 1207 o [HACK99]: A partial implementation of a vulnerability assessment 1208 scenario involving an [I-D.ietf-sacm-ecp] implementation, a 1209 [RFC8322] implementation, and a proprietary evaluator to pull the 1210 pieces together. 1212 o [HACK100]: Work to combine the vulnerability assessment scenario 1213 from [HACK99] with an XMPP-based YANG push model. 1215 o [HACK101]: A fully automated configuration assessment 1216 implementation using XMPP (specifically Publish/Subscribe 1217 capabilities) as a communication mechanism. 1219 o [HACK102]: An exploration of how we might model assessment, 1220 collection, and evaluation abstractly, and then rely on YANG 1221 expressions for the attributes of traditional endpoints. 1223 o [HACK103]: No SACM participation at the Bangkok hackathon. 1225 o [HACK104]: Basic XMPP-to-Concise MAP - Created an XMPP adapter 1226 that can accept basic posture attributes and translate them to 1227 Concise MAP. This hackathon only proved the concept that system 1228 characteristics information can be transported via XMPP and 1229 translated to a (very basic) concise MAP implementation. 1231 o [HACK105]: Advanced XMPP-to-Concise MAP: Full orchestration of 1232 collection capabilities using XMPP. Collector implementations 1233 extend the core XMPP structure to allow OVAL collection 1234 instructions (OVAL objects) to inform posture attribute 1235 collection. Collected system characteristics can be provided to 1236 the Concise MAP XMPP adapter using all 3 available XMPP 1237 capabilities: Publish/Subscribe, Information Query (iq - request/ 1238 response) stanzas, or direct Message stanzas. CDDL was created to 1239 map collected posture attributes to Concise MAP structure. The 1240 XMPP adapter translates the incoming system characteristics and 1241 stores the information in the MAP. 1243 Figure 7 depicts a slightly more detailed view of the architecture 1244 (within the enterprise boundary) - one that fosters the development 1245 of a pluggable ecosystem of cooperative tools. Existing collection 1246 mechanisms can be brought into this architecture by specifying the 1247 interface of the collector and creating the XMPP-Grid Connector 1248 binding for that interface. 1250 Additionally, while not directly depicted in Figure 7, this 1251 architecture does allow point-to-point interfaces. In fact, 1252 [RFC8600] provides brokering capabilities to facilitate such point- 1253 to-point data transfers). Additionally, each of the SACM Components 1254 depicted in Figure 7 may be a provider, a consumer, or both, 1255 depending on the workflow in context. 1257 +--------------+ +--------------+ 1258 | Orchestrator | | Repositories | 1259 +------^-------+ +------^-------+ 1260 | | 1261 | | 1262 +-------v--------------------------v--------+ +-----------------+ 1263 | XMPP-Grid+ <-----> Downstream Uses | 1264 +------------------------^------------------+ +-----------------+ 1265 | 1266 | 1267 +-------v------+ 1268 | XMPP-Grid | 1269 | Connector(s) | 1270 +------^-------+ 1271 | 1272 +------v-------+ 1273 | Collector(s) | 1274 +--------------+ 1276 Figure 7: XMPP-based Architecture 1278 [RFC8600] details a number of XMPP extensions (XEPs) that MUST be 1279 utilized to meet the needs of [RFC7632] and [RFC8248]: 1281 o Service Discovery (XEP-0030): Service Discovery allows XMPP 1282 entities to discover information about other XMPP entities. Two 1283 kinds of information can be discovered: the identity and 1284 capabilities of an entity, such as supported features, and items 1285 associated with an entity. 1287 o Publish-Subscribe (XEP-0060): The PubSub extension enables 1288 entities to create nodes (topics) at a PubSub service and publish 1289 information at those nodes. Once published, an event notification 1290 is broadcast to all entities that have subscribed to that node. 1292 At this point, [RFC8600] specifies fewer features than SACM requires, 1293 and there are other XMPP extensions (XEPs) we need to consider to 1294 meet the needs of [RFC7632] and [RFC8248]. In Figure 7 we therefore 1295 use "XMPP-Grid+" to indicate something more than [RFC8600] alone, 1296 even though we are not yet fully confident in the exact set of XMPP- 1297 related extensions we will require. The authors propose work to 1298 extend (or modify) [RFC8600] to include additional XEPs - possibly 1299 the following: 1301 o Entity Capabilities (XEP-0115): This extension defines the methods 1302 for broadcasting and dynamically discovering an entities' 1303 capabilities. This information is transported via standard XMPP 1304 presence. Example capabilities that could be discovered could 1305 include support for posture attribute collection, support for 1306 specific types of posture attribute collection such as EPCP, 1307 SWIMA, OVAL, or YANG. Other capabilities are still to be 1308 determined. 1310 o Ad Hoc Commands (XEP-0050): This extension allows an XMPP entity 1311 to advertise and execute application-specific commands. Typically 1312 the commands contain data forms (XEP-0004) in order to structure 1313 the information exchange. This extension may be usable for simple 1314 orchestration (i.e. "do assessment"). 1316 o HTTP File Upload (XEP-0363): The HTTP File Upload extension allows 1317 for large data sets to be published to a specific path on an HTTP 1318 server, and receive a URL from which that file can later be 1319 downloaded again. XMPP messages and IQs are meant to be compact, 1320 and large data sets, such as collected posture attributes, may 1321 exceed a message size threshold. Usage of this XEP allows those 1322 larger data sets to be persisted, thus necessitating only the 1323 download URL to be passed via XMPP messages. 1325 o Personal Eventing Protocol (XEP-0163): The Personal Eventing 1326 Protocol can be thought of as a virtual PubSub service, allowing 1327 an XMPP account to publish events only to their roster instead of 1328 a generic PubSub topic. This XEP may be useful in the cases when 1329 collection requests or queries are only intended for a subset of 1330 endpoints and not an entire subscriber set. 1332 o File Repository and Sharing (XEP-0214): This extension defines a 1333 method for XMPP entities to designate a set of file available for 1334 retrieval by other users of their choosing, and is based on PubSub 1335 Collections. 1337 o Easy User Onboarding (XEP-401): The goal of this extension is 1338 simplified client registration, and may be useful when adding new 1339 endpoints or SACM components to the ecosystem. 1341 o Bidirectional-streams Over Synchronous HTTP (BOSH) (XEP-0124): 1342 BOSH emulates the semantics of a long-lived, bidirectional TCP 1343 connection between two entities (aka "long polling"). Consider a 1344 SACM component that is updated dynamically, i.e. an internal 1345 vulnerability definition repository ingesting data from a Feed/ 1346 Repository of External Data, and a second SACM component such as 1347 an Orchestrator. Using BOSH, the Orchestrator can effectively 1348 continuously poll the vulnerability definition repository for 1349 changes/updates. 1351 o PubSub Collection Nodes (XEP-0248): Effectively an extension to 1352 XEP-0060 (Publish-Subscribe), PubSub Collections aim to simplify 1353 an entities' subscription to multiple related topics, and 1354 establishes a "node graph" relating parent nodes to its 1355 descendents. An example "node graph" could be rooted in a 1356 "vulnerability definitions" topic, and contain descendent topics 1357 for OS family-level vulnerability definitions (i.e. Windows), and 1358 further for OS family version-level definitions (i.e. Windows 10 1359 or Windows Server 2016). 1361 o PubSub Since (XEP-0312): This extension enables a subscriber to 1362 automatically receive PubSub and Personal Eventing Protocol (PEP) 1363 notifications since its last logout time. This extension may be 1364 useful in intermittent connection scenarios, or when entities 1365 disconnect and reconnect to the ecosystem. 1367 o PubSub Chaining (XEP-0253): This extension describes the 1368 federation of publishing nodes, enabling a publish node of one 1369 server to be a subscriber to a publishing node of another server. 1371 C.1. Example Architecture using XMPP-Grid and Endpoint Posture 1372 Collection Protocol 1374 Figure 8 depicts a further detailed view of the architecture 1375 including the Endpoint Posture Collection Protocol as the collection 1376 subsystem, illustrating the idea of a pluggable ecosystem of 1377 cooperative tools. 1379 +--------------------+ 1380 | Feeds/Repositories | 1381 | of External Data | 1382 +--------------------+ 1383 | 1384 ********************v*********************** Boundary of Responsibility ******* 1385 * | * 1386 * +--------------+ | +-------------------+ +-------------+ * 1387 * | Orchestrator | | | Posture Attr Repo | | Policy Repo | * 1388 * +------^-------+ | +---------^---------+ +---^---------+ * 1389 * | | | | +----------------+ * 1390 * | | | | | Downstream Uses| * 1391 * | | | | | +-----------+ | * 1392 * +------v---------v-----------v---------------v--+ | |Evaluations| | * 1393 * | XMPP-Grid <-------> +-----------+ | * 1394 * +----------------^-------------------^----------+ | +-----------+ | * 1395 * | | | | Analytics | | * 1396 * | | | +-----------+ | * 1397 * | +-----v--------+ | +-----------+ | * 1398 * | | Results Repo | | | Reporting | | * 1399 * | +--------------+ | +-----------+ | * 1400 * | +----------------+ * 1401 * +---------v-----------+ * 1402 * | XMPP-Grid Connector | * 1403 * +---------^-----------+ * 1404 * | * 1405 * +-----------------v-------------------------------------------------------+ * 1406 * | | * 1407 * | +--Posture Collection Manager------------------------------------------+| * 1408 * | |+-----------------------+ +----------------+ +----------------------+ || * 1409 * | || Communications Server | | Posture Server | | Posture Validator(s) | || * 1410 * | |+----------^------------+ +----------------+ +----------------------+ || * 1411 * | +-----------|----------------------------------------------------------+| * 1412 * | | | * 1413 * | +-----------|-------------------------Endpoint or Endpoint Proxy-------+| * 1414 * | |+----------v------------+ +----------------+ +----------------------+ || * 1415 * | || Communications Client | | Posture Client | | Posture Collector(s) | || * 1416 * | |+-----------------------+ +----------------+ +----------------------+ || * 1417 * | +----------------------------------------------------------------------+| * 1418 * +-----------------Endpoint Posture Collection Profile---------------------+ * 1419 * * 1420 ******************************************************************************* 1422 Figure 8: XMPP-based Architecture including EPCP 1424 Authors' Addresses 1426 Adam W. Montville 1427 Center for Internet Security 1428 31 Tech Valley Drive 1429 East Greenbush, NY 12061 1430 USA 1432 Email: adam.montville.sdo@gmail.com 1434 Bill Munyan 1435 Center for Internet Security 1436 31 Tech Valley Drive 1437 East Greenbush, NY 12061 1438 USA 1440 Email: bill.munyan.ietf@gmail.com