idnits 2.17.00 (12 Aug 2021) /tmp/idnits30556/draft-ietf-sacm-architecture-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2015) is 2402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3444' is defined on line 855, but no explicit reference was found in the text == Outdated reference: draft-ietf-sacm-requirements has been published as RFC 8248 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-07 == Outdated reference: draft-ietf-sacm-use-cases has been published as RFC 7632 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM N. Cam-Winget, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Lorenzin 5 Expires: April 18, 2016 Pulse Secure 6 I. McDonald 7 High North Inc 8 A. Woland 9 Cisco Systems 10 October 16, 2015 12 Secure Automation and Continuous Monitoring (SACM) Architecture 13 draft-ietf-sacm-architecture-05 15 Abstract 17 This document defines an architecture for standardization of 18 interfaces, protocols, and information models related to security 19 automation and continuous monitoring. It describes the basic 20 architecture, components, and interfaces defined to enable the 21 collection, acquisition, and verification of Posture and Posture 22 Assessments. 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 http://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 April 18, 2016. 41 Copyright Notice 43 Copyright (c) 2015 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 (http://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. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 62 3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 5 63 3.1.1. Provider . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.2. Consumer . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1.3. Types of Providers and Consumers . . . . . . . . . . 8 66 3.1.3.1. Collector . . . . . . . . . . . . . . . . . . . . 8 67 3.1.3.2. Evaluator . . . . . . . . . . . . . . . . . . . . 9 68 3.1.3.3. Report Generator . . . . . . . . . . . . . . . . 9 69 3.1.3.4. Data Store . . . . . . . . . . . . . . . . . . . 9 70 3.1.4. Controller . . . . . . . . . . . . . . . . . . . . . 9 71 4. Interfaces between Consumers, Providers, and Controllers . . 11 72 5. Component Functions . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. Control Plane Functions . . . . . . . . . . . . . . . . . 12 74 5.2. Data Plane Functions . . . . . . . . . . . . . . . . . . 14 75 6. Component Capabilities . . . . . . . . . . . . . . . . . . . 15 76 7. Example Illustration of Functions and Workflow . . . . . . . 15 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 82 11.2. Informative References . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 Several data models and protocols (including - but not limited to - 88 NEA, TCG TNC, SCAP, SWIDs, XMPP, etc.) are in use today that allow 89 different applications to perform the collection, acquisition, and 90 assessment of posture. These applications can vary from being 91 focused on general system and security management to specialized 92 configuration, compliance, and control systems. With an existing 93 varied set of applications, there is a strong desire to standardize 94 data models, protocols, and interfaces to better allow for the 95 automation of such data processes. 97 This document addresses general and architectural requirements 98 defined in [I-D.ietf-sacm-requirements]. The architecture described 99 enables standardized collection, acquisition, and verification of 100 Posture and Posture Assessments. This architecture includes the 101 components and interfaces that can be used to better identify the 102 Information Model and type(s) of transport protocols needed for 103 communication. 105 This document uses terminology defined in 106 [I-D.ietf-sacm-terminology]. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 When the words appear in lower case, their natural language meaning 115 is used. 117 2. Problem Statement 119 Securing information and the systems that store, process, and 120 transmit that information is a challenging task for organizations of 121 all sizes, and many security practitioners spend much of their time 122 on manual processes. Administrators can't get technology from 123 disparate sources to work together; they need information to make 124 decisions, but the information is not available. Everyone is 125 collecting the same data, but storing it as different information. 126 Administrators therefore need to collect data and craft their own 127 information, which may not be accurate or interoperable because it's 128 customized by each administrator, not shared. 130 Security automation and continuous monitoring require a large and 131 broad set of mission and business processes; to make the most 132 effective use of technology, the same data must support multiple 133 processes. The need for complex characterization and assessment 134 necessitates components and functions that interoperate and can build 135 off each other to enable far-ranging and/or deep-diving analysis. 136 SACM is standardizing an information model, data models, operations, 137 and transports that will allow for administrators to share with 138 others and to use data from others interoperably. 140 3. Architectural Overview 142 At a high level, the SACM architecture describes "Where" and "How" 143 information and assessment of posture may be collected, processed 144 (e.g. normalization, translation, aggregation, etc.), assessed, 145 exchanged, and/or stored. This section provides an architectural 146 overview of 148 o the basic architectural building blocks, which - in combination - 149 constitute SACM components (the entities, the "where"), and 151 o the relationships and interaction between these building blocks on 152 the data plane and control plane (communications and flows between 153 entities, the "how"). 155 The SACM architecture provides the basic means to describe and 156 compose SACM components. Components enable the basic functionality 157 in SACM, such as Endpoint Attribute Collection or Target Endpoint 158 Posture Assessment. 160 The role(s) a component plays in the SACM architecture are determined 161 by the function(s) that component instantiates. Three main component 162 roles are defined: a Consumer (Cs), a Provider (Pr), and a Controller 163 (Cr) used to facilitate some of the security functions such as 164 authentication and authorization and other metadata functions. See 165 Section 3.1 for details on roles. 167 In SACM, components are composed of functions, the modular building 168 blocks in the SACM architecture. The SACM architecture defines the 169 purpose of these functions. Attributes and operations used by 170 component functions are described in other SACM documents. See 171 Section 5 for details on component functions. 173 Functions use SACM interfaces for communications between components. 174 Interfaces handle management and control functions (such as 175 authentication, authorization, registration, and discovery), and 176 enable SACM components to share information (via publication, query, 177 and subscription). Three primary interfaces are defined: an 178 interface for management and control (A), an interface for data 179 communication between the controller and providers or consumers (B), 180 and an interface for data communication directly between a provider 181 and a consumer (C). See Section 4 for details on interfaces. 183 Figure 1 illustrates the relationships between component roles and 184 interfaces: 186 +--------------------------------------+ 187 | +--------------------------------------+ 188 | | +--------------------------------------+ 189 | | | | 190 +-| | Consumer (Cs) | 191 +-| | 192 +--------------------------------------+ 193 / \ / \ / \ 194 / \ / \ / \ 195 - - - d - - - 196 || ||A | a |B | |C 197 || || | t | | | 198 - - - a - | | 199 \ / \ / | | 200 \ / \ / | | 201 /|---------------------|\ | | 202 /|----/ \--------| d |--|\ 203 / / Controller (Cr) \ ctrl | a | \ 204 \ \ / plane | t | / 205 \|----\ /--------| a |--|/ 206 \|---------------------|/ | | 207 / \ / \ | | 208 / \ / \ | | 209 - - - d - | | 210 || ||A | a |B | |C 211 || || | t | | | 212 - - - a - - - 213 \ / \ / \ / 214 \ / \ / \ / 215 +------------------------------------+ 216 | |-+ 217 | Provider (Pr | | 218 | | |-+ 219 +------------------------------------+ | | 220 +------------------------------------+ | 221 +------------------------------------+ 223 Figure 1: Simple Architectural Model 225 3.1. Component Roles 227 An endpoint, as defined in [I-D.ietf-sacm-terminology], can operate 228 in two primary ways: as the target of an assessment, and/or as a 229 functional component of the SACM architecture that can instantiate 230 one or more functions (see Section 5). In the SACM architecture, 231 individual endpoints may be a target endpoint, a component, or both 232 simultaneously. An endpoint acting as a component may perform one or 233 more roles. Components can take on the role(s) of Provider, 234 Consumer, and/or Controller. 236 3.1.1. Provider 238 The Provider (Pr) is the component that contributes Posture 239 Assessment Information and/or Guidance either spontaneously or in 240 response to a request. A Provider can be a Posture Evaluator, 241 Posture Collector, Data Store (see Section 3.1.3), or an application 242 that has aggregated Posture Assessment Information that can be 243 shared. 245 The Provider implements the capabilities and functions that must be 246 handled to share or provide Posture Assessment information. 248 One means by which a Provider shares information, is in response to a 249 direct request from a Consumer. 251 A Provider may also share information spontaneously. Use cases such 252 as the change in a posture state require that a Provider be able to 253 provide such changes or updates especially to Consumers such as 254 Security Information and Event Management (SIEM) systems; similarly, 255 SIEM applications that are providing live information require any 256 such updates or changes to posture information to be provided 257 spontaneously. Authorization for the enabling for these unsolicited 258 messages happens through the Controller at the time that both 259 Provider and Consumers request authorization for (spontaneous) 260 messages. 262 The information provided, may be filtered or truncated to provide a 263 subset of the requested information to honor the request. This 264 truncation may be performed based on the Consumer's request and/or 265 the Provider's ability to filter. The latter case may be due to 266 security considerations (e.g. authorization restrictions due to 267 domain segregation, privacy, etc.). 269 The Provider may only be able to share the Posture Assessment 270 Information using a specific data model and protocol. It may use a 271 standard data model and/or protocol, a non-standard data model and/or 272 protocol, or any combination of standard and non-standard data models 273 and protocols. However, it must support either one or more standard 274 data models, or one or more standard protocols. It may also choose 275 to advertise its capabilities through a metadata abstraction within 276 the data model itself, or through the use of the registration 277 function of the Controller (see Section 3.1.4). 279 The Provider must be authorized to provide the Posture Assessment 280 Information for specific consumers. 282 3.1.2. Consumer 284 The Consumer (Cs) is the component that requests or accepts Posture 285 Assessment Information and/or Guidance. A Consumer can be a Posture 286 Evaluator, Report Generator, Data Store (see Section 5.2), or an 287 application that consumes Posture Assessment Information in order to 288 perform another function. 290 As described in Section 2.2 of the SACM Use Cases 291 [I-D.ietf-sacm-use-cases], several usage scenarios are posed with 292 different application types requesting posture assessment 293 information. Whether it is a configuration verification system; a 294 checklist verification system; or a system for detecting posture 295 deviations, compliance or vulnerabilities, they all need to acquire 296 information about Posture Assessment. The architectural component 297 performing such requests is a Consumer. 299 The Consumer implements the capabilities and functions that must be 300 handled in order to enable a Posture Assessment Information Request. 301 Requests can be either for a single posture attribute or a set of 302 posture attributes; those attributes can be the raw information, or 303 an evaluation result based upon that information. The Consumer may 304 further choose to query for the information directly (one-time 305 query), or to request for updates to be provided as the Posture 306 Assessment Information changes (subscription). A request could be 307 made directly to an explicitly identified Provider, but a Consumer 308 may also desire to obtain the information without having to know the 309 available Providers. 311 There may be instances where a Consumer may be requesting information 312 from various Providers and, due to its policy or application 313 requirements, may need to be better informed of the Providers and 314 their capabilities. In those use cases, a Consumer may also request 315 to discover the respective capabilities of those Providers using the 316 discovery function of the Controller (see Section 3.1.4) or may 317 request metadata reflecting the capabilities of the Providers. 319 The Controller (described below) must authorize a Consumer to acquire 320 the information it is requesting. The Consumer may also be subject 321 to limits or constraints on the numbers, types, sizes, and rate of 322 requests. 324 3.1.3. Types of Providers and Consumers 326 SACM Providers and Consumers can perform a variety of SACM-related 327 tasks. For example, a Collector can perform Collection tasks; an 328 Evaluator can perform Evaluation tasks. A single Provider or 329 Consumer may be able to perform only one task, or multiple tasks. 330 SACM defines the following types of Providers/Consumers: 332 3.1.3.1. Collector 334 A collector consumes Guidance and/or other Posture Assessment 335 Information; it provides Posture Assessment Information. Collectors 336 may be internal or external. As a SACM component, a Collector may be 337 a Consumer as it may consume guidance information and may also be a 338 Provider as it may publish the collected information. 340 3.1.3.1.1. Internal Collector 342 An internal collector is a collector that runs on the endpoint and 343 collects posture information locally. 345 3.1.3.1.2. External Collector 347 An external collector is a collector that observes endpoints from 348 outside. These collectors may be configured and operated to manage 349 assets for reasons including, but not limited to, posture assessment. 350 Collectors that are not primarily intended to support posture 351 assessment (e.g. intrusion detection systems) may still provide 352 information that speaks to endpoint posture (e.g. behavioral 353 information). 355 Examples: 357 o A RADIUS server, which collects information about which endpoints 358 have logged onto the network 360 o A network profiling system, which collects information by 361 discovering and classifying network nodes 363 o A Network Intrusion Detection System (NIDS) sensor, which collects 364 information about endpoint behavior by observing network traffic 366 o A vulnerability scanner, which collects information about endpoint 367 configuration by scanning endpoints 369 o A hypervisor, which collects information about endpoints running 370 as virtual guests in its host environment 372 o A management system that configures and installs software on the 373 endpoint, which collects information based on its provisioning 374 activities 376 3.1.3.1.3. Collector Interactions With Target Endpoints 378 TODO - examples of endpoint interactions with local internal 379 collector (e.g. NEA client), endpoint with remote internal collector 380 (SNMP query), and external collector (sensor) 382 3.1.3.2. Evaluator 384 An evaluator consumes Posture Assessment Information, Evaluation 385 Results, and/or Guidance; it provides Evaluation Results. An 386 evaluator may consume endpoint attribute assertions, previous 387 evaluations of posture attributes, or previous reports of Evaluation 388 Results. 390 TODO: update the terminology doc to reflect this definition 392 Example: a NEA posture validator [RFC5209] 394 3.1.3.3. Report Generator 396 A report generator consumes Posture Assessment Information, 397 Evaluation Results, and/or Guidance; it provides reports. These 398 reports are based on: 400 o Endpoint Attribute Assertions, including Evaluation Results 402 o Other Reports (e.g., a weekly report may be created from daily 403 reports) 405 It may summarize data continually, as the data arrives. It also may 406 summarize data in response to an ad hoc query. 408 3.1.3.4. Data Store 410 A data store consumes any data; it provides any data. 412 3.1.4. Controller 414 The Controller (Cr or Controller) is a component defined to 415 facilitate the overall SACM management and control system functions. 416 This component is responsible for handling the secure communications 417 establishment (such as the authentication and authorization) between 418 Providers and Consumers. In addition, the Controller may also handle 419 how the data may be routed. While the architecture defines the 420 Controller as a single component, implementations may implement this 421 to suit the different deployment and scaling requirements. In 422 particular, for the data handling, SACM defines three types of 423 Controller: 425 Broker: Intermediary negotiating connection between Provider and 426 Consumer. Implements only control plane functions. A Controller 427 acting as a Broker: 429 * Receives a request for information from a Consumer and instructs 430 the Consumer where and how retrieve the requested information. 432 * Receives a publication request from a Provider and instructs the 433 Provider where and how to deliver the published information. 435 * The information itself is neither distributed nor stored by the 436 Controller. 438 Proxy: Intermediary negotiating on behalf of a Consumer or Provider. 439 Implements both control and data plane functions. A Controller 440 acting as a Proxy: 442 * Receives a request for information from a Consumer, retrieves the 443 information from the appropriate Providers, and provides the 444 information to the Consumer. 446 * Receives a publication request from a Provider, accepts the 447 published information, and distributes it to appropriate 448 consumers. 450 * The information itself is distributed by, but not stored by, the 451 Controller. 453 Repository: Intermediary receiving and storing data from a Provider, 454 and providing stored data to a Consumer. Implements both control 455 and data plane functions. A Controller acting as a Repository: 457 * Receives a request for information from a Consumer, retrieves the 458 information from its data stores, and provides the information to 459 the Consumer. 461 * Receives a publication request from a provider, stores the 462 published information, and distributes it to appropriate 463 Consumers. 465 * The information itself is both handled by and stored by the 466 Controller. 468 A single instantiation of a Controller may be a Broker, Proxy, or 469 Repository, or any combination thereof. 471 Through the use of a discovery mechanism, Consumers can have 472 visibility into the Providers present, the type(s) of Posture 473 Assessment Information available, and how it can be requested. 474 Similarly, a Provider may need to publish what Posture Assessment 475 Information it can share and how it can share it (e.g. protocol, 476 filtering capabilities, etc.). Enabling this visibility through a 477 Controller or through metadata publication also allows for the 478 distinct definition of security considerations (e.g. authorized 479 registration / publication of capabilities by Providers) beyond how a 480 Provider may define its own capability. 482 Beyond the control and management functions for the SACM system, a 483 Controller may also provide proxy or broker or repository (and 484 possibly routing) services in the data plane. In the deployment 485 scenario where Providers do not assert the need to know their 486 Consumers and/or vice versa, the Controller can thus provide the 487 appropriate services to ensure the Posture Assessment Information is 488 appropriately communicated from the Providers to the authorized 489 Consumers. 491 The Controller, acting as a management control plane, helps define 492 how to manage an overall SACM system that allows for Consumers to 493 obtain the desired Posture Assessment Information without the need to 494 distinctly know and establish one (Consumer) to many (Provider) 495 connections. Similarly, a Provider may not need to distinctly know 496 and establish one (Provider) to many (Consumer) connections; e.g. the 497 Controller enables the means to allow a SACM system to support many 498 to many connections. Note that the Controller also allows for the 499 direct discovery and connection between a Consumer and Provider. 501 As a SACM component, the Controller may be instantiated within a 502 system or device acting as a Provider or a Consumer (or both), or as 503 its own distinct Controller entity. In a rich SACM environment, it 504 is feasible to instantiate a Controller that provides both the 505 management (and control) functions for SACM as well as providing the 506 data plane services for the actual data, e.g. Posture Assessment 507 Information flow. Note that Controllers may be implemented to only 508 provide control plane functions (broker), or both control plane 509 functions and data plane services (proxy or repository). 511 4. Interfaces between Consumers, Providers, and Controllers 513 A SACM interface is a transport carrying operations (e.g. publication 514 via a RESTful API). As shown in Figure 1, communication can proceed 515 with the following interfaces and expected functions and behaviors: 517 A: interface "A" shown in Figure 1 handles the management and 518 control functions that are needed to establish, at minimum, a secure 519 communication between Consumers and Providers. The interface must 520 also handle the functions to allow for the discovery and 521 registration of the Providers as well as the ways in which Posture 522 Assessment Information can be provided (or requested). 524 B: interface "B" shown in Figure 1 enables Providers to share their 525 Posture Assessment Information spontaneously; similarly, it enables 526 Consumers to request information without having to know the 527 identities (or reachability) of all the Providers that can fulfill 528 Consumers' requests. 530 C: interface "C" shown in Figure 1 illustrates the ability and 531 desire for Consumers and Providers to be able to communicate 532 directly when a Provider is sharing Posture Assessment Information 533 directly to a Consumer. The interface allows for the different data 534 models and protocols to be used between a Consumer and a Provider 535 with the expectation that the appropriate authentication and 536 authorization mechanisms have been employed to establish a secure 537 communication link between the Consumer and the Provider. 538 Typically, it is expected that the secure link establishment occurs 539 as a management or control function through the abstracted 540 Controller role (e.g. the Controller could be a broker or could be 541 embedded in a Consumer or a Provider). 543 A variety of protocols, such as SNMP, NETCONF, NEA protocols 544 [RFC5209], and other similar interfaces, may be used for collection 545 of data from the target endpoints by the Posture Information 546 Provider. Those interfaces are outside the scope of SACM. 548 5. Component Functions 550 SACM components are composed of a variety of functions, which may be 551 instantiated on a single endpoint or on separate standalone endpoints 552 providing various roles. An endpoint MUST implement one or more of 553 these functions to be considered a SACM component. A SACM solution 554 offers a set of functions across a set of SACM components. 556 The functions described here are the minimum set that is mandatory to 557 implement in a SACM solution. A SACM solution MAY implement 558 additional functions. 560 5.1. Control Plane Functions 562 Control plane functions represent various services offered by the 563 Controller to the Providers and Consumers to facilitate sharing of 564 information. Control plane functions include, but are not limited 565 to: 567 Authentication: The authentication of Consumers and Providers 568 independent of the actual information-sharing communication channel. 569 While authentication between peers (e.g. a Consumer and a Provider) 570 can be achieved directly through peer to peer authentication (using 571 TLS for instance), there are use cases where: 573 * Consumers may request information independent of knowing the 574 identities of the Providers. 576 * Providers may want to share the information without prior 577 solicitation. 579 To address the above use cases, the architecture must account for an 580 abstraction where a Controller may be defined to effect the 581 authentication of the Consumers and Providers independent of the 582 actual information-sharing communication channel. Consumers and 583 Providers that consume or publish information without requiring 584 knowledge of the Providers and Consumers respectively would function 585 in a SACM system where the Controller is a distinct entity. As a 586 distinct SACM component, the Controller would authenticate Providers 587 and Consumers. 589 Authorization: The restriction of Posture Assessment Information 590 sharing between the Consumers and Providers. At minimum, a 591 management function must define the necessary policies to control 592 what Providers can publish and Consumers to accept. The Controller 593 is the authority for the type of Posture Information that a Provider 594 can publish and a Consumer can accept. If a Controller is a Broker, 595 then it may only grant authorization to the capabilities requested 596 by the Provider or Consumer. When acting as a Proxy, as part of its 597 authorization, the Controller may further obscure or block 598 information being shared by a Provider as it distributes it to a 599 Consumer. Similarly, a Repository may block information as recieved 600 by the Provider and pass to the Consumer and to its storage the 601 resulting authorized information. A Provider may also enforce its 602 own authorization based upon its connection to a Controller; though, 603 in the case where an application includes both the Provider and 604 Controller roles, it can choose to implement all authorization on 605 the Controller. Similarly, a Consumer may enforce its own 606 authorization of what data it can receive based on the Controller 607 (or Provider) it is communicaticating with; in the case where an 608 application includes both the Consumer and Controller roles, it can 609 choose to implement all the authorization on the Controller. 611 Identity Management: Since Identity Management for authentication 612 and authorization policies is best performed via a centralized 613 component, the Controller also facilitates this function. 615 The Controller needs to be able to identify the endpoints 616 participating as SACM components and the roles that they play. 617 Similar to how access control may be effected via Authentication, 618 Authorization, and Accounting Systems (e.g. AAA services), the 619 same principle is defined; as AAA services depend on Identity 620 Management services, the Controller will need a similar function 621 and interface to Identity Management services. Note that 622 implementations of this function is abstractly centralized, but to 623 address scalability and the need to manage different resources 624 (e.g. users, processes and devices) a distributed system that is 625 centrally coordinated may be used. 627 Registration/Discovery: A SACM ecosystem needs to provide the 628 ability for devices to discover Providers, Consumers, Controllers 629 and their respective capabilities. For a Consumer to be able to 630 obtain the information of interest must either configure itself to 631 know what Providers to communicate with directly (and their known 632 capabilities, such as the supported data model and information 633 provided) or can dynamically discover the information that is 634 available. Similarly, Providers may need to either be configured to 635 know who to publish the information to, or can dynamically discover 636 its Consumers. 638 In the case where there is a Controller, the capabilities of the 639 Controller must also be advertised so that Providers and Consumers 640 may know how the data is being handled as well (e.g. if acting as a 641 Broker or Repository). The Controller also provides the function of 642 registering the Providers and Consumers; the registration function 643 enables the Controller to also affect the authorization afforded to 644 the Provider or Consumer. 646 5.2. Data Plane Functions 648 There are three basic functions to facilitate data flow: 650 Subscription: A Consumer that wants to recieve information from a 651 specific Provider or from the Controller advertising the 652 availability of specific information (that may come from more than 653 one Provider) will effectively subscribe to recieve the information 654 spontaneously and continuously as new information as subscribed to 655 becomes available. 657 Publication A Provider being registered through the Controller to 658 provide specific information, may publish the information either 659 directly to the Consumers or to the Controller that is acting as the 660 broker or respository. 662 Query/Response A Consumer may contact the Provider directly and 663 request the information through a query operation; and in response, 664 the Provider would send the information directly to the Consumer. 666 6. Component Capabilities 668 TODO: add a discussion of "capability" as being able to talk a 669 specific data model, data operations, or SACM transport 671 TODO: data plane capabilities / control plane capabilities can be 672 discovered via querying the controller 674 7. Example Illustration of Functions and Workflow 676 TODO: once the group reaches consensus on content for the previous 677 sections, revise all this text based upon the agreed-upon 678 architecture 680 +-------------------------------+ 681 | +-------------------------------+ 682 | | | 683 +-| Controller (Cr) | 684 +-------------------------------+ 685 // / \ \\ 686 // / \ \\ 687 A // / \ \\ A 688 // / \ \\ 689 // / B B \ \\ 690 // / \ \\ 691 +------------------------+ +------------------------+ 692 | +----------------------+ A | +------------------------+ 693 | | |===========| | | 694 | | Consumer (C) |-----------| | Provider (P) | 695 +-| | C +-| | 696 +---------------------+ +------------------------+ 698 Figure 2: Communications Model 700 SACM's focus is on the automation of collection, verification and 701 update of system security configurations pertaining to endpoint 702 assessment. In order to carry out these tasks, the architectural 703 components shown in Figure 1 can be further refined as: 705 Providers: a Provider may be dedicated to perform either the 706 collection, aggregation or evaluation of one or more posture 707 attributes whose results can be conveyed to a Consumer. In this 708 example form of the SACM architecture model, these are shown as 709 Collection, Evaluation, and Results Providers. Note that there may 710 be posture attributes or posture assessment information that 711 articulates Guidance information which may or may not be present in 712 the architecture. 714 Consumers: a Consumer may request or receive one or more posture 715 attributes or posture assessment information from a Provider for 716 their own use. In this example form of the SACM architecture model, 717 these are shown as Collection, Evaluation, and Results Consumers. 718 Note that there may be posture attributes or posture assessment 719 information articulating Guidance information which may or may not 720 be present in the architecture to be provided or consumed. 722 Data Stores: a Data Store is both a Provider and a Consumer, storing 723 one or more posture attributes or assessments for endpoints. It 724 should be understood that these repositories interface directly to a 725 Provider or Consumer (and Guidance) but the interfaces used to 726 interact between them is outside the scope of SACM (e.g. no 727 interface arrows are shown in the architecture). 729 Figure 3 illustrates an example flow for how Posture Assessment 730 Information may flow. 732 +-------------+ 733 |Evaluation | 734 +-------------+ |Guidance +--+ 735 |Endpoint | |Function | | 736 +-------+ | +-------------+ | 737 | | | | 738 | +-------+-----+ +-----v-------+ 739 | Collection | |Evaluation | 740 +-> Function +--+--------+ |Function | 741 | | |Collection | +-----------+ +----------+ 742 | +------------+Provider | | |---| | 743 | | | |Collection | |Evaluation| 744 | | | |Consumer | |Provider | 745 | +----+------+ +----^------+ +---+------+ 746 ++---------+ | | | 747 |Collection| +-----v------+ +---+--------+ | 748 |Guidance | | | |Collection | | 749 |Function | |Collection | |Provider | | 750 | | |Consumer |-----| | | 751 +----------+ +------------+ +------------+ | 752 | Collection | | 753 | Data Store | | 754 +------------+ | 755 | 756 +--------------+ +---------------+ | 757 |Evaluation | |Evaluation | | 758 |Results | |Consumer <-----+ 759 |Provider |-----------| | 760 +-----+--------+ +---------------+ 761 | |Results Reporting| 762 | |Function | 763 | +------------^----+ 764 | | 765 +-----v--------+ +----+------+ 766 |Evaluation | |Reporting | 767 |Results | |Guidance | 768 |Consumer | |Data Store | 769 +---+----------+ +-----------+ +-------------+ 770 | | Results | 771 +-----------------------------> Data Store | 772 | | 773 +-------------+ 775 Figure 3: Example Posture Information Flow 777 TODO - add example of / more content around interactions with 778 endpoint, possible communications patterns 780 8. Acknowledgements 782 The authors would like to thank Jim Bieda, Henk Birkholz, Jessica 783 Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David 784 Waltermire for participating in architecture design discussions, 785 reviewing, and contributing to this draft. 787 9. IANA Considerations 789 This memo includes no request to IANA. 791 10. Security Considerations 793 The SACM architecture defines three main components that interface 794 with each other both for management and control (in the control 795 plane) and for the sharing of Posture Assessment Information. 796 Considerations for transitivity of trust between a Provider and 797 Consumer can be made if there is a well understood trust between the 798 Provider and the Controller and between the Consumer and Controller. 799 The trust must include strong mutual authentication, at minimum, 800 between the Provider and Controller and between the Consumer and 801 Controller. 803 To address potential Man-in-the-Middle (MitM) attacks, it is also 804 strongly recommended that the communications be secured to include 805 replay protection and message integrity (e.g. transport integrity and 806 if required, data integrity). Similarly, to avoid potential message 807 disclosure (e.g. where privacy may be needed), confidentiality should 808 also be provided. 810 As the Controller provides the security functions for the SACM 811 system, the Controller should provide strong authorizations based on 812 either or both business and regulatory policies to ensure that only 813 authorized Consumers and obtaining Posture Assessment Information 814 from authorized Providers. It is presumed that once authenticated 815 and authorized, the Provider, Controller or Consumer is deemed 816 trustworthy; though note that it is possible that the modules or 817 devices hosting the SACM components may be compromised as well (e.g. 818 due to malware or tampering); however, addressing that level of 819 trustworthiness is out of scope for SACM. 821 As the data models defined through the interfaces are transport 822 agnostic, the Posture Assessment Information data in the interfaces 823 may leverage the transport security properties as the interfaces are 824 transported between the Provider, Consumer and Controller. However, 825 there may be other devices, modules or components in the path between 826 the Provider, Consumer and Controller that may observe the interfaces 827 flowing through them. 829 11. References 831 11.1. Normative References 833 [I-D.ietf-sacm-requirements] 834 Cam-Winget, N. and L. Lorenzin, "Secure Automation and 835 Continuous Monitoring (SACM) Requirements", draft-ietf- 836 sacm-requirements-08 (work in progress), July 2015. 838 [I-D.ietf-sacm-terminology] 839 Birkholz, H., "Secure Automation and Continuous Monitoring 840 (SACM) Terminology", draft-ietf-sacm-terminology-07 (work 841 in progress), July 2015. 843 [I-D.ietf-sacm-use-cases] 844 Waltermire, D. and D. Harrington, "Endpoint Security 845 Posture Assessment - Enterprise Use Cases", draft-ietf- 846 sacm-use-cases-10 (work in progress), July 2015. 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, 850 DOI 10.17487/RFC2119, March 1997, 851 . 853 11.2. Informative References 855 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 856 Information Models and Data Models", RFC 3444, 857 DOI 10.17487/RFC3444, January 2003, 858 . 860 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 861 Tardo, "Network Endpoint Assessment (NEA): Overview and 862 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 863 . 865 Authors' Addresses 866 Nancy Cam-Winget (editor) 867 Cisco Systems 868 3550 Cisco Way 869 San Jose, CA 95134 870 US 872 Email: ncamwing@cisco.com 874 Lisa Lorenzin 875 Pulse Secure 876 2700 Zanker Rd, Suite 200 877 San Jose, CA 95134 878 US 880 Email: llorenzin@pulsesecure.net 882 Ira E McDonald 883 High North Inc 884 PO Box 221 885 Grand Marais, MI 49839 886 US 888 Email: blueroofmusic@gmail.com 890 Aaron Woland 891 Cisco Systems 892 1900 South Blvd. Suite 200 893 Charlotte, NC 28203 894 US 896 Email: loxx@cisco.com