idnits 2.17.1 draft-haynes-sacm-ecp-mapping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.fitzgeraldmckay-sacm-endpointcompliance], [RFC7632]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 4, 2016) is 3033 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM C. Coffin 3 Internet-Draft D. Haynes 4 Intended status: Informational C. Schmidt 5 Expires: July 7, 2016 The MITRE Corporation 6 J. Fitzgerald-McKay 7 Department of Defense 8 January 4, 2016 10 SACM ECP Mapping 11 draft-haynes-sacm-ecp-mapping-01 13 Abstract 15 This document builds upon 16 [I-D.fitzgeraldmckay-sacm-endpointcompliance] to demonstrate how 17 published IETF, ISO, and TCG standards, available today, can be used 18 to accomplish the use cases outlined in [RFC7632]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 7, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Endpoint Identification and Assessment Planning . . . . . . . 4 56 3. Endpoint Posture Attribute Value Collection . . . . . . . . . 6 57 4. Posture Attribute Evaluation . . . . . . . . . . . . . . . . 7 58 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 9 63 9. Informative References . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 In [I-D.fitzgeraldmckay-sacm-endpointcompliance], several existing 69 standards are identified as aligning with the needs of SACM and are 70 suggested for possible incorporation, either by reference or by 71 adoption, into the set of solutions in the SACM architecture. These 72 standards include the suite of network interfaces defined in the IETF 73 Network Endpoint Assessment (NEA) workgroup, and some additional 74 specifications from the Trusted Computing Group's (TCG's) Trusted 75 Network Communications (formerly Trusted Network Connect) (TNC) [TNC] 76 workgroup. The NEA architecture [RFC5209] is based on the TNC 77 architecture and both are interoperable. The NEA/TNC architecture 78 provide standards-based mechanisms to collect endpoint state and 79 configuration information and securely transmit it to some authority 80 where the information is evaluated against criteria. This aligns 81 closely with the overall SACM goals of "...an architecture to enable 82 standardized collection, acquisition, and verification of Posture and 83 Posture Assessments." This document provides a more detailed mapping 84 of the NEA specifications, as well as some additional TNC 85 specifications that standardize additional behaviors within the NEA/ 86 TNC architecture, to the use cases defined for SACM. 88 At the heart of this proposal is the Endpoint Compliance Profile 89 (ECP) [Endpoint-Compliance-Profile]. The ECP is a high-level 90 standard describing a specific combination and application of NEA and 91 TNC protocols and interfaces specifically designed to support ongoing 92 monitoring of endpoint state and the controlled exposure of collected 93 information to appropriate security applications. The ECP uses the 94 components specified in the NEA/TNC architecture and also defines 95 roles for the additional TNC specifications mentioned in 96 [I-D.fitzgeraldmckay-sacm-endpointcompliance], namely IF-IMC 98 [IF-IMC], IF-IMV [IF-IMV], SWID Message and Attributes for IF-M 99 [SWID-Messages], and Server Discovery and Validation. (The latter is 100 referred to as PDP Discovery and Validation [Server-Discovery] in the 101 ECP as the ECP predated the expansion of that specification's scope.) 102 The ECP dictates the use of specific standards and also clarifies 103 requirements for optional features in order to better standardize 104 assessment practices. The following sections outline how the use of 105 standards in accordance with the ECP can also meet SACM's use cases. 107 In the descriptions below, IETF NEA terminology is used where 108 possible. The table below indicates TNC and NEA terms for 109 corresponding standards and functional units. TCG terms that do not 110 have a NEA counterpart but which are mentioned in the ECP are also 111 identified. 113 +--------------------------------------+-------------------+ 114 | TCG Standards | IETF Standards | 115 +--------------------------------------+-------------------+ 116 | IF-T TLS | PT-TLS (RFC 6876) | 117 | IF-T EAP | PT-EAP (RFC 7171) | 118 | IF-TNCCS | PB-TNC (RFC 5793) | 119 | IF-M | PA-TNC (RFC 5792) | 120 | TNC | NEA (RFC 5209) | 121 | IF-IMC | - | 122 | IF-IMV | - | 123 | SWID Message and Attributes for IF-M | - | 124 | Server Discovery and Validation | - | 125 | Endpoint Compliance Profile | - | 126 +--------------------------------------+-------------------+ 128 Table 1: Mapping Between TNC and NEA Standards 130 +----------------------------+--------------------------------------+ 131 | TCG Terminology | IETF Terminology | 132 +----------------------------+--------------------------------------+ 133 | Access Requestor | NEA Client | 134 | Policy Decision Point | NEA Server + added enforcement | 135 | | capabilities | 136 | Integrity Measurement | Posture Collector | 137 | Collector | | 138 | Integrity Measurement | Posture Validator | 139 | Validator | | 140 | TNC Client | Posture Broker Client | 141 | TNC Server | Posture Broker Server | 142 | Network Access Requestor | Posture Transport Client | 143 | Network Access Authority | Posture Transport Server | 144 +----------------------------+--------------------------------------+ 146 Table 2: Mapping Between TNC and NEA Functional Units 148 The following sections describe where each of the standards mentioned 149 in the ECP fit into use cases 2, 3, and 4 of [RFC7632]. Use case 1 150 is a much higher-level set of capabilities and requirements and so is 151 not treated separately. 153 2. Endpoint Identification and Assessment Planning 155 The Endpoint Identification and Assessment Planning use case (section 156 2.1.2 of [RFC7632]) involves "discovery of endpoints, understanding 157 their composition, identifying the desired state to assess against, 158 and calculating what posture attributes to collect to enable 159 evaluation." Several of the TNC specifications and architectural 160 components identified in the ECP are directly applicable to these 161 activities. 163 The first step in the assessment process is to discover the endpoints 164 on the network. The NEA Architecture allows enterprises to enforce a 165 policy where endpoints (a.k.a., NEA Clients) are only allowed onto 166 the network if they contact a NEA Server and provide measurements to 167 demonstrate their compliance with enterprise policy. In such an 168 enterprise, this would ensure that all endpoints on the network were 169 known. Added security and flexibility for this activity can be 170 provided by the Server Discovery and Validation specification, which 171 can be leveraged to ensure that NEA Clients are connecting to trusted 172 servers before they register themselves and send sensitive 173 information. 175 When a NEA Client first connects to a NEA Server, and on an as-needed 176 basis after that, it can be required to provide posture information 177 that helps to identify the endpoint on the network and characterize 178 its nature, which is critical in determining if an endpoint qualifies 179 as the target of an assessment. Posture information is collected by 180 Posture Collectors on the NEA Client. Once collected, the Posture 181 Collectors securely transmit the attributes back to the Posture 182 Validators on the NEA Server via the PA-TNC (NEA "application" layer) 183 [RFC5792], PB-TNC (NEA "routing" layer) [RFC5793] and either PT-TLS 184 or PT-EAP (NEA "transport" layer) protocols. The collected posture 185 information may also be stored in a CMDB or data repository for later 186 use in assessment targeting and evaluation. Beyond any identifying 187 information collected by the Posture Collectors, the PT-TLS [RFC6876] 188 and PT-EAP [RFC7171] protocols both support certificate-based 189 authentication of the client. 191 The NEA/TNC architecture is designed to be highly flexible and 192 extensible. The IF-IMC (connecting Posture Collectors to Posture 193 Broker Clients) and IF-IMV (connecting Posture Validators to Posture 194 Broker Servers) interfaces allow a range of Posture Collectors and 195 Posture Validators, respectively, to be employed. The standard 196 interfaces mean that new Collector/Validator pairs supporting 197 different types of posture information can be easily added to the 198 assessment infrastructure to meet the needs of individual 199 enterprises. For example, SWID Message and Attributes for IF-M 200 defines a standard way to collect and transport a NEA Client's SWID 201 tag inventory information, which can be very useful in understanding 202 a NEA Client's role and its exposure to software vulnerabilities. 204 Once posture information has been collected, the Posture Validators 205 evaluate the information. Based on this evaluation, the Validators 206 can suggest access control decisions, recommend further assessment of 207 the NEA Client, or take other actions. For example, a NEA Client can 208 be required to provide a SWID tag inventory (using the SWID Message 209 and Attributes for IF-M protocol) when it initially seeks to connect 210 to an enterprise, when a Posture Collector detects a change to the 211 SWID tag inventory, or when it is requested by the NEA Server. The 212 Posture Validator that receives this information might examine the 213 SWID tags of a particular NEA Client and discover that the NEA Client 214 is running a web server. Based on this, the NEA Client may be 215 subject to additional assessment in its role as a web server for the 216 enterprise. Another NEA Client may submit a SWID tag for a piece of 217 software with a known vulnerability. Based on this, the Posture 218 Validator may determine that this NEA Client requires further 219 examination to determine whether mitigating steps have been taken to 220 protect it from the vulnerability. 222 3. Endpoint Posture Attribute Value Collection 224 The Endpoint Posture Attribute Value Collection use case (section 225 2.1.3 of [RFC7632]) follows from the previous use case. The overall 226 goal of this use case is to determine which additional endpoint 227 posture attribute values are needed and then perform the collection. 228 The use case that follows (2.1.4 Posture Attribute Evaluation) uses 229 the attribute values to perform an evaluation of the attributes and 230 their values as part of an overall assessment. 232 In the current use case, the NEA Client(s) in question have already 233 been authenticated and have been granted access to the network. The 234 NEA Client(s) have also been identified and characterized (i.e., OS 235 type and version, hardware platform, etc.) based on the collected 236 information. Some attribute and attribute values from this step may 237 be cached or stored in a CMDB or data repository and may be used 238 within the current use case. 240 Now that the NEA Client is part of the network, a more extensive 241 assessment and/or periodic reassessments can be performed in order to 242 ensure detailed, ongoing compliance with policies. The data 243 collected during this activity could include additional or updated 244 identification and characterization attributes or information to 245 support assessment against checklists or other guidance. Depending 246 on the needs of the enterprise and the nature of the guidance it 247 uses, different Posture Collector/Validator pairs can be employed to 248 gather and transmit this information. As mentioned earlier, the IF- 249 IMV and IF-IMC standards allow these Collectors/Validators to be 250 added to the assessment infrastructure seamlessly. If different 251 information needs to be delivered to different NEA Servers for 252 assessment, the Server Discovery and Validation can help NEA Clients 253 identify and validate the authenticity of those servers. 255 Multiple events could trigger a posture attribute value collection. 256 Some of those events could be triggered on the NEA Client, such as 257 the detection of a change in posture. Other events could trigger the 258 NEA Server to collect attributes, such as the detection of specific 259 network events or net flows, the receipt of new guidance, 260 requirements for periodic reassessment, or a manually triggered 261 assessment by an administrator. All such triggers are supported by 262 the NEA architecture. In particular, Posture Collectors can be 263 instructed to monitor for changes in their attribute set of interest 264 and automatically report events of interest to Posture Validators. 265 Similarly, Posture Validators can be triggered to gather information 266 from a NEA Client in a variety of ways. The process of attribute 267 exchange uses the same set of NEA protocols here as outlined in the 268 preceding use case, namely PA-TNC, PB-TNC, and PT-TLS or PT-EAP. 270 The SWID Message and Attributes for IF-M specification provides an 271 excellent example of this capability. The SWID IMV (a Posture 272 Validator) can request a variety of types of information about an 273 endpoint's SWID tag collection based on guidance, a periodic trigger, 274 and/or manual requests. The SWID IMC (a Posture Collector) can also 275 be instructed to monitor the NEA Client's SWID tag collection for 276 changes, and can be instructed to report certain types of changes to 277 the NEA Server automatically. The former capability allows on-demand 278 updates of a NEA Client's SWID tag collection, while the latter 279 allows the NEA Server to be automatically informed of any changes to 280 the NEA Client's SWID tag collection (or subsets thereof) in real 281 time. 283 4. Posture Attribute Evaluation 285 The Posture Attribute Evaluation use case (section 2.1.4 of 286 [RFC7632]) involves the analysis of posture attribute values, 287 collected from the NEA Client, against the expected values of the 288 posture attributes in order to determine a result. This result can 289 be used to initiate follow up actions. The NEA architecture provides 290 a framework in which this use case can be achieved. 292 Once a NEA Client resides on the network, the NEA architecture 293 supports a number of triggers that can result in the reassessment of 294 that NEA Client. These triggers and the resulting attribute 295 collection are discussed in more detail in the Endpoint Posture 296 Attribute Value Collection use case described in the preceding 297 section. 299 This SACM use case emphasizes posture change detection on an endpoint 300 as a triggering condition. As noted earlier, NEA supports this by 301 allowing Posture Collectors to monitor the NEA Client and 302 automatically push information about changes of interest. Such 303 Posture Collectors may be configurable to be selective in what they 304 report in order to ensure NEA Servers are not deluged by irrelevant 305 data. For example, the SWID Message and Attributes for IF-M 306 specification supports configuring SWID IMCs with lists of specific 307 tags to monitor and/or can be configured only to report how a NEA 308 Client's SWID tag collection has changed since the last update. 310 Once the Posture Validator has the required inputs to carry out the 311 evaluation, it can perform this evaluation and return a result. The 312 result of this evaluation is passed to the Posture Broker Server 313 which then initiates any necessary response. For example, upon 314 evaluation of a NEA Client's SWID tag collection, it might be 315 determined that a newly installed piece of software is not on the 316 organization's whitelist of authorized software. Depending on 317 enterprise policy, this may result in a simple alert to an 318 administrator, or something as proactive as removal of the NEA Client 319 from the enterprise network. 321 5. Conclusion 323 Several years ago, the Trusted Computing Group offered several of 324 their TNC standards to the IETF and these eventually became the NEA 325 standards. If SACM feels that the additional TNC standards discussed 326 here have value, it is hoped that TCG will again be willing to offer 327 them for IETF adoption. Doing this does more than just provide a 328 shortcut to the publication of useful, tested IETF RFCs - it helps 329 unify the approaches of TCG and IETF rather than creating multiple 330 separate solutions to the challenges of automated cyber defense. 331 Consolidating standards around a proven approach not only accelerates 332 standards development but aids consumers by avoiding a multiplicity 333 of competing standards. 335 More generally, this document shows that the described TNC and NEA 336 standards align well with SACM use cases. While they do not address 337 every identified building block of these use cases, they address a 338 large number of them, and the NEA/TNC architecture supports extension 339 points where other standards can be applied to address any missing 340 capabilities. By the same token, because the NEA/TNC architecture so 341 closely aligns with SACM needs, developing a new solution would lead 342 to redundant, competing solutions for many of the activities that 343 SACM seeks to support. For these reasons, the authors urge SACM to 344 consider use of NEA/TNC standards in general, and the ECP in 345 particular, in the development of the SACM architecture. 347 6. IANA Considerations 349 This memo includes no request to IANA. 351 All drafts are required to have an IANA considerations section (see 352 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 353 for a guide). If the draft does not require IANA to do anything, the 354 section contains an explicit statement that this is the case (as 355 above). If there are no requirements for IANA, the section will be 356 removed during conversion into an RFC by the RFC Editor. 358 7. Security Considerations 360 All drafts are required to have a security considerations section. 361 See RFC 3552 [RFC3552] for a guide. 363 8. Change Log 365 8.1. -00 to -01 367 There are no textual changes associated with this revision except for 368 updated references to the Endpoint Security Posture Assessment: 369 Enterprise Use Cases document given that it was recently published as 370 an RFC. This revision primarily reflects a resubmission of the 371 document so that it goes back into active status. The document 372 expired on January 7, 2016. 374 9. Informative References 376 [Endpoint-Compliance-Profile] 377 Trusted Computing Group, "TNC Endpoint Compliance Profile 378 Specification, Version 1.0", December 2014. 380 [I-D.fitzgeraldmckay-sacm-endpointcompliance] 381 Fitzgerald-McKay, J., "Endpoint Compliance Standard", 382 draft-fitzgeraldmckay-sacm-endpointcompliance-01 (work in 383 progress), November 2015. 385 [I-D.narten-iana-considerations-rfc2434bis] 386 Narten, T. and H. Alvestrand, "Guidelines for Writing an 387 IANA Considerations Section in RFCs", draft-narten-iana- 388 considerations-rfc2434bis-09 (work in progress), March 389 2008. 391 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 392 IF-IMC, Version 1.3", February 2013. 394 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 395 IF-IMV, Version 1.4", December 2014. 397 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 398 Text on Security Considerations", BCP 72, RFC 3552, DOI 399 10.17487/RFC3552, July 2003, 400 . 402 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 403 Tardo, "Network Endpoint Assessment (NEA): Overview and 404 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 405 . 407 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 408 (PA) Protocol Compatible with Trusted Network Connect 409 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 410 . 412 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 413 A Posture Broker (PB) Protocol Compatible with Trusted 414 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 415 March 2010, . 417 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 418 Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 419 10.17487/RFC6876, February 2013, 420 . 422 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 423 (PT) Protocol for Extensible Authentication Protocol (EAP) 424 Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, 425 . 427 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 428 Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 429 10.17487/RFC7632, September 2015, 430 . 432 [Server-Discovery] 433 Trusted Computing Group, "DRAFT: TCG Trusted Network 434 Connect PDP Discovery and Validation, Version 1.0", August 435 2013. 437 [SWID-Messages] 438 Trusted Computing Group, "DRAFT: TCG Trusted Network 439 Connect SWID Message and Attributes for IF-M, Version 440 1.0", March 2015. 442 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 443 Architecture for Interoperability, Version 1.5", February 444 2012. 446 Authors' Addresses 448 Chris Coffin 449 The MITRE Corporation 450 202 Burlington Road 451 Bedford, MA 01730 452 USA 454 Email: ccoffin@mitre.org 455 Daniel Haynes 456 The MITRE Corporation 457 202 Burlington Road 458 Bedford, MA 01730 459 USA 461 Email: dhaynes@mitre.org 463 Charles Schmidt 464 The MITRE Corporation 465 202 Burlington Road 466 Bedford, MA 01730 467 USA 469 Email: cmschmidt@mitre.org 471 Jessica Fitzgerald-McKay 472 Department of Defense 473 9800 Savage Road 474 Ft. Meade, Maryland 475 USA 477 Email: jmfitz2@nsa.gov