idnits 2.17.1 draft-ietf-sacm-epcp-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 : ---------------------------------------------------------------------------- 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 4, 2019) is 1632 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-mile-xmpp-grid-04 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-12 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-05 ** Downref: Normative reference to an Informational draft: draft-ietf-sacm-terminology (ref. 'I-D.ietf-sacm-terminology') -- Possible downref: Non-RFC (?) normative reference: ref. 'IF-IMC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IF-IMV' -- Possible downref: Non-RFC (?) normative reference: ref. 'Server-Discovery' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM D. Haynes 3 Internet-Draft The MITRE Corporation 4 Intended status: Best Current Practice J. Fitzgerald-McKay 5 Expires: May 7, 2020 Department of Defense 6 November 4, 2019 8 Endpoint Posture Collection Profile 9 draft-ietf-sacm-epcp-00 11 Abstract 13 This document specifies the Endpoint Posture Collection Profile, 14 which describes the best practices for the application of IETF, TNC, 15 and ISO/IEC data models, protocols, and interfaces to support the on- 16 going collection and communication of endpoint posture to a 17 centralized server where it can be stored and made available to other 18 tools. 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 https://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 May 7, 2020. 37 Copyright Notice 39 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Endpoint Posture Collection Profile . . . . . . . . . . . . . 5 58 2.1. Components . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 60 2.1.1.1. Posture Collection Engine . . . . . . . . . . . . 8 61 2.1.2. Posture Manager . . . . . . . . . . . . . . . . . . . 8 62 2.1.2.1. Posture Collection Manager . . . . . . . . . . . 8 63 2.1.3. Repository . . . . . . . . . . . . . . . . . . . . . 9 64 2.1.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . 9 65 2.1.5. Orchestrator . . . . . . . . . . . . . . . . . . . . 9 66 2.1.6. Application Programming Interface . . . . . . . . . . 9 67 2.2. Transactions . . . . . . . . . . . . . . . . . . . . . . 10 68 2.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . 10 69 2.2.2. Discovery and Validation . . . . . . . . . . . . . . 10 70 2.2.3. Event-Driven Collection . . . . . . . . . . . . . . . 10 71 2.2.4. Querying the Endpoint . . . . . . . . . . . . . . . . 10 72 2.2.5. Data Storage . . . . . . . . . . . . . . . . . . . . 11 73 2.2.6. Data Sharing . . . . . . . . . . . . . . . . . . . . 11 74 3. IETF NEA EPCP Implementation for Traditional Endpoints . . . 11 75 3.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 13 76 3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 13 77 3.2.1. Posture Collector . . . . . . . . . . . . . . . . . . 14 78 3.2.2. Posture Broker Client . . . . . . . . . . . . . . . . 14 79 3.2.3. Posture Transport Client . . . . . . . . . . . . . . 14 80 3.3. Posture Manager . . . . . . . . . . . . . . . . . . . . . 14 81 3.3.1. Posture Validator . . . . . . . . . . . . . . . . . . 14 82 3.3.2. Posture Broker Server . . . . . . . . . . . . . . . . 14 83 3.3.3. Posture Transport Server . . . . . . . . . . . . . . 14 84 3.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 15 85 3.5. IETF SACM Software Asset Management Extension to the IETF 86 NEA EPCP Implementation . . . . . . . . . . . . . . . . . 15 87 3.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 15 88 3.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 15 89 3.5.3. SWID Posture Collectors and Posture Validators . . . 16 90 3.5.3.1. The SWID Posture Collector . . . . . . . . . . . 16 91 3.5.3.2. The SWID Posture Validator . . . . . . . . . . . 16 92 3.5.4. Repository . . . . . . . . . . . . . . . . . . . . . 17 93 4. IETF NETCONF EPCP Implementation for Network Device Endpoints 17 94 4.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 18 95 4.2. Posture Manager Provisioning . . . . . . . . . . . . . . 18 96 4.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 18 97 4.3.1. Datastore . . . . . . . . . . . . . . . . . . . . . . 18 98 4.4. Posture Manager . . . . . . . . . . . . . . . . . . . . . 19 99 4.5. Repository . . . . . . . . . . . . . . . . . . . . . . . 19 100 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 104 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 21 105 8.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 21 106 8.1.2. Network Attacks . . . . . . . . . . . . . . . . . . . 22 107 8.1.3. Posture Manager Attacks . . . . . . . . . . . . . . . 22 108 8.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 22 109 8.2. Countermeasures . . . . . . . . . . . . . . . . . . . . . 23 110 8.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 23 111 8.2.2. Countermeasures for Network Attacks . . . . . . . . . 23 112 8.2.3. Countermeasures for Posture Manager Attacks . . . . . 24 113 8.2.4. Countermeasures for Repository Attacks . . . . . . . 25 114 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 116 10.1. Informative References . . . . . . . . . . . . . . . . . 26 117 10.2. Normative References . . . . . . . . . . . . . . . . . . 26 118 Appendix A. Rationale for an EPCP Solution . . . . . . . . . . . 29 119 A.1. Preventative Posture Assessments . . . . . . . . . . . . 29 120 A.2. All Network-Connected Endpoints are Endpoints . . . . . . 29 121 A.3. All Endpoints on the Network Must be Uniquely Identified 30 122 A.4. Standardized Data Models . . . . . . . . . . . . . . . . 30 123 A.5. Posture Information Must Be Stored . . . . . . . . . . . 30 124 A.6. Posture Information Can Be Shared . . . . . . . . . . . . 31 125 A.7. Enterprise Asset Posture Information Belongs to the 126 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 31 127 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 31 128 B.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 31 129 B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 31 130 B.1.2. Software Asset Management . . . . . . . . . . . . . . 32 131 B.1.3. Vulnerability Management . . . . . . . . . . . . . . 32 132 B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 32 133 B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 33 134 Appendix C. Endpoint Posture Collection Profile Examples . . . . 33 135 C.1. Continuous Posture Assessment of an Endpoint . . . . . . 33 136 C.1.1. Change on Endpoint Triggers Posture Assessment . . . 34 137 C.2. Administrator Searches for Vulnerable Endpoints . . . . . 37 138 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 38 139 D.1. -05 to -00 . . . . . . . . . . . . . . . . . . . . . . . 38 140 D.2. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 39 141 D.3. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 39 142 D.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 39 143 D.5. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 40 144 D.6. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 40 145 D.7. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 40 146 D.8. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 41 147 D.9. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 150 1. Introduction 152 The Endpoint Posture Collection Profile (EPCP) describes the best 153 practices for the collection and communication of posture information 154 from network-connected endpoints to a centralized server leveraging 155 prior work from the IETF NEA WG, the IETF NETCONF WG, IETF NETMOD WG, 156 the Trusted Computing Group (TCG) Trusted Network Communications 157 [TNC] Work Group, and the International Organization for 158 Standardization/International Electrotechnical Commission Joint 159 Technical Committee (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC 160 1, SC7, WG21). 162 This document focuses on reducing the security exposure of a network 163 by enabling: 165 event-driven posture collection; 167 standardized querying of additional posture information as needed; 169 and the communication of that data to a centralized server where 170 it can be made available to other components. 172 Thus, eliminating the need for multiple collection tools on an 173 endpoint collecting the same data for different purposes. Future 174 revisions of this document may include support for the collection of 175 posture information from other endpoint types as well as a 176 standardized interface for storing and querying data in repositories 177 among other capabilities. Additional information about this future 178 work can be found in Section 5 of this document. 180 To support the collection of posture information from new endpoint 181 types, this document is organized such that it first provides a high- 182 level overview of EPCP as well as the abstract components and 183 transactions that will be realized by implementations (Section 2). 184 This is followed by individual sections that discuss the best 185 practices for specific implementations of the EPCP for a given 186 endpoint type (e.g., traditional workstations and servers, network 187 devices, mobile devices, etc.) along with any extensions for 188 supported use cases (software asset management, vulnerability 189 management, etc.). Over time, the best practices may be expanded to 190 address issues that arise, support new capabilities, or support new 191 implementations beyond IETF NEA and IETF NETCONF. 193 1.1. Conventions Used in This Document 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in 198 BCP14 [RFC2119][RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 This specification does not distinguish blocks of informative 202 comments and normative requirements. Therefore, for the sake of 203 clarity, note that lower case instances of must, should, etc. do not 204 indicate normative requirements. 206 1.2. Terminology 208 This document uses terms as defined in [I-D.ietf-sacm-terminology] 209 unless otherwise specified. 211 2. Endpoint Posture Collection Profile 213 The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols, 214 and interfaces can be used to support the posture assessment of 215 endpoints on a network. This profile does not generate new data 216 models, protocols, or interfaces; rather, it offers best practices 217 for a full end-to-end solution for posture assessment, as well as a 218 fresh perspective on how existing standards can be leveraged against 219 vulnerabilities. Rationale for the EPCP solution as well as the 220 supported and non-supported use cases is available in Appendix A and 221 Appendix B respectively. 223 The EPCP defines the following best practices for posture assessments 224 against network-connected endpoints. 226 1. uniquely identifying the endpoint; 228 2. collecting and evaluating posture based on data from the endpoint 229 (asset management, software asset management, vulnerability 230 management, and configuration management); 232 3. creating a secure, authenticated, confidential channel between 233 the endpoint and the posture manager; 235 4. enabling the endpoint to notify the posture manager about changes 236 to its configuration; 238 5. enabling the posture manager to request information about the 239 configuration of the endpoint; and 241 6. storing the posture information in a repository linked to the 242 identifier for the endpoint. 244 Furthermore, the EPCP aims to support data storage and data sharing 245 capabilities to make the collected posture information available to 246 authorized parties and components in support of other post-processes 247 (analytic, access control, remediation, reporting, etc.). 249 2.1. Components 251 To support posture assessment, data storage, and data sharing 252 capabilities, the EPCP defines several components. Some of these 253 components reside on the target endpoint. Others reside on the 254 posture manager that manages communications with the target endpoint 255 and stores the target endpoint's posture information in a repository. 257 The primary focus of this document is on the communication between 258 the posture manager and endpoints through the posture collection 259 manager and posture collection engine components. While the 260 orchestrator, evaluator, repository, and API will be discussed in the 261 context of the EPCP, these components are for illustrative purposes 262 only and are not strictly defined nor are best practices provided for 263 them. As a result, vendors are free to implement these components 264 and interfaces in a way that makes the most sense for their products. 266 Orchestrator 267 +--------+ 268 | | 269 | | 270 | |<---+ 271 | | | 272 | | | ************Posture Collection Profile************* 273 | | | * * 274 +--------+ | * Posture Manager Endpoint * 275 | * +----------------+ +----------------+ * 276 publish/ | * | | | | * 277 subscribe | * | | | | * 278 +---->| | | | * 279 Repository * | | report/ | | * 280 +--------+ * | +------------+ | publish | +------------+ | * 281 | | store * | | | |<----------| | | | * 282 | |<-------->| | Posture | | | | Posture | | * 283 | | * | | Collection | | | | Collection | | * 284 | | * | | Manager | | query/ | | Engine | | * 285 | |<---+ * | | | | subscribe | | | | * 286 | | | * | | | |---------->| | | | * 287 +--------+ | * | +------------+ | | +------------+ | * 288 | * | | | | * 289 request/ | * | | | | * 290 response | * | | | | * 291 | * | | | | * 292 Evaluator | * +----------------+ +----------------+ * 293 +--------+ | * ^ ^ * 294 | | | ********|****|************************************* 295 | | | | +-------------+ 296 | |<---+ | | 297 | | | +-------------------------+ 298 | | | | Application Programming | 299 | | | | Interface (API) | 300 +--------+ | +-------------------------+ 301 ^ | 302 | query/response | 303 +---------------------+ 305 Figure 1: EPCP Components 307 2.1.1. Endpoint 309 An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is 310 monitored by the enterprise and is the target of posture assessments. 311 To support these posture assessments, posture information is 312 collected via a posture collection engine. 314 2.1.1.1. Posture Collection Engine 316 The posture collection engine is located on the target endpoint and 317 can either push data to the posture collection manager (see 318 Section 2.2.3) or receive queries for data from the posture 319 collection manager (see Section 2.2.4). The posture collection 320 engine sends collected posture information to the posture manager 321 where it can be sanity checked and stored in the repository. The 322 posture collection engine also contains a capability that sets up 323 exchanges between the target endpoint and posture manager. This 324 capability makes the posture collection engine responsible for 325 performing the client-side portion of encryption handshakes, and for 326 locating authorized posture managers with which to communicate. 328 2.1.2. Posture Manager 330 The posture manager is an endpoint that collects and validates 331 posture information received about a target endpoint. It also stores 332 the posture information it receives in the repository where it can be 333 retrieved and used in evaluations. The posture manager does not 334 evaluate the posture information. 336 2.1.2.1. Posture Collection Manager 338 The posture collection manager is a lightweight and extensible 339 component that facilitates the coordination and execution of posture 340 collection requests using collection mechanisms deployed across the 341 enterprise. The posture collection manager may query and retrieve 342 guidance from the repository to guide the collection of posture 343 information from the target endpoint. 345 The posture collection manager also contains a capability that sets 346 up exchanges between the target endpoint and the posture manager, and 347 manages data sent to and from the posture collection engine. It is 348 also responsible for performing the server-side portion of encryption 349 handshakes. 351 If the posture manager wants to register for the continuous 352 collection of endpoint posture changes with the endpoint, then it 353 must do so in a secure and scalable way. Specifically, it will need 354 to create subscriptions with endpoints in a way which allows the 355 posture data to be pushed. Effectively, this means that the target 356 endpoint must be able to establish secure transport connectivity to 357 the posture collection manager as needed, and the posture collection 358 manager must be able to periodically collect the current state of the 359 endpoint and assess its posture. 361 2.1.3. Repository 363 The repository hosts guidance, endpoint identification information, 364 and posture information reported by target endpoints where it is made 365 available to authorized components and persisted over a period of 366 time set by the administrator. Information stored in the repository 367 will be accessible to authorized parties via a standardized API. The 368 repository may be a standalone component or may be located on the 369 posture manager. Furthermore, an implementation is not restricted to 370 a single repository and may leverage several repositories to provide 371 this functionality. 373 2.1.4. Evaluator 375 The evaluator assesses the posture status of a target endpoint by 376 comparing collected posture information against the desired state of 377 the target endpoint specified in guidance. The evaluator queries and 378 retrieves the appropriate guidance from the repository as well as 379 queries and retrieves the posture information required for the 380 assessment from the repository. If the required posture information 381 is not available in the repository, the evaluator may request the 382 posture information from the posture collection manager, which will 383 result in the collection of additional posture information from the 384 target endpoint. This information is subsequently stored in the 385 repository where it is made available to the evaluator and other 386 components. The results of the assessment are stored in the 387 repository where they are available to tools and administrators for 388 post-processes including follow-up actions, further evaluation, and 389 historical purposes. The evaluator may also be triggered by events 390 on an endpoint or the network. 392 2.1.5. Orchestrator 394 The orchestrator provides a publish/subscribe interface for the 395 repository so that infrastructure endpoints can subscribe to and 396 receive published posture assessment results from the repository 397 regarding endpoint posture changes. 399 2.1.6. Application Programming Interface 401 The API allows authorized users, infrastructure endpoints, and 402 software to query the repository as well as manage endpoints and 403 other components used in EPCP via the posture manager. 405 2.2. Transactions 407 The following sections describe the transactions associated with EPCP 408 components and may be provided in an implementation. The 409 transactions span the deployment of an endpoint, integration into the 410 EPCP, data collection, and the storage and dissemination of that 411 information for different use cases. 413 2.2.1. Provisioning 415 An endpoint is provisioned with one or more attributes that will 416 serve as its unique identifier on the network as well as the 417 components (e.g., posture collection engine, etc.) and data models 418 (e.g., SWID) necessary to interact with the posture manager. 419 Examples of such attributes include serial numbers, hardware 420 certificates compliant with [IEEE-802-1ar], and the identities of 421 hardware cryptographic modules among others. An endpoint should also 422 have a MAC address which should change over time. Once provisioning 423 is complete, the endpoint is deployed on the network. Over time, 424 components and data models may need to be added to the endpoint or 425 updated to support the collection needs of an enterprise. 427 2.2.2. Discovery and Validation 429 If necessary, the target endpoint finds and validates the posture 430 manager. The posture collection engine on the target endpoint and 431 posture collection manager on the posture manager complete an 432 encryption handshake, during which endpoint identity information is 433 exchanged. 435 2.2.3. Event-Driven Collection 437 The posture assessment is initiated when the posture collector engine 438 on the target endpoint notices that relevant posture information on 439 the endpoint has changed. Then, the posture collection engine 440 initiates a posture assessment information exchange with the posture 441 collection manager. 443 2.2.4. Querying the Endpoint 445 The posture assessment is initiated by the posture collection 446 manager. This can occur because: 448 1. policy states that a previous assessment has become invalid, or 450 2. the posture collection manager is triggered by a sensor or an 451 administrator (via the posture manager's API) that an assessment 452 must be completed. 454 2.2.5. Data Storage 456 Once posture information is received by the posture manager, it is 457 forwarded to the repository. The repository could be co-located with 458 the posture manager, or standalone where the repository and posture 459 manager directly communicate with each other or the communication is 460 brokered through the orchestrator. The posture information is stored 461 in the repository along with past posture information collected about 462 the target endpoint. 464 2.2.6. Data Sharing 466 Because the target endpoint posture information was sent in 467 standards-based data models over secure, standardized protocols, and 468 then stored in a centralized repository linked to unique endpoint 469 identifiers, authorized parties are able to access the posture 470 information. Such authorized parties may include, but are not 471 limited to, administrators or endpoint owners (via the posture 472 manager's API), evaluators that access the repository directly, and 473 orchestrators that rely on publish/subscribe communications with the 474 repository. 476 3. IETF NEA EPCP Implementation for Traditional Endpoints 478 When EPCP is used, posture collectors running on the target endpoint 479 gather posture information as changes occur on the endpoint. The 480 posture information is aggregated by the posture broker client and 481 forwarded to a posture manager, over a secure channel, via the 482 posture transport client. Once received by the posture transport 483 server on the posture manager, the posture information is directed by 484 the posture broker server to the appropriate posture validators where 485 it can be processed and stored in a repository. There the posture 486 information can be used to carry out assessments or other post- 487 processing tasks. Posture collectors can also be queried by posture 488 validators to refresh posture information about the target endpoint 489 or to ask a specific question about posture information. This is 490 shown in Figure 2. 492 Posture Posture 493 Collection Collection 494 Manager Engine 495 +---------------+ +---------------+ 496 | | | | 497 | +-----------+ | PA-TNC | +-----------+ | 498 | | Posture | |--------| | Posture | | 499 | | Validator | | | | Collector | | 500 | +-----------+ | | +-----------+ | 501 | | | | | | 502 | | IF-IMV | | | IF-IMC | 503 | | | | | | 504 | +-----------+ | PB-TNC | +-----------+ | 505 | | PB Server | |--------| | PB Client | | 506 | +-----------+ | | +-----------+ | 507 | | | | | | 508 | | | | | | 509 | | | | | | 510 | +-----------+ | | +-----------+ | 511 | | PT Server | |<------>| | PT Client | | 512 | +-----------+ | PT-TLS | +-----------+ | 513 | | | | 514 +---------------+ +---------------+ 516 Figure 2: NEA Components 518 These requirements are written with a view to performing a posture 519 assessment on an endpoint and refer to defined components of the NEA 520 architecture [RFC5209] as well as the IF-IMV [IF-IMV] and IF-IMC 521 [IF-IMC] interfaces defined in the Trusted Computing Group's TNC Work 522 Group. As with the NEA architecture, vendors have discretion as to 523 how these NEA components map to separate pieces of software or 524 endpoints. 526 It should be noted that the posture broker client and posture 527 transport client components of the posture collection engine and the 528 posture broker server and posture transport server components of the 529 posture collection manager would likely need to be implemented by a 530 single vendor because there are no standardized interfaces between 531 the respective components and would not be interoperable. 533 Examples of the EPCP as implemented using the components from the NEA 534 architecture are provided in Appendix C. 536 3.1. Endpoint Provisioning 538 An endpoint SHOULD be provisioned with a machine certificate that 539 will serve as its unique identifier on the network as well as the 540 components necessary to interact with the posture manager. This 541 includes a posture collection engine to manage requests from the 542 posture manager and the posture collectors necessary to collect the 543 posture information of importance to the enterprise. The endpoint is 544 deployed on the network. 546 The target endpoint SHOULD authenticate to the posture manager using 547 a machine certificate during the establishment of the outer tunnel 548 achieved with the posture transport protocol defined in [RFC6876]. 549 [IF-IMV] specifies how to pull an endpoint identifier out of a 550 machine certificate. An endpoint identifier SHOULD be created in 551 conformance with [IF-IMV] from a machine certificate sent via 552 [RFC6876]. 554 Other authenticators are possible. The target endpoint MAY 555 authenticate to the posture manager using a combination of the 556 machine account and password; however, this is less secure and not 557 recommended. A more secure approach would leverage a hardware 558 certificate compliant with [IEEE-802-1ar]; this identifier SHOULD be 559 associated with the identity of a hardware cryptographic module, in 560 accordance with [IEEE-802-1ar], if present on the endpoint. The 561 enterprise SHOULD establish a certificate root authority; install its 562 root certificate on endpoints and on the posture manager; and 563 provision the endpoints and the posture manager with machine 564 certificates. 566 3.2. Endpoint 568 The endpoint MUST conform to [RFC5793], which levies several 569 requirements against the endpoint. An endpoint that complies with 570 these requirements will be able to: 572 1. attempt to initiate a session with the posture manager if the 573 posture makes a request to send an update to the posture manager; 575 2. notify the posture collector if no PT-TLS session with the 576 posture manager can be created; 578 3. notify the posture collector when a PT-TLS session is 579 established; and 581 4. receive information from the posture collectors, forward this 582 information to the posture manager via the posture collection 583 engine. 585 3.2.1. Posture Collector 587 Any posture collector used in an EPCP solution MUST be conformant 588 with the TCG TNC Integrity Measurement Collector interface [IF-IMC]. 590 3.2.2. Posture Broker Client 592 The posture broker client MUST conform to [IF-IMC] to enable 593 communications between the posture broker client and the posture 594 collectors on the endpoint. 596 3.2.3. Posture Transport Client 598 The posture transport client MUST implement PT-TLS. 600 The posture transport client MUST support the use of machine 601 certificates for TLS at each endpoint consistent with the 602 requirements stipulated in [RFC6876] and [Server-Discovery]. 604 The posture transport client MUST be able to locate an authorized 605 posture manager, and switch to a new posture manager when required by 606 the network, in conformance with [Server-Discovery]. 608 3.3. Posture Manager 610 The posture manager MUST conform to all requirements in [RFC5793]. 612 3.3.1. Posture Validator 614 Any posture validator used in an EPCP solution MUST be conformant 615 with the TCG TNC Integrity Measurement Verifier interface [IF-IMV]. 617 3.3.2. Posture Broker Server 619 The posture broker server MUST conform to [IF-IMV]. Conformance to 620 [IF-IMV] enables the posture broker server to obtain endpoint 621 identity information from the posture transport server, and pass this 622 information to any posture validators on the posture manager. 624 3.3.3. Posture Transport Server 626 The posture transport server MUST implement PT-TLS. 628 The posture transport server MUST support the use of machine 629 certificates for TLS at each endpoint consistent with the 630 requirements stipulated in [RFC6876] and [Server-Discovery]. 632 3.4. Repository 634 EPCP requires a simple interface for the repository. Posture 635 validators on the posture manager receive the target endpoint posture 636 information via PA-TNC [RFC5792] messages sent from corresponding 637 posture collectors on the target endpoint. The posture validators 638 store this information in the repository linked to the identity of 639 the target endpoint where the posture collectors are located. 641 3.5. IETF SACM Software Asset Management Extension to the IETF NEA EPCP 642 Implementation 644 This section defines the requirements associated with the Software 645 Inventory Message and Attributes (SWIMA) extension for PA-TNC 646 [RFC8412] in support of the software asset management use case with 647 the IETF NEA EPCP implementation. 649 3.5.1. Endpoint Pre-Provisioning 651 The following requirements assume that the platform or OS vendor 652 supports the use of [SWID] and/or [I-D.ietf-sacm-coswid] tags and the 653 standard directory locations for the SWID and CoSWID tags as 654 specified by the [SWID] specification. 656 3.5.2. SWID Tags 658 The primary content for the EPCP is the information conveyed in the 659 elements of a SWID or CoSWID tag. The SWID specification defines an 660 XML-based software identification tag and the CoSWID specification 661 defines a Concise Binary Object Representation (CBOR) that is 662 compatible with the SWID specification. CoSWID tags require 663 significantly less memory and bandwidth to store and transmit as 664 compared to the traditional XML-based SWID tags. 666 For readability, since CoSWID is a concise representation of SWID, 667 only SWID is used throughout the remainder of this document although 668 CoSWID may be used in addition to, or in place of, SWID. 670 The endpoint MUST have SWID tags stored in a directory specified in 671 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 672 also be generated by: 674 o the software installer; or 676 o third-party software that creates tags based on the applications 677 it sees installed on the endpoint. 679 The elements in the SWID tag MUST be populated as specified in 680 [SWID]. These tags, and the directory in which they are stored, MUST 681 be updated as software is added, removed, or updated. 683 3.5.3. SWID Posture Collectors and Posture Validators 685 The following sections outline the requirements for SWID Posture 686 Collectors and Posture Validators. 688 3.5.3.1. The SWID Posture Collector 690 For the EPCP, the SWID posture collector MUST be conformant with 691 [RFC8412], which includes requirements for: 693 1. Collecting SWID tags from the SWID directory; 695 2. Monitoring the SWID directory for changes; 697 3. Initiating a session with the posture manager to report changes 698 to the directory; 700 4. Maintaining a list of changes to the SWID directory when updates 701 take place and no PT-TLS connection can be created with the 702 posture manager; 704 5. Responding to a request for SWID tags from the SWID Posture 705 Validator on the posture manager; and 707 6. Responding to a query from the SWID posture validator as to 708 whether all updates have been sent. 710 The SWID posture collector is not responsible for detecting that the 711 SWID directory was not updated when an application was either 712 installed or uninstalled. 714 3.5.3.2. The SWID Posture Validator 716 Conformance to [RFC8412] enables the SWID posture validator to: 718 1. Send messages to the SWID posture collector (at the behest of the 719 administrator at the posture manager console) requesting updates 720 for SWID tags located on endpoint; 722 2. Ask the SWID posture collector whether all updates to the SWID 723 directory located at the posture manager have been sent; and 725 3. Perform any validation and processing on the collected SWID 726 posture information prior to storage. 728 In addition to these requirements, a SWID posture validator used in 729 conformance with this profile MUST be capable of passing this SWID 730 posture information as well as the associated endpoint identity to 731 the repository for storage. 733 3.5.4. Repository 735 The interface SHOULD enable an administrator to: 737 1. Query which endpoints have reported SWID tags for a particular 738 application 740 2. Query which SWID tags are installed on an endpoint; and 742 3. Query tags based on characteristics, such as vendor, publisher, 743 etc. 745 4. IETF NETCONF EPCP Implementation for Network Device Endpoints 747 When EPCP is used, a NETCONF client that implements the posture 748 collection manager sends a query to target network device endpoint 749 requesting posture information over a secure channel. Once the 750 NETCONF server on the endpoint receives the request, it queries one 751 or more datastores for the posture information. The NETCONF server 752 then reports the information back to the NETCONF client where it can 753 be stored in a repository for use by other tools. This is shown in 754 Figure 3. 756 Posture Posture 757 Collection Collection 758 Manager Engine 759 +---------------+ +---------------+ 760 | | | | 761 | | | +-----------+ | 762 | | | | Data | | 763 | | | | Store(s) | | 764 | | | +-----------+ | 765 | | | | | 766 | | | | | 767 | +-----------+ | | +-----------+ | 768 | | NETCONF | | | | NETCONF | | 769 | | Client | |<------->| | Server | | 770 | +-----------+ | NETCONF | +-----------+ | 771 | | | | 772 +---------------+ +---------------+ 774 Figure 3: NETCONF Components 776 These requirements are written with a view to performing a posture 777 assessment on network device endpoints (routers, switches, etc.) and 778 refer to defined components of the NETCONF architecture and map back 779 to EPCP. As with the NETCONF architecture, vendors have discretion 780 as to how these NETCONF components map to separate pieces of software 781 or endpoints. 783 4.1. Endpoint Provisioning 785 For the posture manager to be able to query the datastores on the 786 endpoint, the endpoint MUST be configured to grant the posture 787 manager access to its datastores as described in [RFC6241]. The 788 posture manager is identified by its NETCONF username. The endpoint 789 is deployed on the network. 791 4.2. Posture Manager Provisioning 793 For the posture manager to be able to query the datastores on the 794 endpoint, the posture manager MUST be provisioned with a NETCONF 795 username that will be used to authenticate the posture manager to the 796 endpoint as described in [RFC6241]. The username generated will be 797 determined by the selected transport protocol. The posture manager 798 is deployed on the network. 800 4.3. Endpoint 802 An endpoint MUST conform to the requirements outlined for servers in 803 the NETCONF protocol as defined in [RFC6241]. This requires the 804 implementation of NETCONF over SSH [RFC6242]. An endpoint MAY 805 support the NETCONF protocol over other transports such as TLS 806 [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040]. 808 4.3.1. Datastore 810 A NETCONF datastore on an endpoint MUST support the operations 811 outlined in [RFC6241], but, the actual implementation of the 812 datastore is left to the endpoint vendor. 814 Datastores MUST support the YANG data modeling language [RFC7950] for 815 expressing endpoint posture information in a structured format. In 816 addition, datastores MAY support other data models such as XML (via 817 YIN) for representing posture information. 819 Datastores MUST support the compliance posture information specified 820 in [RFC7317]. Datastores MAY support other models standardized or 821 proprietary as deemed appropriate by the endpoint vendor. 823 4.4. Posture Manager 825 A posture manager MUST conform to the requirements specified for 826 clients in the NETCONF protocol as defined in [RFC6241]. This 827 requires the implementation of NETCONF over SSH [RFC6242]. A posture 828 manager MAY also support the NETCONF protocol over other transports 829 such as TLS [RFC7589]. In addition, a posture manager MAY support 830 the RESTCONF protocol as defined in [RFC8040]. 832 4.5. Repository 834 EPCP requires a simple interface for the repository. The posture 835 collection manager on the posture manager receives the target 836 endpoint posture information via NETCONF [RFC6241] messages sent from 837 posture collection engine on the target endpoint. The posture 838 collection manager stores this information in the repository linked 839 to the identity of the target endpoint from which it was collected. 841 5. Future Work 843 This section captures ideas for future work related to EPCP that 844 might be of interest to the IETF SACM WG. These ideas are listed in 845 no particular order. 847 o [RFC8639], [RFC8640], and [RFC8641] could be leveraged for an 848 HTTP-based subscription for EPCP. Specifically, it could be used 849 for the posture collection manager to continuously receive posture 850 changes as they happen from the posture collection engine. At 851 this point, it seems like [I-D.ietf-netconf-restconf-notif] would 852 be a good match to these requirements. However, further 853 investigation into the applicability of supporting a RESTCONF 854 server capability to handle subscription requests needs to be 855 made. Specific questions which should be examined include: 857 * Number of endpoints which can be continuously tracked by a 858 single posture collection manager. Scalability questions to be 859 considered include elements from the number of transport 860 connections maintained as well as the volume and churn of 861 posture evidence which will be continuously pushed to the 862 posture collection manager. 864 * Ability of the posture collection manager to establish and 865 maintain a continuous state of endpoint posture during 866 failures. This includes failures/reboots on either side of the 867 interface. 869 * Ability to support the full set of functions described for 870 NETCONF within Section 4. 872 o Add support endpoint types beyond workstations, servers, and 873 network infrastructure devices. 875 o Examine the integration of [I-D.ietf-mile-xmpp-grid]. 877 o Define a standard interface and API for interacting with the 878 repository. Requirements to consider include: creating a secure 879 channel between a publisher and the repository, creating a secure 880 channel between a subscriber and the repository, and the types of 881 interactions that must be supported between publishers and 882 subscribers to a repository. 884 o Define a standard interface for communications between the posture 885 broker client and posture transport client(s) as well as the 886 posture broker server and posture transport server(s). 888 o Retention of posture information on the target endpoint. 890 o Define an orchestrator component as well as publish/subscribe 891 interface for it. 893 o Define an evaluator component as well as an interface for it. 895 o Reassess the use of MAC addresses as a device identifier among 896 network tools, based on technical research into current security 897 best practices in IoT, automotive, mobile, and other privacy- 898 sensitive market domains. 900 6. Contributors 902 The authors wish to thank all of those in the TCG TNC work group who 903 contributed to development of the TNC ECP specification [ECP] upon 904 which this document is based. 906 The authors also wish to give a special thanks to Henk Birkholz, Dan 907 Ehrlich, Ira McDonald, Kathleen Moriarty, David Oliva, and Eric Voit 908 for their thoughtful comments and edits to this document. 910 7. IANA Considerations 912 This document does not define any new IANA registries. However, this 913 document does reference other documents that do define IANA 914 registries. As a result, the IANA Considerations section of the 915 referenced documents should be consulted. 917 8. Security Considerations 919 This Security Considerations section includes an analysis of the 920 attacks that may be mounted against systems that implement the EPCP 921 (Section 8.1) and the countermeasures that may be used to prevent or 922 mitigate these attacks (Section 8.2). Overall, a substantial 923 reduction in cyber risk can be achieved. 925 8.1. Threat Model 927 This section lists the attacks that can be mounted on a NEA 928 implementation of an EPCP environment. The following section 929 (Section 8.2) describes countermeasures. 931 Because the EPCP describes a specific use case for NEA components, 932 many security considerations for these components are addressed in 933 more detail in the technical specifications: [RFC8412], [IF-IMC], 934 [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV]. 936 8.1.1. Endpoint Attacks 938 While the EPCP provides substantial improvements in endpoint 939 security, endpoints can still be compromised. For this reason, all 940 parties must regard data coming from endpoints as potentially 941 unreliable or even malicious. An analogy can be drawn with human 942 testimony in an investigation or trial. Human testimony is essential 943 but must be regarded with suspicion. 945 o Compromise of endpoint: A compromised endpoint may report false 946 information to confuse or even provide maliciously crafted 947 information with a goal of infecting others. 949 o Putting bad information in SWID directory: Even if an endpoint is 950 not completely compromised, some of the software running on it may 951 be unreliable or even malicious. This software, potentially 952 including the SWID generation or discovery tool, or malicious 953 software pretending to be a SWID generation or discovery tool, can 954 place incorrect or maliciously crafted information into the SWID 955 directory. Endpoint users may even place such information in the 956 directory, whether motivated by curiosity or confusion or a desire 957 to bypass restrictions on their use of the endpoint. 959 o Identity spoofing (impersonation): A compromised endpoint may 960 attempt to impersonate another endpoint to gain its privileges or 961 to besmirch the reputation of that other endpoint. This is of 962 particular concern when using MAC addresses to identify endpoints, 963 which while widely used in endpoint behavior monitoring and threat 964 assessment tools, are easy to spoof. 966 8.1.2. Network Attacks 968 Generally, the network cannot be trusted. A variety of attacks can 969 be mounted using the network, including: 971 o Eavesdropping, modification, injection, replay, deletion; 973 o Traffic analysis; and 975 o Denial of service and blocking traffic. 977 8.1.3. Posture Manager Attacks 979 The posture manager is a critical security element and therefore 980 merits considerable scrutiny. A variety of attacks can be leveraged 981 against the Posture Manager. 983 o Compromised trusted posture manager: A compromised posture manager 984 or a malicious party that is able to impersonate a posture manager 985 can incorrectly grant or deny access to endpoints, place incorrect 986 information into the repository, or send malicious messages to 987 endpoints. 989 o Misconfiguration of posture manager: Accidental or purposeful 990 misconfiguration of a trusted posture manager can cause effects 991 that are similar to those listed for "Compromised trusted posture 992 manager". 994 o Malicious untrusted posture manager: An untrusted posture manager 995 cannot mount any significant attacks because all properly 996 implemented endpoints will refuse to engage in any meaningful 997 dialog with such a posture manager. 999 8.1.4. Repository Attacks 1001 The repository is also an important security element and therefore 1002 merits careful scrutiny. 1004 o Putting bad information into trusted repository: An authorized 1005 repository client such as a server may be able to put incorrect 1006 information into a trusted repository or delete or modify 1007 historical information, causing incorrect decisions about endpoint 1008 security. Placing maliciously crafted data in the repository 1009 could even lead to the compromise of repository clients, if they 1010 fail to carefully check such data. 1012 o Compromised trusted repository: A compromised trusted repository 1013 or a malicious untrusted repository that is able to impersonate a 1014 trusted repository can lead to effects similar to those listed for 1015 "Putting bad information into trusted repository". Further, a 1016 compromised trusted repository can report different results to 1017 different repository clients or deny access to the repository for 1018 selected repository clients. 1020 o Misconfiguration of trusted repository: Accidental or purposeful 1021 misconfiguration of a trusted repository can deny access to the 1022 repository or result in loss of historical data. 1024 o Malicious untrusted repository: An untrusted repository cannot 1025 mount any significant attacks because all properly implemented 1026 repository clients will refuse to engage in any meaningful dialog 1027 with such a repository. 1029 8.2. Countermeasures 1031 This section lists the countermeasures that can be used in a NEA 1032 implementation of an EPCP environment. 1034 8.2.1. Countermeasures for Endpoint Attacks 1036 This profile is in and of itself a countermeasure for a compromised 1037 endpoint. A primary defense for an endpoint is to run up to date 1038 software configured to be run as safely as possible. 1040 Ensuring that anti-virus signatures are up to date and that a 1041 firewall is configured are also protections for an endpoint that are 1042 supported by the current NEA specifications. 1044 For secure device identification and to correlate device identifiers 1045 if the MAC address is randomized, MAC addresses should be collected 1046 along with other, more secure endpoint identifiers. Endpoints that 1047 have hardware cryptographic modules that are provisioned by the 1048 enterprise, in accordance with [IEEE-802-1ar], can protect the 1049 private keys used for authentication and help prevent adversaries 1050 from stealing credentials that can be used for impersonation. Future 1051 versions of the EPCP may want to discuss in greater detail how to use 1052 a hardware cryptographic module, in accordance with [IEEE-802-1ar], 1053 to protect credentials and to protect the integrity of the code that 1054 executes during the bootstrap process by hashing or recording 1055 indicators of compromise. 1057 8.2.2. Countermeasures for Network Attacks 1059 To address network attacks, [RFC6876] includes required encryption, 1060 authentication, integrity protection, and replay protection. 1061 [Server-Discovery] also includes authorization checks to ensure that 1062 only authorized servers are trusted by endpoints. Any unspecified or 1063 not yet specified network protocols employed in the EPCP (e.g., the 1064 protocol used to interface with the repository) should include 1065 similar protections. 1067 These protections reduce the scope of the network threat to traffic 1068 analysis and denial of service. Countermeasures for traffic analysis 1069 (e.g., masking) are usually impractical but may be employed. 1070 Countermeasures for denial of service (e.g., detecting and blocking 1071 particular sources) SHOULD be used when appropriate to detect and 1072 block denial of service attacks. These are routine practices in 1073 network security. 1075 8.2.3. Countermeasures for Posture Manager Attacks 1077 Because of the serious consequences of posture manager compromise, 1078 posture managers SHOULD be especially well hardened against attack 1079 and minimized to reduce their attack surface. They SHOULD be 1080 monitored using the NEA protocols to ensure the integrity of the 1081 behavior and analysis data stored on the posture manager and SHOULD 1082 utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for 1083 identity and/or integrity measurements of the posture manager. They 1084 should be well managed to minimize vulnerabilities in the underlying 1085 platform and in systems upon which the posture manager depends. 1086 Network security measures such as firewalls or intrusion detection 1087 systems may be used to monitor and limit traffic to and from the 1088 posture manager. Personnel with administrative access to the posture 1089 manager should be carefully screened and monitored to detect problems 1090 as soon as possible. Posture manager administrators should not use 1091 password-based authentication but should instead use non-reusable 1092 credentials and multi-factor authentication (where available). 1093 Physical security measures should be employed to prevent physical 1094 attacks on posture managers. 1096 To ease detection of posture manager compromise, should it occur, 1097 posture manager behavior should be monitored to detect unusual 1098 behavior (such as a server reboot, unusual traffic patterns, or other 1099 odd behavior). Endpoints should log and/or notify users and/or 1100 administrators when peculiar posture manager behavior is detected. 1101 To aid forensic investigation, permanent read-only audit logs of 1102 security-relevant information pertaining to posture manager 1103 (especially administrative actions) should be maintained. If posture 1104 manager compromise is detected, the posture manager's certificate 1105 should be revoked and careful analysis should be performed of the 1106 source and impact of this compromise. Any reusable credentials that 1107 may have been compromised should be reissued. 1109 Endpoints can reduce the threat of server compromise by minimizing 1110 the number of trusted posture managers, using the mechanisms 1111 described in [Server-Discovery]. 1113 8.2.4. Countermeasures for Repository Attacks 1115 If the host for the repository is located on its own endpoint, it 1116 should be protected with the same measures taken to protect the 1117 posture manager. In this circumstance, all messages between the 1118 posture manager and repository should be protected with a mature 1119 security protocol such as TLS or IPsec. 1121 The repository can aid in the detection of compromised endpoints if 1122 an adversary cannot tamper with its contents. For instance, if an 1123 endpoint reports that it does not have an application with a known 1124 vulnerability installed, an administrator can check whether the 1125 endpoint might be lying by querying the repository for the history of 1126 what applications were installed on the endpoint. 1128 To help prevent tampering with the information in the repository: 1130 1. Only authorized parties should have privilege to run code on the 1131 endpoint and to change the repository. 1133 2. If a separate endpoint hosts the repository, then the 1134 functionality of that endpoint should be limited to hosting the 1135 repository. The firewall on the repository should only allow 1136 access to the posture manager and to any endpoint authorized for 1137 administration. 1139 3. The repository should ideally use "write-once" media to archive 1140 the history of what was placed in the repository, to include a 1141 snapshot of the current status of applications on endpoints. 1143 9. Privacy Considerations 1145 The EPCP specifically addresses the collection of posture data from 1146 enterprise endpoints by an enterprise network. As such, privacy is a 1147 fundamental concern for those deploying this EPCP solution, given EU 1148 GDPR, California CCPA, and many other privacy regulations. The 1149 enterprise SHOULD implement and enforce their duty of care. 1151 A possible exception may be the concerns a user may have when 1152 attempting to connect a personal endpoint (such as a phone or mobile 1153 endpoint) to an enterprise network. The user may not want to share 1154 certain details, such as an endpoint identifier or SWID tags, with 1155 the enterprise. The user can configure their NEA client to reject 1156 requests for this information; however, it is possible that the 1157 enterprise policy will not allow the user's endpoint to connect to 1158 the network without providing the requested data. 1160 An enterprise network SHOULD limit access to endpoint posture and 1161 identification information to authorized users and SHOULD enforce 1162 policies that prevent the export of endpoint posture metadata to 1163 unauthorized third parties. 1165 10. References 1167 10.1. Informative References 1169 [CIS] http://www.cisecurity.org/controls/, "CIS Critical 1170 Security Controls". 1172 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1173 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1174 Protect Your ICT System", November 2012. 1176 [ECP] Trusted Computing Group, "TCG Trusted Network Connect 1177 Endpoint Compliance Profile, Version 1.10", December 2014. 1179 [IEEE-802-1ar] 1180 Institute of Electrical and Electronics Engineers, "IEEE 1181 802.1ar", December 2009. 1183 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1184 Tardo, "Network Endpoint Assessment (NEA): Overview and 1185 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1186 . 1188 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1189 Architecture for Interoperability, Version 1.5", February 1190 2012. 1192 10.2. Normative References 1194 [I-D.ietf-mile-xmpp-grid] 1195 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 1196 "Using XMPP for Security Information Exchange", draft- 1197 ietf-mile-xmpp-grid-04 (work in progress), October 2017. 1199 [I-D.ietf-netconf-restconf-notif] 1200 Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 1201 A. Bierman, "Dynamic subscription to YANG Events and 1202 Datastores over RESTCONF", draft-ietf-netconf-restconf- 1203 notif-15 (work in progress), June 2019. 1205 [I-D.ietf-sacm-coswid] 1206 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1207 Waltermire, "Concise Software Identification Tags", draft- 1208 ietf-sacm-coswid-12 (work in progress), July 2019. 1210 [I-D.ietf-sacm-terminology] 1211 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1212 Winget, "Terminology for Security Assessment", draft-ietf- 1213 sacm-terminology-05 (work in progress), August 2014. 1215 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1216 IF-IMC, Version 1.3", February 2013. 1218 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1219 IF-IMV, Version 1.4", December 2014. 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, 1223 DOI 10.17487/RFC2119, March 1997, 1224 . 1226 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1227 (PA) Protocol Compatible with Trusted Network Connect 1228 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1229 . 1231 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1232 A Posture Broker (PB) Protocol Compatible with Trusted 1233 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1234 March 2010, . 1236 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1237 and A. Bierman, Ed., "Network Configuration Protocol 1238 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1239 . 1241 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1242 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1243 . 1245 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1246 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1247 DOI 10.17487/RFC6876, February 2013, 1248 . 1250 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1251 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1252 2014, . 1254 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1255 NETCONF Protocol over Transport Layer Security (TLS) with 1256 Mutual X.509 Authentication", RFC 7589, 1257 DOI 10.17487/RFC7589, June 2015, 1258 . 1260 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1261 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1262 . 1264 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1265 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1266 . 1268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1270 May 2017, . 1272 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1273 J. Fitzgerald-McKay, "Software Inventory Message and 1274 Attributes (SWIMA) for PA-TNC", RFC 8412, 1275 DOI 10.17487/RFC8412, July 2018, 1276 . 1278 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1279 E., and A. Tripathy, "Subscription to YANG Notifications", 1280 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1281 . 1283 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1284 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1285 and Datastores over NETCONF", RFC 8640, 1286 DOI 10.17487/RFC8640, September 2019, 1287 . 1289 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1290 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1291 September 2019, . 1293 [Server-Discovery] 1294 Trusted Computing Group, "DRAFT: TCG Trusted Network 1295 Connect PDP Discovery and Validation, Version 1.0", 1296 October 2015. 1298 [SWID] "Information technology--Software asset management--Part 1299 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1301 Appendix A. Rationale for an EPCP Solution 1303 A.1. Preventative Posture Assessments 1305 The value of continuous endpoint posture assessment is well 1306 established. Security experts have identified asset management and 1307 vulnerability remediation as a critical step for preventing 1308 intrusions. Application whitelisting, patching applications and 1309 operating systems, and using the latest versions of applications top 1310 the Defense Signals Directorate's "Top 4 Mitigations to Protect Your 1311 ICT System". [DSD] "Inventory of Authorized and Unauthorized 1312 Endpoints", "Inventory of Authorized and Unauthorized Software", and 1313 "Continuous Vulnerability Assessment and Remediation" are Controls 1, 1314 2, and 3, respectively, of the CIS Controls [CIS]. While there are 1315 commercially available solutions that attempt to address these 1316 security controls, these solutions do not: 1318 run on all types of endpoints; 1320 consistently interoperate with other tools that could make use of 1321 the data collected; 1323 collect posture information from all types of endpoints in a 1324 consistent, standardized schema; 1326 require vetted, standardized protocols that have been evaluated by 1327 the international community for cryptographic soundness. 1329 As is true of most solutions offered today, the solution found in the 1330 EPCP does not attempt to solve the lying endpoint problem, or detect 1331 infected endpoints; rather, it focuses on ensuring that healthy 1332 endpoints remain healthy by keeping software up-to-date and patched. 1334 A.2. All Network-Connected Endpoints are Endpoints 1336 As defined by [I-D.ietf-sacm-terminology], an endpoint is any 1337 physical or virtual computing endpoint that can be connected to a 1338 network. Posture assessment against policy is equally, if not more, 1339 important for continuously-connected endpoints, such as enterprise 1340 workstations and infrastructure endpoints, as it is for sporadically 1341 connected endpoints. Continuously-connected endpoints are just as 1342 likely to fall out of compliance with policy, and a standardized 1343 posture assessment method is necessary to ensure they can be properly 1344 handled. 1346 A.3. All Endpoints on the Network Must be Uniquely Identified 1348 Many administrators struggle to identify what endpoints are connected 1349 to the network at any given time. By requiring a standardized method 1350 of endpoint identity, the EPCP will enable administrators to answer 1351 the basic question, "What is on my network?" In 1352 [I-D.ietf-sacm-terminology], SACM defines this set of endpoints on 1353 the network as the SACM domain. Unique endpoint identification also 1354 enables the comparison of current and past endpoint posture 1355 assessments, by allowing administrators to correlate assessments from 1356 the same endpoint. This makes it easier to flag suspicious changes 1357 in endpoint posture for manual or automatic review, and helps to 1358 swiftly identify malicious changes to endpoint applications. 1360 A.4. Standardized Data Models 1362 Meeting EPCP best practices requires the use of standardized data 1363 models for the exchange of posture information. This helps to ensure 1364 that the posture information sent from endpoints to the repository 1365 can be easily stored, due to their known format, and shared with 1366 authorized endpoints and users. 1368 Posture information must be sent over standardized protocols to 1369 ensure the confidentiality and authenticity of this data while in 1370 transit. Implementations of the EPCP include [RFC6876] and [RFC6241] 1371 for communication between the target endpoint and the posture 1372 manager. These protocols allow networks that implement this solution 1373 to collect large amounts of posture information from an endpoint to 1374 make decisions about that endpoint's compliance with some policy. 1375 The EPCP offers a solution for all endpoints already connected to the 1376 network. Periodic assessments and automated reporting of changes to 1377 endpoint posture allow for instantaneous identification of connected 1378 endpoints that are no longer compliant with some policy. 1380 A.5. Posture Information Must Be Stored 1382 Posture information must be stored by the repository and must be 1383 exposed to an interface at the posture manager. Standardized data 1384 models enable standardized queries from an interface exposed to an 1385 administrator at the posture manager. A repository must retain any 1386 current posture information retrieved from the target endpoint and 1387 store it indexed by the unique identifier for the endpoint. Any 1388 posture collection manager specified by this profile must be able to 1389 ascertain from its corresponding posture collection engine whether 1390 the posture information is up to date. An interface on the posture 1391 manager must support a request to obtain up-to-date information when 1392 an endpoint is connected. This interface must also support the 1393 ability to make a standard set of queries about the posture 1394 information stored by the repository. In the future, some forms of 1395 posture information might be retained at the endpoint. The interface 1396 on the posture manager must accommodate the ability to make a request 1397 to the corresponding posture collection engine about the posture of 1398 the target endpoint. Standardized data models and protocols also 1399 enable the security of posture assessment results. By storing these 1400 results indexed under the endpoint's unique identifier, secure 1401 storage itself enables endpoint posture information correlation, and 1402 ensures that the enterprise's repositories always offer the freshest, 1403 most up-to-date view of the enterprise's endpoint posture information 1404 possible. 1406 A.6. Posture Information Can Be Shared 1408 By exposing posture information using a standardized interface and 1409 API, other security and operational components have a high level of 1410 insight into the enterprise's endpoints and the software installed on 1411 them. This will support innovation in the areas of asset management, 1412 vulnerability scanning, and interfaces, as any authorized 1413 infrastructure endpoint can interact with the posture information. 1415 A.7. Enterprise Asset Posture Information Belongs to the Enterprise 1417 Owners and administrators must have complete control of posture 1418 information, policy, and endpoint mitigation. Standardized data 1419 models, protocols and interfaces help to ensure that this posture 1420 information is not locked in proprietary databases, but is made 1421 available to its owners. This enables administrators to develop as 1422 nuanced a policy as necessary to keep their networks secure. Of 1423 course, there may be exceptions to this such as the case with 1424 privacy-related information (e.g., personally identifiable 1425 information). 1427 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 1429 B.1. Supported Use Cases 1431 The following sections describe the different use cases supported by 1432 the EPCP. 1434 B.1.1. Hardware Asset Management 1436 Using the API on the posture manager, an authorized user can learn: 1438 o what endpoints are connected to the network at any given time; and 1440 o what SWID tags were reported for the endpoints. 1442 The ability to answer these questions offers a standards-based 1443 approach to asset management, which is a vital part of enterprise 1444 processes such as compliance report generation for the Federal 1445 Information Security Modernization Act (FISMA), Payment Card Industry 1446 Data Security Standard (PCI DSS), Health Insurance Portability and 1447 Accountability Act (HIPAA), etc. 1449 B.1.2. Software Asset Management 1451 The API on the posture manager provides the ability for authorized 1452 users and infrastructure to know which software is installed on which 1453 endpoints on the enterprise's network. This allows the enterprise to 1454 answer questions about what software is installed to determine if it 1455 is licensed or prohibited. This information can also drive other use 1456 cases such as: 1458 o vulnerability management: knowing what software is installed 1459 supports the ability to determine which endpoints contain 1460 vulnerable software and need to be patched. 1462 o configuration management: knowing which security controls need to 1463 be applied to harden installed software and better protect 1464 endpoints. 1466 B.1.3. Vulnerability Management 1468 The API also provides the ability for authorized users or 1469 infrastructure to locate endpoints running software for which 1470 vulnerabilities have been announced. Because of 1472 1. the unique IDs assigned to each endpoint; and 1474 2. the rich application data provided in the endpoints' posture 1475 information, 1477 the repository can be queried to find all endpoints running a 1478 vulnerable application. Endpoints suspected of being vulnerable can 1479 be addressed by the administrator or flagged for further scrutiny. 1481 B.1.4. Threat Detection and Analysis 1483 The repository's standardized API allows authorized infrastructure 1484 endpoints and software to search endpoint posture assessment 1485 information for evidence that an endpoint's software inventory has 1486 changed, and can make endpoint software inventory data available to 1487 other endpoints. This automates security data sharing in a way that 1488 expedites the correlation of relevant network data, allowing 1489 administrators and infrastructure endpoints to identify odd endpoint 1490 behavior and configuration using secure, standardized data models and 1491 protocols. 1493 B.2. Non-Supported Use Cases 1495 Several use cases, including but not limited to these, are not 1496 covered by the EPCP: 1498 o Gathering non-standardized types of posture information: The EPCP 1499 does not prevent administrators from collecting posture 1500 information in proprietary formats from the endpoint; however, it 1501 does not set requirements for doing so. 1503 o Solving the lying endpoint problem: The EPCP does not address the 1504 lying endpoint problem; the profile makes no assertions that it 1505 can catch an endpoint that is, either maliciously or accidentally, 1506 reporting false posture information to the posture manager. 1507 However, other solutions may be able to use the posture 1508 information collected using the capabilities described in this 1509 profile to catch an endpoint in a lie. For example, a sensor may 1510 be able to compare the posture information it has collected on an 1511 endpoint's activity on the network to what the endpoint reported 1512 to the posture manager and flag discrepancies. However, these 1513 capabilities are not described in this profile. 1515 Appendix C. Endpoint Posture Collection Profile Examples 1517 The following subsections provide examples of the EPCP as implemented 1518 using components from the NEA architecture. 1520 C.1. Continuous Posture Assessment of an Endpoint 1521 Endpoint Posture Manager 1522 +---------------+ +---------------+ 1523 | | | | 1524 | +-----------+ | | +-----------+ | 1525 | | SWID | | | | SWID | | 1526 | | Posture | | | | Posture | | 1527 | | Collector | | | | Validator | | 1528 | +-----------+ | | +-----------+ | 1529 | | | | | | 1530 | | IF-IMC | | | IF-IMV | 1531 | | | | | | 1532 | +-----------+ | | +-----------+ | 1533 | | PB Client | | | | PB Server | | 1534 | +-----------+ | | +-----------+ | 1535 | | | | | | 1536 | | | | | | 1537 | | | | | | 1538 | +-----------+ | | +-----------+ | 1539 | | PT Client | |<------>| | PT Server | | 1540 | +-----------+ | PT-TLS | +-----------+ | 1541 | | | | 1542 +---------------+ +---------------+ 1544 Figure 4: Continuous Posture Assessment of an Endpoint 1546 C.1.1. Change on Endpoint Triggers Posture Assessment 1548 A new application is installed on the endpoint, and the SWID 1549 directory is updated. This triggers an update from the SWID posture 1550 collector to the SWID posture validator. The message is sent down 1551 the NEA stack, encapsulated by NEA protocols until it is sent by the 1552 posture transport client to the posture transport server. The 1553 posture transport server then forwards it up through the stack, where 1554 the layers of encapsulation are removed until the SWID message 1555 arrives at the SWID posture validator. 1557 Endpoint Posture Manager 1558 +---------------+ +---------------+ 1559 | | | | 1560 | +-----------+ | | +-----------+ | 1561 | | SWID | | | | SWID | | 1562 | | Posture | | | | Posture | | 1563 | | Collector | | | | Validator | | 1564 | +-----------+ | | +-----------+ | 1565 | | | SWID Message | | | 1566 | | IF-IMC | for PA-TNC | | IF-IMV | 1567 | | | | | | 1568 | +-----------+ | | +-----------+ | 1569 | | PB Client | | | | PB Server | | 1570 | +-----------+ | | +-----------+ | 1571 | | | | | | 1572 | | | PB-TNC {SWID | | | 1573 | | | Message for | | | 1574 | | | PA-TNC} | | | 1575 | +-----------+ | | +-----------+ | 1576 | | PT Client | |<-------------->| | PT Server | | 1577 | +-----------+ | PT-TLS {PB-TNC | +-----------+ | 1578 | | {SWID Message | | 1579 +---------------+ for PA-TNC}} +---------------+ 1581 Figure 5: Compliance Protocol Encapsulation 1583 The SWID posture validator stores the new tag information in the 1584 repository. If the tag indicates that the endpoint is compliant with 1585 the policy, then the process is complete until the next time an 1586 update is needed (either because policy states that the endpoint must 1587 submit posture assessment results periodically or because an 1588 install/uninstall/update event on the endpoint triggers a posture 1589 assessment). 1591 Endpoint Posture Manager 1592 +---------------+ +---------------+ 1593 | | | | 1594 | +-----------+ | | +-----------+ | 1595 | | SWID | | | | SWID |-|-+ 1596 | | Posture | | | | Posture | | | 1597 | | Collector | | | | Validator | | | 1598 | +-----------+ | | +-----------+ | | 1599 | | | | | | | Repository 1600 | | IF-IMC | | | IF-IMV | | +--------+ 1601 | | | | | | | | | 1602 | +-----------+ | | +-----------+ | | | | 1603 | | PB Client | | | | PB Server | | +---->| | 1604 | +-----------+ | | +-----------+ | | | 1605 | | | | | | +--------+ 1606 | | | | | | 1607 | | | | | | 1608 | +-----------+ | | +-----------+ | 1609 | | PT Client | |<------>| | PT Server | | 1610 | +-----------+ | PT-TLS | +-----------+ | 1611 | | | | 1612 +---------------+ +---------------+ 1614 Figure 6: Storing SWIDs in the Repository 1616 If the endpoint has fallen out of compliance with a policy, the 1617 posture manager can alert the administrator via the posture manager's 1618 API. The administrator can then take steps to address the problem. 1619 If the administrator has already established a policy for 1620 automatically addressing this problem, that policy will be followed. 1622 (") 1623 __|__ 1624 +-->| 1625 Endpoint Posture Manager | / \ 1626 +---------------+ +---------------+ | 1627 | | | | | 1628 | +-----------+ | | +-----------+ | | 1629 | | SWID | | | | SWID |-|-+ 1630 | | Posture | | | | Posture | | 1631 | | Collector | | | | Validator | | 1632 | +-----------+ | | +-----------+ | 1633 | | | | | | Repository 1634 | | IF-IMC | | | IF-IMV | +--------+ 1635 | | | | | | | | 1636 | +-----------+ | | +-----------+ | | | 1637 | | PB Client | | | | PB Server | | | | 1638 | +-----------+ | | +-----------+ | | | 1639 | | | | | | +--------+ 1640 | | | | | | 1641 | | | | | | 1642 | +-----------+ | | +-----------+ | 1643 | | PT Client | |<------>| | PT Server | | 1644 | +-----------+ | PT-TLS | +-----------+ | 1645 | | | | 1646 +---------------+ +---------------+ 1648 Figure 7: Server Alerts Network Admin 1650 C.2. Administrator Searches for Vulnerable Endpoints 1652 An announcement is made that a particular version of a piece of 1653 software has a vulnerability. The administrator uses the API on the 1654 posture manager to search the repository for endpoints that reported 1655 the SWID tag for the vulnerable software. 1657 (") 1658 __|__ 1659 +-->| 1660 Endpoint Posture Manager | / \ 1661 +---------------+ +---------------+ | 1662 | | | | | 1663 | +-----------+ | | +-----------+ | | 1664 | | SWID | | | | SWID |-|-+ 1665 | | Posture | | | | Posture | | 1666 | | Collector | | | | Validator | | 1667 | +-----------+ | | +-----------+ | 1668 | | | | | | Repository 1669 | | IF-IMC | | | IF-IMV | +--------+ 1670 | | | | | | | | 1671 | +-----------+ | | +-----------+ | | | 1672 | | PB Client | | | | PB Server | |------>| | 1673 | +-----------+ | | +-----------+ | | | 1674 | | | | | | +--------+ 1675 | | | | | | 1676 | | | | | | 1677 | +-----------+ | | +-----------+ | 1678 | | PT Client | |<------>| | PT Server | | 1679 | +-----------+ | PT-TLS | +-----------+ | 1680 | | | | 1681 +---------------+ +---------------+ 1683 Figure 8: Admin Searches for Vulnerable Endpoints 1685 The repository returns a list of entries matching the administrator's 1686 search. The administrator can then address the vulnerable endpoints 1687 by taking some follow-up action such as removing it from the network, 1688 quarantining it, or updating the vulnerable software. 1690 Appendix D. Change Log 1692 D.1. -05 to -00 1694 Changed the title of the draft to draft-ietf-sacm-epcp. 1696 Updated the diagram so the Endpoint and Posture Manager are the 1697 primary focus of EPCP. 1699 Added a reference to CoSWID in the Software Asset Management 1700 extension of the IETF NEA EPCP implementation. 1702 Further clarified the use of MAC addresses in EPCP. 1704 Included a requirement in the Privacy Considerations that the 1705 enterprise should exercise due diligence with respect to the privacy 1706 of certain data given privacy regulations. 1708 Added a requirement around an endpoint being provisioned with a 1709 machine certificate. 1711 Clarified that other protocols and interfaces may be supported beyond 1712 IETF NEA and NETCONF. 1714 Made various typographical and editorial changes. 1716 D.2. -04 to -05 1718 Updated the diagram so the Evaluator and Repository are "current 1719 work". 1721 Clarified how the Posture Collection Engine can push data, respond to 1722 queries, and establish secure transport connectivity for fulfilling 1723 subscriptions. 1725 Expanded on the future work around leveraging NETCONF, RESTCONF, and 1726 YANG Push for network devices. 1728 Documented the need to reassess MAC addresses as a device identifier. 1730 Made various typographical and editorial changes. 1732 D.3. -03 to -04 1734 Addressed various comments from the SACM WG. 1736 Refactored the document to better focus it on the communications 1737 between endpoints and the posture manager and the best practices for 1738 EPCP implementations. 1740 Made other editorial changes and improved consistency throughout the 1741 document. 1743 D.4. -02 to -03 1745 Addressed various comments from the SACM WG. 1747 Added a reference to TCG ECP 1.0. 1749 Removed text in the "SWID Posture Validator" section that states it 1750 performs evaluation. This was removed because it contradicts the 1751 posture manager not performing any evaluations. 1753 Expanded the "Provisioning" section of the "EPCP Transactions" 1754 section to include examples of endpoint identifiers and the need to 1755 provision endpoints with components and data models. 1757 Combined text for the capabilities of the Administrative Interface 1758 and API. 1760 Removed superfluous and introductory text from the "Security 1761 Considerations" section. 1763 Renamed section "Vulnerability Searches" to Vulnerability 1764 Management". 1766 Changed I-D category to BCP. 1768 Changed references to the NETMOD architecture to the NETCONF 1769 architecture because NETCONF represents the management protocol 1770 whereas NETMOD is focused on the definition of data models. 1772 Addressed various editorial suggestions. 1774 D.5. -01 to -02 1776 Addressed various comments from the SACM WG. 1778 Added a section for the collection of posture information from 1779 network devices using standards from the NETMOD WG. 1781 Updated EPCP component diagrams so they were not specific to a NEA- 1782 based implementation. 1784 Updated EPCP NEA example diagrams to reflect all the components in 1785 the NEA architecture. 1787 D.6. -00 to -01 1789 There are no textual changes associated with this revision. This 1790 revision simply reflects a resubmission of the document so that it 1791 remains in active status. 1793 D.7. -01 to -02 1795 Added references to the Software Inventory Message and Attributes 1796 (SWIMA) for PA-TNC I-D. 1798 Replaced references to PC-TNC with IF-IMC. 1800 Removed erroneous hyphens from a couple of section titles. 1802 Made a few minor editorial changes. 1804 D.8. -02 to -00 1806 Draft adopted by IETF SACM WG. 1808 D.9. -00 to -01 1810 Significant edits to up-level the draft to describe SACM collection 1811 over multiple different protocols. 1813 Replaced references to SANS with CIS. 1815 Made other minor editorial changes. 1817 Authors' Addresses 1819 Danny Haynes 1820 The MITRE Corporation 1821 202 Burlington Road 1822 Bedford, MA 01730 1823 USA 1825 Email: dhaynes@mitre.org 1827 Jessica Fitzgerald-McKay 1828 Department of Defense 1829 9800 Savage Road 1830 Ft. Meade, Maryland 1831 USA 1833 Email: jmfitz2@nsa.gov