idnits 2.17.1 draft-ietf-sacm-ecp-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 7) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 41 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([ECP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2019) is 1771 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 (-26) exists of draft-ietf-netconf-subscribed-notifications-13 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-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: 3 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SACM D. Haynes 2 Internet-Draft The MITRE Corporation 3 Intended status: Best Current Practice J. Fitzgerald-McKay 4 Expires: December 23, 2019 Department of Defense 5 L. Lorenzin 6 Pulse Secure 7 June 21, 2019 9 Endpoint Posture Collection Profile 10 draft-ietf-sacm-ecp-05 12 Abstract 14 This document specifies the Endpoint Posture Collection Profile, 15 which describes the best practices for the application of IETF, TNC, 16 and ISO/IEC data models, protocols, and interfaces to support the on- 17 going collection and communication of endpoint posture to a 18 centralized server where it can be stored and made available to other 19 tools. This document is an extension of the Trusted Computing 20 Group's Endpoint Compliance Profile Version 1.0 specification [ECP]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 23, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Endpoint Posture Collection Profile . . . . . . . . . . . . . 5 59 3.1. Components . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1.1.1. Posture Collection Engine . . . . . . . . . . . . 7 62 3.1.2. Posture Manager . . . . . . . . . . . . . . . . . . . 8 63 3.1.2.1. Posture Collection Manager . . . . . . . . . . . 8 64 3.1.3. Repository . . . . . . . . . . . . . . . . . . . . . 8 65 3.1.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1.5. Orchestrator . . . . . . . . . . . . . . . . . . . . 9 67 3.1.6. Administrative Interface and API . . . . . . . . . . 9 68 3.2. Transactions . . . . . . . . . . . . . . . . . . . . . . 9 69 3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . 10 70 3.2.2. Discovery and Validation . . . . . . . . . . . . . . 10 71 3.2.3. Event Driven Collection . . . . . . . . . . . . . . . 10 72 3.2.4. Querying the Endpoint . . . . . . . . . . . . . . . . 10 73 3.2.5. Data Storage . . . . . . . . . . . . . . . . . . . . 10 74 3.2.6. Data Sharing . . . . . . . . . . . . . . . . . . . . 11 75 4. IETF NEA EPCP Implementation for Traditional Endpoints . . . 11 76 4.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 13 77 4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.2.1. Posture Collector . . . . . . . . . . . . . . . . . . 14 79 4.2.2. Posture Broker Client . . . . . . . . . . . . . . . . 14 80 4.2.3. Posture Transport Client . . . . . . . . . . . . . . 14 81 4.3. Posture Manager . . . . . . . . . . . . . . . . . . . . . 14 82 4.3.1. Posture Validator . . . . . . . . . . . . . . . . . . 14 83 4.3.2. Posture Broker Server . . . . . . . . . . . . . . . . 14 84 4.3.3. Posture Transport Server . . . . . . . . . . . . . . 14 85 4.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.5. IETF SACM SWAM Extension to the IETF NEA EPCP 87 Implementation . . . . . . . . . . . . . . . . . . . . . 15 88 4.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 15 89 4.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 15 90 4.5.3. SWID Posture Collectors and Posture Validators . . . 15 91 4.5.3.1. The SWID Posture Collector . . . . . . . . . . . 16 92 4.5.3.2. The SWID Posture Validator . . . . . . . . . . . 16 93 4.5.4. Repository . . . . . . . . . . . . . . . . . . . . . 17 94 5. IETF NETCONF EPCP Implementation for Network Device Endpoints 17 95 5.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 18 96 5.2. Posture Manager Provisioning . . . . . . . . . . . . . . 18 97 5.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 18 98 5.3.1. Datastore . . . . . . . . . . . . . . . . . . . . . . 18 99 5.4. Posture Manager . . . . . . . . . . . . . . . . . . . . . 19 100 5.5. Repository . . . . . . . . . . . . . . . . . . . . . . . 19 101 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 22 106 9.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 23 107 9.1.2. Network Attacks . . . . . . . . . . . . . . . . . . . 23 108 9.1.3. Posture Manager Attacks . . . . . . . . . . . . . . . 23 109 9.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 24 110 9.2. Countermeasures . . . . . . . . . . . . . . . . . . . . . 25 111 9.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 25 112 9.2.2. Countermeasures for Network Attacks . . . . . . . . . 25 113 9.2.3. Countermeasures for Posture Manager Attacks . . . . . 26 114 9.2.4. Countermeasures for Repository Attacks . . . . . . . 26 115 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 117 11.1. Informative References . . . . . . . . . . . . . . . . . 27 118 11.2. Normative References . . . . . . . . . . . . . . . . . . 28 119 Appendix A. Rationale for an EPCP Solution . . . . . . . . . . . 30 120 A.1. Preventative Posture Assessments . . . . . . . . . . . . 30 121 A.2. All Network-Connected Endpoints are Endpoints . . . . . . 31 122 A.3. All Endpoints on the Network Must be Uniquely Identified 31 123 A.4. Standardized Data Models . . . . . . . . . . . . . . . . 31 124 A.5. Posture Information Must Be Stored . . . . . . . . . . . 32 125 A.6. Posture Information Can Be Shared . . . . . . . . . . . . 32 126 A.7. Enterprise Asset Posture Information Belongs to the 127 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 32 128 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 33 129 B.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 33 130 B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 33 131 B.1.2. Software Asset Management . . . . . . . . . . . . . . 33 132 B.1.3. Vulnerability Management . . . . . . . . . . . . . . 34 133 B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 34 134 B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 34 135 Appendix C. Endpoint Posture Collection Profile Examples . . . . 35 136 C.1. Continuous Posture Assessment of an Endpoint . . . . . . 35 137 C.1.1. Change on Endpoint Triggers Posture Assessment . . . 35 138 C.2. Administrator Searches for Vulnerable Endpoints . . . . . 38 139 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 39 140 D.1. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 39 141 D.2. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 40 142 D.3. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 40 143 D.4. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 41 144 D.5. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41 145 D.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 41 146 D.7. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 41 147 D.8. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 41 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 150 1. Introduction 152 The Endpoint Posture Collection Profile (EPCP) builds on prior work 153 from the IETF NEA WG, the IETF NETCONF WG, IETF NETMOD WG, the 154 Trusted Computing Group (TCG) Trusted Network Communications [TNC] 155 WG, and the International Organization for Standardization/ 156 International Electrotechnical Commission Joint Technical Committee 157 (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC 1, SC7, WG21) to 158 describe the best practices for the collection and communication of 159 posture information from network-connected endpoints to a centralized 160 server. 162 This document focuses on reducing the security exposure of a network 163 by enabling event-driven posture collection, standardized querying of 164 additional posture information as needed, and the communication of 165 that data to a centralized server where it can made available to 166 other components. Thus, eliminating the need for redundant 167 collection and agents on endpoints. Future revisions of this 168 document may include support for the collection of posture 169 information from other endpoint types as well as a standardized 170 interface for storing and querying data in repositories among other 171 capabilities. Additional information about this future work can be 172 found in Section 6 of this document. 174 To support the collection of posture information from new endpoint 175 types, this document is organized such that it first provides a high- 176 level overview of EPCP as well as its abstract architectural 177 components and transactions that will be realized by implementations 178 (Section 3). This is followed by individual sections that discuss 179 the best practices for specific implementations of the EPCP for a 180 given endpoint type (e.g., traditional, network device, etc.) along 181 with any extensions for supported use cases (software asset 182 management, vulnerability management, etc.). 184 2. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. This 189 specification does not distinguish blocks of informative comments and 190 normative requirements. Therefore, for the sake of clarity, note 191 that lower case instances of must, should, etc. do not indicate 192 normative requirements. 194 Furthermore, this document uses terms as defined in 195 [I-D.ietf-sacm-terminology] unless otherwise specified. 197 3. Endpoint Posture Collection Profile 199 The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols, 200 and interfaces can be used to support the posture assessment of 201 endpoints on a network. This profile does not generate new data 202 models, protocols, or interfaces; rather, it offers best practices 203 for a full end-to-end solution for posture assessment, as well as a 204 fresh perspective on how existing standards can be leveraged against 205 vulnerabilities. Rationale for the EPCP solution as well as the 206 supported and non-supported use cases is available in Appendix A and 207 Appendix B respectively. 209 The EPCP makes it possible to perform posture assessments against all 210 network-connected endpoints by: 212 1. uniquely identifying the endpoint; 214 2. collecting and evaluating posture based on data from the endpoint 215 (asset management, software asset management, vulnerability 216 management, and configuration management); 218 3. creating a secure, authenticated, confidential channel between 219 the endpoint and the posture manager; 221 4. enabling the endpoint to notify the posture manager about changes 222 to its configuration; 224 5. enabling the posture manager to request information about the 225 configuration of the endpoint; and 227 6. storing the posture information in a repository linked to the 228 identifier for the endpoint. 230 Furthermore, the EPCP aims to support data storage and data sharing 231 capabilities to make the collected posture information available to 232 authorized parties and components in support of other processes 233 (analytic, access control, remediation, reporting, etc.). 235 3.1. Components 237 To perform posture assessment, data storage, and data sharing, the 238 EPCP defines several components. Some of these components reside on 239 the target endpoint. Others reside on a posture manager that manages 240 communications with the target endpoint and stores the target 241 endpoint's posture information in a repository. 243 It should be noted that the primary focus of this document is on the 244 communication between the posture manager and endpoints. While the 245 orchestrator, evaluator, repository, and administrative interface and 246 API will be discussed in the context of the broader EPCP 247 architecture, these components are not strictly defined nor are best 248 practices provided for them at this time. As a result, vendors are 249 free to implement these components and interfaces in a way that makes 250 the most sense for their products. 252 *********FUTURE WORK********** Posture Manager Endpoint 253 * Orchestrator * +----------------+ +----------------+ 254 * +--------+ * | | | | 255 * | |<------------>| | | | 256 * | | publish/ * | | | | 257 * | | subscribe * | | | | 258 * | | * | +------------+ | | +------------+ | 259 * +--------+ * | | | | | | | | 260 *********FUTURE WORK********** | | Posture | | report/ | | Posture | | 261 | | Collection | | publish | | Collection | | 262 Evaluator Repository | | Manager | |<----------| | Engine | | 263 +------+ +--------+ | | | | | | | | 264 | | | | | | | | | | | | 265 | | | | | +------------+ | | +------------+ | 266 | |<-------->| |<---------->| | query/ | | 267 | | request/ | | store | | subscribe | | 268 | | respond | | | |---------->| | 269 | | | | | | | | 270 +------+ +--------+ +----------------+ +----------------+ 271 | ^ ^ 272 | query | | 273 +----------------------------------------+ | 274 | 275 ***************************FUTURE WORK***********|************* 276 * | * 277 * +--------------------------------+ * 278 * | Administrative Interface | * 279 * | and API | * 280 * +--------------------------------+ * 281 * * 282 ***************************FUTURE WORK************************* 284 Figure 1: EPCP Components 286 3.1.1. Endpoint 288 An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is 289 monitored by the enterprise and is the target of posture assessments. 290 To support these posture assessments, posture information is 291 collected via a posture collection engine. 293 3.1.1.1. Posture Collection Engine 295 The posture collection engine is located on the target endpoint and 296 can either receive queries for data from the posture collection 297 manager (see Section 3.2.4) or can push data to the posture 298 collection manager (see Section 3.2.3). The posture collection 299 engine sends collected posture information to the posture manager 300 where it can be sanity checked and stored in the repository. The 301 posture collection engine also contains a capability that sets up 302 exchanges between the target endpoint and posture manager. This 303 capability makes the posture collection engine responsible for 304 performing the client-side portion of encryption handshakes, and for 305 locating authorized posture managers with which to communicate. 307 3.1.2. Posture Manager 309 The posture manager is an endpoint that collects, validates, and 310 enriches posture information received about a target endpoint. It 311 also stores the posture information it receives in the repository 312 where it can be evaluated. The posture manager does not evaluate the 313 posture information. 315 3.1.2.1. Posture Collection Manager 317 A posture collection manager is a lightweight and extensible 318 component that facilitates the coordination and execution of posture 319 collection requests using collection mechanisms deployed across the 320 enterprise. The posture collection manager may query and retrieve 321 guidance from the repository to guide the collection of posture 322 information from the target endpoint. 324 The posture collection manager also contains a capability that sets 325 up exchanges between the target endpoint and the posture manager, and 326 manages data sent to and from posture collection engine. It is also 327 responsible for performing the server-side portion of encryption 328 handshakes. 330 If the posture manager wants to register for continuous collection of 331 endpoint posture changes with the endpoint, then it must do so in a 332 scalable way. Specifically, it will need to create subscriptions 333 with endpoints in a way which allows the posture data to be securely 334 pushed. Effectively this means that the endpoint must be able to 335 establish secure transport connectivity to the posture collection 336 manager as needed, and the collection manager must be able to 337 periodically collect the current state of the endpoint to verify the 338 expected state of that endpoint. 340 3.1.3. Repository 342 The repository hosts guidance, endpoint identification information, 343 and posture information reported by target endpoints where it is made 344 available to authorized components and persisted over a period of 345 time set by the administrator. Information stored in the repository 346 will be accessible to authorized parties via a standard 347 administrative interface as well as through a standardized API. The 348 repository may be a standalone component or may be located on the 349 posture manager. Furthermore, an implementation is not restricted to 350 a single repository and may leverage several repositories to provide 351 this functionality. 353 3.1.4. Evaluator 355 The evaluator assesses the posture status of a target endpoint by 356 comparing collected posture information against the desired state of 357 the target endpoint specified in guidance. The evaluator queries and 358 retrieves the appropriate guidance from the repository as well as 359 queries and retrieves the posture information required for the 360 assessment from the repository. If the required posture information 361 is not available in the repository, the evaluator may request the 362 posture information from the posture collection manager, which will 363 result in the collection of additional posture information from the 364 target endpoint. This information is subsequently stored in the 365 repository where it is made available to the evaluator and other 366 components. The results of the assessment are stored in the 367 repository where they are available to tools and administrators for 368 follow-up actions, further evaluation, and historical purposes. 370 3.1.5. Orchestrator 372 The orchestrator provides a publish/subscribe interface for the 373 repository so that infrastructure endpoints can subscribe to and 374 receive published posture assessment results from the repository 375 regarding endpoint posture changes. 377 3.1.6. Administrative Interface and API 379 The administrative interface allows administrators to query the 380 repository and manage the endpoints and software used in the EPCP via 381 the posture manager. Similarly, an API is necessary to allow 382 infrastructure endpoints and software access to the information 383 stored in the repository and to manage the endpoints and software 384 used in the EPCP. The administrative interface and API provide 385 authorized users, infrastructure endpoints, and software with the 386 ability to query the repository for data, send commands to the 387 posture collection managers requesting information from the 388 associated posture collection engines residing on endpoints, and 389 establish and update the policy that resides on the posture manager. 391 3.2. Transactions 393 The following sections describe the transactions associated with the 394 components of the EPCP architecture and may be provided in an 395 implementation. 397 3.2.1. Provisioning 399 An endpoint is provisioned with one or more attributes that will 400 serve as its unique identifier on the network as well as the 401 components and data models necessary to interact with the posture 402 manager. Examples of such identifiers include MAC addresses, serial 403 numbers, hardware certificates compliant with [IEEE-802-1ar], and the 404 identities of hardware cryptographic modules among others. Once 405 provisioning is complete, the endpoint is deployed on the network. 406 Over time, components and data models may need to be added to the 407 endpoint or updated to support the collection needs of an enterprise. 409 3.2.2. Discovery and Validation 411 If necessary, the target endpoint finds and validates the posture 412 manager. The posture collection engine on the target endpoint and 413 posture collection manager on the posture manager complete an 414 encryption handshake, during which endpoint identity information is 415 exchanged. 417 3.2.3. Event Driven Collection 419 The posture assessment is initiated when the posture collector engine 420 on the target endpoint notices that relevant posture information on 421 the endpoint has changed. Then, the posture collection engine 422 initiates a posture assessment information exchange with the posture 423 collection manager. 425 3.2.4. Querying the Endpoint 427 The posture assessment is initiated by the posture collection 428 manager. This can occur because: 430 1. policy states that a previous assessment has aged out or become 431 invalid, or 433 2. the posture collection manager is alerted by a sensor or an 434 administrator (via the posture manager's administrative 435 interface) that an assessment must be completed. 437 3.2.5. Data Storage 439 Once posture information is received by the posture manager, it is 440 forwarded to the repository. The repository could be co-located with 441 the posture manager, or there could be direct or brokered 442 communication between the posture manager and the repository. The 443 posture information is stored in the repository along with past 444 posture information collected about the target endpoint. 446 3.2.6. Data Sharing 448 Because the target endpoint posture information was sent in 449 standards-based data models over secure, standardized protocols, and 450 then stored in a centralized repository linked to unique endpoint 451 identifiers, authorized parties are able to access the posture 452 information. Such authorized parties may include, but are not 453 limited to, administrators or endpoint owners (via the posture 454 manager's administrative interface), evaluators that access the 455 repository directly, and orchestrators that rely on publish/subscribe 456 communications with the repository. 458 4. IETF NEA EPCP Implementation for Traditional Endpoints 460 When EPCP is used, posture collectors running on the target endpoint 461 gather posture information as changes occur on the endpoint. The 462 data is aggregated by the posture broker client and forwarded to a 463 posture manager, over a secure channel, via the posture transport 464 client. Once received by the posture transport server on the posture 465 manager, the posture information is directed by the posture broker 466 server to the appropriate posture validators where it can be 467 processed and stored in a repository. There the posture information 468 can be used by other tools to carry out assessment tasks. Posture 469 collectors can also be queried by posture validators to refresh 470 posture information about the target endpoint or to ask a specific 471 question about posture information. This is shown in Figure 2. 473 Posture Posture 474 Collection Collection 475 Manager Engine 476 +---------------+ +---------------+ 477 | | | | 478 | +-----------+ | PA-TNC | +-----------+ | 479 | | Posture | |--------| | Posture | | 480 | | Validator | | | | Collector | | 481 | +-----------+ | | +-----------+ | 482 | | | | | | 483 | | IF-IMV | | | IF-IMC | 484 | | | | | | 485 | +-----------+ | PB-TNC | +-----------+ | 486 | | PB Server | |--------| | PB Client | | 487 | +-----------+ | | +-----------+ | 488 | | | | | | 489 | | | | | | 490 | | | | | | 491 | +-----------+ | | +-----------+ | 492 | | PT Server | |<------>| | PT Client | | 493 | +-----------+ | PT-TLS | +-----------+ | 494 | | | | 495 +---------------+ +---------------+ 497 Figure 2: NEA Components 499 These requirements are written with a view to performing a posture 500 assessment on an endpoint; as the EPCP grows and evolves, these 501 requirements will be expanded to address issues that arise. Note 502 that these requirements refer to defined components of the NEA 503 architecture [RFC5209]. As with the NEA architecture, vendors have 504 discretion as to how these NEA components map to separate pieces of 505 software or endpoints. 507 Furthermore, it should be noted that the posture broker client and 508 posture transport client components of the posture collection engine 509 and the posture broker server and posture transport server components 510 of the posture collection manager would likely need to be implemented 511 by a single vendor because there are no standardized interfaces 512 between the respective components and would not be interoperable. 514 Examples of the EPCP as implemented using the components from the NEA 515 architecture are provided in Appendix C. 517 4.1. Endpoint Provisioning 519 An endpoint is provisioned with a machine certificate that will serve 520 as its unique identifier on the network as well as the components 521 necessary to interact with the posture manager. This includes a 522 posture collection engine to manage requests from the posture manager 523 and the posture collectors necessary to collect the posture 524 information of importance to the enterprise. The endpoint is 525 deployed on the network. 527 The target endpoint SHOULD authenticate to the posture manager using 528 a machine certificate during the establishment of the outer tunnel 529 achieved with the posture transport protocol defined in [RFC6876]. 530 [IF-IMV] specifies how to pull an endpoint identifier out of a 531 machine certificate. An endpoint identifier SHOULD be created in 532 conformance with [IF-IMV] from a machine certificate sent via 533 [RFC6876]. 535 In the future, the identity could be a hardware certificate compliant 536 with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated 537 with the identity of a hardware cryptographic module, in accordance 538 with [IEEE-802-1ar], if present on the endpoint. The enterprise 539 SHOULD stand up a certificate root authority; install its root 540 certificate on endpoints and on the posture manager; and provision 541 the endpoints and the posture manager with machine certificates. The 542 target endpoint MAY authenticate to the posture manager using a 543 combination of the machine account and password; however, this is 544 less secure and not recommended. 546 4.2. Endpoint 548 The endpoint MUST conform to [RFC5793], which levies several 549 requirements against the endpoint. An endpoint that complies with 550 these requirements will be able to: 552 1. attempt to initiate a session with the posture manager if the 553 posture makes a request to send an update to posture manager; 555 2. notify the posture collector if no PT-TLS session with the 556 posture manager can be created; 558 3. notify the posture collector when a PT-TLS session is 559 established; and 561 4. receive information from the posture collectors, forward this 562 information to the posture manager via the posture collection 563 engine. 565 4.2.1. Posture Collector 567 Any posture collector used in an EPCP solution MUST be conformant 568 with the TCG TNC Integrity Measurement Collector interface [IF-IMC]. 570 4.2.2. Posture Broker Client 572 The posture broker client MUST conform to [IF-IMC] to enable 573 communications between the posture broker client and the posture 574 collectors on the endpoint. 576 4.2.3. Posture Transport Client 578 The posture transport client MUST implement PT-TLS. 580 The posture transport client MUST support the use of machine 581 certificates for TLS at each endpoint consistent with the 582 requirements stipulated in [RFC6876] and [Server-Discovery]. 584 The posture transport client MUST be able to locate an authorized 585 posture manager, and switch to a new posture manager when required by 586 the network, in conformance with [Server-Discovery]. 588 4.3. Posture Manager 590 The posture manager MUST conform to all requirements in the 591 [RFC5793]. 593 4.3.1. Posture Validator 595 Any posture validator used in an EPCP solution MUST be conformant 596 with the TCG TNC Integrity Measurement Verifier interface [IF-IMV]. 598 4.3.2. Posture Broker Server 600 The posture broker server MUST conform to [IF-IMV]. Conformance to 601 [IF-IMV] enables the posture broker server to obtain endpoint 602 identity information from the posture transport server, and pass this 603 information to any posture validators on the posture manager. 605 4.3.3. Posture Transport Server 607 The posture transport server MUST implement PT-TLS. 609 The posture transport server MUST support the use of machine 610 certificates for TLS at each endpoint consistent with the 611 requirements stipulated in [RFC6876] and [Server-Discovery]. 613 4.4. Repository 615 EPCP requires a simple administrative interface for the repository. 616 Posture validators on the posture manager receive the target endpoint 617 posture information via PA-TNC [RFC5792] messages sent from 618 corresponding posture collectors on the target endpoint. The posture 619 validators store this information in the repository linked to the 620 identity of the target endpoint where the posture collectors are 621 located. 623 4.5. IETF SACM SWAM Extension to the IETF NEA EPCP Implementation 625 This section defines the requirements associated with the software 626 asset management extension [RFC8412] to the IETF NEA EPCP 627 implementation. 629 4.5.1. Endpoint Pre-Provisioning 631 This section defines the requirements associated with implementing 632 SWIMA. 634 The following requirements assume that the platform or OS vendor 635 supports the use of SWID tags and has identified a standard directory 636 location for the SWID tags to be located as specified by [SWID]. 638 4.5.2. SWID Tags 640 The primary content for the EPCP is the information conveyed in the 641 elements of a SWID tag. 643 The endpoint MUST have SWID tags stored in a directory specified in 644 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 645 also be generated by: 647 o the software installer; or 649 o third-party software that creates tags based on the applications 650 it sees installed on the endpoint. 652 The elements in the SWID tag MUST be populated as specified in 653 [SWID]. These tags, and the directory in which they are stored, MUST 654 be updated as software is added, removed, or updated. 656 4.5.3. SWID Posture Collectors and Posture Validators 657 4.5.3.1. The SWID Posture Collector 659 For the EPCP, the SWID posture collector MUST be conformant with 660 [RFC8412], which includes requirements for: 662 1. Collecting SWID tags from the SWID directory; 664 2. Monitoring the SWID directory for changes; 666 3. Initiating a session with the posture manager to report changes 667 to the directory; 669 4. Maintaining a list of changes to the SWID directory when updates 670 take place and no PT-TLS connection can be created with the 671 posture manager; 673 5. Responding to a request for SWID tags from the SWID Posture 674 Validator on the posture manager; and 676 6. Responding to a query from the SWID posture validator as to 677 whether all updates have been sent. 679 The SWID posture collector is not responsible for detecting that the 680 SWID directory was not updated when an application was either 681 installed or uninstalled. 683 4.5.3.2. The SWID Posture Validator 685 Conformance to [RFC8412] enables the SWID posture validator to: 687 1. Send messages to the SWID posture collector (at the behest of the 688 administrator at the posture manager console) requesting updates 689 for SWID tags located on endpoint; 691 2. Ask the SWID posture collector whether all updates to the SWID 692 directory located at the posture manager have been sent; and 694 3. Perform any validation and processing on the collected SWID 695 posture information prior to storage. 697 In addition to these requirements, a SWID posture validator used in 698 conformance with this profile MUST be capable of passing this SWID 699 posture information as well as the associated endpoint identity to 700 the repository for storage. 702 4.5.4. Repository 704 The administrative interface SHOULD enable an administrator to: 706 1. Query which endpoints have reported SWID tags for a particular 707 application 709 2. Query which SWID tags are installed on an endpoint; and 711 3. Query tags based on characteristics, such as vendor, publisher, 712 etc. 714 5. IETF NETCONF EPCP Implementation for Network Device Endpoints 716 When EPCP is used, a NETCONF client that implements the posture 717 collection manager sends a query to target network device endpoint 718 requesting posture information over a secure channel. Once the 719 NETCONF server on the endpoint receives the request, it queries one 720 or more datastores for the posture information. The NETCONF server 721 then reports the information back to the NETCONF client where it can 722 be stored in a repository for use by other tools. This is shown in 723 Figure 3. 725 Posture Posture 726 Collection Collection 727 Manager Engine 728 +---------------+ +---------------+ 729 | | | | 730 | | | +-----------+ | 731 | | | | Data | | 732 | | | | Store(s) | | 733 | | | +-----------+ | 734 | | | | | 735 | | | | | 736 | +-----------+ | | +-----------+ | 737 | | NETCONF | | | | NETCONF | | 738 | | Client | |<------->| | Server | | 739 | +-----------+ | NETCONF | +-----------+ | 740 | | | | 741 +---------------+ +---------------+ 743 Figure 3: NETCONF Components 745 These requirements are written with a view to performing a posture 746 assessment on network device endpoints (routers, switches, etc.); as 747 the EPCP grows and evolves, these requirements will be expanded to 748 address issues that arise. 750 Note that these requirements refer to defined components of the 751 NETCONF architecture and map back to EPCP. As with the NETCONF 752 architecture, vendors have discretion as to how these NETCONF 753 components map to separate pieces of software or endpoints. 755 5.1. Endpoint Provisioning 757 For the posture manager to be able to query the datastores on the 758 endpoint, the endpoint MUST be configured to grant the posture 759 manager access to its datastores as described in [RFC6241]. The 760 posture manager is identified by its NETCONF username. The endpoint 761 is deployed on the network. 763 5.2. Posture Manager Provisioning 765 For the posture manager to be able to query the datastores on the 766 endpoint, the posture manager MUST be provisioned with a NETCONF 767 username that will be used to authenticate the posture manager to the 768 endpoint as described in [RFC6241]. The username generated will be 769 determined by the selected transport protocol. The posture manager 770 is deployed on the network. 772 5.3. Endpoint 774 An endpoint MUST conform to the requirements outlined for servers in 775 the NETCONF protocol as defined in [RFC6241]. This requires the 776 implementation of NETCONF over SSH [RFC6242]. An endpoint MAY 777 support the NETCONF protocol over other transports such as TLS 778 [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040]. 780 5.3.1. Datastore 782 A NETCONF datastore on an endpoint MUST support the operations 783 outlined in [RFC6241], but, the actual implementation of the 784 datastore is left to the endpoint vendor. 786 Datastores MUST support the YANG data modeling language [RFC7950] for 787 expressing endpoint posture information in a structured format. In 788 addition, datastores MAY support other data models such as XML (via 789 YIN) for representing posture information. 791 Datastores MUST support the compliance posture information specified 792 in [RFC7317]. Datastores MAY support other models standardized or 793 proprietary as deemed appropriate by the endpoint vendor. 795 5.4. Posture Manager 797 A posture manager MUST conform to the requirements specified for 798 clients in the NETCONF protocol as defined in [RFC6241]. This 799 requires the implementation of NETCONF over SSH [RFC6242]. A posture 800 manager MAY also support the NETCONF protocol over other transports 801 such as TLS [RFC7589]. In addition, a posture manager MAY support 802 the RESTCONF protocol as defined in [RFC8040]. 804 While ad-hoc fetch/polling via NETCONF and RESTCONF is useful for 805 assessing endpoint compliance, such solutions by themselves are not 806 able to detect changes as they occur on the endpoint. As a result, a 807 future revision of this document will support 808 [I-D.ietf-netconf-yang-push] to receive updates on YANG-modeled 809 posture information. Similarly, because not all posture information 810 is modeled in YANG, a future revision of this document will reference 811 [I-D.ietf-netconf-subscribed-notifications] once it is a standard to 812 support continuous streams of unstructured data from the endpoint to 813 the posture manager. 815 5.5. Repository 817 EPCP requires a simple administrative interface for the repository. 818 The posture collection manager on the posture manager receives the 819 target endpoint posture information via NETCONF [RFC6241] messages 820 sent from posture collection engine on the target endpoint. The 821 posture collection manager stores this information in the repository 822 linked to the identity of the target endpoint from which it was 823 collected. 825 6. Future Work 827 This section captures ideas for future work related to EPCP that 828 might be of interest to the IETF SACM WG. These ideas are listed in 829 no particular order. 831 o The [I-D.ietf-netconf-subscribed-notifications] and 832 [I-D.ietf-netconf-yang-push] which have been submitted to IESG for 833 publication could be leveraged for an HTTP-based subscription for 834 EPCP. Specifically, it could be used for the posture collection 835 manager to continuously receive posture changes as they happen 836 from the posture collection engine. At this point, it seems like 837 [I-D.ietf-netconf-restconf-notif] would be a good match to these 838 requirements. However further investigation into the 839 applicability of supporting a RESTCONF server capability on to 840 handle subscription requests needs to be made. Specific questions 841 which should be examined include: 843 * Number of endpoints which can be continuously tracked by a 844 single posture collection manager. Scalability questions to be 845 considered include elements from the number of transport 846 connects maintained to the volume of volume and churn of 847 posture evidence which will be continuously pushed to the 848 posture collection manager manager. 850 * Ability of the posture collection manager to establish and 851 maintain a continuous state of endpoint posture during 852 failures. This includes failures/reboots on either side of the 853 interface. 855 * Ability to support for the full set of functions described for 856 NETCONF within Section 5. 858 o Add support endpoint types beyond workstations, servers, and 859 network infrastructure devices. 861 o Examine the integration of [I-D.ietf-mile-xmpp-grid]. 863 o Define a standard interface and API for interacting with the 864 repository. Requirements to consider include: creating a secure 865 channel between a publisher and the repository, creating a secure 866 channel between a subscriber and the repository, and the types of 867 interactions that must be supported between publishers and 868 subscribers to a repository. 870 o Define a standard interface for communications between the posture 871 broker client and posture transport client(s) as well as the 872 posture broker server and posture transport server(s). 874 o Retention of posture information on the target endpoint. 876 o Define an orchestrator component as well as publish/subscribe 877 interface for it. 879 o Define an evaluator component as well as an interface for it. 881 o Reassess the use of MAC addresses, including market research to 882 determine if MAC addresses continue to be a widely implemented 883 device identifier among network tools. 885 7. Acknowledgements 887 The authors wish to thank all of those in the TCG TNC work group who 888 contributed to development of the TNC ECP specification upon which 889 this document is based. 891 +-----------------------+-------------------------------------------+ 892 | Member | Organization | 893 +-----------------------+-------------------------------------------+ 894 | Padma Krishnaswamy | Battelle Memorial Institute | 895 | | | 896 | Eric Fleischman | Boeing | 897 | | | 898 | Richard Hill | Boeing | 899 | | | 900 | Steven Venema | Boeing | 901 | | | 902 | Nancy Cam-Winget | Cisco Systems | 903 | | | 904 | Scott Pope | Cisco Systems | 905 | | | 906 | Max Pritikin | Cisco Systems | 907 | | | 908 | Allan Thompson | Cisco Systems | 909 | | | 910 | Nicolai Kuntze | Fraunhofer Institute for Secure | 911 | | Information Technology (SIT) | 912 | | | 913 | Ira McDonald | High North | 914 | | | 915 | Dr. Andreas Steffen | HSR University of Applied Sciences | 916 | | Rapperswil | 917 | | | 918 | Josef von Helden | Hochschule Hannover | 919 | | | 920 | James Tan | Infoblox | 921 | | | 922 | Steve Hanna (TNC-WG | Juniper Networks | 923 | Co-Chair) | | 924 | | | 925 | Cliff Kahn | Juniper Networks | 926 | | | 927 | Lisa Lorenzin | Juniper Networks | 928 | | | 929 | Atul Shah (TNC-WG Co- | Microsoft | 930 | Chair) | | 931 | | | 932 | Jon Baker | MITRE | 933 | | | 934 | Charles Schmidt | MITRE | 935 | | | 936 | Rainer Enders | NCP Engineering | 937 | | | 938 | Dick Wilkins | Phoenix Technologies | 939 | | | 940 | David Waltermire | NIST | 941 | | | 942 | Mike Boyle | U.S. Government | 943 | | | 944 | Emily Doll | U.S. Government | 945 | | | 946 | Jessica Fitzgerald- | U.S. Government | 947 | McKay | | 948 | | | 949 | Mary Lessels | U.S. Government | 950 | | | 951 | Chris Salter | U.S. Government | 952 +-----------------------+-------------------------------------------+ 954 Table 1: Members of the TNC Work Group that Contributed to the 955 Document 957 Special thanks also to Dan Ehrlich, Kathleen Moriarty, David Oliva 958 and Eric Voit for their thoughtful comments and edits. 960 8. IANA Considerations 962 This document does not define any new IANA registries. However, this 963 document does reference other documents that do define IANA 964 registries. As a result, the IANA Considerations section of the 965 referenced documents should be consulted. 967 9. Security Considerations 969 This Security Considerations section includes an analysis of the 970 attacks that may be mounted against systems that implement the EPCP 971 (Section 9.1) and the countermeasures that may be used to prevent or 972 mitigate these attacks (Section 9.2). Overall, a substantial 973 reduction in cyber risk can be achieved. 975 9.1. Threat Model 977 This section lists the attacks that can be mounted on a NEA 978 implementation of an EPCP environment. The following section 979 (Section 9.2) describes countermeasures. 981 Because the EPCP describes a specific use case for NEA components, 982 many security considerations for these components are addressed in 983 more detail in the technical specifications: [RFC8412], [IF-IMC], 984 [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV]. 986 9.1.1. Endpoint Attacks 988 While the EPCP provides substantial improvements in endpoint 989 security, endpoints can still be compromised. For this reason, all 990 parties must regard data coming from endpoints as potentially 991 unreliable or even malicious. An analogy can be drawn with human 992 testimony in an investigation or trial. Human testimony is essential 993 but must be regarded with suspicion. 995 o Compromise of endpoint: A compromised endpoint may report false 996 information to confuse or even provide maliciously crafted 997 information with a goal of infecting others. 999 o Putting bad information in SWID directory: Even if an endpoint is 1000 not completely compromised, some of the software running on it may 1001 be unreliable or even malicious. This software, potentially 1002 including the SWID generation or discovery tool, or malicious 1003 software pretending to be a SWID generation or discovery tool, can 1004 place incorrect or maliciously crafted information into the SWID 1005 directory. Endpoint users may even place such information in the 1006 directory, whether motivated by curiosity or confusion or a desire 1007 to bypass restrictions on their use of the endpoint. 1009 o Identity spoofing (impersonation): A compromised endpoint may 1010 attempt to impersonate another endpoint to gain its privileges or 1011 to besmirch the reputation of that other endpoint. This is of 1012 particular concern when using MAC addresses to identify endpoints, 1013 which, while widely used in endpoint behavior monitoring and 1014 threat assessment tools, are easy to spoof. 1016 9.1.2. Network Attacks 1018 Generally, the network cannot be trusted. A variety of attacks can 1019 be mounted using the network, including: 1021 o Eavesdropping, modification, injection, replay, deletion; 1023 o Traffic analysis; and 1025 o Denial of service and blocking traffic. 1027 9.1.3. Posture Manager Attacks 1029 The posture manager is a critical security element and therefore 1030 merits considerable scrutiny. A variety of attacks can be leveraged 1031 against the Posture Manager. 1033 o Compromised trusted manager: A compromised posture manager or a 1034 malicious party that is able to impersonate a posture manager can 1035 incorrectly grant or deny access to endpoints, place incorrect 1036 information into the repository, or send malicious messages to 1037 endpoints. 1039 o Misconfiguration of posture manager: Accidental or purposeful 1040 misconfiguration of a trusted posture manager can cause effects 1041 that are similar to those listed for compromised trusted posture 1042 manager. 1044 o Malicious untrusted posture manager: An untrusted posture manager 1045 cannot mount any significant attacks because all properly 1046 implemented endpoints will refuse to engage in any meaningful 1047 dialog with such a posture manager. 1049 9.1.4. Repository Attacks 1051 The repository is also an important security element and therefore 1052 merits careful scrutiny. 1054 o Putting bad information into trusted repository: An authorized 1055 repository client such as a server may be able to put incorrect 1056 information into a trusted repository or delete or modify 1057 historical information, causing incorrect decisions about endpoint 1058 security. Placing maliciously crafted data in the repository 1059 could even lead to compromise of repository clients, if they fail 1060 to carefully check such data. 1062 o Compromised trusted repository: A compromised trusted repository 1063 or a malicious untrusted repository that is able to impersonate a 1064 trusted repository can lead to effects similar to those listed for 1065 "Putting bad information into trusted repository". Further, a 1066 compromised trusted repository can report different results to 1067 different repository clients or deny access to the repository for 1068 selected repository clients. 1070 o Misconfiguration of trusted repository: Accidental or purposeful 1071 misconfiguration of a trusted repository can deny access to the 1072 repository or result in loss of historical data. 1074 o Malicious untrusted repository: An untrusted repository cannot 1075 mount any significant attacks because all properly implemented 1076 repository clients will refuse to engage in any meaningful dialog 1077 with such a repository. 1079 9.2. Countermeasures 1081 This section lists the countermeasures that can be used in a NEA 1082 implementation of an EPCP environment. 1084 9.2.1. Countermeasures for Endpoint Attacks 1086 This profile is in and of itself a countermeasure for a compromised 1087 endpoint. A primary defense for an endpoint is to run up to date 1088 software configured to be run as safely as possible. 1090 Ensuring that anti-virus signatures are up to date and that a 1091 firewall is configured are also protections for an endpoint that are 1092 supported by the current NEA specifications. 1094 For secure device identification and to correlate device identifiers 1095 if the MAC address is randomized, MAC addresses should be collected 1096 along with other, more secure endpoint identifiers. Endpoints that 1097 have hardware cryptographic modules that are provisioned by the 1098 enterprise, in accordance with [IEEE-802-1ar], can protect the 1099 private keys used for authentication and help prevent adversaries 1100 from stealing credentials that can be used for impersonation. Future 1101 versions of the EPCP may want to discuss in greater detail how to use 1102 a hardware cryptographic module, in accordance with [IEEE-802-1ar], 1103 to protect credentials and to protect the integrity of the code that 1104 executes during the bootstrap process by hashing or recording 1105 indicators of compromise. 1107 9.2.2. Countermeasures for Network Attacks 1109 To address network attacks, [RFC6876] includes required encryption, 1110 authentication, integrity protection, and replay protection. 1111 [Server-Discovery] also includes authorization checks to ensure that 1112 only authorized servers are trusted by endpoints. Any unspecified or 1113 not yet specified network protocols employed in the EPCP (e.g. the 1114 protocol used to interface with the repository) should include 1115 similar protections. 1117 These protections reduce the scope of the network threat to traffic 1118 analysis and denial of service. Countermeasures for traffic analysis 1119 (e.g. masking) are usually impractical but may be employed. 1120 Countermeasures for denial of service (e.g. detecting and blocking 1121 particular sources) SHOULD be used when appropriate to detect and 1122 block denial of service attacks. These are routine practices in 1123 network security. 1125 9.2.3. Countermeasures for Posture Manager Attacks 1127 Because of the serious consequences of posture manager compromise, 1128 posture managers SHOULD be especially well hardened against attack 1129 and minimized to reduce their attack surface. They SHOULD be 1130 monitored using the NEA protocols to ensure the integrity of the 1131 behavior and analysis data stored on the posture manager and SHOULD 1132 utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for 1133 identity and/or integrity measurements of the posture manager. They 1134 should be well managed to minimize vulnerabilities in the underlying 1135 platform and in systems upon which the posture manager depends. 1136 Network security measures such as firewalls or intrusion detection 1137 systems may be used to monitor and limit traffic to and from the 1138 posture manager. Personnel with administrative access to the posture 1139 manager should be carefully screened and monitored to detect problems 1140 as soon as possible. Posture manager administrators should not use 1141 password-based authentication but should instead use non-reusable 1142 credentials and multi-factor authentication (where available). 1143 Physical security measures should be employed to prevent physical 1144 attacks on posture managers. 1146 To ease detection of posture manager compromise, should it occur, 1147 posture manager behavior should be monitored to detect unusual 1148 behavior (such as a server reboot, unusual traffic patterns, or other 1149 odd behavior). Endpoints should log and/or notify users and/or 1150 administrators when peculiar posture manager behavior is detected. 1151 To aid forensic investigation, permanent read-only audit logs of 1152 security-relevant information pertaining to posture manager 1153 (especially administrative actions) should be maintained. If posture 1154 manager compromise is detected, the posture manager's certificate 1155 should be revoked and careful analysis should be performed of the 1156 source and impact of this compromise. Any reusable credentials that 1157 may have been compromised should be reissued. 1159 Endpoints can reduce the threat of server compromise by minimizing 1160 the number of trusted posture managers, using the mechanisms 1161 described in [Server-Discovery]. 1163 9.2.4. Countermeasures for Repository Attacks 1165 If the host for the repository is located on its own endpoint, it 1166 should be protected with the same measures taken to protect the 1167 posture manager. In this circumstance, all messages between the 1168 posture manager and repository should be protected with a mature 1169 security protocol such as TLS or IPsec. 1171 The repository can aid in the detection of compromised endpoints if 1172 an adversary cannot tamper with its contents. For instance, if an 1173 endpoint reports that it does not have an application with a known 1174 vulnerability installed, an administrator can check whether the 1175 endpoint might be lying by querying the repository for the history of 1176 what applications were installed on the endpoint. 1178 To help prevent tampering with the information in the repository: 1180 1. Only authorized parties should have privilege to run code on the 1181 endpoint and to change the repository. 1183 2. If a separate endpoint hosts the repository, then the 1184 functionality of that endpoint should be limited to hosting the 1185 repository. The firewall on the repository should only allow 1186 access to the posture manager and to any endpoint authorized for 1187 administration. 1189 3. The repository should ideally use "write once" media to archive 1190 the history of what was placed in the repository, to include a 1191 snapshot of the current status of applications on endpoints. 1193 10. Privacy Considerations 1195 The EPCP specifically addresses the collection of posture data from 1196 enterprise endpoints by an enterprise network. As such, privacy is 1197 not going to often arise as a concern for those deploying this 1198 solution. 1200 A possible exception may be the concerns a user may have when 1201 attempting to connect a personal endpoint (such as a phone or mobile 1202 endpoint) to an enterprise network. The user may not want to share 1203 certain details, such as an endpoint identifier or SWID tags, with 1204 the enterprise. The user can configure their NEA client to reject 1205 requests for this information; however, it is possible that the 1206 enterprise policy will not allow the user's endpoint to connect to 1207 the network without providing the requested data. 1209 An enterprise network should limit access to endpoint posture and 1210 identification information to authorized users. 1212 11. References 1214 11.1. Informative References 1216 [CIS] http://www.cisecurity.org/controls/, "CIS Critical 1217 Security Controls". 1219 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1220 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1221 Protect Your ICT System", November 2012. 1223 [ECP] Trusted Computing Group, "TCG Trusted Network Connect 1224 Endpoint Compliance Profile, Version 1.10", December 2014. 1226 [IEEE-802-1ar] 1227 Institute of Electrical and Electronics Engineers, "IEEE 1228 802.1ar", December 2009. 1230 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1231 Tardo, "Network Endpoint Assessment (NEA): Overview and 1232 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1233 . 1235 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1236 Architecture for Interoperability, Version 1.5", February 1237 2012. 1239 11.2. Normative References 1241 [I-D.ietf-mile-xmpp-grid] 1242 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 1243 "Using XMPP for Security Information Exchange", draft- 1244 ietf-mile-xmpp-grid-04 (work in progress), October 2017. 1246 [I-D.ietf-netconf-restconf-notif] 1247 Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 1248 A. Bierman, "Dynamic subscription to YANG Events and 1249 Datastores over RESTCONF", draft-ietf-netconf-restconf- 1250 notif-15 (work in progress), June 2019. 1252 [I-D.ietf-netconf-subscribed-notifications] 1253 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1254 A. Tripathy, "Customized Subscriptions to a Publisher's 1255 Event Streams", draft-ietf-netconf-subscribed- 1256 notifications-13 (work in progress), June 2018. 1258 [I-D.ietf-netconf-yang-push] 1259 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1260 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1261 Subscription", draft-ietf-netconf-yang-push-12 (work in 1262 progress), December 2017. 1264 [I-D.ietf-sacm-terminology] 1265 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1266 Winget, "Terminology for Security Assessment", draft-ietf- 1267 sacm-terminology-05 (work in progress), August 2014. 1269 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1270 IF-IMC, Version 1.3", February 2013. 1272 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1273 IF-IMV, Version 1.4", December 2014. 1275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1276 Requirement Levels", BCP 14, RFC 2119, 1277 DOI 10.17487/RFC2119, March 1997, 1278 . 1280 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1281 (PA) Protocol Compatible with Trusted Network Connect 1282 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1283 . 1285 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1286 A Posture Broker (PB) Protocol Compatible with Trusted 1287 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1288 March 2010, . 1290 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1291 and A. Bierman, Ed., "Network Configuration Protocol 1292 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1293 . 1295 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1296 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1297 . 1299 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1300 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1301 DOI 10.17487/RFC6876, February 2013, 1302 . 1304 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1305 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1306 2014, . 1308 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1309 NETCONF Protocol over Transport Layer Security (TLS) with 1310 Mutual X.509 Authentication", RFC 7589, 1311 DOI 10.17487/RFC7589, June 2015, 1312 . 1314 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1315 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1316 . 1318 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1319 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1320 . 1322 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1323 J. Fitzgerald-McKay, "Software Inventory Message and 1324 Attributes (SWIMA) for PA-TNC", RFC 8412, 1325 DOI 10.17487/RFC8412, July 2018, 1326 . 1328 [Server-Discovery] 1329 Trusted Computing Group, "DRAFT: TCG Trusted Network 1330 Connect PDP Discovery and Validation, Version 1.0", 1331 October 2015. 1333 [SWID] "Information technology--Software asset management--Part 1334 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1336 Appendix A. Rationale for an EPCP Solution 1338 A.1. Preventative Posture Assessments 1340 The value of continuous endpoint posture assessment is well 1341 established. Security experts have identified asset management and 1342 vulnerability remediation as a critical step for preventing 1343 intrusions. Application whitelisting, patching applications and 1344 operating systems, and using the latest versions of applications top 1345 the Defense Signals Directorate's "Top 4 Mitigations to Protect Your 1346 ICT System". [DSD] "Inventory of Authorized and Unauthorized 1347 Endpoints", "Inventory of Authorized and Unauthorized Software", and 1348 "Continuous Vulnerability Assessment and Remediation" are Controls 1, 1349 2, and 3, respectively, of the CIS Controls [CIS]. While there are 1350 commercially available solutions that attempt to address these 1351 security controls, these solutions do not run on all types of 1352 endpoints; consistently interoperate with other tools that could make 1353 use of the data collected; collect posture information from all types 1354 of endpoints in a consistent, standardized schema; or require vetted, 1355 standardized protocols that have been evaluated by the international 1356 community for cryptographic soundness. 1358 As is true of most solutions offered today, the solution found in the 1359 EPCP does not attempt to solve the lying endpoint problem, or detect 1360 infected endpoints; rather, it focuses on ensuring that healthy 1361 endpoints remain healthy by keeping software up-to-date and patched. 1363 A.2. All Network-Connected Endpoints are Endpoints 1365 As defined by [I-D.ietf-sacm-terminology], an endpoint is any 1366 physical or virtual computing endpoint that can be connected to a 1367 network. Posture assessment against policy is equally, if not more, 1368 important for continuously connected endpoints, such as enterprise 1369 workstations and infrastructure endpoints, as it is for sporadically 1370 connected endpoints. Continuously connected endpoints are just as 1371 likely to fall out of compliance with policy, and a standardized 1372 posture assessment method is necessary to ensure they can be properly 1373 handled. 1375 A.3. All Endpoints on the Network Must be Uniquely Identified 1377 Many administrators struggle to identify what endpoints are connected 1378 to the network at any given time. By requiring a standardized method 1379 of endpoint identity, the EPCP will enable administrators to answer 1380 the basic question, "What is on my network?" In 1381 [I-D.ietf-sacm-terminology], SACM defines this set of endpoints on 1382 the network as the SACM domain. Unique endpoint identification also 1383 enables the comparison of current and past endpoint posture 1384 assessments, by allowing administrators to correlate assessments from 1385 the same endpoint. This makes it easier to flag suspicious changes 1386 in endpoint posture for manual or automatic review, and helps to 1387 swiftly identify malicious changes to endpoint applications. 1389 A.4. Standardized Data Models 1391 Meeting EPCP best practices requires the use of standardized data 1392 models for the exchange of posture information. This helps to ensure 1393 that the posture information sent from endpoints to the repository 1394 can be easily stored, due to their known format, and shared with 1395 authorized endpoints and users. 1397 Posture information must be sent over standardized protocols to 1398 ensure the confidentiality and authenticity of this data while in 1399 transit. Implementations of the EPCP include [RFC6876] and [RFC6241] 1400 for communication between the target endpoint and the posture 1401 manager. These protocols allow networks that implement this solution 1402 to collect large amounts of posture information from an endpoint to 1403 make decisions about that endpoint's compliance with some policy. 1404 The EPCP offers a solution for all endpoints already connected to the 1405 network. Periodic assessments and automated reporting of changes to 1406 endpoint posture allow for instantaneous identification of connected 1407 endpoints that are no longer compliant to some policy. 1409 A.5. Posture Information Must Be Stored 1411 Posture information must be stored by the repository and must be 1412 exposed to an interface at the posture manager. Standard data models 1413 enable standard queries from an interface exposed to an administrator 1414 at the posture manager console. A repository must retain any current 1415 posture information retrieved from the target endpoint and store it 1416 indexed by the unique identifier for the endpoint. Any posture 1417 collection manager specified by this profile must be able to 1418 ascertain from its corresponding posture collection engine whether 1419 the posture information is up to date. An interface on the posture 1420 manager must support a request to obtain up-to-date information when 1421 an endpoint is connected. This interface must also support the 1422 ability to make a standard set of queries about the posture 1423 information stored by the repository. In the future, some forms of 1424 posture information might be retained at the endpoint. The interface 1425 on the posture manager must accommodate the ability to make a request 1426 to the corresponding posture collection engine about the posture of 1427 the target endpoint. Standard data models and protocols also enable 1428 the security of posture assessment results. By storing these results 1429 indexed under the endpoint's unique identification, secure storage 1430 itself enables endpoint posture information correlation, and ensures 1431 that the enterprise's repositories always offer the freshest, most 1432 up-to-date view of the enterprise's endpoint posture information 1433 possible. 1435 A.6. Posture Information Can Be Shared 1437 By exposing posture information using a standard interface and API, 1438 other security and operational components have a high level of 1439 insight into the enterprise's endpoints and the software installed on 1440 them. This will support innovation in the areas of asset management, 1441 vulnerability scanning, and administrative interfaces, as any 1442 authorized infrastructure endpoint can interact with the posture 1443 information. 1445 A.7. Enterprise Asset Posture Information Belongs to the Enterprise 1447 Owners and administrators must have complete control of posture 1448 information, policy, and endpoint mitigation. Standardized data 1449 models, protocols and interfaces help to ensure that this posture 1450 information is not locked in proprietary databases, but is made 1451 available to its owners. This enables administrators to develop as 1452 nuanced a policy as necessary to keep their networks secure. Of 1453 course, there may be exceptions to this such as the case with 1454 privacy-related information (e.g., personally identifiable 1455 information). 1457 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 1459 B.1. Supported Use Cases 1461 The following sections describe the different use cases supported by 1462 the EPCP. 1464 B.1.1. Hardware Asset Management 1466 Using the administrative interface on the posture manager, an 1467 authorized user can learn: 1469 o what endpoints are connected to the network at any given time; and 1471 o what SWID tags were reported for the endpoints. 1473 The ability to answer these questions offers a standards-based 1474 approach to asset management, which is a vital part of enterprise 1475 processes such as compliance report generation for the Federal 1476 Information Security Modernization Act (FISMA), Payment Card Industry 1477 Data Security Standard (PCI DSS), Health Insurance Portability and 1478 Accountability Act (HIPAA), etc. 1480 B.1.2. Software Asset Management 1482 The administrative interface on the posture manager provides the 1483 ability for authorized users and infrastructure to know which 1484 software is installed on which endpoints on the enterprise's network. 1485 This allows the enterprise to answer questions about what software is 1486 installed to determine if it is licensed or prohibited. This 1487 information can also drive other use cases such as: 1489 o vulnerability management: knowing what software is installed 1490 supports the ability to determine which endpoints contain 1491 vulnerable software and need to be patched. 1493 o configuration management: knowing which security controls need to 1494 be applied to harden installed software and better protect 1495 endpoints. 1497 B.1.3. Vulnerability Management 1499 The administrative interface also provides the ability for authorized 1500 users or infrastructure to locate endpoints running software for 1501 which vulnerabilities have been announced. Because of 1503 1. the unique IDs assigned to each endpoint; and 1505 2. the rich application data provided in the endpoints' posture 1506 information, 1508 the repository can be queried to find all endpoints running a 1509 vulnerable application. Endpoints suspected of being vulnerable can 1510 be addressed by the administrator or flagged for further scrutiny. 1512 B.1.4. Threat Detection and Analysis 1514 The repository's standardized API allows authorized infrastructure 1515 endpoints and software to search endpoint posture assessment 1516 information for evidence that an endpoint's software inventory has 1517 changed, and can make endpoint software inventory data available to 1518 other endpoints. This automates security data sharing in a way that 1519 expedites the correlation of relevant network data, allowing 1520 administrators and infrastructure endpoints to identify odd endpoint 1521 behavior and configuration using secure, standards-based data models 1522 and protocols. 1524 B.2. Non-Supported Use Cases 1526 Several use cases, including but not limited to these, are not 1527 covered by the EPCP: 1529 o Gathering non-standardized types of posture information: The EPCP 1530 does not prevent administrators from collecting posture 1531 information in proprietary formats from the endpoint; however it 1532 does not set requirements for doing so. 1534 o Solving the lying endpoint problem: The EPCP does not address the 1535 lying endpoint problem; the Profile makes no assertions that it 1536 can catch an endpoint that is, either maliciously or accidentally, 1537 reporting false posture information to the posture manager. 1538 However, other solutions may be able to use the posture 1539 information collected using the capabilities described in this 1540 profile to catch an endpoint in a lie. For example, a sensor may 1541 be able to compare the posture information it has collected on an 1542 endpoint's activity on the network to what the endpoint reported 1543 to the server and flag discrepancies. However, these capabilities 1544 are not described in this profile. 1546 Appendix C. Endpoint Posture Collection Profile Examples 1548 The following subsections provide examples of the EPCP as implemented 1549 using components from the NEA architecture. 1551 C.1. Continuous Posture Assessment of an Endpoint 1553 Endpoint Posture Manager 1554 +---------------+ +---------------+ 1555 | | | | 1556 | +-----------+ | | +-----------+ | 1557 | | SWID | | | | SWID | | 1558 | | Posture | | | | Posture | | 1559 | | Collector | | | | Validator | | 1560 | +-----------+ | | +-----------+ | 1561 | | | | | | 1562 | | IF-IMC | | | IF-IMV | 1563 | | | | | | 1564 | +-----------+ | | +-----------+ | 1565 | | PB Client | | | | PB Server | | 1566 | +-----------+ | | +-----------+ | 1567 | | | | | | 1568 | | | | | | 1569 | | | | | | 1570 | +-----------+ | | +-----------+ | 1571 | | PT Client | |<------>| | PT Server | | 1572 | +-----------+ | PT-TLS | +-----------+ | 1573 | | | | 1574 +---------------+ +---------------+ 1576 Figure 4: Continuous Posture Assessment of an Endpoint 1578 C.1.1. Change on Endpoint Triggers Posture Assessment 1580 A new application is installed on the endpoint, and the SWID 1581 directory is updated. This triggers an update from the SWID posture 1582 collector to the SWID posture validator. The message is sent down 1583 the NEA stack, encapsulated by NEA protocols until it is sent by the 1584 posture transport client to the posture transport server. The 1585 posture transport server then forwards it up through the stack, where 1586 the layers of encapsulation are removed until the SWID Message 1587 arrives at the SWID posture validator. 1589 Endpoint Posture Manager 1590 +---------------+ +---------------+ 1591 | | | | 1592 | +-----------+ | | +-----------+ | 1593 | | SWID | | | | SWID | | 1594 | | Posture | | | | Posture | | 1595 | | Collector | | | | Validator | | 1596 | +-----------+ | | +-----------+ | 1597 | | | SWID Message | | | 1598 | | IF-IMC | for PA-TNC | | IF-IMV | 1599 | | | | | | 1600 | +-----------+ | | +-----------+ | 1601 | | PB Client | | | | PB Server | | 1602 | +-----------+ | | +-----------+ | 1603 | | | | | | 1604 | | | PB-TNC {SWID | | | 1605 | | | Message for | | | 1606 | | | PA-TNC} | | | 1607 | +-----------+ | | +-----------+ | 1608 | | PT Client | |<-------------->| | PT Server | | 1609 | +-----------+ | PT-TLS {PB-TNC | +-----------+ | 1610 | | {SWID Message | | 1611 +---------------+ for PA-TNC}} +---------------+ 1613 Figure 5: Compliance Protocol Encapsulation 1615 The SWID posture validator stores the new tag information in the 1616 repository. If the tag indicates that the endpoint is compliant to 1617 the policy, then the process is complete until the next time an 1618 update is needed (either because policy states that the endpoint must 1619 submit posture assessment results periodically or because an 1620 install/uninstall/update on the endpoint triggers a posture 1621 assessment). 1623 Endpoint Posture Manager 1624 +---------------+ +---------------+ 1625 | | | | 1626 | +-----------+ | | +-----------+ | 1627 | | SWID | | | | SWID |-|-+ 1628 | | Posture | | | | Posture | | | 1629 | | Collector | | | | Validator | | | 1630 | +-----------+ | | +-----------+ | | 1631 | | | | | | | Repository 1632 | | IF-IMC | | | IF-IMV | | +--------+ 1633 | | | | | | | | | 1634 | +-----------+ | | +-----------+ | | | | 1635 | | PB Client | | | | PB Server | | +---->| | 1636 | +-----------+ | | +-----------+ | | | 1637 | | | | | | +--------+ 1638 | | | | | | 1639 | | | | | | 1640 | +-----------+ | | +-----------+ | 1641 | | PT Client | |<------>| | PT Server | | 1642 | +-----------+ | PT-TLS | +-----------+ | 1643 | | | | 1644 +---------------+ +---------------+ 1646 Figure 6: Storing SWIDs in the Repository 1648 If the endpoint has fallen out of compliance with a policy, the 1649 posture manager can alert the administrator via the posture manager's 1650 administrative interface. The administrator can then take steps to 1651 address the problem. If the administrator has already established a 1652 policy for automatically addressing this problem, that policy will be 1653 followed. 1655 (") 1656 __|__ 1657 +-->| 1658 Endpoint Posture Manager | / \ 1659 +---------------+ +---------------+ | 1660 | | | | | 1661 | +-----------+ | | +-----------+ | | 1662 | | SWID | | | | SWID |-|-+ 1663 | | Posture | | | | Posture | | 1664 | | Collector | | | | Validator | | 1665 | +-----------+ | | +-----------+ | 1666 | | | | | | Repository 1667 | | IF-IMC | | | IF-IMV | +--------+ 1668 | | | | | | | | 1669 | +-----------+ | | +-----------+ | | | 1670 | | PB Client | | | | PB Server | | | | 1671 | +-----------+ | | +-----------+ | | | 1672 | | | | | | +--------+ 1673 | | | | | | 1674 | | | | | | 1675 | +-----------+ | | +-----------+ | 1676 | | PT Client | |<------>| | PT Server | | 1677 | +-----------+ | PT-TLS | +-----------+ | 1678 | | | | 1679 +---------------+ +---------------+ 1681 Figure 7: Server Alerts Network Admin 1683 C.2. Administrator Searches for Vulnerable Endpoints 1685 An announcement is made that a particular version of a piece of 1686 software has a vulnerability. The administrator uses the 1687 administrative interface on the server to search the repository for 1688 endpoints that reported the SWID tag for the vulnerable software. 1690 (") 1691 __|__ 1692 +-->| 1693 Endpoint Posture Manager | / \ 1694 +---------------+ +---------------+ | 1695 | | | | | 1696 | +-----------+ | | +-----------+ | | 1697 | | SWID | | | | SWID |-|-+ 1698 | | Posture | | | | Posture | | 1699 | | Collector | | | | Validator | | 1700 | +-----------+ | | +-----------+ | 1701 | | | | | | Repository 1702 | | IF-IMC | | | IF-IMV | +--------+ 1703 | | | | | | | | 1704 | +-----------+ | | +-----------+ | | | 1705 | | PB Client | | | | PB Server | |------>| | 1706 | +-----------+ | | +-----------+ | | | 1707 | | | | | | +--------+ 1708 | | | | | | 1709 | | | | | | 1710 | +-----------+ | | +-----------+ | 1711 | | PT Client | |<------>| | PT Server | | 1712 | +-----------+ | PT-TLS | +-----------+ | 1713 | | | | 1714 +---------------+ +---------------+ 1716 Figure 8: Admin Searches for Vulnerable Endpoints 1718 The repository returns a list of entries in the matching the 1719 administrator's search. The administrator can then address the 1720 vulnerable endpoints by taking some follow-up action such as removing 1721 it from the network, quarantining it, or updating the vulnerable 1722 software. 1724 Appendix D. Change Log 1726 D.1. -04 to -05 1728 Updated the diagram so the Evaluator and Repository are "current 1729 work". 1731 Clarified how the Posture Collection Engine can push data, respond to 1732 queries, and establish secure transport connectivity for fulfilling 1733 subscriptions. 1735 Expanded on the future work around leveraging NETCONF, RESTCONF, and 1736 YANG Push for network devices. 1738 Documented the need to reassess MAC addresses as a device identifier. 1740 Made various typographical and editorial changes. 1742 D.2. -03 to -04 1744 Addressed various comments from the SACM WG. 1746 Refactored the document to better focus it on the communications 1747 between endpoints and the posture manager and the best practices for 1748 EPCP implementations. 1750 Made other editorial changes and improved consistency throughout the 1751 document. 1753 D.3. -02 to -03 1755 Addressed various comments from the SACM WG. 1757 Added a reference to TCG ECP 1.0. 1759 Removed text in the "SWID Posture Validator" section that states it 1760 performs evaluation. This was removed because it contradicts the 1761 posture manager not performing any evaluations. 1763 Expanded the "Provisioning" section of the "EPCP Transactions" 1764 section to include examples of endpoint identifiers and the need to 1765 provision endpoints with components and data models. 1767 Combined text for the capabilities of the Administrative Interface 1768 and API. 1770 Removed superfluous and introductory text from the "Security 1771 Considerations" section. 1773 Renamed section "Vulnerability Searches" to Vulnerability 1774 Management". 1776 Changed I-D category to BCP. 1778 Changed references to the NETMOD architecture to the NETCONF 1779 architecture because NETCONF represents the management protocol 1780 whereas NETMOD is focused on the definition of data models. 1782 Addressed various editorial suggestions. 1784 D.4. -01 to -02 1786 Addressed various comments from the SACM WG. 1788 Added a section for the collection of posture information from 1789 network devices using standards from the NETMOD WG. 1791 Updated EPCP component diagrams so they were not specific to a NEA- 1792 based implementation. 1794 Updated EPCP NEA example diagrams to reflect all the components in 1795 the NEA architecture. 1797 D.5. -00 to -01 1799 There are no textual changes associated with this revision. This 1800 revision simply reflects a resubmission of the document so that it 1801 remains in active status. 1803 D.6. -01 to -02 1805 Added references to the Software Inventory Message and Attributes 1806 (SWIMA) for PA-TNC I-D. 1808 Replaced references to PC-TNC with IF-IMC. 1810 Removed erroneous hyphens from a couple of section titles. 1812 Made a few minor editorial changes. 1814 D.7. -02 to -00 1816 Draft adopted by IETF SACM WG. 1818 D.8. -00 to -01 1820 Significant edits to up-level the draft to describe SACM collection 1821 over multiple different protocols. 1823 Replaced references to SANS with CIS. 1825 Made other minor editorial changes. 1827 Authors' Addresses 1828 Danny Haynes 1829 The MITRE Corporation 1830 202 Burlington Road 1831 Bedford, MA 01730 1832 USA 1834 Email: dhaynes@mitre.org 1836 Jessica Fitzgerald-McKay 1837 Department of Defense 1838 9800 Savage Road 1839 Ft. Meade, Maryland 1840 USA 1842 Email: jmfitz2@nsa.gov 1844 Lisa Lorenzin 1845 Pulse Secure 1846 2700 Zanker Rd., Suite 200 1847 San Jose, CA 95134 1848 US 1850 Email: llorenzin@pulsesecure.net