idnits 2.17.1 draft-camwinget-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 (June 24, 2014) is 3593 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC3444' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC5209' is defined on line 329, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-04 == 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: December 26, 2014 L. Lorenzin 6 Juniper Networks 7 I. McDonald 8 High North Inc 9 A. Woland 10 Cisco Systems 11 June 24, 2014 13 Secure Automation and Continuous Monitoring (SACM) Architecture 14 draft-camwinget-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 December 26, 2014. 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 6.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Several data models and protocols are in use today that allow 76 different applications to perform the collection, acquisition and 77 assessment of posture. These applications can vary from being 78 focused on general system and security management to specialized 79 configuration, compliance and control systems. With an existing 80 varied set of applications, there is a strong desire to standardize 81 data models, protocols and interfaces to better allow for the 82 automation of such data processes. 84 This document describes an architecture to enable standardized 85 collection, acquisition, and verification of Posture and Posture 86 Assessments. The architecture will include the components and 87 interfaces that can be used to better identify the Information Model, 88 type(s) of transport protocols needed for communication, and further, 89 provide a model from which requirements can be drawn. 91 This document uses terminology defined in 92 [I-D.ietf-sacm-terminology]. 94 2. Architectural Overview 96 Figure 1 shows a proposed SACM architecture. Three main functional 97 components are defined: a Posture Assessment Information Consumer 98 (C), a Posture Assessment Information Provider (P) and a Control 99 Plane (CP) used to facilitate some of the security functions such as 100 authentication and authorization and other metadata functions. 102 +-----------------------------------+ 103 | +-----------------------------------+ 104 | | +-----------------------------------+ 105 | | | | 106 +-| | Posture Assessment | 107 +-| Information Consumer (C) | 108 +-----------------------------------+ 109 / \ / \ / \ 110 / \ / \ / \ 111 - - - - - - 112 A | | || ||B | |C 113 | | || || | | 114 | | - - - - 115 | | \ / \ / 116 | | \ / \ / 117 /|--------| |------------------------------------------------ |\ 118 / -------------------------------------------------------------- \ 119 / Broker/Proxy/Repository: AuthZ, Directory, metadata/capability \ 120 \ [Control Plane (CP)] / 121 \ -------------------------------------------------------------- / 122 \|--------| |------------------------------------------------ |/ 123 A | | || ||B | |C 124 | | || || | | 125 - - - - - - 126 \ / \ / \ / 127 \ / \ / \ / 128 +-----------------------------------+ 129 | |-+ 130 | Posture Assessment | | 131 | Information Provider (P) | |-+ 132 | | | | 133 +-----------------------------------+ | | 134 +-----------------------------------+ | 135 +-----------------------------------+ 137 Simple Architectural Model 139 The functional components in the proposed architecture are further 140 described in this section. 142 2.1. Posture Assessment Information Consumer 144 As described in Section 2.2 of the SACM Use Cases 145 [I-D.ietf-sacm-use-cases], several usage scenarios are posed with 146 different application types requesting posture assessment 147 information. Whether it is a configuration verification system, a 148 checklist verification system, or a system for detecting posture 149 deviations, compliance or vulnerabilities, they all need to acquire 150 information about Posture Assessment. Thus, the architectural 151 component to enable such requests is defined as a Posture Assessment 152 Information Consumer (C or Consumer). 154 The Consumer defines the capabilities and functions that must be 155 handled in order to facilitiate a Posture Assessment Information 156 Request. Requests can be either for a single posture attribute or a 157 set of posture attributes where those attributes can be the raw 158 information or an evaluated or assessed state based upon that 159 information. The Consumer may further choose to query for the 160 information directly (one-time query), or to request for updates to 161 be provided as the Posture Assessment Information changes 162 (Subscription). A request could be made directly to an explicitly 163 identified Posture Assessment Information Provider (P or Provider), 164 but a Consumer may also desire to obtain the information without 165 having to know the available providers. 167 There may be instances where a Consumer may be requesting information 168 from various Providers and due to its policy or application 169 requirements may need to be better informed of the Providers and 170 their capabilities. In those use cases, a Consumer may also request 171 to discover the respective capabilities of those Providers. 173 The Control Plane (described below) must authorize a Consumer to 174 acquire the information it is requesting. The Consumer may also be 175 subject to limits or constraints on the numbers, types, sizes, and 176 rate of requests. 178 2.2. Posture Assessment Information Provider 180 The Posture Assessment Information Provider (P or Provider) is the 181 component that contributes Posture Assessment Information either 182 spontaneously or in response to a request. A Provider can be a 183 Posture Evaluator, Posture Collector, or an application that has 184 aggregated Posture Assessment Information that can be shared. 186 The Provider defines the capabilities and functions that must be 187 handled to share or provide Posture Assessment information. A 188 Provider may provide the information spontaneously, or in response to 189 a direct request from a Consumer. The information may be filtered or 190 truncated to honor the request either by the Consumer's request, or 191 the Providers's ability to filter (or provide only a subset of the 192 requested information) or due to security considerations (e.g. 193 authorization restrictions due to domain segregation, privacy, etc.). 195 The Provider may only be able to share the Posture Assessment 196 Information using a specific data model and protocol. It may use a 197 standard data model and/or protocol, a non-standard data model and/or 198 protocol, or any combination of standard and non-standard data models 199 and protocols. It may also choose to advertise its capabilities 200 through a metadata abstraction. 202 The Provider must be authorized to provide the Posture Assessment 203 Information and further, be authorized to do so with the specific 204 data models and protocols. 206 2.3. Control Plane 208 The Control Plane may be an abstracted component but is distinctly 209 defined as a component to execute on some of the security functions 210 and overall system functions. Some of the functions include: 212 Authentication: with use cases where Consumers may request 213 information independent of knowing the identities of the Providers 214 and Providers may want to share the information unsolicited, the 215 architecture must account for an abstraction where a control plane 216 or a broker may be defined to affect the authentication of the 217 Consumers and Providers independent of the actual information 218 sharing communication channel. 220 Authorization: to address security for how Posture Assessment 221 Information is shared between the Consumers and Providers, at 222 minimum a management function to define those policies are needed. 223 However, with the introduction of the control plane with use cases 224 where R's may request information independent of knowing the 225 identities of the P's and Providers (P's) wanting to share the 226 information unsolicited, the architecture must account for an 227 abstraction where a control plane or a broker may be defined to 228 affect the authentication of the R's and P's independent of the 229 actual information sharing communication channel. 231 Identity Management: As typically, Identity Management for 232 authentication and authorization policies are best defined through a 233 centralized component, the Control Plane also provides those 234 services. 236 Discovery/Registration: a discovery mechanism is required to 237 facilitate the interaction of Providers that may have different 238 Posture Assessment Information and potentially limited (or a rich 239 set) of ways in which they can share the information; that is, 240 through the discovery mechanism Consumers can have visibility of the 241 Providers present and the type(s) of Posture Assessment Information 242 that is available and how it can be requested. Similarly, a 243 Provider may need to register its "capability" for the Posture 244 Assessment Information it can share and how it can share it (e.g. 245 protocol or with filtering capabilities). Enabling this function 246 through a broker or control plane also allows for the distinct 247 definition of security considerations (e.g. authorized registration 248 of capabilities and of Providers) beyond how a Provider may define 249 its own capability. 251 The Control Plane also helps define how to manage an overall SACM 252 system that allows for Consumers to obtain the desired Posture 253 Assessment Information without the need to distinctly know and 254 establish a one (Consumers) to many (Provider) connections. Note 255 that the Control Plane also allows for the direct discovery and 256 connection between a Consumer and Provider. 258 2.4. Interfaces between Consumers, Providers and Control Plane 260 As shown in Figure 1, communication can proceed with the following 261 interfaces and expected functions and behaviors: 263 A: interface "A" shown in Figure 1 demonstrates the ability and 264 desire for Consumers and Providers to be able to communicate 265 directly when a Provider is sharing Posture Assessment Information 266 directly to a Consumer. The interface allows for the different data 267 models and protocols to be used between a Consumer and a Provider 268 with the expectation that the appropriate authentication and 269 authorization mechanisms have been employed to establish a secure 270 communication link between the Consumer and the Provider. 271 Typically, it is expected that the secure link establishment occurs 272 as a management or control function through the abstracted control 273 plane component (e.g. the control plane could be a proxy or could be 274 embedded in a Consumer or a Provider). 276 B: interface "B" shown in Figure 1 handles the management and 277 control functions that are needed to establish, at minimum, a secure 278 communication between Consumers and Providers. The interface must 279 also handle the functions to allow for the discovery and 280 registration of the Providers as well as the ways in which Posture 281 Assessment Information can be provided (or requested). 283 C: interface "C" shown in Figure 1 enables Providers to share their 284 Posture Assessment Information spontaneously; similarly, it enables 285 Consumers to request information without having to know the 286 identities (or reachability) of all the Providers that can fulfill 287 Consumers' requests. 289 3. Acknowledgements 291 The authors would like to thank Jessica Fitzgerald-McKay, Trevor 292 Freeman, Jim Bieda and Adam Montville for participating in the 293 architecture design discussions that lead to this draft. 295 4. IANA Considerations 297 This memo includes no request to IANA. 299 5. Security Considerations 301 TBD. This section will need to cover the AAA and confidentiality/ 302 integrity of the data and data transports to be considered. Also, 303 the considerations for the interfaces (which may be covered in 304 transports) between the Consumers, Providers, and the Control Plane. 306 6. References 308 6.1. Normative References 310 [I-D.ietf-sacm-terminology] 311 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 312 Winget, "Terminology for Security Assessment", draft-ietf- 313 sacm-terminology-04 (work in progress), May 2014. 315 [I-D.ietf-sacm-use-cases] 316 Waltermire, D. and D. Harrington, "Endpoint Security 317 Posture Assessment - Enterprise Use Cases", draft-ietf- 318 sacm-use-cases-07 (work in progress), April 2014. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 6.2. Informative References 325 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 326 Information Models and Data Models", RFC 3444, January 327 2003. 329 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 330 Tardo, "Network Endpoint Assessment (NEA): Overview and 331 Requirements", RFC 5209, June 2008. 333 Authors' Addresses 335 Nancy Cam-Winget (editor) 336 Cisco Systems 337 3550 Cisco Way 338 San Jose, CA 95134 339 US 341 Email: ncamwing@cisco.com 343 Brian Ford 344 Cisco Systems 345 5507-10 Nesconset Hwy #242 346 Mt Sinai, NY 11766 347 US 349 Email: brford@cisco.com 351 Lisa Lorenzin 352 Juniper Networks 353 3614 Laurel Creek Way 354 Durham, NC 27712 355 US 357 Email: llorenzin@juniper.net 359 Ira E McDonald 360 High North Inc 361 PO Box 221 362 Grand Marais, MI 49839 363 US 365 Email: blueroofmusic@gmail.com 367 Aaron Woland 368 Cisco Systems 369 1900 South Blvd. Suite 200 370 Charlotte, NC 28203 371 US 373 Email: loxx@cisco.com