idnits 2.17.1 draft-ietf-sacm-arch-01.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 72 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], [I-D.ietf-mile-xmpp-grid], [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 (February 22, 2019) is 1862 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 705, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-mile-xmpp-grid-09 == Outdated reference: A later version (-05) exists of draft-ietf-sacm-ecp-04 Summary: 2 errors (**), 0 flaws (~~), 4 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: August 26, 2019 February 22, 2019 7 Security Automation and Continuous Monitoring (SACM) Architecture 8 draft-ietf-sacm-arch-01 10 Abstract 12 This memo defines a Security Automation and Continuous Monitoring 13 (SACM) architecture. This work is built upon 14 [I-D.ietf-mile-xmpp-grid], and is predicated upon information gleaned 15 from SACM Use Cases and Requirements ([RFC7632] and [RFC8248] 16 respectively), and terminology as found in 17 [I-D.ietf-sacm-terminology]. 19 WORKING GROUP: The source for this draft is maintained in GitHub. 20 Suggested changes should be submitted as pull requests at 21 https://github.com/sacmwg/ietf-mandm-sacm-arch/. Instructions are on 22 that page as well. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 26, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Open Questions . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 61 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 62 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 63 3.1. SACM Roles . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Exploring An XMPP-based Solution . . . . . . . . . . . . 5 65 3.3. Example Architecture using XMPP-Grid and Endpoint Posture 66 Collection Protocol . . . . . . . . . . . . . . . . . . . 8 67 4. Components, Capabilities, Interfaces, and Workflows . . . . . 10 68 4.1. Components . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 11 70 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.4. Workflows . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.4.1. IT Asset Management . . . . . . . . . . . . . . . . . 12 73 4.4.2. Vulnerability Management . . . . . . . . . . . . . . 12 74 4.4.3. Configuration Management . . . . . . . . . . . . . . 14 75 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 8.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Appendix A. Mapping to RFC8248 . . . . . . . . . . . . . . . . . 18 82 Appendix B. Example Components . . . . . . . . . . . . . . . . . 21 83 B.1. Policy Services . . . . . . . . . . . . . . . . . . . . . 21 84 B.2. Software Inventory . . . . . . . . . . . . . . . . . . . 22 85 B.3. Datastream Collection . . . . . . . . . . . . . . . . . . 23 86 B.4. Network Configuration Collection . . . . . . . . . . . . 23 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 The purpose of this draft is to define an architectural solution for 92 a SACM Domain. This draft also defines an implementation of the 93 architecutre, built upon [I-D.ietf-mile-xmpp-grid] and 94 [I-D.ietf-sacm-ecp]. These approaches complement each other to more 95 completely meet the spirit of [RFC7632] and requirements found in 96 [RFC8248]. 98 This solution gains the most advantage by supporting a variety of 99 collection mechanisms. In this sense, the solution ideally intends 100 to enable a cooperative ecosystem of tools from disparate sources 101 with minimal operator configuration. The solution described in this 102 document seeks to accommodate these recognitions by first defining a 103 generic abstract architecture, then making that solution somewhat 104 more concrete. 106 Keep in mind that, at this point, the draft is tracking ongoing work 107 being performed primarily around and during IETF hackathons. The 108 list of hackathon efforts follows: 110 o [HACK99]: A partial implementation of a vulnerability assessment 111 scenario involving an [I-D.ietf-sacm-ecp] implementation, a 112 [RFC8322] implementation, and a proprietary evaluator to pull the 113 pieces together. 115 o [HACK100]: Work to combine the vulnerability assessment scenario 116 from [HACK99] with an XMPP-based YANG push model. 118 o [HACK101]: A fully automated configuration assessment 119 implementation using XMPP as a communication mechanism. 121 o [HACK102]: An exploration of how we might model assessment, 122 collection, and evaluation abstractly, and then rely on YANG 123 expressions for the attributes of traditional endpoints. 125 1.1. Open Questions 127 [NOTE: This section will eventually be removed.] 129 The following is a list of open questions we still have about the 130 path forward with this exploration: 132 o Should workflows be documented in this draft or separate drafts? 134 o Should interfaces be documented in workflow drafts or separate 135 drafts (or even this draft)? 137 1.2. Requirements notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in RFC 142 2119, BCP 14 [RFC2119]. 144 2. Terms and Definitions 146 This draft defers to [I-D.ietf-sacm-terminology] for terms and 147 definitions. 149 3. Architectural Overview 151 The generic approach proposed herein recognizes the need to obtain 152 information from existing state collection mechanisms, and makes 153 every attempt to respect [RFC7632] and [RFC8248]. At the foundation 154 of any architecture are entities, or components, that need to 155 communicate. They communicate by sharing information, where, in a 156 given flow one or more components are consumers of information and 157 one or more components are providers of information. 159 +--------------------+ 160 | Feeds/Repositories | 161 | of External Data | 162 +--------------------+ 163 | 164 | 165 *****************************v**************** Enterprise Boundary ************ 166 * | * 167 * +--------------+ | +--------------+ * 168 * | Orchestrator | | | Repositories | * 169 * +------^-------+ | +----^---------+ * 170 * | | | +----------------+ * 171 * A | B | C | | Downstream Uses| * 172 * | | | | +-----------+ | * 173 * +------v------------------v----------v------+ | |Evaluations| | * 174 * | Message Transfer System <-------> +-----------+ | * 175 * +----------------------^--------------------+ D | +-----------+ | * 176 * E | | | Analytics | | * 177 * | | +-----------+ | * 178 * +-------------v---------+ | +-----------+ | * 179 * | Collection Subsystems | | | Reporting | | * 180 * +-----------------------+ | +-----------+ | * 181 * +----------------+ * 182 ******************************************************************************* 184 Figure 1: Notional Architecture 186 As shown in Figure 1, the notional SACM architecture consists of some 187 basic SACM Components using a message transfer system to communicate. 188 While not depicted, the message transfer system is expected to 189 maximally align with the requirements described in [RFC8248], which 190 means that the message transfer system will support brokered (i.e. 191 point-to-point) and proxied data exchange. 193 Additionally, component-specific interfaces (i.e. such as A, B, C, D, 194 and E in Figure 1) are expected to be specified logically then bound 195 to one or more specific implementations. This SHOULD be done for 196 each capability related to the given SACM Component. 198 3.1. SACM Roles 200 This document suggests a variety of players in a cooperative 201 ecosystem - we call these players SACM Components. SACM Components 202 may be composed of other SACM Components, and each SACM Component 203 plays one, or more, of several roles relevant to the ecosystem. 204 Generally each role is either a consumer of information or a provider 205 of information. The "Components, Capabilities, Interfaces, and 206 Workflows" section provides more details about SACM Components that 207 play these types of roles. 209 3.2. Exploring An XMPP-based Solution 211 Figure 2 depicts a slightly more detailed view of the architecture 212 (within the enterprise boundary) - one that fosters the development 213 of a pluggable ecosystem of cooperative tools. Existing collection 214 mechanisms can be brought into this architecture by specifying the 215 interface of the collector and creating the XMPP-Grid Connector 216 binding for that interface. 218 Additionally, while not directly depicted in Figure 2, this 219 architecture does allow point-to-point interfaces. In fact, 220 [I-D.ietf-mile-xmpp-grid] provides brokering capabilities to 221 facilitate such point-to-point data transfers). Additionally, each 222 of the SACM Components depicted in Figure 2 may be a provider, a 223 consumer, or both, depending on the workflow in context. 225 +--------------+ +--------------+ 226 | Orchestrator | | Repositories | 227 +------^-------+ +------^-------+ 228 | | 229 | | 230 +-------v--------------------------v--------+ +-----------------+ 231 | XMPP-Grid+ <-----> Downstream Uses | 232 +------------------------^------------------+ +-----------------+ 233 | 234 | 235 +-------v------+ 236 | XMPP-Grid | 237 | Connector(s) | 238 +------^-------+ 239 | 240 +------v-------+ 241 | Collector(s) | 242 +--------------+ 244 Figure 2: XMPP-based Architecture 246 [I-D.ietf-mile-xmpp-grid] details a number of XMPP extensions (XEPs) 247 that MUST be utilized to meet the needs of [RFC7632] and [RFC8248]: 249 o Service Discovery (XEP-0030): Service Discovery allows XMPP 250 entities to discover information about other XMPP entities. Two 251 kinds of information can be discovered: the identity and 252 capabilities of an entity, such as supported features, and items 253 associated with an entity. 255 o Publish-Subscribe (XEP-0060): The PubSub extension enables 256 entities to create nodes (topics) at a PubSub service and publish 257 information at those nodes. Once published, an event notification 258 is broadcast to all entities that have subscribed to that node. 260 At this point, [I-D.ietf-mile-xmpp-grid] specifies fewer features 261 than SACM requires, and there are other XMPP extensions (XEPs) we 262 need to consider to meet the needs of [RFC7632] and [RFC8248]. In 263 Figure 2 we therefore use "XMPP-Grid+" to indicate something more 264 than [I-D.ietf-mile-xmpp-grid] alone, even though we are not yet 265 fully confident in the exact set of XMPP-related extensions we will 266 require. The authors propose work to extend (or modify) 267 [I-D.ietf-mile-xmpp-grid] to include additional XEPs - possibly the 268 following: 270 o Entity Capabilities (XEP-0115): This extension defines the methods 271 for broadcasting and dynamically discovering an entities' 272 capabilities. This information is transported via standard XMPP 273 presence. Example capabilities that could be discovered could 274 include support for posture attribute collection, support for 275 specific types of posture attribute collection such as EPCP, 276 SWIMA, OVAL, or YANG. Other capabilities are still to be 277 determined. 279 o Ad Hoc Commands (XEP-0050): This extension allows an XMPP entity 280 to advertise and execute application-specific commands. Typically 281 the commands contain data forms (XEP-0004) in order to structure 282 the information exchange. This extension may be usable for simple 283 orchestration (i.e. "do assessment"). 285 o HTTP File Upload (XEP-0363): The HTTP File Upload extension allows 286 for large data sets to be published to a specific path on an HTTP 287 server, and receive a URL from which that file can later be 288 downloaded again. XMPP messages and IQs are meant to be compact, 289 and large data sets, such as collected posture attributes, may 290 exceed a message size threshold. Usage of this XEP allows those 291 larger data sets to be persisted, thus necessitating only the 292 download URL to be passed via XMPP messages. 294 o Personal Eventing Protocol (XEP-0163): The Personal Eventing 295 Protocol can be thought of as a virtual PubSub service, allowing 296 an XMPP account to publish events only to their roster instead of 297 a generic PubSub topic. This XEP may be useful in the cases when 298 collection requests or queries are only intended for a subset of 299 endpoints and not an entire subscriber set. 301 o File Repository and Sharing (XEP-0214): This extension defines a 302 method for XMPP entities to designate a set of file available for 303 retrieval by other users of their choosing, and is based on PubSub 304 Collections. 306 o Easy User Onboarding (XEP-401): The goal of this extension is 307 simplified client registration, and may be useful when adding new 308 endpoints or SACM components to the ecosystem. 310 o Bidirectional-streams Over Synchronous HTTP (BOSH) (XEP-0124): 311 BOSH emulates the semantics of a long-lived, bidirectional TCP 312 connection between two entities (aka "long polling"). Consider a 313 SACM component that is updated dynamically, i.e. an internal 314 vulnerability definition repository ingesting data from a Feed/ 315 Repository of External Data, and a second SACM component such as 316 an Orchestrator. Using BOSH, the Orchestrator can effectively 317 continuously poll the vulnerability definition repository for 318 changes/updates. 320 o PubSub Collection Nodes (XEP-0248): Effectively an extension to 321 XEP-0060 (Publish-Subscribe), PubSub Collections aim to simplify 322 an entities' subscription to multiple related topics, and 323 establishes a "node graph" relating parent nodes to its 324 descendents. An example "node graph" could be rooted in a 325 "vulnerability definitions" topic, and contain descendent topics 326 for OS family-level vulnerability definitions (i.e. Windows), and 327 further for OS family version-level definitions (i.e. Windows 10 328 or Windows Server 2016). 330 o PubSub Since (XEP-0312): This extension enables a subscriber to 331 automatically receive PubSub and Personal Eventing Protocol (PEP) 332 notifications since its last logout time. This extension may be 333 useful in intermittent connection scenarios, or when entities 334 disconnect and reconnect to the ecosystem. 336 o PubSub Chaining (XEP-0253): This extension describes the 337 federation of publishing nodes, enabling a publish node of one 338 server to be a subscriber to a publishing node of another server. 340 3.3. Example Architecture using XMPP-Grid and Endpoint Posture 341 Collection Protocol 343 Figure 3 depicts a further detailed view of the architecture 344 including the Endpoint Posture Collection Protocol as the collection 345 subsystem, illustrating the idea of a pluggable ecosystem of 346 cooperative tools. 348 +--------------------+ 349 | Feeds/Repositories | 350 | of External Data | 351 +--------------------+ 352 | 353 ********************v************************* Enterprise Boundary ************ 354 * | * 355 * +--------------+ | +-------------------+ +-------------+ * 356 * | Orchestrator | | | Posture Attr Repo | | Policy Repo | * 357 * +------^-------+ | +---------^---------+ +---^---------+ * 358 * | | | | +----------------+ * 359 * | | | | | Downstream Uses| * 360 * | | | | | +-----------+ | * 361 * +------v---------v-----------v---------------v--+ | |Evaluations| | * 362 * | XMPP-Grid <-------> +-----------+ | * 363 * +----------------^-------------------^----------+ | +-----------+ | * 364 * | | | | Analytics | | * 365 * | | | +-----------+ | * 366 * | +-----v--------+ | +-----------+ | * 367 * | | Results Repo | | | Reporting | | * 368 * | +--------------+ | +-----------+ | * 369 * | +----------------+ * 370 * +---------v-----------+ * 371 * | XMPP-Grid Connector | * 372 * +---------^-----------+ * 373 * | * 374 * +-----------------v-------------------------------------------------------+ * 375 * | | * 376 * | +--Posture Collection Manager------------------------------------------+| * 377 * | |+-----------------------+ +----------------+ +----------------------+ || * 378 * | || Communications Server | | Posture Server | | Posture Validator(s) | || * 379 * | |+----------^------------+ +----------------+ +----------------------+ || * 380 * | +-----------|----------------------------------------------------------+| * 381 * | | | * 382 * | +-----------|-------------------------Endpoint or Endpoint Proxy-------+| * 383 * | |+----------v------------+ +----------------+ +----------------------+ || * 384 * | || Communications Client | | Posture Client | | Posture Collector(s) | || * 385 * | |+-----------------------+ +----------------+ +----------------------+ || * 386 * | +----------------------------------------------------------------------+| * 387 * +-----------------Endpoint Posture Collection Profile---------------------+ * 388 * * 389 ******************************************************************************* 391 Figure 3: XMPP-based Architecture including EPCP 393 4. Components, Capabilities, Interfaces, and Workflows 395 The SACM Architecture consists of a variety of SACM Components, and 396 named components are intended to embody one or more specific 397 capabilities. Interacting with these capabilities will require at 398 least two levels of interface specification. The first is a logical 399 interface specification, and the second is at least one binding to a 400 specific transfer mechanism. An example transfer mechanism is XMPP- 401 Grid+. 403 The following subsections describe some of the components, 404 capabilities, and interfaces we may expect to see participating in a 405 SACM Domain. 407 4.1. Components 409 The following is a list of suggested SACM Component classes and 410 specializations. 412 o Repository 414 * Vulnerability Information Repository 416 * Asset Inventory Repository 418 + Software Inventory Repository 420 + Device Inventory Repository 422 * Configuration Policy Repository 424 * Configuration State Repository 426 o Collector 428 * Vulnerability State Collector 430 * Asset Inventory Collector 432 + Software Inventory Collector 434 + Device Inventory Collector 436 * Configuration State Collector 438 o Evaluator 440 * Vulnerability State Evaluator 441 * Asset Inventory Evaluator 443 + Software Inventory Evaluator 445 + Device Inventory Evaluator 447 * Configuration State Evaluator 449 o Orchestrator 451 * Vulnerability Management Orchestrator 453 * Asset Management Orchestrator 455 + Software Inventory Evaluator 457 + Device Inventory Evaluator 459 * Configuration Management Orchestrator 461 4.2. Capabilities 463 Repositories will have a need for fairly standard CRUD operations and 464 query by attribute operations. Collector interfaces may enable ad 465 hoc assessment (on-demand processing), state item watch actions (i.e. 466 watch a particular item for particular change), persisting other 467 behaviors (i.e. setting some mandatory reporting period). Evaluators 468 may have their own set of interfaces, and an Assessor would represent 469 both Collector and Evaluation interfaces, and may have additional 470 concerns added to an Assessor Interface. 472 Not to be overlooked, whatever solution at which we arrive, per 473 [RFC8248], MUST support capability negotiation. While not explicitly 474 treated here, each interface will understand specific serializations, 475 and other component needs to express those serializations to other 476 components. 478 A capability language is fully explored in mandl-sacm-tool- 479 capability-language (to be submitted). 481 4.3. Interfaces 483 Interfaces should be derived directly from identified workflows, 484 several of which are described in this document. 486 4.4. Workflows 488 The workflows described in this document should be considered as 489 candidate workflows - informational for the purpose of discovering 490 the necessary components and specifying their interfaces. 492 4.4.1. IT Asset Management 494 Information Technology asset management is easier said than done. 495 The [CISCONTROLS] have two controls dealing with IT asset management. 496 Control 1, Inventory and Control of Hardware Assets, states, 497 "Actively manage (inventory, track, and correct) all hardware devices 498 on the network so that only authorized devices are given access, and 499 unauthorized and unmanaged devices are found and prevented from 500 gaining access." Control 2, Inventory and Control of Software 501 Assets, states, "Actively manage (inventory, track, and correct) all 502 software on the network so that only authorized software is installed 503 and can execute, and that unauthorized and unmanaged software is 504 found and prevented from installation or execution." 506 In spirit, this covers all of the processing entities on your network 507 (as opposed to things like network cables, dongles, adapters, etc.), 508 whether physical or virtual. 510 An IT asset management capability needs to be able to: 512 o Identify and catalog new assets by executing Target Endpoint 513 Discovery Tasks 515 o Provide information about its managed assets, including uniquely 516 identifying information (for that enterprise) 518 o Handle software and/or hardware (including virtual assets) 520 o Represent cloud hybrid environments 522 4.4.2. Vulnerability Management 524 Vulnerability management is a relatively established process. 525 According to the [CISCONTROLS], continuous vulnerability management 526 the act of continuously acquiring, assessing, and taking subsequent 527 action on new information in order to identify and remediate 528 vulnerabilities, therefore minimizing the window of opportunity for 529 attackers. 531 4.4.2.1. Vulnerability Assessment Workflow Assumptions 533 A number of assumptions must be stated to clarify the scope of a 534 vulnerability assessment workflow: 536 o The enterprise has received vulnerability description information, 537 and that the information has already been processed into 538 vulnerability detection data that the enterprise's security 539 software tools can understand and use. 541 o The enterprise has a suitable IT Asset Management capability 543 o The enterprise has a means of extracting relevant information 544 about enterprise endpoints in a form that is compatible with the 545 vulnerability description data (appropriate Collectors for their 546 technologies) 548 o All information described in this scenario is available in the 549 vulnerability description data and serves as the basis of 550 assessments. 552 o The enterprise can provide all relevant information about any 553 endpoint needed to perform the described assessment (the 554 appropriate Repositories are available) 556 o The enterprise has a mechanism for long-term storage of 557 vulnerability description information, vulnerability detection 558 data, and vulnerability assessment results. 560 o The enterprise has a procedure for reassessment of endpoints at 561 some point after initial assessment 563 4.4.2.2. Vulnerability Assessment Workflow 565 When new vulnerability description information is received by the 566 enterprise, affected endpoints are identified and assessed. The 567 vulnerability is said to apply to an endpoint if the endpoint 568 satisfies the conditions expressed in the vulnerability detection 569 data. 571 A vulnerability assessment (i.e. vulnerability detection) is 572 performed in two steps: 574 o Endpoint information collected by the endpoint management 575 capabilities is examined by the vulnerability management 576 capabilities through Evaluation Tasks. 578 o If the data possessed by the endpoint management capabilities is 579 insufficient, a Collection Task is triggered and the necessary 580 data is collected from the target endpoint. 582 Vulnerability detection relies on the examination of different 583 endpoint information depending on the nature of a specific 584 vulnerability. Common endpoint information used to detect a 585 vulnerability includes: 587 o A specific software version is installed on the endpoint 589 o File system attributes 591 o Specific state attributes 593 In many cases, the endpoint information needed to determine an 594 endpoint's vulnerability status will have been previously collected 595 by the endpoint management capabilities and available in a 596 Repository. However, in other cases, the necessary endpoint 597 information will not be readily available in a Repository and a 598 Collection Task will be triggered to collect it from the target 599 endpoint. Of course, some implementations of endpoint management 600 capabilities may prefer to enable operators to perform this 601 collection under certain circumstances, even when sufficient 602 information can be provided by the endpoint management capabilities 603 (e.g. there may be freshness requirements for information). 605 The collection of additional endpoint information for the purpose of 606 vulnerability assessment does not necessarily need to be a pull by 607 the vulnerability assessment capabilities. Over time, some new 608 pieces of information that are needed during common types of 609 assessments might be identified. Endpoint management capabilities 610 can be reconfigured to have this information delivered automatically. 611 This avoids the need to trigger additional Collection Tasks to gather 612 this information during assessments, streamlining the assessment 613 process. Likewise, it might be observed that certain information 614 delivered by endpoint management capabilities is rarely used. In 615 this case, it might be useful to re-configure the endpoint management 616 capabilities to no longer collect this information to reduce network 617 and processing overhead. Instead, a new Collection Task can be 618 triggered to gather this data on the rare occasions when it is 619 needed. 621 4.4.3. Configuration Management 623 Configuration management involves configuration assessment, which 624 requires state assessment (TODO: Tie to SACM use cases). The 625 [CISCONTROLS] specify two high-level controls concerning 626 configuration management (Control 5 for non-network devices and 627 Control 11 for network devices). As an aside, these controls are 628 listed separately because many enterprises have different 629 organizations for managing network infrastructure and workload 630 endpoints. Merging the two controls results in a requirement to: 631 "Establish, implement, and actively manage (track, report on, 632 correct) the security configuration of (endpoints) using a rigorous 633 configuration management and change control process in order to 634 prevent attackers from exploiting vulnerable services and settings." 636 Typically, an enterprise will use configuration guidance from a 637 reputable source, and from time to time they may tailor the guidance 638 from that source prior to adopting it as part of their enterprise 639 standard. The enterprise standard is then provided to the 640 appropriate configuration assessment tools and they assess endpoints 641 and/or appropriate endpoint information. A preferred flow follows: 643 o Reputable source publishes new or updated configuration guidance 645 o Enterprise configuration assessment capability retrieves 646 configuration guidance from reputable source 648 o Optional: Configuration guidance is tailored for enterprise- 649 specific needs 651 o Configuration assessment tool queries asset inventory repository 652 to retrieve a list of affected endpoints 654 o Configuration assessment tool queries configuration state 655 repository to evaluate compliance 657 o If information is stale or unavailable, configuration assessment 658 tool triggers an ad hoc assessment 660 The SACM architecture needs to support varying deployment models to 661 accommodate the current state of the industry, but should strongly 662 encourage event-driven approaches to monitoring configuration. 664 5. Privacy Considerations 666 TODO 668 6. Security Considerations 670 TODO 672 7. IANA Considerations 674 IANA tables can probably be used to make life a little easier. We 675 would like a place to enumerate: 677 o Capability/operation semantics 679 o SACM Component implementation identifiers 681 o SACM Component versions 683 o Associations of SACM Components (and versions) to specific 684 Capabilities 686 8. References 688 8.1. Normative References 690 [I-D.ietf-mile-xmpp-grid] 691 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 692 "Using XMPP for Security Information Exchange", draft- 693 ietf-mile-xmpp-grid-09 (work in progress), December 2018. 695 [I-D.ietf-sacm-ecp] 696 Haynes, D., Fitzgerald-McKay, J., and L. Lorenzin, 697 "Endpoint Posture Collection Profile", draft-ietf-sacm- 698 ecp-04 (work in progress), February 2019. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, 702 DOI 10.17487/RFC2119, March 1997, 703 . 705 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 706 J. Fitzgerald-McKay, "Software Inventory Message and 707 Attributes (SWIMA) for PA-TNC", RFC 8412, 708 DOI 10.17487/RFC8412, July 2018, 709 . 711 8.2. Informative References 713 [CISCONTROLS] 714 "CIS Controls v7.0", n.d., 715 . 717 [draft-birkholz-sacm-yang-content] 718 Birkholz, H. and N. Cam-Winget, "YANG subscribed 719 notifications via SACM Statements", n.d., 720 . 723 [HACK100] "IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP", 724 n.d., . 727 [HACK101] "IETF 101 Hackathon - Configuration Assessment XMPP", 728 n.d., . 730 [HACK102] "IETF 102 Hackathon - YANG Collection on Traditional 731 Endpoints", n.d., 732 . 734 [HACK99] "IETF 99 Hackathon - Vulnerability Scenario EPCP", n.d., 735 . 738 [I-D.ietf-sacm-terminology] 739 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 740 A. Montville, "Security Automation and Continuous 741 Monitoring (SACM) Terminology", draft-ietf-sacm- 742 terminology-16 (work in progress), December 2018. 744 [NIST800126] 745 Waltermire, D., Quinn, S., Booth, H., Scarfone, K., and D. 746 Prisaca, "SP 800-126 Rev. 3 - The Technical Specification 747 for the Security Content Automation Protocol (SCAP) - SCAP 748 Version 1.3", February 2018, 749 . 752 [NISTIR7694] 753 Halbardier, A., Waltermire, D., and M. Johnson, "NISTIR 754 7694 Specification for Asset Reporting Format 1.1", n.d., 755 . 758 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 759 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 760 October 2007, . 762 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 763 Posture Assessment: Enterprise Use Cases", RFC 7632, 764 DOI 10.17487/RFC7632, September 2015, 765 . 767 [RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and 768 Continuous Monitoring (SACM) Requirements", RFC 8248, 769 DOI 10.17487/RFC8248, September 2017, 770 . 772 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 773 Oriented Lightweight Information Exchange (ROLIE)", 774 RFC 8322, DOI 10.17487/RFC8322, February 2018, 775 . 777 [XMPPEXT] "XMPP Extensions", n.d., . 779 Appendix A. Mapping to RFC8248 781 This section provides a mapping of XMPP and XMPP Extensions to the 782 relevant requirements from [RFC8248]. In the table below, the ID and 783 Name columns provide the ID and Name of the requirement directly out 784 of [RFC8248]. The Supported By column may contain one of several 785 values: 787 o N/A: The requirement is not applicable to this architectural 788 exploration 790 o Architecture: This architecture (possibly assuming some 791 components) should meet the requirement 793 o XMPP: The set of XMPP Core specifications and the collection of 794 applicable extensions, deployment, and operational considerations. 796 o XMPP-Core: The requirement is satisfied by a core XMPP feature 798 o XEP-nnnn: The requirement is satisfied by a numbered XMPP 799 extension (see [XMPPEXT]) 801 o Operational: The requirement is an operational concern or can be 802 addressed by an operational deployment 804 o Implementation: The requirement is an implementation concern 806 If there is no entry in the Supported By column, then there is a gap 807 that must be filled. 809 +----------+----------------------------------------+---------------+ 810 | ID | Name | Supported By | 811 +----------+----------------------------------------+---------------+ 812 | G-001 | Solution Extensibility | XMPP-Core | 813 | | | | 814 | G-002 | Interoperability | XMPP | 815 | | | | 816 | G-003 | Scalability | XMPP | 817 | | | | 818 | G-004 | Versatility | XMPP-Core | 819 | | | | 820 | G-005 | Information Extensibility | XMPP-Core | 821 | | | | 822 | G-006 | Data Protection | Operational | 823 | | | | 824 | G-007 | Data Partitioning | Operational | 825 | | | | 826 | G-008 | Versioning and Backward Compatibility | XEP-0115/0030 | 827 | | | | 828 | G-009 | Information Discovery | XEP-0030 | 829 | | | | 830 | G-010 | Target Endpoint Discovery | XMPP-Core | 831 | | | | 832 | G-011 | Push and Pull Access | XEP-0060/0312 | 833 | | | | 834 | G-012 | SACM Component Interface | N/A | 835 | | | | 836 | G-013 | Endpoint Location and Network Topology | | 837 | | | | 838 | G-014 | Target Endpoint Identity | XMPP-Core | 839 | | | | 840 | G-015 | Data Access Control | | 841 | | | | 842 | ARCH-001 | Component Functions | XMPP | 843 | | | | 844 | ARCH-002 | Scalability | XMPP-Core | 845 | | | | 846 | ARCH-003 | Flexibility | XMPP-Core | 847 | | | | 848 | ARCH-004 | Separation of Data and Management | | 849 | | Functions | | 850 | | | | 851 | ARCH-005 | Topology Flexibility | XMPP-Core | 852 | | | | 853 | ARCH-006 | Capability Negotiation | XEP-0115/0030 | 854 | | | | 855 | ARCH-007 | Role-Based Authorization | XMPP-Core | 856 | | | | 857 | ARCH-008 | Context-Based Authorization | | 858 | | | | 859 | ARCH-009 | Time Synchronization | Operational | 860 | | | | 861 | IM-001 | Extensible Attribute Vocabulary | N/A | 862 | | | | 863 | IM-002 | Posture Data Publication | N/A | 864 | | | | 865 | IM-003 | Data Model Negotiation | N/A | 866 | | | | 867 | IM-004 | Data Model Identification | N/A | 868 | | | | 869 | IM-005 | Data Lifetime Management | N/A | 870 | | | | 871 | IM-006 | Singularity and Modularity | N/A | 872 | | | | 873 | DM-001 | Element Association | N/A | 874 | | | | 875 | DM-002 | Data Model Structure | N/A | 876 | | | | 877 | DM-003 | Search Flexibility | N/A | 878 | | | | 879 | DM-004 | Full vs. Partial Updates | N/A | 880 | | | | 881 | DM-005 | Loose Coupling | N/A | 882 | | | | 883 | DM-006 | Data Cardinality | N/A | 884 | | | | 885 | DM-007 | Data Model Negotiation | N/A | 886 | | | | 887 | DM-008 | Data Origin | N/A | 888 | | | | 889 | DM-009 | Origination Time | N/A | 890 | | | | 891 | DM-010 | Data Generation | N/A | 892 | | | | 893 | DM-011 | Data Source | N/A | 894 | | | | 895 | DM-012 | Data Updates | N/A | 896 | | | | 897 | DM-013 | Multiple Collectors | N/A | 898 | | | | 899 | DM-014 | Attribute Extensibility | N/A | 900 | | | | 901 | DM-015 | Solicited vs. Unsolicited Updates | N/A | 902 | | | | 903 | DM-016 | Transfer Agnostic | N/A | 904 | | | | 905 | OP-001 | Time Synchronization | | 906 | | | | 907 | OP-002 | Collection Abstraction | | 908 | | | | 909 | OP-003 | Collection Composition | | 910 | | | | 911 | OP-004 | Attribute-Based Query | | 912 | | | | 913 | OP-005 | Information-Based Query with Filtering | | 914 | | | | 915 | OP-006 | Operation Scalability | | 916 | | | | 917 | OP-007 | Data Abstraction | | 918 | | | | 919 | OP-008 | Provider Restriction | | 920 | | | | 921 | T-001 | Multiple Transfer Protocol Support | Architecture | 922 | | | | 923 | T-002 | Data Integrity | Operational | 924 | | | | 925 | T-003 | Data Confidentiality | Operational | 926 | | | | 927 | T-004 | Transfer Protection | | 928 | | | | 929 | T-005 | Transfer Reliability | | 930 | | | | 931 | T-006 | Transfer-Layer Requirements | | 932 | | | | 933 | T-007 | Transfer Protocol Adoption | Architecture | 934 +----------+----------------------------------------+---------------+ 936 Appendix B. Example Components 938 B.1. Policy Services 940 Consider a policy server conforming to [RFC8322]. [RFC8322] 941 describes a RESTful way based on the ATOM Publishing Protocol 942 ([RFC5023]) to find specific data collections. While this represents 943 a specific binding (i.e. RESTful API based on [RFC5023]), there is a 944 more abstract way to look at ROLIE. 946 ROLIE provides notional workspaces and collections, and provides the 947 concept of information categories and links. Strictly speaking, 948 these are logical concepts independent of the RESTful binding ROLIE 949 specifies. In other words, ROLIE binds a logical interface (i.e. 950 GET workspace, GET collection, SET entry, and so on) to a specific 951 mechanism (namely an ATOM Publication Protocol extension). 953 It is not inconceivable to believe there could be a different 954 interface mechanism, or a connector, providing these same operations 955 using XMPP-Grid as the transfer mechanism. 957 Even if a [RFC8322] server were external to an organization, there 958 would be a need for a policy source inside the organization as well, 959 and it may be preferred for such a policy source to be connected 960 directly to the ecosystem's communication infrastructure. 962 B.2. Software Inventory 964 The SACM working group has accepted work on the Endpoint Posture 965 Collection Profile [I-D.ietf-sacm-ecp], which describes a collection 966 architecture and may be viewed as a collector coupled with a 967 collection-specific repository. 969 Posture Manager Endpoint 970 Orchestrator +---------------+ +---------------+ 971 +--------+ | | | | 972 | | | +-----------+ | | +-----------+ | 973 | |<---->| | Posture | | | | Posture | | 974 | | pub/ | | Validator | | | | Collector | | 975 | | sub | +-----------+ | | +-----------+ | 976 +--------+ | | | | | | 977 | | | | | | 978 Evaluator Repository | | | | | | 979 +------+ +--------+ | +-----------+ |<-------| +-----------+ | 980 | | | | | | Posture | | report | | Posture | | 981 | | | | | | Collection| | | | Collection| | 982 | |<-----> | |<-----| | Manager | | query | | Engine | | 983 | |request/| | store| +-----------+ |------->| +-----------+ | 984 | |respond | | | | | | 985 | | | | | | | | 986 +------+ +--------+ +---------------+ +---------------+ 988 Figure 4: EPCP Collection Architecture 990 In Figure 4, any of the communications between the Posture Manager 991 and EPCP components to its left could be performed directly or 992 indirectly using a given message transfer mechanism. For example, 993 the pub/sub interface between the Orchestrator and the Posture 994 Manager could be using a proprietary method or using 995 [I-D.ietf-mile-xmpp-grid] or some other pub/sub mechanism. 996 Similarly, the store connection from the Posture Manager to the 997 Repository could be performed internally to a given implementation, 998 via a RESTful API invocation over HTTPS, or even over a pub/sub 999 mechanism. 1001 Our assertion is that the Evaluator, Repository, Orchestrator, and 1002 Posture Manager all have the potential to represent SACM Components 1003 with specific capability interfaces that can be logically specified, 1004 then bound to one or more specific transfer mechanisms (i.e. RESTful 1005 API, [RFC8322], [I-D.ietf-mile-xmpp-grid], and so on). 1007 B.3. Datastream Collection 1009 [NIST800126], also known as SCAP 1.3, provides the technical 1010 specifications for a "datastream collection". The specification 1011 describes the "datastream collection" as being "composed of SCAP data 1012 streams and SCAP source components". A "datastream" provides an 1013 encapsulation of the SCAP source components required to, for example, 1014 perform configuration assessment on a given endpoint. These source 1015 components include XCCDF checklists, OVAL Definitions, and CPE 1016 Dictionary information. A single "datastream collection" may 1017 encapsulate multiple "datastreams", and reference any number of SCAP 1018 components. Datastream collections were intended to provide an 1019 envelope enabling transfer of SCAP data more easily. 1021 The [NIST800126] specification also defines the "SCAP result data 1022 stream" as being conformant to the Asset Reporting Format 1023 specification, defined in [NISTIR7694]. The Asset Reporting Format 1024 provides an encapsulation of the SCAP source components, Asset 1025 Information, and SCAP result components, such as system 1026 characteristics and state evaluation results. 1028 What [NIST800126]did not do is specify the interface for finding or 1029 acquiring source datastream information, nor an interface for 1030 publishing result information. Discovering the actual resources for 1031 this information could be done via ROLIE, as described in the Policy 1032 Services section above, but other repositories of SCAP data exist as 1033 well. 1035 B.4. Network Configuration Collection 1037 [draft-birkholz-sacm-yang-content] illustrates a SACM Component 1038 incorporating a YANG Push client function and an XMPP-grid publisher 1039 function. [draft-birkholz-sacm-yang-content] further states "the 1040 output of the YANG Push client function is encapsulated in a SACM 1041 Content Element envelope, which is again encapsulated in a SACM 1042 statement envelope" which are published, essentially, via an XMPP- 1043 Grid Connector for SACM Components also part of the XMPP-Grid. 1045 This is a specific example of an existing collection mechanism being 1046 adapted to the XMPP-Grid message transfer system. 1048 Authors' Addresses 1050 Adam W. Montville 1051 Center for Internet Security 1052 31 Tech Valley Drive 1053 East Greenbush, NY 12061 1054 USA 1056 Email: adam.w.montville@gmail.com 1058 Bill Munyan 1059 Center for Internet Security 1060 31 Tech Valley Drive 1061 East Greenbush, NY 12061 1062 USA 1064 Email: bill.munyan.ietf@gmail.com