idnits 2.17.1 draft-ietf-sacm-epcp-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: ---------------------------------------------------------------------------- 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 (February 25, 2020) is 1521 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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: Standards Track J. Fitzgerald-McKay 5 Expires: August 28, 2020 Department of Defense 6 February 25, 2020 8 Endpoint Posture Collection Profile 9 draft-ietf-sacm-epcp-01 11 Abstract 13 This document specifies the Endpoint Posture Collection Profile, 14 which describes the requirements 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 August 28, 2020. 37 Copyright Notice 39 Copyright (c) 2020 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. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 38 140 D.2. -05 to -00 . . . . . . . . . . . . . . . . . . . . . . . 38 141 D.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 39 142 D.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 39 143 D.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 40 144 D.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 40 145 D.7. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41 146 D.8. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 41 147 D.9. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 41 148 D.10. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 151 1. Introduction 153 The Endpoint Posture Collection Profile (EPCP) describes the 154 requirements for the collection and communication of posture 155 information from network-connected endpoints to a centralized server 156 leveraging prior work from the IETF NEA WG, the IETF NETCONF WG, IETF 157 NETMOD WG, the Trusted Computing Group (TCG) Trusted Network 158 Communications [TNC] Work Group, and the International Organization 159 for Standardization/International Electrotechnical Commission Joint 160 Technical Committee (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC 161 1, SC7, WG21). 163 This document focuses on reducing the security exposure of a network 164 by enabling: 166 o event-driven posture collection; 168 o standardized querying of additional posture information as needed; 170 o and the communication of that data to a centralized server where 171 it can be made available to other components. 173 Thus, eliminating the need for multiple collection tools on an 174 endpoint collecting the same data for different purposes. Future 175 revisions of this document may include support for the collection of 176 posture information from other endpoint types as well as a 177 standardized interface for storing and querying data in repositories 178 among other capabilities. Additional information about this future 179 work can be found in Section 5 of this document. 181 To support the collection of posture information from new endpoint 182 types, this document is organized such that it first provides a high- 183 level overview of EPCP as well as the abstract components and 184 transactions that will be realized by implementations (Section 2). 185 This is followed by individual sections that discuss the requirements 186 for specific implementations of the EPCP for a given endpoint type 187 (e.g., traditional workstations and servers, network devices, mobile 188 devices, etc.) along with any extensions for supported use cases 189 (software asset management, vulnerability management, etc.). Over 190 time, the requirements may be expanded to address issues that arise, 191 support new capabilities, or support new implementations beyond IETF 192 NEA and IETF NETCONF. 194 1.1. Conventions Used in This Document 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in 199 BCP14 [RFC2119][RFC8174] when, and only when, they appear in all 200 capitals, as shown here. 202 This specification does not distinguish blocks of informative 203 comments and normative requirements. Therefore, for the sake of 204 clarity, note that lower case instances of must, should, etc. do not 205 indicate normative requirements. 207 1.2. Terminology 209 This document uses terms as defined in [I-D.ietf-sacm-terminology] 210 unless otherwise specified. 212 2. Endpoint Posture Collection Profile 214 The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols, 215 and interfaces can be used to support the posture assessment of 216 endpoints on a network. This profile does not generate new data 217 models, protocols, or interfaces; rather, it offers requirements for 218 a full end-to-end solution for posture assessment, as well as a fresh 219 perspective on how existing standards can be leveraged against 220 vulnerabilities. Rationale for the EPCP solution as well as the 221 supported and non-supported use cases is available in Appendix A and 222 Appendix B respectively. 224 The EPCP makes it possible to perform posture assessments against all 225 network-connected endpoints by: 227 1. uniquely identifying the endpoint; 229 2. collecting and evaluating posture based on data from the endpoint 230 (asset management, software asset management, vulnerability 231 management, and configuration management); 233 3. creating a secure, authenticated, confidential channel between 234 the endpoint and the posture manager; 236 4. enabling the endpoint to notify the posture manager about changes 237 to its configuration; 239 5. enabling the posture manager to request information about the 240 configuration of the endpoint; and 242 6. storing the posture information in a repository linked to the 243 identifier for the endpoint. 245 Furthermore, the EPCP aims to support data storage and data sharing 246 capabilities to make the collected posture information available to 247 authorized parties and components in support of other post-processes 248 (analytic, access control, remediation, reporting, etc.). 250 2.1. Components 252 To support posture assessment, data storage, and data sharing 253 capabilities, the EPCP defines several components. Some of these 254 components reside on the target endpoint. Others reside on the 255 posture manager that manages communications with the target endpoint 256 and stores the target endpoint's posture information in a repository. 258 The primary focus of this document is on the communication between 259 the posture manager and endpoints through the posture collection 260 manager and posture collection engine components. While the 261 orchestrator, evaluator, repository, and API will be discussed in the 262 context of the EPCP, these components are for illustrative purposes 263 only and are not strictly defined nor are requirements provided for 264 them. As a result, vendors are free to implement these components 265 and interfaces in a way that makes the most sense for their products. 267 Orchestrator 268 +--------+ 269 | | 270 | | 271 | |<---+ 272 | | | 273 | | | ************Posture Collection Profile************* 274 | | | * * 275 +--------+ | * Posture Manager Endpoint * 276 | * +----------------+ +----------------+ * 277 publish/ | * | | | | * 278 subscribe | * | | | | * 279 +---->| | | | * 280 Repository * | | report/ | | * 281 +--------+ * | +------------+ | publish | +------------+ | * 282 | | store * | | | |<----------| | | | * 283 | |<-------->| | Posture | | | | Posture | | * 284 | | * | | Collection | | | | Collection | | * 285 | | * | | Manager | | query/ | | Engine | | * 286 | |<---+ * | | | | subscribe | | | | * 287 | | | * | | | |---------->| | | | * 288 +--------+ | * | +------------+ | | +------------+ | * 289 | * | | | | * 290 request/ | * | | | | * 291 response | * | | | | * 292 | * | | | | * 293 Evaluator | * +----------------+ +----------------+ * 294 +--------+ | * ^ ^ * 295 | | | ********|****|************************************* 296 | | | | +-------------+ 297 | |<---+ | | 298 | | | +-------------------------+ 299 | | | | Application Programming | 300 | | | | Interface (API) | 301 +--------+ | +-------------------------+ 302 ^ | 303 | query/response | 304 +---------------------+ 306 Figure 1: EPCP Components 308 2.1.1. Endpoint 310 An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is 311 monitored by the enterprise and is the target of posture assessments. 312 To support these posture assessments, posture information is 313 collected via a posture collection engine. 315 2.1.1.1. Posture Collection Engine 317 The posture collection engine is located on the target endpoint and 318 can either push data to the posture collection manager (see 319 Section 2.2.3) or receive queries for data from the posture 320 collection manager (see Section 2.2.4). The posture collection 321 engine sends collected posture information to the posture manager 322 where it can be sanity checked and stored in the repository. The 323 posture collection engine also contains a capability that sets up 324 exchanges between the target endpoint and posture manager. This 325 capability makes the posture collection engine responsible for 326 performing the client-side portion of encryption handshakes, and for 327 locating authorized posture managers with which to communicate. 329 2.1.2. Posture Manager 331 The posture manager is an endpoint that collects and validates 332 posture information received about a target endpoint. It also stores 333 the posture information it receives in the repository where it can be 334 retrieved and used in evaluations. The posture manager does not 335 evaluate the posture information. 337 2.1.2.1. Posture Collection Manager 339 The posture collection manager is a lightweight and extensible 340 component that facilitates the coordination and execution of posture 341 collection requests using collection mechanisms deployed across the 342 enterprise. The posture collection manager may query and retrieve 343 guidance from the repository to guide the collection of posture 344 information from the target endpoint. 346 The posture collection manager also contains a capability that sets 347 up exchanges between the target endpoint and the posture manager, and 348 manages data sent to and from the posture collection engine. It is 349 also responsible for performing the server-side portion of encryption 350 handshakes. 352 If the posture manager wants to register for the continuous 353 collection of endpoint posture changes with the endpoint, then it 354 must do so in a secure and scalable way. Specifically, it will need 355 to create subscriptions with endpoints in a way which allows the 356 posture data to be pushed. Effectively, this means that the target 357 endpoint must be able to establish secure transport connectivity to 358 the posture collection manager as needed, and the posture collection 359 manager must be able to periodically collect the current state of the 360 endpoint and assess its posture. 362 2.1.3. Repository 364 The repository hosts guidance, endpoint identification information, 365 and posture information reported by target endpoints where it is made 366 available to authorized components and persisted over a period of 367 time set by the administrator. Information stored in the repository 368 will be accessible to authorized parties via a standardized API. The 369 repository may be a standalone component or may be located on the 370 posture manager. Furthermore, an implementation is not restricted to 371 a single repository and may leverage several repositories to provide 372 this functionality. 374 2.1.4. Evaluator 376 The evaluator assesses the posture status of a target endpoint by 377 comparing collected posture information against the desired state of 378 the target endpoint specified in guidance. The evaluator queries and 379 retrieves the appropriate guidance from the repository as well as 380 queries and retrieves the posture information required for the 381 assessment from the repository. If the required posture information 382 is not available in the repository, the evaluator may request the 383 posture information from the posture collection manager, which will 384 result in the collection of additional posture information from the 385 target endpoint. This information is subsequently stored in the 386 repository where it is made available to the evaluator and other 387 components. The results of the assessment are stored in the 388 repository where they are available to tools and administrators for 389 post-processes including follow-up actions, further evaluation, and 390 historical purposes. The evaluator may also be triggered by events 391 on an endpoint or the network. 393 2.1.5. Orchestrator 395 The orchestrator provides a publish/subscribe interface for the 396 repository so that infrastructure endpoints can subscribe to and 397 receive published posture assessment results from the repository 398 regarding endpoint posture changes. 400 2.1.6. Application Programming Interface 402 The API allows authorized users, infrastructure endpoints, and 403 software to query the repository as well as manage endpoints and 404 other components used in EPCP via the posture manager. 406 2.2. Transactions 408 The following sections describe the transactions associated with EPCP 409 components and may be provided in an implementation. The 410 transactions span the deployment of an endpoint, integration into the 411 EPCP, data collection, and the storage and dissemination of that 412 information for different use cases. 414 2.2.1. Provisioning 416 An endpoint is provisioned with one or more attributes that will 417 serve as its unique identifier on the network as well as the 418 components (e.g., posture collection engine, etc.) and data models 419 (e.g., SWID) necessary to interact with the posture manager. 420 Examples of such attributes include serial numbers, hardware 421 certificates compliant with [IEEE-802-1ar], and the identities of 422 hardware cryptographic modules among others. An endpoint should also 423 have a MAC address which should change over time. Once provisioning 424 is complete, the endpoint is deployed on the network. Over time, 425 components and data models may need to be added to the endpoint or 426 updated to support the collection needs of an enterprise. 428 2.2.2. Discovery and Validation 430 If necessary, the target endpoint finds and validates the posture 431 manager. The posture collection engine on the target endpoint and 432 posture collection manager on the posture manager complete an 433 encryption handshake, during which endpoint identity information is 434 exchanged. 436 2.2.3. Event-Driven Collection 438 The posture assessment is initiated when the posture collector engine 439 on the target endpoint notices that relevant posture information on 440 the endpoint has changed. Then, the posture collection engine 441 initiates a posture assessment information exchange with the posture 442 collection manager. 444 2.2.4. Querying the Endpoint 446 The posture assessment is initiated by the posture collection 447 manager. This can occur because: 449 1. policy states that a previous assessment has become invalid, or 451 2. the posture collection manager is triggered by a sensor or an 452 administrator (via the posture manager's API) that an assessment 453 must be completed. 455 2.2.5. Data Storage 457 Once posture information is received by the posture manager, it is 458 forwarded to the repository. The repository could be co-located with 459 the posture manager, or standalone where the repository and posture 460 manager directly communicate with each other or the communication is 461 brokered through the orchestrator. The posture information is stored 462 in the repository along with past posture information collected about 463 the target endpoint. 465 2.2.6. Data Sharing 467 Because the target endpoint posture information was sent in 468 standards-based data models over secure, standardized protocols, and 469 then stored in a centralized repository linked to unique endpoint 470 identifiers, authorized parties are able to access the posture 471 information. Such authorized parties may include, but are not 472 limited to, administrators or endpoint owners (via the posture 473 manager's API), evaluators that access the repository directly, and 474 orchestrators that rely on publish/subscribe communications with the 475 repository. 477 3. IETF NEA EPCP Implementation for Traditional Endpoints 479 When EPCP is used, posture collectors running on the target endpoint 480 gather posture information as changes occur on the endpoint. The 481 posture information is aggregated by the posture broker client and 482 forwarded to a posture manager, over a secure channel, via the 483 posture transport client. Once received by the posture transport 484 server on the posture manager, the posture information is directed by 485 the posture broker server to the appropriate posture validators where 486 it can be processed and stored in a repository. There the posture 487 information can be used to carry out assessments or other post- 488 processing tasks. Posture collectors can also be queried by posture 489 validators to refresh posture information about the target endpoint 490 or to ask a specific question about posture information. This is 491 shown in Figure 2. 493 Posture Posture 494 Collection Collection 495 Manager Engine 496 +---------------+ +---------------+ 497 | | | | 498 | +-----------+ | PA-TNC | +-----------+ | 499 | | Posture | |--------| | Posture | | 500 | | Validator | | | | Collector | | 501 | +-----------+ | | +-----------+ | 502 | | | | | | 503 | | IF-IMV | | | IF-IMC | 504 | | | | | | 505 | +-----------+ | PB-TNC | +-----------+ | 506 | | PB Server | |--------| | PB Client | | 507 | +-----------+ | | +-----------+ | 508 | | | | | | 509 | | | | | | 510 | | | | | | 511 | +-----------+ | | +-----------+ | 512 | | PT Server | |<------>| | PT Client | | 513 | +-----------+ | PT-TLS | +-----------+ | 514 | | | | 515 +---------------+ +---------------+ 517 Figure 2: NEA Components 519 These requirements are written with a view to performing a posture 520 assessment on an endpoint and refer to defined components of the NEA 521 architecture [RFC5209] as well as the IF-IMV [IF-IMV] and IF-IMC 522 [IF-IMC] interfaces defined in the Trusted Computing Group's TNC Work 523 Group. As with the NEA architecture, vendors have discretion as to 524 how these NEA components map to separate pieces of software or 525 endpoints. 527 It should be noted that the posture broker client and posture 528 transport client components of the posture collection engine and the 529 posture broker server and posture transport server components of the 530 posture collection manager would likely need to be implemented by a 531 single vendor because there are no standardized interfaces between 532 the respective components and would not be interoperable. 534 Examples of the EPCP as implemented using the components from the NEA 535 architecture are provided in Appendix C. 537 3.1. Endpoint Provisioning 539 An endpoint SHOULD be provisioned with a machine certificate that 540 will serve as its unique identifier on the network as well as the 541 components necessary to interact with the posture manager. This 542 includes a posture collection engine to manage requests from the 543 posture manager and the posture collectors necessary to collect the 544 posture information of importance to the enterprise. The endpoint is 545 deployed on the network. 547 The target endpoint SHOULD authenticate to the posture manager using 548 a machine certificate during the establishment of the outer tunnel 549 achieved with the posture transport protocol defined in [RFC6876]. 550 [IF-IMV] specifies how to pull an endpoint identifier out of a 551 machine certificate. An endpoint identifier SHOULD be created in 552 conformance with [IF-IMV] from a machine certificate sent via 553 [RFC6876]. 555 Other authenticators are possible. The target endpoint MAY 556 authenticate to the posture manager using a combination of the 557 machine account and password; however, this is less secure and not 558 recommended. A more secure approach would leverage a hardware 559 certificate compliant with [IEEE-802-1ar]; this identifier SHOULD be 560 associated with the identity of a hardware cryptographic module, in 561 accordance with [IEEE-802-1ar], if present on the endpoint. The 562 enterprise SHOULD establish a certificate root authority; install its 563 root certificate on endpoints and on the posture manager; and 564 provision the endpoints and the posture manager with machine 565 certificates. 567 3.2. Endpoint 569 The endpoint MUST conform to [RFC5793], which levies several 570 requirements against the endpoint. An endpoint that complies with 571 these requirements will be able to: 573 1. attempt to initiate a session with the posture manager if the 574 posture makes a request to send an update to the posture manager; 576 2. notify the posture collector if no PT-TLS session with the 577 posture manager can be created; 579 3. notify the posture collector when a PT-TLS session is 580 established; and 582 4. receive information from the posture collectors, forward this 583 information to the posture manager via the posture collection 584 engine. 586 3.2.1. Posture Collector 588 Any posture collector used in an EPCP solution MUST be conformant 589 with the TCG TNC Integrity Measurement Collector interface [IF-IMC]. 591 3.2.2. Posture Broker Client 593 The posture broker client MUST conform to [IF-IMC] to enable 594 communications between the posture broker client and the posture 595 collectors on the endpoint. 597 3.2.3. Posture Transport Client 599 The posture transport client MUST implement PT-TLS. 601 The posture transport client MUST support the use of machine 602 certificates for TLS at each endpoint consistent with the 603 requirements stipulated in [RFC6876] and [Server-Discovery]. 605 The posture transport client MUST be able to locate an authorized 606 posture manager, and switch to a new posture manager when required by 607 the network, in conformance with [Server-Discovery]. 609 3.3. Posture Manager 611 The posture manager MUST conform to all requirements in [RFC5793]. 613 3.3.1. Posture Validator 615 Any posture validator used in an EPCP solution MUST be conformant 616 with the TCG TNC Integrity Measurement Verifier interface [IF-IMV]. 618 3.3.2. Posture Broker Server 620 The posture broker server MUST conform to [IF-IMV]. Conformance to 621 [IF-IMV] enables the posture broker server to obtain endpoint 622 identity information from the posture transport server, and pass this 623 information to any posture validators on the posture manager. 625 3.3.3. Posture Transport Server 627 The posture transport server MUST implement PT-TLS. 629 The posture transport server MUST support the use of machine 630 certificates for TLS at each endpoint consistent with the 631 requirements stipulated in [RFC6876] and [Server-Discovery]. 633 3.4. Repository 635 EPCP requires a simple interface for the repository. Posture 636 validators on the posture manager receive the target endpoint posture 637 information via PA-TNC [RFC5792] messages sent from corresponding 638 posture collectors on the target endpoint. The posture validators 639 store this information in the repository linked to the identity of 640 the target endpoint where the posture collectors are located. 642 3.5. IETF SACM Software Asset Management Extension to the IETF NEA EPCP 643 Implementation 645 This section defines the requirements associated with the Software 646 Inventory Message and Attributes (SWIMA) extension for PA-TNC 647 [RFC8412] in support of the software asset management use case with 648 the IETF NEA EPCP implementation. 650 3.5.1. Endpoint Pre-Provisioning 652 The following requirements assume that the platform or OS vendor 653 supports the use of [SWID] and/or [I-D.ietf-sacm-coswid] tags and the 654 standard directory locations for the SWID and CoSWID tags as 655 specified by the [SWID] specification. 657 3.5.2. SWID Tags 659 The primary content for the EPCP is the information conveyed in the 660 elements of a SWID or CoSWID tag. The SWID specification defines an 661 XML-based software identification tag and the CoSWID specification 662 defines a Concise Binary Object Representation (CBOR) that is 663 compatible with the SWID specification. CoSWID tags require 664 significantly less memory and bandwidth to store and transmit as 665 compared to the traditional XML-based SWID tags. 667 For readability, since CoSWID is a concise representation of SWID, 668 only SWID is used throughout the remainder of this document although 669 CoSWID may be used in addition to, or in place of, SWID. 671 The endpoint MUST have SWID tags stored in a directory specified in 672 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 673 also be generated by: 675 o the software installer; or 677 o third-party software that creates tags based on the applications 678 it sees installed on the endpoint. 680 The elements in the SWID tag MUST be populated as specified in 681 [SWID]. These tags, and the directory in which they are stored, MUST 682 be updated as software is added, removed, or updated. 684 3.5.3. SWID Posture Collectors and Posture Validators 686 The following sections outline the requirements for SWID Posture 687 Collectors and Posture Validators. 689 3.5.3.1. The SWID Posture Collector 691 For the EPCP, the SWID posture collector MUST be conformant with 692 [RFC8412], which includes requirements for: 694 1. Collecting SWID tags from the SWID directory; 696 2. Monitoring the SWID directory for changes; 698 3. Initiating a session with the posture manager to report changes 699 to the directory; 701 4. Maintaining a list of changes to the SWID directory when updates 702 take place and no PT-TLS connection can be created with the 703 posture manager; 705 5. Responding to a request for SWID tags from the SWID Posture 706 Validator on the posture manager; and 708 6. Responding to a query from the SWID posture validator as to 709 whether all updates have been sent. 711 The SWID posture collector is not responsible for detecting that the 712 SWID directory was not updated when an application was either 713 installed or uninstalled. 715 3.5.3.2. The SWID Posture Validator 717 Conformance to [RFC8412] enables the SWID posture validator to: 719 1. Send messages to the SWID posture collector (at the behest of the 720 administrator at the posture manager console) requesting updates 721 for SWID tags located on endpoint; 723 2. Ask the SWID posture collector whether all updates to the SWID 724 directory located at the posture manager have been sent; and 726 3. Perform any validation and processing on the collected SWID 727 posture information prior to storage. 729 In addition to these requirements, a SWID posture validator used in 730 conformance with this profile MUST be capable of passing this SWID 731 posture information as well as the associated endpoint identity to 732 the repository for storage. 734 3.5.4. Repository 736 The interface SHOULD enable an administrator to: 738 1. Query which endpoints have reported SWID tags for a particular 739 application 741 2. Query which SWID tags are installed on an endpoint; and 743 3. Query tags based on characteristics, such as vendor, publisher, 744 etc. 746 4. IETF NETCONF EPCP Implementation for Network Device Endpoints 748 When EPCP is used, a NETCONF client that implements the posture 749 collection manager sends a query to target network device endpoint 750 requesting posture information over a secure channel. Once the 751 NETCONF server on the endpoint receives the request, it queries one 752 or more datastores for the posture information. The NETCONF server 753 then reports the information back to the NETCONF client where it can 754 be stored in a repository for use by other tools. This is shown in 755 Figure 3. 757 Posture Posture 758 Collection Collection 759 Manager Engine 760 +---------------+ +---------------+ 761 | | | | 762 | | | +-----------+ | 763 | | | | Data | | 764 | | | | Store(s) | | 765 | | | +-----------+ | 766 | | | | | 767 | | | | | 768 | +-----------+ | | +-----------+ | 769 | | NETCONF | | | | NETCONF | | 770 | | Client | |<------->| | Server | | 771 | +-----------+ | NETCONF | +-----------+ | 772 | | | | 773 +---------------+ +---------------+ 775 Figure 3: NETCONF Components 777 These requirements are written with a view to performing a posture 778 assessment on network device endpoints (routers, switches, etc.) and 779 refer to defined components of the NETCONF architecture and map back 780 to EPCP. As with the NETCONF architecture, vendors have discretion 781 as to how these NETCONF components map to separate pieces of software 782 or endpoints. 784 4.1. Endpoint Provisioning 786 For the posture manager to be able to query the datastores on the 787 endpoint, the endpoint MUST be configured to grant the posture 788 manager access to its datastores as described in [RFC6241]. The 789 posture manager is identified by its NETCONF username. The endpoint 790 is deployed on the network. 792 4.2. Posture Manager Provisioning 794 For the posture manager to be able to query the datastores on the 795 endpoint, the posture manager MUST be provisioned with a NETCONF 796 username that will be used to authenticate the posture manager to the 797 endpoint as described in [RFC6241]. The username generated will be 798 determined by the selected transport protocol. The posture manager 799 is deployed on the network. 801 4.3. Endpoint 803 An endpoint MUST conform to the requirements outlined for servers in 804 the NETCONF protocol as defined in [RFC6241]. This requires the 805 implementation of NETCONF over SSH [RFC6242]. An endpoint MAY 806 support the NETCONF protocol over other transports such as TLS 807 [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040]. 809 4.3.1. Datastore 811 A NETCONF datastore on an endpoint MUST support the operations 812 outlined in [RFC6241], but, the actual implementation of the 813 datastore is left to the endpoint vendor. 815 Datastores MUST support the YANG data modeling language [RFC7950] for 816 expressing endpoint posture information in a structured format. In 817 addition, datastores MAY support other data models such as XML (via 818 YIN) for representing posture information. 820 Datastores MUST support the compliance posture information specified 821 in [RFC7317]. Datastores MAY support other models standardized or 822 proprietary as deemed appropriate by the endpoint vendor. 824 4.4. Posture Manager 826 A posture manager MUST conform to the requirements specified for 827 clients in the NETCONF protocol as defined in [RFC6241]. This 828 requires the implementation of NETCONF over SSH [RFC6242]. A posture 829 manager MAY also support the NETCONF protocol over other transports 830 such as TLS [RFC7589]. In addition, a posture manager MAY support 831 the RESTCONF protocol as defined in [RFC8040]. 833 4.5. Repository 835 EPCP requires a simple interface for the repository. The posture 836 collection manager on the posture manager receives the target 837 endpoint posture information via NETCONF [RFC6241] messages sent from 838 posture collection engine on the target endpoint. The posture 839 collection manager stores this information in the repository linked 840 to the identity of the target endpoint from which it was collected. 842 5. Future Work 844 This section captures ideas for future work related to EPCP that 845 might be of interest to the IETF SACM WG. These ideas are listed in 846 no particular order. 848 o [RFC8639], [RFC8640], and [RFC8641] could be leveraged for an 849 HTTP-based subscription for EPCP. Specifically, it could be used 850 for the posture collection manager to continuously receive posture 851 changes as they happen from the posture collection engine. At 852 this point, it seems like [I-D.ietf-netconf-restconf-notif] would 853 be a good match to these requirements. However, further 854 investigation into the applicability of supporting a RESTCONF 855 server capability to handle subscription requests needs to be 856 made. Specific questions which should be examined include: 858 * Number of endpoints which can be continuously tracked by a 859 single posture collection manager. Scalability questions to be 860 considered include elements from the number of transport 861 connections maintained as well as the volume and churn of 862 posture evidence which will be continuously pushed to the 863 posture collection manager. 865 * Ability of the posture collection manager to establish and 866 maintain a continuous state of endpoint posture during 867 failures. This includes failures/reboots on either side of the 868 interface. 870 * Ability to support the full set of functions described for 871 NETCONF within Section 4. 873 o Add support endpoint types beyond workstations, servers, and 874 network infrastructure devices. 876 o Examine the integration of [I-D.ietf-mile-xmpp-grid]. 878 o Define a standard interface and API for interacting with the 879 repository. Requirements to consider include: creating a secure 880 channel between a publisher and the repository, creating a secure 881 channel between a subscriber and the repository, and the types of 882 interactions that must be supported between publishers and 883 subscribers to a repository. 885 o Define a standard interface for communications between the posture 886 broker client and posture transport client(s) as well as the 887 posture broker server and posture transport server(s). 889 o Retention of posture information on the target endpoint. 891 o Define an orchestrator component as well as publish/subscribe 892 interface for it. 894 o Define an evaluator component as well as an interface for it. 896 o Reassess the use of MAC addresses as a device identifier among 897 network tools, based on technical research into current security 898 best practices in IoT, automotive, mobile, and other privacy- 899 sensitive market domains. 901 6. Contributors 903 The authors wish to thank all of those in the TCG TNC work group who 904 contributed to development of the TNC ECP specification [ECP] upon 905 which this document is based. 907 The authors also wish to give a special thanks to Henk Birkholz, Dan 908 Ehrlich, Ira McDonald, Kathleen Moriarty, David Oliva, and Eric Voit 909 for their thoughtful comments and edits to this document. 911 7. IANA Considerations 913 This document does not define any new IANA registries. However, this 914 document does reference other documents that do define IANA 915 registries. As a result, the IANA Considerations section of the 916 referenced documents should be consulted. 918 8. Security Considerations 920 This Security Considerations section includes an analysis of the 921 attacks that may be mounted against systems that implement the EPCP 922 (Section 8.1) and the countermeasures that may be used to prevent or 923 mitigate these attacks (Section 8.2). Overall, a substantial 924 reduction in cyber risk can be achieved. 926 8.1. Threat Model 928 This section lists the attacks that can be mounted on a NEA 929 implementation of an EPCP environment. The following section 930 (Section 8.2) describes countermeasures. 932 Because the EPCP describes a specific use case for NEA components, 933 many security considerations for these components are addressed in 934 more detail in the technical specifications: [RFC8412], [IF-IMC], 935 [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV]. 937 8.1.1. Endpoint Attacks 939 While the EPCP provides substantial improvements in endpoint 940 security, endpoints can still be compromised. For this reason, all 941 parties must regard data coming from endpoints as potentially 942 unreliable or even malicious. An analogy can be drawn with human 943 testimony in an investigation or trial. Human testimony is essential 944 but must be regarded with suspicion. 946 o Compromise of endpoint: A compromised endpoint may report false 947 information to confuse or even provide maliciously crafted 948 information with a goal of infecting others. 950 o Putting bad information in SWID directory: Even if an endpoint is 951 not completely compromised, some of the software running on it may 952 be unreliable or even malicious. This software, potentially 953 including the SWID generation or discovery tool, or malicious 954 software pretending to be a SWID generation or discovery tool, can 955 place incorrect or maliciously crafted information into the SWID 956 directory. Endpoint users may even place such information in the 957 directory, whether motivated by curiosity or confusion or a desire 958 to bypass restrictions on their use of the endpoint. 960 o Identity spoofing (impersonation): A compromised endpoint may 961 attempt to impersonate another endpoint to gain its privileges or 962 to besmirch the reputation of that other endpoint. This is of 963 particular concern when using MAC addresses to identify endpoints, 964 which while widely used in endpoint behavior monitoring and threat 965 assessment tools, are easy to spoof. 967 8.1.2. Network Attacks 969 Generally, the network cannot be trusted. A variety of attacks can 970 be mounted using the network, including: 972 o Eavesdropping, modification, injection, replay, deletion; 974 o Traffic analysis; and 976 o Denial of service and blocking traffic. 978 8.1.3. Posture Manager Attacks 980 The posture manager is a critical security element and therefore 981 merits considerable scrutiny. A variety of attacks can be leveraged 982 against the Posture Manager. 984 o Compromised trusted posture manager: A compromised posture manager 985 or a malicious party that is able to impersonate a posture manager 986 can incorrectly grant or deny access to endpoints, place incorrect 987 information into the repository, or send malicious messages to 988 endpoints. 990 o Misconfiguration of posture manager: Accidental or purposeful 991 misconfiguration of a trusted posture manager can cause effects 992 that are similar to those listed for "Compromised trusted posture 993 manager". 995 o Malicious untrusted posture manager: An untrusted posture manager 996 cannot mount any significant attacks because all properly 997 implemented endpoints will refuse to engage in any meaningful 998 dialog with such a posture manager. 1000 8.1.4. Repository Attacks 1002 The repository is also an important security element and therefore 1003 merits careful scrutiny. 1005 o Putting bad information into trusted repository: An authorized 1006 repository client such as a server may be able to put incorrect 1007 information into a trusted repository or delete or modify 1008 historical information, causing incorrect decisions about endpoint 1009 security. Placing maliciously crafted data in the repository 1010 could even lead to the compromise of repository clients, if they 1011 fail to carefully check such data. 1013 o Compromised trusted repository: A compromised trusted repository 1014 or a malicious untrusted repository that is able to impersonate a 1015 trusted repository can lead to effects similar to those listed for 1016 "Putting bad information into trusted repository". Further, a 1017 compromised trusted repository can report different results to 1018 different repository clients or deny access to the repository for 1019 selected repository clients. 1021 o Misconfiguration of trusted repository: Accidental or purposeful 1022 misconfiguration of a trusted repository can deny access to the 1023 repository or result in loss of historical data. 1025 o Malicious untrusted repository: An untrusted repository cannot 1026 mount any significant attacks because all properly implemented 1027 repository clients will refuse to engage in any meaningful dialog 1028 with such a repository. 1030 8.2. Countermeasures 1032 This section lists the countermeasures that can be used in a NEA 1033 implementation of an EPCP environment. 1035 8.2.1. Countermeasures for Endpoint Attacks 1037 This profile is in and of itself a countermeasure for a compromised 1038 endpoint. A primary defense for an endpoint is to run up to date 1039 software configured to be run as safely as possible. 1041 Ensuring that anti-virus signatures are up to date and that a 1042 firewall is configured are also protections for an endpoint that are 1043 supported by the current NEA specifications. 1045 For secure device identification and to correlate device identifiers 1046 if the MAC address is randomized, MAC addresses should be collected 1047 along with other, more secure endpoint identifiers. Endpoints that 1048 have hardware cryptographic modules that are provisioned by the 1049 enterprise, in accordance with [IEEE-802-1ar], can protect the 1050 private keys used for authentication and help prevent adversaries 1051 from stealing credentials that can be used for impersonation. Future 1052 versions of the EPCP may want to discuss in greater detail how to use 1053 a hardware cryptographic module, in accordance with [IEEE-802-1ar], 1054 to protect credentials and to protect the integrity of the code that 1055 executes during the bootstrap process by hashing or recording 1056 indicators of compromise. 1058 8.2.2. Countermeasures for Network Attacks 1060 To address network attacks, [RFC6876] includes required encryption, 1061 authentication, integrity protection, and replay protection. 1062 [Server-Discovery] also includes authorization checks to ensure that 1063 only authorized servers are trusted by endpoints. Any unspecified or 1064 not yet specified network protocols employed in the EPCP (e.g., the 1065 protocol used to interface with the repository) should include 1066 similar protections. 1068 These protections reduce the scope of the network threat to traffic 1069 analysis and denial of service. Countermeasures for traffic analysis 1070 (e.g., masking) are usually impractical but may be employed. 1071 Countermeasures for denial of service (e.g., detecting and blocking 1072 particular sources) SHOULD be used when appropriate to detect and 1073 block denial of service attacks. These are routine practices in 1074 network security. 1076 8.2.3. Countermeasures for Posture Manager Attacks 1078 Because of the serious consequences of posture manager compromise, 1079 posture managers SHOULD be especially well-hardened against attack 1080 and minimized to reduce their attack surface. They SHOULD be 1081 monitored using the NEA protocols to ensure the integrity of the 1082 behavior and analysis data stored on the posture manager and SHOULD 1083 utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for 1084 identity and/or integrity measurements of the posture manager. They 1085 should be well-managed to minimize vulnerabilities in the underlying 1086 platform and in systems upon which the posture manager depends. 1087 Network security measures such as firewalls or intrusion detection 1088 systems may be used to monitor and limit traffic to and from the 1089 posture manager. Personnel with administrative access to the posture 1090 manager should be carefully screened and monitored to detect problems 1091 as soon as possible. Posture manager administrators should not use 1092 password-based authentication but should instead use non-reusable 1093 credentials and multi-factor authentication (where available). 1094 Physical security measures should be employed to prevent physical 1095 attacks on posture managers. 1097 To ease detection of posture manager compromise, should it occur, 1098 posture manager behavior should be monitored to detect unusual 1099 behavior (such as a server reboot, unusual traffic patterns, or other 1100 odd behavior). Endpoints should log and/or notify users and/or 1101 administrators when peculiar posture manager behavior is detected. 1102 To aid forensic investigation, permanent read-only audit logs of 1103 security-relevant information pertaining to posture manager 1104 (especially administrative actions) should be maintained. If posture 1105 manager compromise is detected, the posture manager's certificate 1106 should be revoked and careful analysis should be performed of the 1107 source and impact of this compromise. Any reusable credentials that 1108 may have been compromised should be reissued. 1110 Endpoints can reduce the threat of server compromise by minimizing 1111 the number of trusted posture managers, using the mechanisms 1112 described in [Server-Discovery]. 1114 8.2.4. Countermeasures for Repository Attacks 1116 If the host for the repository is located on its own endpoint, it 1117 should be protected with the same measures taken to protect the 1118 posture manager. In this circumstance, all messages between the 1119 posture manager and repository should be protected with a mature 1120 security protocol such as TLS or IPsec. 1122 The repository can aid in the detection of compromised endpoints if 1123 an adversary cannot tamper with its contents. For instance, if an 1124 endpoint reports that it does not have an application with a known 1125 vulnerability installed, an administrator can check whether the 1126 endpoint might be lying by querying the repository for the history of 1127 what applications were installed on the endpoint. 1129 To help prevent tampering with the information in the repository: 1131 1. Only authorized parties should have privilege to run code on the 1132 endpoint and to change the repository. 1134 2. If a separate endpoint hosts the repository, then the 1135 functionality of that endpoint should be limited to hosting the 1136 repository. The firewall on the repository should only allow 1137 access to the posture manager and to any endpoint authorized for 1138 administration. 1140 3. The repository should ideally use "write-once" media to archive 1141 the history of what was placed in the repository, to include a 1142 snapshot of the current status of applications on endpoints. 1144 9. Privacy Considerations 1146 The EPCP specifically addresses the collection of posture data from 1147 enterprise endpoints by an enterprise network. As such, privacy is a 1148 fundamental concern for those deploying this EPCP solution, given EU 1149 GDPR, California CCPA, and many other privacy regulations. The 1150 enterprise SHOULD implement and enforce their duty of care. 1152 A possible exception may be the concerns a user may have when 1153 attempting to connect a personal endpoint (such as a phone or mobile 1154 endpoint) to an enterprise network. The user may not want to share 1155 certain details, such as an endpoint identifier or SWID tags, with 1156 the enterprise. The user can configure their NEA client to reject 1157 requests for this information; however, it is possible that the 1158 enterprise policy will not allow the user's endpoint to connect to 1159 the network without providing the requested data. 1161 An enterprise network SHOULD limit access to endpoint posture and 1162 identification information to authorized users and SHOULD enforce 1163 policies that prevent the export of endpoint posture metadata to 1164 unauthorized third parties. 1166 10. References 1168 10.1. Informative References 1170 [CIS] http://www.cisecurity.org/controls/, "CIS Critical 1171 Security Controls". 1173 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1174 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1175 Protect Your ICT System", November 2012. 1177 [ECP] Trusted Computing Group, "TCG Trusted Network Connect 1178 Endpoint Compliance Profile, Version 1.10", December 2014. 1180 [IEEE-802-1ar] 1181 Institute of Electrical and Electronics Engineers, "IEEE 1182 802.1ar", December 2009. 1184 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1185 Tardo, "Network Endpoint Assessment (NEA): Overview and 1186 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1187 . 1189 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1190 Architecture for Interoperability, Version 1.5", February 1191 2012. 1193 10.2. Normative References 1195 [I-D.ietf-mile-xmpp-grid] 1196 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 1197 "Using XMPP for Security Information Exchange", draft- 1198 ietf-mile-xmpp-grid-04 (work in progress), October 2017. 1200 [I-D.ietf-netconf-restconf-notif] 1201 Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 1202 A. Bierman, "Dynamic subscription to YANG Events and 1203 Datastores over RESTCONF", draft-ietf-netconf-restconf- 1204 notif-15 (work in progress), June 2019. 1206 [I-D.ietf-sacm-coswid] 1207 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1208 Waltermire, "Concise Software Identification Tags", draft- 1209 ietf-sacm-coswid-12 (work in progress), July 2019. 1211 [I-D.ietf-sacm-terminology] 1212 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1213 Winget, "Terminology for Security Assessment", draft-ietf- 1214 sacm-terminology-05 (work in progress), August 2014. 1216 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1217 IF-IMC, Version 1.3", February 2013. 1219 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1220 IF-IMV, Version 1.4", December 2014. 1222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1223 Requirement Levels", BCP 14, RFC 2119, 1224 DOI 10.17487/RFC2119, March 1997, 1225 . 1227 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1228 (PA) Protocol Compatible with Trusted Network Connect 1229 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1230 . 1232 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1233 A Posture Broker (PB) Protocol Compatible with Trusted 1234 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1235 March 2010, . 1237 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1238 and A. Bierman, Ed., "Network Configuration Protocol 1239 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1240 . 1242 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1243 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1244 . 1246 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1247 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1248 DOI 10.17487/RFC6876, February 2013, 1249 . 1251 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1252 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1253 2014, . 1255 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1256 NETCONF Protocol over Transport Layer Security (TLS) with 1257 Mutual X.509 Authentication", RFC 7589, 1258 DOI 10.17487/RFC7589, June 2015, 1259 . 1261 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1262 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1263 . 1265 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1266 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1267 . 1269 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1270 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1271 May 2017, . 1273 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1274 J. Fitzgerald-McKay, "Software Inventory Message and 1275 Attributes (SWIMA) for PA-TNC", RFC 8412, 1276 DOI 10.17487/RFC8412, July 2018, 1277 . 1279 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1280 E., and A. Tripathy, "Subscription to YANG Notifications", 1281 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1282 . 1284 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1285 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1286 and Datastores over NETCONF", RFC 8640, 1287 DOI 10.17487/RFC8640, September 2019, 1288 . 1290 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1291 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1292 September 2019, . 1294 [Server-Discovery] 1295 Trusted Computing Group, "DRAFT: TCG Trusted Network 1296 Connect PDP Discovery and Validation, Version 1.0", 1297 October 2015. 1299 [SWID] "Information technology--Software asset management--Part 1300 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1302 Appendix A. Rationale for an EPCP Solution 1304 A.1. Preventative Posture Assessments 1306 The value of continuous endpoint posture assessment is well 1307 established. Security experts have identified asset management and 1308 vulnerability remediation as a critical step for preventing 1309 intrusions. Application whitelisting, patching applications and 1310 operating systems, and using the latest versions of applications top 1311 the Defense Signals Directorate's "Top 4 Mitigations to Protect Your 1312 ICT System". [DSD] "Inventory of Authorized and Unauthorized 1313 Endpoints", "Inventory of Authorized and Unauthorized Software", and 1314 "Continuous Vulnerability Assessment and Remediation" are Controls 1, 1315 2, and 3, respectively, of the CIS Controls [CIS]. While there are 1316 commercially available solutions that attempt to address these 1317 security controls, these solutions do not: 1319 o run on all types of endpoints; 1321 o consistently interoperate with other tools that could make use of 1322 the data collected; 1324 o collect posture information from all types of endpoints in a 1325 consistent, standardized schema; 1327 o require vetted, standardized protocols that have been evaluated by 1328 the international community for cryptographic soundness. 1330 As is true of most solutions offered today, the solution found in the 1331 EPCP does not attempt to solve the lying endpoint problem, or detect 1332 infected endpoints; rather, it focuses on ensuring that healthy 1333 endpoints remain healthy by keeping software up-to-date and patched. 1335 A.2. All Network-Connected Endpoints are Endpoints 1337 As defined by [I-D.ietf-sacm-terminology], an endpoint is any 1338 physical or virtual computing endpoint that can be connected to a 1339 network. Posture assessment against policy is equally, if not more, 1340 important for continuously-connected endpoints, such as enterprise 1341 workstations and infrastructure endpoints, as it is for sporadically 1342 connected endpoints. Continuously-connected endpoints are just as 1343 likely to fall out of compliance with policy, and a standardized 1344 posture assessment method is necessary to ensure they can be properly 1345 handled. 1347 A.3. All Endpoints on the Network Must be Uniquely Identified 1349 Many administrators struggle to identify what endpoints are connected 1350 to the network at any given time. By requiring a standardized method 1351 of endpoint identity, the EPCP will enable administrators to answer 1352 the basic question, "What is on my network?" In 1353 [I-D.ietf-sacm-terminology], SACM defines this set of endpoints on 1354 the network as the SACM domain. Unique endpoint identification also 1355 enables the comparison of current and past endpoint posture 1356 assessments, by allowing administrators to correlate assessments from 1357 the same endpoint. This makes it easier to flag suspicious changes 1358 in endpoint posture for manual or automatic review, and helps to 1359 swiftly identify malicious changes to endpoint applications. 1361 A.4. Standardized Data Models 1363 EPCP requirements prescribe the use of standardized data models for 1364 the exchange of posture information. This helps to ensure that the 1365 posture information sent from endpoints to the repository can be 1366 easily stored, due to their known format, and shared with authorized 1367 endpoints and users. 1369 Posture information must be sent over standardized protocols to 1370 ensure the confidentiality and authenticity of this data while in 1371 transit. Implementations of the EPCP include [RFC6876] and [RFC6241] 1372 for communication between the target endpoint and the posture 1373 manager. These protocols allow networks that implement this solution 1374 to collect large amounts of posture information from an endpoint to 1375 make decisions about that endpoint's compliance with some policy. 1376 The EPCP offers a solution for all endpoints already connected to the 1377 network. Periodic assessments and automated reporting of changes to 1378 endpoint posture allow for instantaneous identification of connected 1379 endpoints that are no longer compliant with some policy. 1381 A.5. Posture Information Must Be Stored 1383 Posture information must be stored by the repository and must be 1384 exposed to an interface at the posture manager. Standardized data 1385 models enable standardized queries from an interface exposed to an 1386 administrator at the posture manager. A repository must retain any 1387 current posture information retrieved from the target endpoint and 1388 store it indexed by the unique identifier for the endpoint. Any 1389 posture collection manager specified by this profile must be able to 1390 ascertain from its corresponding posture collection engine whether 1391 the posture information is up to date. An interface on the posture 1392 manager must support a request to obtain up-to-date information when 1393 an endpoint is connected. This interface must also support the 1394 ability to make a standard set of queries about the posture 1395 information stored by the repository. In the future, some forms of 1396 posture information might be retained at the endpoint. The interface 1397 on the posture manager must accommodate the ability to make a request 1398 to the corresponding posture collection engine about the posture of 1399 the target endpoint. Standardized data models and protocols also 1400 enable the security of posture assessment results. By storing these 1401 results indexed under the endpoint's unique identifier, secure 1402 storage itself enables endpoint posture information correlation, and 1403 ensures that the enterprise's repositories always offer the freshest, 1404 most up-to-date view of the enterprise's endpoint posture information 1405 possible. 1407 A.6. Posture Information Can Be Shared 1409 By exposing posture information using a standardized interface and 1410 API, other security and operational components have a high level of 1411 insight into the enterprise's endpoints and the software installed on 1412 them. This will support innovation in the areas of asset management, 1413 vulnerability scanning, and interfaces, as any authorized 1414 infrastructure endpoint can interact with the posture information. 1416 A.7. Enterprise Asset Posture Information Belongs to the Enterprise 1418 Owners and administrators must have complete control of posture 1419 information, policy, and endpoint mitigation. Standardized data 1420 models, protocols and interfaces help to ensure that this posture 1421 information is not locked in proprietary databases, but is made 1422 available to its owners. This enables administrators to develop as 1423 nuanced a policy as necessary to keep their networks secure. Of 1424 course, there may be exceptions to this such as the case with 1425 privacy-related information (e.g., personally identifiable 1426 information). 1428 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 1430 B.1. Supported Use Cases 1432 The following sections describe the different use cases supported by 1433 the EPCP. 1435 B.1.1. Hardware Asset Management 1437 Using the API on the posture manager, an authorized user can learn: 1439 o what endpoints are connected to the network at any given time; and 1441 o what SWID tags were reported for the endpoints. 1443 The ability to answer these questions offers a standards-based 1444 approach to asset management, which is a vital part of enterprise 1445 processes such as compliance report generation for the Federal 1446 Information Security Modernization Act (FISMA), Payment Card Industry 1447 Data Security Standard (PCI DSS), Health Insurance Portability and 1448 Accountability Act (HIPAA), etc. 1450 B.1.2. Software Asset Management 1452 The API on the posture manager provides the ability for authorized 1453 users and infrastructure to know which software is installed on which 1454 endpoints on the enterprise's network. This allows the enterprise to 1455 answer questions about what software is installed to determine if it 1456 is licensed or prohibited. This information can also drive other use 1457 cases such as: 1459 o vulnerability management: knowing what software is installed 1460 supports the ability to determine which endpoints contain 1461 vulnerable software and need to be patched. 1463 o configuration management: knowing which security controls need to 1464 be applied to harden installed software and better protect 1465 endpoints. 1467 B.1.3. Vulnerability Management 1469 The API also provides the ability for authorized users or 1470 infrastructure to locate endpoints running software for which 1471 vulnerabilities have been announced. Because of 1473 1. the unique IDs assigned to each endpoint; and 1475 2. the rich application data provided in the endpoints' posture 1476 information, 1478 the repository can be queried to find all endpoints running a 1479 vulnerable application. Endpoints suspected of being vulnerable can 1480 be addressed by the administrator or flagged for further scrutiny. 1482 B.1.4. Threat Detection and Analysis 1484 The repository's standardized API allows authorized infrastructure 1485 endpoints and software to search endpoint posture assessment 1486 information for evidence that an endpoint's software inventory has 1487 changed, and can make endpoint software inventory data available to 1488 other endpoints. This automates security data sharing in a way that 1489 expedites the correlation of relevant network data, allowing 1490 administrators and infrastructure endpoints to identify odd endpoint 1491 behavior and configuration using secure, standardized data models and 1492 protocols. 1494 B.2. Non-Supported Use Cases 1496 Several use cases, including but not limited to these, are not 1497 covered by the EPCP: 1499 o Gathering non-standardized types of posture information: The EPCP 1500 does not prevent administrators from collecting posture 1501 information in proprietary formats from the endpoint; however, it 1502 does not set requirements for doing so. 1504 o Solving the lying endpoint problem: The EPCP does not address the 1505 lying endpoint problem; the profile makes no assertions that it 1506 can catch an endpoint that is, either maliciously or accidentally, 1507 reporting false posture information to the posture manager. 1508 However, other solutions may be able to use the posture 1509 information collected using the capabilities described in this 1510 profile to catch an endpoint in a lie. For example, a sensor may 1511 be able to compare the posture information it has collected on an 1512 endpoint's activity on the network to what the endpoint reported 1513 to the posture manager and flag discrepancies. However, these 1514 capabilities are not described in this profile. 1516 Appendix C. Endpoint Posture Collection Profile Examples 1518 The following subsections provide examples of the EPCP as implemented 1519 using components from the NEA architecture. 1521 C.1. Continuous Posture Assessment of an Endpoint 1522 Endpoint Posture Manager 1523 +---------------+ +---------------+ 1524 | | | | 1525 | +-----------+ | | +-----------+ | 1526 | | SWID | | | | SWID | | 1527 | | Posture | | | | Posture | | 1528 | | Collector | | | | Validator | | 1529 | +-----------+ | | +-----------+ | 1530 | | | | | | 1531 | | IF-IMC | | | IF-IMV | 1532 | | | | | | 1533 | +-----------+ | | +-----------+ | 1534 | | PB Client | | | | PB Server | | 1535 | +-----------+ | | +-----------+ | 1536 | | | | | | 1537 | | | | | | 1538 | | | | | | 1539 | +-----------+ | | +-----------+ | 1540 | | PT Client | |<------>| | PT Server | | 1541 | +-----------+ | PT-TLS | +-----------+ | 1542 | | | | 1543 +---------------+ +---------------+ 1545 Figure 4: Continuous Posture Assessment of an Endpoint 1547 C.1.1. Change on Endpoint Triggers Posture Assessment 1549 A new application is installed on the endpoint, and the SWID 1550 directory is updated. This triggers an update from the SWID posture 1551 collector to the SWID posture validator. The message is sent down 1552 the NEA stack, encapsulated by NEA protocols until it is sent by the 1553 posture transport client to the posture transport server. The 1554 posture transport server then forwards it up through the stack, where 1555 the layers of encapsulation are removed until the SWID message 1556 arrives at the SWID posture validator. 1558 Endpoint Posture Manager 1559 +---------------+ +---------------+ 1560 | | | | 1561 | +-----------+ | | +-----------+ | 1562 | | SWID | | | | SWID | | 1563 | | Posture | | | | Posture | | 1564 | | Collector | | | | Validator | | 1565 | +-----------+ | | +-----------+ | 1566 | | | SWID Message | | | 1567 | | IF-IMC | for PA-TNC | | IF-IMV | 1568 | | | | | | 1569 | +-----------+ | | +-----------+ | 1570 | | PB Client | | | | PB Server | | 1571 | +-----------+ | | +-----------+ | 1572 | | | | | | 1573 | | | PB-TNC {SWID | | | 1574 | | | Message for | | | 1575 | | | PA-TNC} | | | 1576 | +-----------+ | | +-----------+ | 1577 | | PT Client | |<-------------->| | PT Server | | 1578 | +-----------+ | PT-TLS {PB-TNC | +-----------+ | 1579 | | {SWID Message | | 1580 +---------------+ for PA-TNC}} +---------------+ 1582 Figure 5: Compliance Protocol Encapsulation 1584 The SWID posture validator stores the new tag information in the 1585 repository. If the tag indicates that the endpoint is compliant with 1586 the policy, then the process is complete until the next time an 1587 update is needed (either because policy states that the endpoint must 1588 submit posture assessment results periodically or because an 1589 install/uninstall/update event on the endpoint triggers a posture 1590 assessment). 1592 Endpoint Posture Manager 1593 +---------------+ +---------------+ 1594 | | | | 1595 | +-----------+ | | +-----------+ | 1596 | | SWID | | | | SWID |-|-+ 1597 | | Posture | | | | Posture | | | 1598 | | Collector | | | | Validator | | | 1599 | +-----------+ | | +-----------+ | | 1600 | | | | | | | Repository 1601 | | IF-IMC | | | IF-IMV | | +--------+ 1602 | | | | | | | | | 1603 | +-----------+ | | +-----------+ | | | | 1604 | | PB Client | | | | PB Server | | +---->| | 1605 | +-----------+ | | +-----------+ | | | 1606 | | | | | | +--------+ 1607 | | | | | | 1608 | | | | | | 1609 | +-----------+ | | +-----------+ | 1610 | | PT Client | |<------>| | PT Server | | 1611 | +-----------+ | PT-TLS | +-----------+ | 1612 | | | | 1613 +---------------+ +---------------+ 1615 Figure 6: Storing SWIDs in the Repository 1617 If the endpoint has fallen out of compliance with a policy, the 1618 posture manager can alert the administrator via the posture manager's 1619 API. The administrator can then take steps to address the problem. 1620 If the administrator has already established a policy for 1621 automatically addressing this problem, that policy will be followed. 1623 (") 1624 __|__ 1625 +--> | 1626 Endpoint Posture Manager | / \ 1627 +---------------+ +---------------+ | 1628 | | | | | 1629 | +-----------+ | | +-----------+ | | 1630 | | SWID | | | | SWID |-|-+ 1631 | | Posture | | | | Posture | | 1632 | | Collector | | | | Validator | | 1633 | +-----------+ | | +-----------+ | 1634 | | | | | | Repository 1635 | | IF-IMC | | | IF-IMV | +--------+ 1636 | | | | | | | | 1637 | +-----------+ | | +-----------+ | | | 1638 | | PB Client | | | | PB Server | | | | 1639 | +-----------+ | | +-----------+ | | | 1640 | | | | | | +--------+ 1641 | | | | | | 1642 | | | | | | 1643 | +-----------+ | | +-----------+ | 1644 | | PT Client | |<------>| | PT Server | | 1645 | +-----------+ | PT-TLS | +-----------+ | 1646 | | | | 1647 +---------------+ +---------------+ 1649 Figure 7: Server Alerts Network Admin 1651 C.2. Administrator Searches for Vulnerable Endpoints 1653 An announcement is made that a particular version of a piece of 1654 software has a vulnerability. The administrator uses the API on the 1655 posture manager to search the repository for endpoints that reported 1656 the SWID tag for the vulnerable software. 1658 (") 1659 __|__ 1660 +-->| 1661 Endpoint Posture Manager | / \ 1662 +---------------+ +---------------+ | 1663 | | | | | 1664 | +-----------+ | | +-----------+ | | 1665 | | SWID | | | | SWID |-|-+ 1666 | | Posture | | | | Posture | | 1667 | | Collector | | | | Validator | | 1668 | +-----------+ | | +-----------+ | 1669 | | | | | | Repository 1670 | | IF-IMC | | | IF-IMV | +--------+ 1671 | | | | | | | | 1672 | +-----------+ | | +-----------+ | | | 1673 | | PB Client | | | | PB Server | |------>| | 1674 | +-----------+ | | +-----------+ | | | 1675 | | | | | | +--------+ 1676 | | | | | | 1677 | | | | | | 1678 | +-----------+ | | +-----------+ | 1679 | | PT Client | |<------>| | PT Server | | 1680 | +-----------+ | PT-TLS | +-----------+ | 1681 | | | | 1682 +---------------+ +---------------+ 1684 Figure 8: Admin Searches for Vulnerable Endpoints 1686 The repository returns a list of entries matching the administrator's 1687 search. The administrator can then address the vulnerable endpoints 1688 by taking some follow-up action such as removing it from the network, 1689 quarantining it, or updating the vulnerable software. 1691 Appendix D. Change Log 1693 D.1. -00 to -01 1695 Changed the status of the draft from "Best Current Practices" to 1696 "Standards Track". 1698 D.2. -05 to -00 1700 Changed the title of the draft to draft-ietf-sacm-epcp. 1702 Updated the diagram so the Endpoint and Posture Manager are the 1703 primary focus of EPCP. 1705 Added a reference to CoSWID in the Software Asset Management 1706 extension of the IETF NEA EPCP implementation. 1708 Further clarified the use of MAC addresses in EPCP. 1710 Included a requirement in the Privacy Considerations that the 1711 enterprise should exercise due diligence with respect to the privacy 1712 of certain data given privacy regulations. 1714 Added a requirement around an endpoint being provisioned with a 1715 machine certificate. 1717 Clarified that other protocols and interfaces may be supported beyond 1718 IETF NEA and NETCONF. 1720 Made various typographical and editorial changes. 1722 D.3. -04 to -05 1724 Updated the diagram so the Evaluator and Repository are "current 1725 work". 1727 Clarified how the Posture Collection Engine can push data, respond to 1728 queries, and establish secure transport connectivity for fulfilling 1729 subscriptions. 1731 Expanded on the future work around leveraging NETCONF, RESTCONF, and 1732 YANG Push for network devices. 1734 Documented the need to reassess MAC addresses as a device identifier. 1736 Made various typographical and editorial changes. 1738 D.4. -03 to -04 1740 Addressed various comments from the SACM WG. 1742 Refactored the document to better focus it on the communications 1743 between endpoints and the posture manager and the best practices for 1744 EPCP implementations. 1746 Made other editorial changes and improved consistency throughout the 1747 document. 1749 D.5. -02 to -03 1751 Addressed various comments from the SACM WG. 1753 Added a reference to TCG ECP 1.0. 1755 Removed text in the "SWID Posture Validator" section that states it 1756 performs evaluation. This was removed because it contradicts the 1757 posture manager not performing any evaluations. 1759 Expanded the "Provisioning" section of the "EPCP Transactions" 1760 section to include examples of endpoint identifiers and the need to 1761 provision endpoints with components and data models. 1763 Combined text for the capabilities of the Administrative Interface 1764 and API. 1766 Removed superfluous and introductory text from the "Security 1767 Considerations" section. 1769 Renamed section "Vulnerability Searches" to Vulnerability 1770 Management". 1772 Changed I-D category to BCP. 1774 Changed references to the NETMOD architecture to the NETCONF 1775 architecture because NETCONF represents the management protocol 1776 whereas NETMOD is focused on the definition of data models. 1778 Addressed various editorial suggestions. 1780 D.6. -01 to -02 1782 Addressed various comments from the SACM WG. 1784 Added a section for the collection of posture information from 1785 network devices using standards from the NETMOD WG. 1787 Updated EPCP component diagrams so they were not specific to a NEA- 1788 based implementation. 1790 Updated EPCP NEA example diagrams to reflect all the components in 1791 the NEA architecture. 1793 D.7. -00 to -01 1795 There are no textual changes associated with this revision. This 1796 revision simply reflects a resubmission of the document so that it 1797 remains in active status. 1799 D.8. -01 to -02 1801 Added references to the Software Inventory Message and Attributes 1802 (SWIMA) for PA-TNC I-D. 1804 Replaced references to PC-TNC with IF-IMC. 1806 Removed erroneous hyphens from a couple of section titles. 1808 Made a few minor editorial changes. 1810 D.9. -02 to -00 1812 Draft adopted by IETF SACM WG. 1814 D.10. -00 to -01 1816 Significant edits to up-level the draft to describe SACM collection 1817 over multiple different protocols. 1819 Replaced references to SANS with CIS. 1821 Made other minor editorial changes. 1823 Authors' Addresses 1825 Danny Haynes 1826 The MITRE Corporation 1827 202 Burlington Road 1828 Bedford, MA 01730 1829 USA 1831 Email: dhaynes@mitre.org 1833 Jessica Fitzgerald-McKay 1834 Department of Defense 1835 9800 Savage Road 1836 Ft. Meade, Maryland 1837 USA 1839 Email: jmfitz2@nsa.gov