idnits 2.17.1 draft-ietf-sacm-architecture-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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 23, 2015) is 3193 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'RFC3444' is defined on line 768, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-sacm-requirements-08 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-07 Summary: 0 errors (**), 0 flaws (~~), 6 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: January 24, 2016 Pulse Secure 6 I. McDonald 7 High North Inc 8 A. Woland 9 Cisco Systems 10 July 23, 2015 12 Secure Automation and Continuous Monitoring (SACM) Architecture 13 draft-ietf-sacm-architecture-04 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 January 24, 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 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 61 3.1. Component Roles . . . . . . . . . . . . . . . . . . . . . 5 62 3.1.1. Provider . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1.2. Consumer . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.3. Types of Providers and Controllers . . . . . . . . . 7 65 3.1.3.1. Collector . . . . . . . . . . . . . . . . . . . . 7 66 3.1.3.2. Evaluator . . . . . . . . . . . . . . . . . . . . 8 67 3.1.3.3. Report Generator . . . . . . . . . . . . . . . . 9 68 3.1.3.4. Data Store . . . . . . . . . . . . . . . . . . . 9 69 3.1.4. Controller . . . . . . . . . . . . . . . . . . . . . 9 70 4. Interfaces between Consumers, Providers, and Controllers . . 11 71 5. Component Functions . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. Control Plane Functions . . . . . . . . . . . . . . . . . 12 73 5.2. Data Plane Functions . . . . . . . . . . . . . . . . . . 13 74 6. Component Capabilities . . . . . . . . . . . . . . . . . . . 13 75 7. Example Illustration of Functions and Workflow . . . . . . . 13 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 11.2. Informative References . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 Several data models and protocols (including - but not limited to - 87 NEA, TCG TNC, SCAP, SWIDs, XMPP, etc.) are in use today that allow 88 different applications to perform the collection, acquisition, and 89 assessment of posture. These applications can vary from being 90 focused on general system and security management to specialized 91 configuration, compliance, and control systems. With an existing 92 varied set of applications, there is a strong desire to standardize 93 data models, protocols, and interfaces to better allow for the 94 automation of such data processes. 96 This document addresses general and architectural requirements 97 defined in [I-D.ietf-sacm-requirements]. The architecture described 98 enables standardized collection, acquisition, and verification of 99 Posture and Posture Assessments. This architecture includes the 100 components and interfaces that can be used to better identify the 101 Information Model and type(s) of transport protocols needed for 102 communication. 104 This document uses terminology defined in 105 [I-D.ietf-sacm-terminology]. 107 2. Problem Statement 109 Securing information and the systems that store, process, and 110 transmit that information is a challenging task for organizations of 111 all sizes, and many security practitioners spend much of their time 112 on manual processes. Administrators can't get technology from 113 disparate sources to work together; they need information to make 114 decisions, but the information is not available. Everyone is 115 collecting the same data, but storing it as different information. 116 Administrators therefore need to collect data and craft their own 117 information, which may not be accurate or interoperable because it's 118 customized by each administrator, not shared. 120 Security automation and continuous monitoring require a large and 121 broad set of mission and business processes; to make the most 122 effective of use of technology, the same data must support multiple 123 processes. The need for complex characterization and assessment 124 necessitates components and functions that interoperate and can build 125 off each other to enable far-ranging and/or deep-diving analysis. 126 SACM is standardizing an information model, data models, operations, 127 and transports that will allow for administrators to share with 128 others and to use data from others interoperably. 130 3. Architectural Overview 132 At a high level, the SACM architecture describes "Where" and "How" 133 information and assessment of posture may be collected, processed 134 (e.g. normalization, translation, aggregation, etc.), assessed, 135 exchanged, and/or stored. This section provides an architectural 136 overview of 1.) the basic architectural building blocks, which - in 137 combination - constitute SACM components (the entities, the "where"), 138 and 2.) the relationships and interaction between these building 139 blocks on the data plane and control plane (communications and flows 140 between entities, the "how"). 142 The SACM architecture provides the basic means to describe and 143 compose SACM components. Components enable the basic functionality 144 in SACM, such as Endpoint Attribute Collection or Target Endpoint 145 Posture Assessment. 147 The role(s) a component plays in the SACM architecture are determined 148 by the function(s) that component instantiates. Three main component 149 roles are defined: a Consumer (C), a Provider (P), and a Controller 150 (Cr) used to facilitate some of the security functions such as 151 authentication and authorization and other metadata functions. See 152 Section 3.1 for details on roles. 154 In SACM, components are composed of functions, the modular building 155 blocks in the SACM architecture. The SACM architecture defines the 156 purpose of these functions. Attributes and operations used by 157 component functions are described in other SACM documents. See 158 Section 5 for details on component functions. 160 Functions use SACM interfaces for communications between components. 161 Interfaces handle management and control functions (such as 162 authentication, authorization, registration, and discovery), and 163 enable SACM components to share information (via publication, query, 164 and subscription). Three primary interfaces are defined: an 165 interface for management and control (A), an interface for data 166 communication between the controller and providers or consumers (B), 167 and an interface for data communication directly between a provider 168 and a consumer (C). See Section 4 for details on interfaces. 170 Figure 1 illustrates the relationships between component roles and 171 interfaces: 173 +--------------------------------------+ 174 | +--------------------------------------+ 175 | | +--------------------------------------+ 176 | | | | 177 +-| | Consumer (C) | 178 +-| | 179 +--------------------------------------+ 180 / \ / \ / \ 181 / \ / \ / \ 182 - - - d - - - 183 || ||A | a |B | |C 184 || || | t | | | 185 - - - a - | | 186 \ / \ / | | 187 \ / \ / | | 188 /|---------------------|\ | | 189 /|----/ \--------| d |--|\ 190 / / Controller (Cr) \ ctrl | a | \ 191 \ \ / plane | t | / 192 \|----\ /--------| a |--|/ 193 \|---------------------|/ | | 194 / \ / \ | | 195 / \ / \ | | 196 - - - d - | | 197 || ||A | a |B | |C 198 || || | t | | | 199 - - - a - - - 200 \ / \ / \ / 201 \ / \ / \ / 202 +------------------------------------+ 203 | |-+ 204 | Provider (P) | | 205 | | |-+ 206 +------------------------------------+ | | 207 +------------------------------------+ | 208 +------------------------------------+ 210 Figure 1: Simple Architectural Model 212 3.1. Component Roles 214 An endpoint, as defined in [I-D.ietf-sacm-terminology], can operate 215 in two primary ways: as the target of an assessment, and/or as a 216 functional component of the SACM architecture that can instantiate 217 one or more functions (see Section 5). In the SACM architecture, 218 individual endpoints may be a target endpoint, a component, or both 219 simultaneously. An endpoint acting as a component may perform one or 220 more roles. Components can take on the role(s) of Provider, 221 Consumer, and/or Controller. 223 3.1.1. Provider 225 The Provider (P or Provider) is the component that contributes 226 Posture Assessment Information and/or Guidance either spontaneously 227 or in response to a request. A Provider can be a Posture Evaluator, 228 Posture Collector, Data Store (see Section 3.1.3), or an application 229 that has aggregated Posture Assessment Information that can be 230 shared. 232 The Provider implements the capabilities and functions that must be 233 handled to share or provide Posture Assessment information. 235 A Provider may provide information spontaneously, or in response to a 236 direct request from a Consumer. The information may be filtered or 237 truncated to provide a subset of the requested information to honor 238 the request. This truncation may be performed based on the 239 Consumer's request and/or the Provider's ability to filter. The 240 latter case may be due to security considerations (e.g. authorization 241 restrictions due to domain segregation, privacy, etc.). 243 The Provider may only be able to share the Posture Assessment 244 Information using a specific data model and protocol. It may use a 245 standard data model and/or protocol, a non-standard data model and/or 246 protocol, or any combination of standard and non-standard data models 247 and protocols. However, it must support either one or more standard 248 data models, or one or more standard protocols. It may also choose 249 to advertise its capabilities through a metadata abstraction within 250 the data model itself, or through the use of the registration 251 function of the Controller (see Section 3.1.4). 253 The Provider must be authorized to provide the Posture Assessment 254 Information and further, be authorized to do so with specific data 255 models and protocols and/or for specific consumers. 257 3.1.2. Consumer 259 The Consumer (C or Consumer) is the component that requests or 260 accepts Posture Assessment Information and/or Guidance. A Consumer 261 can be a Posture Evaluator, Report Generator, Data Store (see 262 Section 5.2), or an application that consumes Posture Assessment 263 Information in order to perform another function. 265 As described in Section 2.2 of the SACM Use Cases 266 [I-D.ietf-sacm-use-cases], several usage scenarios are posed with 267 different application types requesting posture assessment 268 information. Whether it is a configuration verification system; a 269 checklist verification system; or a system for detecting posture 270 deviations, compliance or vulnerabilities, they all need to acquire 271 information about Posture Assessment. The architectural component 272 performing such requests is a Consumer. 274 The Consumer implements the capabilities and functions that must be 275 handled in order to enable a Posture Assessment Information Request. 276 Requests can be either for a single posture attribute or a set of 277 posture attributes; those attributes can be the raw information, or 278 an evaluation result based upon that information. The Consumer may 279 further choose to query for the information directly (one-time 280 query), or to request for updates to be provided as the Posture 281 Assessment Information changes (subscription). A request could be 282 made directly to an explicitly identified Provider, but a Consumer 283 may also desire to obtain the information without having to know the 284 available Providers. 286 There may be instances where a Consumer may be requesting information 287 from various Providers and, due to its policy or application 288 requirements, may need to be better informed of the Providers and 289 their capabilities. In those use cases, a Consumer may also request 290 to discover the respective capabilities of those Providers using the 291 discovery function of the Controller (see Section 3.1.4) or may 292 request metadata reflecting the capabilities of the Providers. 294 The Controller (described below) must authorize a Consumer to acquire 295 the information it is requesting. The Consumer may also be subject 296 to limits or constraints on the numbers, types, sizes, and rate of 297 requests. 299 3.1.3. Types of Providers and Controllers 301 SACM Providers and Consumers can perform a variety of SACM-related 302 tasks. For example, a Collector can perform Collection tasks; an 303 Evaluator can perform Evaluation tasks. A single Provider or 304 Consumer may be able to perform only one task, or multiple tasks. 305 SACM defines the following types of Providers/Consumers: 307 3.1.3.1. Collector 309 A collector consumes Guidance and/or other Posture Assessment 310 Information; it provides Posture Assessment Information. Collectors 311 may be internal or external. 313 3.1.3.1.1. Internal Collector 315 An internal collector is a collector that runs on the endpoint and 316 collects posture information locally. 318 3.1.3.1.2. External Collector 320 An external collector is a collector that observes endpoints from 321 outside. These collectors may be configured and operated to manage 322 assets for reasons including, but not limited to, posture assessment. 323 Collectors that are not primarily intended to support posture 324 assessment (e.g. intrusion detection systems) may still provide 325 information that speaks to endpoint posture (e.g. behavioral 326 information). 328 Examples: 330 o A RADIUS server, which collects information about which endpoints 331 have logged onto the network 333 o A network profiling system, which collects information by 334 discovering and classifying network nodes 336 o A Network Intrusion Detection System (NIDS) sensor, which collects 337 information about endpoint behavior by observing network traffic 339 o A vulnerability scanner, which collects information about endpoint 340 configuration by scanning endpoints 342 o A hypervisor, which collects information about endpoints running 343 as virtual guests in its host environment 345 o A management system that configures and installs software on the 346 endpoint, which collects information based on its provisioning 347 activities 349 3.1.3.1.3. Collector Interactions With Target Endpoints 351 TODO - examples of endpoint interactions with local internal 352 collector (e.g. NEA client), endpoint with remote internal collector 353 (SNMP query), and external collector (sensor) 355 3.1.3.2. Evaluator 357 An evaluator consumes Posture Assessment Information, Evaluation 358 Results, and/or Guidance; it provides Evaluation Results. An 359 evaluator may consume endpoint attribute assertions, previous 360 evaluations of posture attributes, or previous reports of Evaluation 361 Results. 363 TODO: update the terminology doc to reflect this definition 365 Example: a NEA posture validator [RFC5209] 367 3.1.3.3. Report Generator 369 A report generator consumes Posture Assessment Information, 370 Evaluation Results, and/or Guidance; it provides reports. These 371 reports are based on: 373 o Endpoint Attribute Assertions, including Evaluation Results 375 o Other Reports (e.g., a weekly report may be created from daily 376 reports) 378 It may summarize data continually, as the data arrives. It also may 379 summarize data in response to an ad hoc query. 381 3.1.3.4. Data Store 383 A data store consumes any data; it provides any data. 385 3.1.4. Controller 387 The Controller (Cr or Controller) is a component defined to 388 facilitate information sharing and to execute on security functions 389 and overall SACM management and control system functions. SACM 390 defines three types of Controller: 392 Broker: Intermediary negotiating connection between Provider and 393 Consumer. Implements only control plane functions. A Controller 394 acting as a Broker: 396 * Receives a request for information from a Consumer and instructs 397 the Consumer where and how retrieve the requested information. 399 * Receives a publication request from a Provider and instructs the 400 Provider where and how to deliver the published information. 402 The information itself is neither distributed nor stored by the 403 Controller. 405 Proxy: Intermediary negotiating on behalf of a Consumer or Provider. 406 Implements both control and data plane functions. A Controller 407 acting as a Proxy: 409 * Receives a request for information from a Consumer, retrieves the 410 information from the appropriate Providers, and provides the 411 information to the Consumer. 413 * Receives a publication request from a Provider, accepts the 414 published information, and distributes it to appropriate 415 consumers. 417 The information itself is distributed by, but not stored by, the 418 Controller. 420 Repository: Intermediary receiving and storing data from a Provider, 421 and providing stored data to a Consumer. Implements both control 422 and data plane functions. A Controller acting as a Repository: 424 * Receives a request for information from a Consumer, retrieves the 425 information from its data stores, and provides the information to 426 the Consumer. 428 * Receives a publication request from a provider, stores the 429 published information, and distributes it to appropriate 430 Consumers. 432 The information itself is both handled by and stored by the 433 Controller. 435 A single instantiation of a Controller may be a Broker, Proxy, or 436 Repository, or any combination thereof. 438 Through the use of a discovery mechanism, Consumers can have 439 visibility into the Providers present, the type(s) of Posture 440 Assessment Information available, and how it can be requested. 441 Similarly, a Provider may need to publish what Posture Assessment 442 Information it can share and how it can share it (e.g. protocol, 443 filtering capabilities, etc.). Enabling this visibility through a 444 Controller or through metadata publication also allows for the 445 distinct definition of security considerations (e.g. authorized 446 registration / publication of capabilities by Providers) beyond how a 447 Provider may define its own capability. 449 Beyond the control and management functions for the SACM system, a 450 Controller may also provide proxy or broker or repository (and 451 possibly routing) services in the data plane. In the deployment 452 scenario where Providers do not assert the need to know their 453 Consumers and/or vice versa, the Controller can thus provide the 454 appropriate services to ensure the Posture Assessment Information is 455 appropriately communicated from the Providers to the authorized 456 Consumers. 458 The Controller, acting as a management control plane, helps define 459 how to manage an overall SACM system that allows for Consumers to 460 obtain the desired Posture Assessment Information without the need to 461 distinctly know and establish one (Consumer) to many (Provider) 462 connections. Similarly, a Provider may not need to distinctly know 463 and establish one (Provider) to many (Consumer) connections; e.g. the 464 Controller enables the means to allow a SACM system to support many 465 to many connections. Note that the Controller also allows for the 466 direct discovery and connection between a Consumer and Provider. 468 As a SACM component, the Controller may be instantiated within a 469 system or device acting as a Provider or a Consumer (or both), or as 470 its own distinct Controller entity. In a rich SACM environment, it 471 is feasible to instantiate a Controller that provides both the 472 management (and control) functions for SACM as well as providing the 473 data plane services for the actual data, e.g. Posture Assessment 474 Information flow. Note that Controllers may be implemented to only 475 provide control plane functions (broker), or both control plane 476 functions and data plane services (proxy or repository). 478 4. Interfaces between Consumers, Providers, and Controllers 480 A SACM interface is a transport carrying operations (e.g. publication 481 via a RESTful API). As shown in Figure 1, communication can proceed 482 with the following interfaces and expected functions and behaviors: 484 A: interface "A" shown in Figure 1 handles the management and 485 control functions that are needed to establish, at minimum, a secure 486 communication between Consumers and Providers. The interface must 487 also handle the functions to allow for the discovery and 488 registration of the Providers as well as the ways in which Posture 489 Assessment Information can be provided (or requested). 491 B: interface "B" shown in Figure 1 enables Providers to share their 492 Posture Assessment Information spontaneously; similarly, it enables 493 Consumers to request information without having to know the 494 identities (or reachability) of all the Providers that can fulfill 495 Consumers' requests. 497 C: interface "C" shown in Figure 1 illustrates the ability and 498 desire for Consumers and Providers to be able to communicate 499 directly when a Provider is sharing Posture Assessment Information 500 directly to a Consumer. The interface allows for the different data 501 models and protocols to be used between a Consumer and a Provider 502 with the expectation that the appropriate authentication and 503 authorization mechanisms have been employed to establish a secure 504 communication link between the Consumer and the Provider. 505 Typically, it is expected that the secure link establishment occurs 506 as a management or control function through the abstracted 507 Controller role (e.g. the Controller could be a broker or could be 508 embedded in a Consumer or a Provider). 510 A variety of protocols, such as SNMP, NETCONF, NEA protocols 511 [RFC5209], and other similar interfaces, may be used for collection 512 of data from the target endpoints by the Posture Information 513 Provider. Those interfaces are outside the scope of SACM. 515 5. Component Functions 517 SACM components are composed of a variety of functions, which may be 518 instantiated on a single endpoint or on separate standalone endpoints 519 providing various roles. An endpoint MUST implement one or more of 520 these functions to be considered a SACM component. A SACM solution 521 offers a set of functions across a set of SACM components. 523 The functions described here are the minimum set that is mandatory to 524 implement in a SACM solution. A SACM solution MAY implement 525 additional functions. 527 5.1. Control Plane Functions 529 Control plane functions represent various services offered by the 530 Controller to the Providers and Consumers to facilitate sharing of 531 information. Control plane functions include, but are not limited 532 to: 534 Authentication: The authentication of Consumers and Providers 535 independent of the actual information-sharing communication channel. 536 This supports use cases where: 538 * Consumers may request information independent of knowing the 539 identities of the Providers. 541 * Providers may want to share the information without prior 542 solicitation. 544 The architecture must account for an abstraction where a Controller 545 may be defined to effect the authentication of the Consumers and 546 Providers independent of the actual information-sharing communication 547 channel. 549 Authorization: The restriction of Posture Assessment Information 550 sharing between the Consumers and Providers. At minimum, a 551 management function must define the necessary policies. 553 Identity Management: Since Identity Management for authentication 554 and authorization policies is best performed via a centralized 555 component, the Controller also facilitates this function. 557 The Controller needs to be able to identify the endpoints 558 participating as SACM components and the roles that they play. 559 Similar to how access control may be effected via Authentication, 560 Authorization, and Accounting Systems (e.g. AAA services), the same 561 principle is defined; as AAA services depend on Identity Management 562 services, the Controller will need a similar function and interface 563 to Identity Management services. 565 Registration/Discovery: The discovery of what Providers are 566 available, what information a Provider can share, and how it can be 567 requested / communicated. A discovery mechanism is required to 568 facilitate interaction with Providers that may have different 569 Posture Assessment Information and potentially limited, or a rich 570 set of, ways in which they can share the information. 572 5.2. Data Plane Functions 574 Subscription 576 Publication 578 Query 580 6. Component Capabilities 582 TODO: add a discussion of "capability" as being able to talk a 583 specific data model, data operations, or SACM transport 585 TODO: data plane capabilities / control plane capabilities can be 586 discovered via querying the controller 588 7. Example Illustration of Functions and Workflow 590 TODO: once the group reaches consensus on content for the previous 591 sections, revise all this text based upon the agreed-upon 592 architecture 593 +-------------------------------+ 594 | +-------------------------------+ 595 | | | 596 +-| Controller (Cr) | 597 +-------------------------------+ 598 // / \ \\ 599 // / \ \\ 600 A // / \ \\ A 601 // / \ \\ 602 // / B B \ \\ 603 // / \ \\ 604 +------------------------+ +------------------------+ 605 | +----------------------+ A | +------------------------+ 606 | | |===========| | | 607 | | Consumer (C) |-----------| | Provider (P) | 608 +-| | C +-| | 609 +---------------------+ +------------------------+ 611 Figure 2: Communications Model 613 SACM's focus is on the automation of collection, verification and 614 update of system security configurations pertaining to endpoint 615 assessment. In order to carry out these tasks, the architectural 616 components shown in Figure 1 can be further refined as: 618 Providers: a Provider may be dedicated to perform either the 619 collection, aggregation or evaluation of one or more posture 620 attributes whose results can be conveyed to a Consumer. In this 621 example form of the SACM architecture model, these are shown as 622 Collection, Evaluation, and Results Providers. Note that there may 623 be posture attributes or posture assessment information that 624 articulates Guidance information which may or may not be present in 625 the architecture. 627 Consumers: a Consumer may request or receive one or more posture 628 attributes or posture assessment information from a Provider for 629 their own use. In this example form of the SACM architecture model, 630 these are shown as Collection, Evaluation, and Results Consumers. 631 Note that there may be posture attributes or posture assessment 632 information articulating Guidance information which may or may not 633 be present in the architecture to be provided or consumed. 635 Data Stores: a Data Store is both a Provider and a Consumer, storing 636 one or more posture attributes or assessments for endpoints. It 637 should be understood that these repositories interface directly to a 638 Provider or Consumer (and Guidance) but the interfaces used to 639 interact between them is outside the scope of SACM (e.g. no 640 interface arrows are shown in the architecture). 642 Figure 3 illustrates an example flow for how Posture Assessment 643 Information may flow. 645 +-------------+ 646 |Evaluation | 647 +-------------+ |Guidance +--+ 648 |Endpoint | |Function | | 649 +-------+ | +-------------+ | 650 | | | | 651 | +-------+-----+ +-----v-------+ 652 | Collection | |Evaluation | 653 +-> Function +--+--------+ |Function | 654 | | |Collection | +-----------+ +----------+ 655 | +------------+Provider | | |---| | 656 | | | |Collection | |Evaluation| 657 | | | |Consumer | |Provider | 658 | +----+------+ +----^------+ +---+------+ 659 ++---------+ | | | 660 |Collection| +-----v------+ +---+--------+ | 661 |Guidance | | | |Collection | | 662 |Function | |Collection | |Provider | | 663 | | |Consumer |-----| | | 664 +----------+ +------------+ +------------+ | 665 | Collection | | 666 | Data Store | | 667 +------------+ | 668 | 669 +--------------+ +---------------+ | 670 |Evaluation | |Evaluation | | 671 |Results | |Consumer <-----+ 672 |Provider |-----------| | 673 +-----+--------+ +---------------+ 674 | |Results Reporting| 675 | |Function | 676 | +------------^----+ 677 | | 678 +-----v--------+ +----+------+ 679 |Evaluation | |Reporting | 680 |Results | |Guidance | 681 |Consumer | |Data Store | 682 +---+----------+ +-----------+ +-------------+ 683 | | Results | 684 +-----------------------------> Data Store | 685 | | 686 +-------------+ 688 Figure 3: Example Posture Information Flow 690 TODO - add example of / more content around interactions with 691 endpoint, possible communications patterns 693 8. Acknowledgements 695 The authors would like to thank Jim Bieda, Henk Birkholz, Jessica 696 Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David 697 Waltermire for participating in architecture design discussions, 698 reviewing, and contributing to this draft. 700 9. IANA Considerations 702 This memo includes no request to IANA. 704 10. Security Considerations 706 The SACM architecture defines three main components that interface 707 with each other both for management and control (in the control 708 plane) and for the sharing of Posture Assessment Information. 709 Considerations for transitivity of trust between a Provider and 710 Consumer can be made if there is a well understood trust between the 711 Provider and the Controller and between the Consumer and Controller. 712 The trust must include strong mutual authentication, at minimum, 713 between the Provider and Controller and between the Consumer and 714 Controller. 716 To address potential Man-in-the-Middle (MitM) attacks, it is also 717 strongly recommended that the communications be secured to include 718 replay protection and message integrity (e.g. transport integrity and 719 if required, data integrity). Similarly, to avoid potential message 720 disclosure (e.g. where privacy may be needed), confidentiality should 721 also be provided. 723 As the Controller provides the security functions for the SACM 724 system, the Controller should provide strong authorizations based on 725 either or both business and regulatory policies to ensure that only 726 authorized Consumers and obtaining Posture Assessment Information 727 from authorized Providers. It is presumed that once authenticated 728 and authorized, the Provider, Controller or Consumer is deemed 729 trustworthy; though note that it is possible that the modules or 730 devices hosting the SACM components may be compromised as well (e.g. 731 due to malware or tampering); however, addressing that level of 732 trustworthiness is out of scope for SACM. 734 As the data models defined through the interfaces are transport 735 agnostic, the Posture Assessment Information data in the interfaces 736 may leverage the transport security properties as the interfaces are 737 transported between the Provider, Consumer and Controller. However, 738 there may be other devices, modules or components in the path between 739 the Provider, Consumer and Controller that may observe the interfaces 740 flowing through them. 742 11. References 744 11.1. Normative References 746 [I-D.ietf-sacm-requirements] 747 Cam-Winget, N. and L. Lorenzin, "Secure Automation and 748 Continuous Monitoring (SACM) Requirements", draft-ietf- 749 sacm-requirements-08 (work in progress), July 2015. 751 [I-D.ietf-sacm-terminology] 752 Birkholz, H., "Secure Automation and Continuous Monitoring 753 (SACM) Terminology", draft-ietf-sacm-terminology-07 (work 754 in progress), July 2015. 756 [I-D.ietf-sacm-use-cases] 757 Waltermire, D. and D. Harrington, "Endpoint Security 758 Posture Assessment - Enterprise Use Cases", draft-ietf- 759 sacm-use-cases-10 (work in progress), July 2015. 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, 763 DOI 10.17487/RFC2119, March 1997, 764 . 766 11.2. Informative References 768 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 769 Information Models and Data Models", RFC 3444, 770 DOI 10.17487/RFC3444, January 2003, 771 . 773 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 774 Tardo, "Network Endpoint Assessment (NEA): Overview and 775 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 776 . 778 Authors' Addresses 779 Nancy Cam-Winget (editor) 780 Cisco Systems 781 3550 Cisco Way 782 San Jose, CA 95134 783 US 785 Email: ncamwing@cisco.com 787 Lisa Lorenzin 788 Pulse Secure 789 2700 Zanker Rd, Suite 200 790 San Jose, CA 95134 791 US 793 Email: llorenzin@pulsesecure.net 795 Ira E McDonald 796 High North Inc 797 PO Box 221 798 Grand Marais, MI 49839 799 US 801 Email: blueroofmusic@gmail.com 803 Aaron Woland 804 Cisco Systems 805 1900 South Blvd. Suite 200 806 Charlotte, NC 28203 807 US 809 Email: loxx@cisco.com