idnits 2.17.1 draft-ietf-sacm-architecture-00.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 6 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2014) is 3476 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC3444' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC5209' is defined on line 414, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-05 == Outdated reference: A later version (-10) exists of draft-ietf-sacm-use-cases-07 Summary: 1 error (**), 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 B. Ford 4 Intended status: Informational Cisco Systems 5 Expires: April 16, 2015 L. Lorenzin 6 Pulse Secure 7 I. McDonald 8 High North Inc 9 A. Woland 10 Cisco Systems 11 October 13, 2014 13 Secure Automation and Continuous Monitoring (SACM) Architecture 14 draft-ietf-sacm-architecture-00 16 Abstract 18 This document describes an architecture for standardization of 19 interfaces, protocols and information models related to security 20 automation and continuous monitoring. It describes the basic 21 architecture, components and their interfaces defined to enable the 22 collection, acquisition and verification of Posture and Posture 23 Assessments. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 16, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 61 2.1. Posture Assessment Information Consumer . . . . . . . . . 4 62 2.2. Posture Assessment Information Provider . . . . . . . . . 5 63 2.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6 64 2.4. Interfaces between Consumers, Providers and Control Plane 7 65 3. Example mapping to SACM Architecture . . . . . . . . . . . . 8 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 Several data models and protocols are in use today that allow 77 different applications to perform the collection, acquisition and 78 assessment of posture. These applications can vary from being 79 focused on general system and security management to specialized 80 configuration, compliance and control systems. With an existing 81 varied set of applications, there is a strong desire to standardize 82 data models, protocols and interfaces to better allow for the 83 automation of such data processes. 85 This document describes an architecture to enable standardized 86 collection, acquisition, and verification of Posture and Posture 87 Assessments. The architecture will include the components and 88 interfaces that can be used to better identify the Information Model, 89 type(s) of transport protocols needed for communication, and further, 90 provide a model from which requirements can be drawn. 92 This document uses terminology defined in 93 [I-D.ietf-sacm-terminology]. 95 2. Architectural Overview 97 At a high level, the architecture describes 'How' and 'Where' 98 information and assessment of posture may be collected, processed or 99 assessed. The core components are shown in Figure 1. Three main 100 functional components are defined: a Posture Assessment Information 101 Consumer (C), a Posture Assessment Information Provider (P) and a 102 Control Plane (CP) used to facilitate some of the security functions 103 such as authentication and authorization and other metadata 104 functions. 106 +-----------------------------------+ 107 | +-----------------------------------+ 108 | | +-----------------------------------+ 109 | | | | 110 +-| | Posture Assessment | 111 +-| Information Consumer (C) | 112 +-----------------------------------+ 113 / \ / \ / \ 114 / \ / \ / \ 115 - - - - - - 116 A | | || ||B | |C 117 | | || || | | 118 | | - - - - 119 | | \ / \ / 120 | | \ / \ / 121 /|--------| |------------------------------------------------ |\ 122 / -------------------------------------------------------------- \ 123 / Broker/Proxy/Repository: AuthZ, Directory, metadata/capability \ 124 \ [Control Plane (CP)] / 125 \ -------------------------------------------------------------- / 126 \|--------| |------------------------------------------------ |/ 127 A | | || ||B | |C 128 | | || || | | 129 - - - - - - 130 \ / \ / \ / 131 \ / \ / \ / 132 +-----------------------------------+ 133 | |-+ 134 | Posture Assessment | | 135 | Information Provider (P) | |-+ 136 | | | | 137 +-----------------------------------+ | | 138 +-----------------------------------+ | 139 +-----------------------------------+ 141 Simple Architectural Model 143 The functional components in the proposed architecture are further 144 described in this section. 146 2.1. Posture Assessment Information Consumer 148 As described in Section 2.2 of the SACM Use Cases 149 [I-D.ietf-sacm-use-cases], several usage scenarios are posed with 150 different application types requesting posture assessment 151 information. Whether it is a configuration verification system, a 152 checklist verification system, or a system for detecting posture 153 deviations, compliance or vulnerabilities, they all need to acquire 154 information about Posture Assessment. Thus, the architectural 155 component to enable such requests is defined as a Posture Assessment 156 Information Consumer (C or Consumer). 158 The Consumer defines the capabilities and functions that must be 159 handled in order to facilitiate a Posture Assessment Information 160 Request. Requests can be either for a single posture attribute or a 161 set of posture attributes where those attributes can be the raw 162 information or an evaluated or assessed state based upon that 163 information. The Consumer may further choose to query for the 164 information directly (one-time query), or to request for updates to 165 be provided as the Posture Assessment Information changes 166 (Subscription). A request could be made directly to an explicitly 167 identified Posture Assessment Information Provider (P or Provider), 168 but a Consumer may also desire to obtain the information without 169 having to know the available providers. 171 There may be instances where a Consumer may be requesting information 172 from various Providers and due to its policy or application 173 requirements may need to be better informed of the Providers and 174 their capabilities. In those use cases, a Consumer may also request 175 to discover the respective capabilities of those Providers. 177 The Control Plane (described below) must authorize a Consumer to 178 acquire the information it is requesting. The Consumer may also be 179 subject to limits or constraints on the numbers, types, sizes, and 180 rate of requests. 182 2.2. Posture Assessment Information Provider 184 The Posture Assessment Information Provider (P or Provider) is the 185 component that contributes Posture Assessment Information either 186 spontaneously or in response to a request. A Provider can be a 187 Posture Evaluator, Posture Collector, or an application that has 188 aggregated Posture Assessment Information that can be shared. 190 The Provider defines the capabilities and functions that must be 191 handled to share or provide Posture Assessment information. A 192 Provider may provide the information spontaneously, or in response to 193 a direct request from a Consumer. The information may be filtered or 194 truncated to honor the request either by the Consumer's request, or 195 the Providers's ability to filter (or provide only a subset of the 196 requested information) or due to security considerations (e.g. 197 authorization restrictions due to domain segregation, privacy, etc.). 199 The Provider may only be able to share the Posture Assessment 200 Information using a specific data model and protocol. It may use a 201 standard data model and/or protocol, a non-standard data model and/or 202 protocol, or any combination of standard and non-standard data models 203 and protocols. It may also choose to advertise its capabilities 204 through a metadata abstraction. 206 The Provider must be authorized to provide the Posture Assessment 207 Information and further, be authorized to do so with the specific 208 data models and protocols. 210 2.3. Control Plane 212 The Control Plane may be an abstracted component but is distinctly 213 defined as a component to execute on some of the security functions 214 and overall system functions. Some of the functions include: 216 Authentication: with use cases where Consumers may request 217 information independent of knowing the identities of the Providers 218 and Providers may want to share the information unsolicited, the 219 architecture must account for an abstraction where a control plane 220 or a broker may be defined to affect the authentication of the 221 Consumers and Providers independent of the actual information 222 sharing communication channel. 224 Authorization: to address security for how Posture Assessment 225 Information is shared between the Consumers and Providers, at 226 minimum a management function to define those policies are needed. 227 However, with the introduction of the control plane with use cases 228 where R's may request information independent of knowing the 229 identities of the P's and Providers (P's) wanting to share the 230 information unsolicited, the architecture must account for an 231 abstraction where a control plane or a broker may be defined to 232 affect the authentication of the R's and P's independent of the 233 actual information sharing communication channel. 235 Identity Management: As typically, Identity Management for 236 authentication and authorization policies are best defined through a 237 centralized component, the Control Plane also provides those 238 services. 240 Discovery/Registration: a discovery mechanism is required to 241 facilitate the interaction of Providers that may have different 242 Posture Assessment Information and potentially limited (or a rich 243 set) of ways in which they can share the information; that is, 244 through the discovery mechanism Consumers can have visibility of the 245 Providers present and the type(s) of Posture Assessment Information 246 that is available and how it can be requested. Similarly, a 247 Provider may need to register its "capability" for the Posture 248 Assessment Information it can share and how it can share it (e.g. 249 protocol or with filtering capabilities). Enabling this function 250 through a broker or control plane also allows for the distinct 251 definition of security considerations (e.g. authorized registration 252 of capabilities and of Providers) beyond how a Provider may define 253 its own capability. 255 The Control Plane also helps define how to manage an overall SACM 256 system that allows for Consumers to obtain the desired Posture 257 Assessment Information without the need to distinctly know and 258 establish a one (Consumers) to many (Provider) connections. Note 259 that the Control Plane also allows for the direct discovery and 260 connection between a Consumer and Provider. 262 2.4. Interfaces between Consumers, Providers and Control Plane 264 As shown in Figure 1, communication can proceed with the following 265 interfaces and expected functions and behaviors: 267 A: interface "A" shown in Figure 1 demonstrates the ability and 268 desire for Consumers and Providers to be able to communicate 269 directly when a Provider is sharing Posture Assessment Information 270 directly to a Consumer. The interface allows for the different data 271 models and protocols to be used between a Consumer and a Provider 272 with the expectation that the appropriate authentication and 273 authorization mechanisms have been employed to establish a secure 274 communication link between the Consumer and the Provider. 275 Typically, it is expected that the secure link establishment occurs 276 as a management or control function through the abstracted control 277 plane component (e.g. the control plane could be a proxy or could be 278 embedded in a Consumer or a Provider). 280 B: interface "B" shown in Figure 1 handles the management and 281 control functions that are needed to establish, at minimum, a secure 282 communication between Consumers and Providers. The interface must 283 also handle the functions to allow for the discovery and 284 registration of the Providers as well as the ways in which Posture 285 Assessment Information can be provided (or requested). 287 C: interface "C" shown in Figure 1 enables Providers to share their 288 Posture Assessment Information spontaneously; similarly, it enables 289 Consumers to request information without having to know the 290 identities (or reachability) of all the Providers that can fulfill 291 Consumers' requests. 293 3. Example mapping to SACM Architecture 295 SACM's focus is on the automation of collection, verification and 296 update of system security configurations pertaining to endpoint 297 assessment. In order to carry out these tasks, the architectural 298 components shown in Figure 1 can be further refined as: 300 Posture Assessment Information Provider: a Provider may be dedicated 301 to perform either the collection, aggregation or evaluation of one 302 or more posture attributes whose results can be conveyed to a 303 Posture Assessment Information Consumer. In this example form of 304 the SACM architecture model, these are shown as Collection, 305 Evaluation and Results Providers. Note that there may be posture 306 attributes or posture assessment information that articulates 307 Guidance information which may or many not be present in the 308 architecture. 310 Posture Assessment Information Consumer: a Consumer may request or 311 recieve one or more posture attributes or posture assessment 312 information from a Posture Assessment Information Provider for their 313 own use. In this example form of the SACM architecture model, these 314 are shown as Collection, Evaluation and Results Consumers. Note 315 that there may be posture attributes or posture assessment 316 information that articulates Guidance information which may or many 317 not be present in the architecture to be Provided or Consumed. 319 Repositories: a Repository stores one or more posture attributes or 320 assessments for endpoints. It should be understood that these 321 repositories interface directly to a Provider or Consumer (and 322 Guidance) but the interfaces used to interact between them is 323 outside the scope of SACM (e.g. no interface arrows are shown in the 324 architecture). 326 Figure 2 illustrates an example flow for how posture information may 327 flow. 329 +-------------+ 330 |Evaluation | 331 +-------------+ |Guidance +--+ 332 |Endpoint | |Capability | | 333 +-------+ | +-------------+ | 334 | | | | 335 | +-------+-----+ +-----v-------+ 336 | Collection | |Evaluation | 337 +-> Capability +--+--------+ |Capability | 338 | | |Collection | +-----------+ +----------+ 339 | +------------+Producer | | |---| | 340 | | | |Collection | |Evaluation| 341 | | | |Consumer | |Producer | 342 | +----+------+ +----^------+ +---+------+ 343 ++---------+ | | | 344 |Collection| +-----v------+ +---+--------+ | 345 |Guidance | | | |Collection | | 346 |Capability| |Collection | |Producer | | 347 | | |Consumer |-----| | | 348 +----------+ +------------+ +------------+ | 349 | Collection | | 350 | Repository | | 351 +------------+ | 352 | 353 +--------------+ +---------------+ | 354 |Evaluation | |Evaluation | | 355 |Results | |Consumer <-----+ 356 |Producer |-----------| | 357 +-----+--------+ +---------------+ 358 | |Results Reporting| 359 | |Capability | 360 | +------------^----+ 361 | | 362 +-----v--------+ +----+------+ 363 |Evaluation | |Reporting | 364 |Results | |Guidance | 365 |Consumer | |Repository | 366 +---+----------+ +-----------+ +-------------+ 367 | | Results | 368 +-----------------------------> Repository | 369 | | 370 +-------------+ 372 Example Posture Information Flow 374 4. Acknowledgements 376 The authors would like to thank Jessica Fitzgerald-McKay, Trevor 377 Freeman, Jim Bieda and Adam Montville for participating in the 378 architecture design discussions that lead to this draft. 380 5. IANA Considerations 382 This memo includes no request to IANA. 384 6. Security Considerations 386 TBD. This section will need to cover the AAA and confidentiality/ 387 integrity of the data and data transports to be considered. Also, 388 the considerations for the interfaces (which may be covered in 389 transports) between the Consumers, Providers, and the Control Plane. 391 7. References 393 7.1. Normative References 395 [I-D.ietf-sacm-terminology] 396 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 397 Winget, "Terminology for Security Assessment", draft-ietf- 398 sacm-terminology-05 (work in progress), August 2014. 400 [I-D.ietf-sacm-use-cases] 401 Waltermire, D. and D. Harrington, "Endpoint Security 402 Posture Assessment - Enterprise Use Cases", draft-ietf- 403 sacm-use-cases-07 (work in progress), April 2014. 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 7.2. Informative References 410 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 411 Information Models and Data Models", RFC 3444, January 412 2003. 414 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 415 Tardo, "Network Endpoint Assessment (NEA): Overview and 416 Requirements", RFC 5209, June 2008. 418 Authors' Addresses 420 Nancy Cam-Winget (editor) 421 Cisco Systems 422 3550 Cisco Way 423 San Jose, CA 95134 424 US 426 Email: ncamwing@cisco.com 428 Brian Ford 429 Cisco Systems 430 5507-10 Nesconset Hwy #242 431 Mt Sinai, NY 11766 432 US 434 Email: brford@cisco.com 436 Lisa Lorenzin 437 Pulse Secure 438 2700 Zanker Rd, Suite 200 439 San Jose, CA 95134 440 US 442 Email: llorenzin@pulsesecure.net 444 Ira E McDonald 445 High North Inc 446 PO Box 221 447 Grand Marais, MI 49839 448 US 450 Email: blueroofmusic@gmail.com 452 Aaron Woland 453 Cisco Systems 454 1900 South Blvd. Suite 200 455 Charlotte, NC 28203 456 US 458 Email: loxx@cisco.com