idnits 2.17.1 draft-ietf-sacm-ecp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 10 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 (February 15, 2019) is 1890 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 (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM D. Haynes 3 Internet-Draft The MITRE Corporation 4 Intended status: Best Current Practice J. Fitzgerald-McKay 5 Expires: August 19, 2019 Department of Defense 6 L. Lorenzin 7 Pulse Secure 8 February 15, 2019 10 Endpoint Posture Collection Profile 11 draft-ietf-sacm-ecp-04 13 Abstract 15 This document specifies the Endpoint Posture Collection Profile, 16 which describes the best practices for the application of IETF, TNC, 17 and ISO/IEC data models, protocols, and interfaces to support the on- 18 going collection and communication of endpoint posture to a 19 centralized server where it can be stored and made available to other 20 tools. This document is an extension of the Trusted Computing 21 Group's Endpoint Compliance Profile Version 1.0 specification [ECP]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 19, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Endpoint Posture Collection Profile . . . . . . . . . . . . . 5 60 3.1. Components . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.1.1. Posture Collection Engine . . . . . . . . . . . . 7 63 3.1.2. Posture Manager . . . . . . . . . . . . . . . . . . . 7 64 3.1.2.1. Posture Collection Manager . . . . . . . . . . . 7 65 3.1.3. Repository . . . . . . . . . . . . . . . . . . . . . 7 66 3.1.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1.5. Orchestrator . . . . . . . . . . . . . . . . . . . . 8 68 3.1.6. Administrative Interface and API . . . . . . . . . . 8 69 3.2. Transactions . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . 9 71 3.2.2. Discovery and Validation . . . . . . . . . . . . . . 9 72 3.2.3. Event Driven Collection . . . . . . . . . . . . . . . 9 73 3.2.4. Querying . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2.5. Data Storage . . . . . . . . . . . . . . . . . . . . 10 75 3.2.6. Data Sharing . . . . . . . . . . . . . . . . . . . . 10 76 4. IETF NEA EPCP Implementation for Traditional Endpoints . . . 10 77 4.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 12 78 4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.2.1. Posture Collector . . . . . . . . . . . . . . . . . . 13 80 4.2.2. Posture Broker Client . . . . . . . . . . . . . . . . 13 81 4.2.3. Posture Transport Client . . . . . . . . . . . . . . 13 82 4.3. Posture Manager . . . . . . . . . . . . . . . . . . . . . 13 83 4.3.1. Posture Validator . . . . . . . . . . . . . . . . . . 13 84 4.3.2. Posture Broker Server . . . . . . . . . . . . . . . . 13 85 4.3.3. Posture Transport Server . . . . . . . . . . . . . . 13 86 4.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.5. IETF SACM SWAM Extension to the IETF NEA EPCP 88 Implementation . . . . . . . . . . . . . . . . . . . . . 14 89 4.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 14 90 4.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 14 91 4.5.3. SWID Posture Collectors and Posture Validators . . . 14 92 4.5.3.1. The SWID Posture Collector . . . . . . . . . . . 15 93 4.5.3.2. The SWID Posture Validator . . . . . . . . . . . 15 94 4.5.4. Repository . . . . . . . . . . . . . . . . . . . . . 16 95 5. IETF NETCONF EPCP Implementation for Network Device Endpoints 16 96 5.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 17 97 5.2. Posture Manager Provisioning . . . . . . . . . . . . . . 17 98 5.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 17 99 5.3.1. Datastore . . . . . . . . . . . . . . . . . . . . . . 17 100 5.4. Posture Manager . . . . . . . . . . . . . . . . . . . . . 18 101 5.5. Repository . . . . . . . . . . . . . . . . . . . . . . . 18 102 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 106 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 21 107 9.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 21 108 9.1.2. Network Attacks . . . . . . . . . . . . . . . . . . . 22 109 9.1.3. Posture Manager Attacks . . . . . . . . . . . . . . . 22 110 9.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 22 111 9.2. Countermeasures . . . . . . . . . . . . . . . . . . . . . 23 112 9.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 23 113 9.2.2. Countermeasures for Network Attacks . . . . . . . . . 23 114 9.2.3. Countermeasures for Posture Manager Attacks . . . . . 24 115 9.2.4. Countermeasures for Repository Attacks . . . . . . . 25 116 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 118 11.1. Informative References . . . . . . . . . . . . . . . . . 26 119 11.2. Normative References . . . . . . . . . . . . . . . . . . 26 120 Appendix A. Rationale for an EPCP Solution . . . . . . . . . . . 28 121 A.1. Preventative Posture Assessments . . . . . . . . . . . . 28 122 A.2. All Network-Connected Endpoints are Endpoints . . . . . . 29 123 A.3. All Endpoints on the Network Must be Uniquely Identified 29 124 A.4. Standardized Data Models . . . . . . . . . . . . . . . . 29 125 A.5. Posture Information Must Be Stored . . . . . . . . . . . 30 126 A.6. Posture Information Can Be Shared . . . . . . . . . . . . 30 127 A.7. Enterprise Asset Posture Information Belongs to the 128 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 30 129 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 31 130 B.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 31 131 B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 31 132 B.1.2. Software Asset Management . . . . . . . . . . . . . . 31 133 B.1.3. Vulnerability Management . . . . . . . . . . . . . . 32 134 B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 32 135 B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 32 136 Appendix C. Endpoint Posture Collection Profile Examples . . . . 33 137 C.1. Continuous Posture Assessment of an Endpoint . . . . . . 33 138 C.1.1. Change on Endpoint Triggers Posture Assessment . . . 33 139 C.2. Administrator Searches for Vulnerable Endpoints . . . . . 36 140 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 37 141 D.1. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 37 142 D.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 38 143 D.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 38 144 D.4. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39 145 D.5. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 39 146 D.6. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 39 147 D.7. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 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 insupport 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************* 253 * * 254 * * 255 * * Posture Manager Endpoint 256 * Orchestrator * +----------------+ +----------------+ 257 * +--------+ * | | | | 258 * | |<------*->| | | | 259 * | | pub/ * | | | | 260 * | | sub * | | | | 261 * | | * | +------------+ | | +------------+ | 262 * +--------+ * | | | | | | | | 263 * * | | Posture | | | | Posture | | 264 * Evaluator Repository * | | Collection | | | | Collection | | 265 * +------+ +--------+ * | | Manager | |<-------| | Engine | | 266 * | | | | * | | | | report | | | | 267 * | | | | * | +------------+ | | +------------+ | 268 * | |<-----> | |<------*->| | query | | 269 * | |request/| | store * | |------->| | 270 * | |respond | | * | | | | 271 * | | | | * | | | | 272 * +------+ +--------+ * +----------------+ +----------------+ 273 * | * ^ 274 * | query * | 275 * +-----------------------------*----------+ 276 * * 277 * **************************** 278 * * 279 * +--------------------------------+ * 280 * | Administrative Interface | * 281 * | and API | * 282 * +--------------------------------+ * 283 * * 284 ************FUTURE WORK**************************************** 286 Figure 1: EPCP Components 288 3.1.1. Endpoint 290 An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is 291 monitored by the enterprise and is the target of posture assessments. 292 To support these posture assessments, posture information is 293 collected via a posture collection engine. 295 3.1.1.1. Posture Collection Engine 297 The posture collection engine is located on the target endpoint and 298 receives queries from a posture collection manager. It also sends 299 collected posture information to the posture manager where it can be 300 sanity checked and stored in the repository. The posture collection 301 engine also contains a capability that sets up exchanges between the 302 target endpoint and posture manager. This capability makes the 303 posture collection engine responsible for performing the client-side 304 portion of encryption handshakes, and for locating authorized posture 305 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 3.1.3. Repository 332 The repository hosts guidance, endpoint identification information, 333 and posture information reported by target endpoints where it is made 334 available to authorized components and persisted over a period of 335 time set by the administrator. Information stored in the repository 336 will be accessible to authorized parties via a standard 337 administrative interface as well as through a standardized API. The 338 repository may be a standalone component or may be located on the 339 posture manager. Furthermore, an implementation is not restricted to 340 a single repository and may leverage several repositories to provide 341 this functionality. 343 3.1.4. Evaluator 345 The evaluator assesses the posture status of a target endpoint by 346 comparing collected posture information against the desired state of 347 the target endpoint specified in guidance. The evaluator queries and 348 retrieves the appropriate guidance from the repository as well as 349 queries and retrieves the posture information required for the 350 assessment from the repository. If the required posture information 351 is not available in the repository, the evaluator may request the 352 posture information from the posture collection manager, which will 353 result in the collection of additional posture information from the 354 target endpoint. This information is subsequently stored in the 355 repository where it is made available to the evaluator and other 356 components. The results of the assessment are stored in the 357 repository where they are available to tools and administrators for 358 follow-up actions, further evaluation, and historical purposes. 360 3.1.5. Orchestrator 362 The orchestrator provides a publish/subscribe interface for the 363 repository so that infrastructure endpoints can subscribe to and 364 receive published posture assessment results from the repository 365 regarding endpoint posture changes. 367 3.1.6. Administrative Interface and API 369 The administrative interface allows administrators to query the 370 repository and manage the endpoints and software used in the EPCP via 371 the posture manager. Similarly, an API is necessary to allow 372 infrastructure endpoints and software access to the information 373 stored in the repository and to manage the endpoints and software 374 used in the EPCP. The administrative interface and API provide 375 authorized users, infrastructure endpoints, and software with the 376 ability to query the repository for data, send commands to the 377 posture collection managers requesting information from the 378 associated posture collection engines residing on endpoints, and 379 establish and update the policy that resides on the posture manager 381 3.2. Transactions 383 The following sections describe the transactions associated with the 384 components of the EPCP architecture and may be provided in an 385 implementation. 387 3.2.1. Provisioning 389 An endpoint is provisioned with one or more attributes that will 390 serve as its unique identifier on the network as well as the 391 components and data models necessary to interact with the posture 392 manager. Examples of such identifiers include MAC addresses, serial 393 numbers, hardware certificates compliant with [IEEE-802-1ar], and the 394 identities of hardware cryptographic modules among others. Once 395 provisioning is complete, the endpoint is deployed on the network. 396 Over time, components and data models may need to be added to the 397 endpoint or updated to support the collection needs of an enterprise. 399 3.2.2. Discovery and Validation 401 If necessary, the target endpoint finds and validates the posture 402 manager. The posture collection engine on the target endpoint and 403 posture collection manager on the posture manager complete an 404 encryption handshake, during which endpoint identity information is 405 exchanged. 407 3.2.3. Event Driven Collection 409 The posture assessment is initiated when the posture collector engine 410 on the target endpoint notices that relevant posture information on 411 the endpoint has changed. Then, the posture collection engine 412 initiates a posture assessment information exchange with the posture 413 collection manager. 415 3.2.4. Querying 417 The posture assessment is initiated by the posture collection 418 manager. This can occur because: 420 1. policy states that a previous assessment has aged out or become 421 invalid, or 423 2. the posture collection manager is alerted by a sensor or an 424 administrator (via the posture manager's administrative 425 interface) that an assessment must be completed 427 3.2.5. Data Storage 429 Once posture information is received by the posture manager, it is 430 forwarded to the repository. The repository could be co-located with 431 the posture manager, or there could be direct or brokered 432 communication between the posture manager and the repository. The 433 posture information is stored in the repository along with past 434 posture information collected about the target endpoint. 436 3.2.6. Data Sharing 438 Because the target endpoint posture information was sent in 439 standards-based data models over secure, standardized protocols, and 440 then stored in a centralized repository linked to unique endpoint 441 identifiers, authorized parties are able to access the posture 442 information. Such authorized parties may include, but are not 443 limited to, administrators or endpoint owners (via the posture 444 manager's administrative interface), evaluators that access the 445 repository directly, and orchestrators that rely on publish/subscribe 446 communications with the repository. 448 4. IETF NEA EPCP Implementation for Traditional Endpoints 450 When EPCP is used, posture collectors running on the target endpoint 451 gather posture information as changes occur on the endpoint. The 452 data is aggregated by the posture broker client and forwarded to a 453 posture manager, over a secure channel, via the posture transport 454 client. Once received by the posture transport server on the posture 455 manager, the posture information is directed by the posture broker 456 server to the appropriate posture validators where it can be 457 processed and stored in a repository. There the posture information 458 can be used by other tools to carry out assessment tasks. Posture 459 collectors can also be queried by posture validators to refresh 460 posture information about the target endpoint or to ask a specific 461 question about posture information. This is shown in Figure 2. 463 Posture Posture 464 Collection Collection 465 Manager Engine 466 +---------------+ +---------------+ 467 | | | | 468 | +-----------+ | PA-TNC | +-----------+ | 469 | | Posture | |--------| | Posture | | 470 | | Validator | | | | Collector | | 471 | +-----------+ | | +-----------+ | 472 | | | | | | 473 | | IF-IMV | | | IF-IMC | 474 | | | | | | 475 | +-----------+ | PB-TNC | +-----------+ | 476 | | PB Server | |--------| | PB Client | | 477 | +-----------+ | | +-----------+ | 478 | | | | | | 479 | | | | | | 480 | | | | | | 481 | +-----------+ | | +-----------+ | 482 | | PT Server | |<------>| | PT Client | | 483 | +-----------+ | PT-TLS | +-----------+ | 484 | | | | 485 +---------------+ +---------------+ 487 Figure 2: NEA Components 489 These requirements are written with a view to performing a posture 490 assessment on an endpoint; as the EPCP grows and evolves, these 491 requirements will be expanded to address issues that arise. Note 492 that these requirements refer to defined components of the NEA 493 architecture [RFC5209]. As with the NEA architecture, vendors have 494 discretion as to how these NEA components map to separate pieces of 495 software or endpoints. 497 Furthermore, it should be noted that the posture broker client and 498 posture transport client components of the posture collection engine 499 and the posture broker server and posture transport server components 500 of the posture collection manager would likely need to be implemented 501 by a single vendor because there are no standardized interfaces 502 between the respective components and would not be interoperable. 504 Examples of the EPCP as implemented using the components from the NEA 505 architecture are provided in Appendix C. 507 4.1. Endpoint Provisioning 509 An endpoint is provisioned with a machine certificate that will serve 510 as its unique identifier on the network as well as the components 511 necessary to interact with the posture manager. This includes a 512 posture collection engine to manage requests from the posture manager 513 and the posture collectors necessary to collect the posture 514 information of importance to the enterprise. The endpoint is 515 deployed on the network. 517 The target endpoint SHOULD authenticate to the posture manager using 518 a machine certificate during the establishment of the outer tunnel 519 achieved with the posture transport protocol defined in [RFC6876]. 520 [IF-IMV] specifies how to pull an endpoint identifier out of a 521 machine certificate. An endpoint identifier SHOULD be created in 522 conformance with [IF-IMV] from a machine certificate sent via 523 [RFC6876]. 525 In the future, the identity could be a hardware certificate compliant 526 with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated 527 with the identity of a hardware cryptographic module, in accordance 528 with [IEEE-802-1ar], if present on the endpoint. The enterprise 529 SHOULD stand up a certificate root authority; install its root 530 certificate on endpoints and on the posture manager; and provision 531 the endpoints and the posture manager with machine certificates. The 532 target endpoint MAY authenticate to the posture manager using a 533 combination of the machine account and password; however, this is 534 less secure and not recommended. 536 4.2. Endpoint 538 The endpoint MUST conform to [RFC5793], which levies several 539 requirements against the endpoint. An endpoint that complies with 540 these requirements will be able to: 542 1. attempt to initiate a session with the posture manager if the 543 posture makes a request to send an update to posture manager; 545 2. notify the posture collector if no PT-TLS session with the 546 posture manager can be created; 548 3. notify the posture collector when a PT-TLS session is 549 established; and 551 4. receive information from the posture collectors, forward this 552 information to the posture manager via the posture collection 553 engine. 555 4.2.1. Posture Collector 557 Any posture collector used in an EPCP solution MUST be conformant 558 with the TCG TNC Integrity Measurement Collector interface [IF-IMC]. 560 4.2.2. Posture Broker Client 562 The posture broker client MUST conform to [IF-IMC] to enable 563 communications between the posture broker client and the posture 564 collectors on the endpoint. 566 4.2.3. Posture Transport Client 568 The posture transport client MUST implement PT-TLS. 570 The posture transport client MUST support the use of machine 571 certificates for TLS at each endpoint consistent with the 572 requirements stipulated in [RFC6876] and [Server-Discovery]. 574 The posture transport client MUST be able to locate an authorized 575 posture manager, and switch to a new posture manager when required by 576 the network, in conformance with [Server-Discovery]. 578 4.3. Posture Manager 580 The posture manager MUST conform to all requirements in the 581 [RFC5793]. 583 4.3.1. Posture Validator 585 Any posture validator used in an EPCP solution MUST be conformant 586 with the TCG TNC Integrity Measurement Verifier interface [IF-IMV]. 588 4.3.2. Posture Broker Server 590 The posture broker server MUST conform to [IF-IMV]. Conformance to 591 [IF-IMV] enables the posture broker server to obtain endpoint 592 identity information from the posture transport server, and pass this 593 information to any posture validators on the posture manager. 595 4.3.3. Posture Transport Server 597 The posture transport server MUST implement PT-TLS. 599 The posture transport server MUST support the use of machine 600 certificates for TLS at each endpoint consistent with the 601 requirements stipulated in [RFC6876] and [Server-Discovery]. 603 4.4. Repository 605 EPCP requires a simple administrative interface for the repository. 606 Posture validators on the posture manager receive the target endpoint 607 posture information via PA-TNC [RFC5792] messages sent from 608 corresponding posture collectors on the target endpoint. The posture 609 validators store this information in the repository linked to the 610 identity of the target endpoint where the posture collectors are 611 located. 613 4.5. IETF SACM SWAM Extension to the IETF NEA EPCP Implementation 615 This section defines the requirements associated with the software 616 asset management extension [RFC8412] to the IETF NEA EPCP 617 implementation. 619 4.5.1. Endpoint Pre-Provisioning 621 This section defines the requirements associated with implementing 622 SWIMA. 624 The following requirements assume that the platform or OS vendor 625 supports the use of SWID tags and has identified a standard directory 626 location for the SWID tags to be located as specified by [SWID]. 628 4.5.2. SWID Tags 630 The primary content for the EPCP is the information conveyed in the 631 elements of a SWID tag. 633 The endpoint MUST have SWID tags stored in a directory specified in 634 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 635 also be generated by: 637 o the software installer; or 639 o third-party software that creates tags based on the applications 640 it sees installed on the endpoint. 642 The elements in the SWID tag MUST be populated as specified in 643 [SWID]. These tags, and the directory in which they are stored, MUST 644 be updated as software is added, removed, or updated. 646 4.5.3. SWID Posture Collectors and Posture Validators 647 4.5.3.1. The SWID Posture Collector 649 For the EPCP, the SWID posture collector MUST be conformant with 650 [RFC8412], which includes requirements for: 652 1. Collecting SWID tags from the SWID directory 654 2. Monitoring the SWID directory for changes 656 3. Initiating a session with the posture manager to report changes 657 to the directory 659 4. Maintaining a list of changes to the SWID directory when updates 660 take place and no PT-TLS connection can be created with the 661 posture manager 663 5. Responding to a request for SWID tags from the SWID Posture 664 Validator on the posture manager 666 6. Responding to a query from the SWID posture validator as to 667 whether all updates have been sent 669 The SWID posture collector is not responsible for detecting that the 670 SWID directory was not updated when an application was either 671 installed or uninstalled. 673 4.5.3.2. The SWID Posture Validator 675 Conformance to [RFC8412] enables the SWID posture validator to: 677 1. Send messages to the SWID posture collector (at the behest of the 678 administrator at the posture manager console) requesting updates 679 for SWID tags located on endpoint 681 2. Ask the SWID posture collector whether all updates to the SWID 682 directory located at the posture manager have been sent 684 3. Perform any validation and processing on the collected SWID 685 posture information prior to storage 687 In addition to these requirements, a SWID posture validator used in 688 conformance with this profile MUST be capable of passing this SWID 689 posture information as well as the associated endpoint identity to 690 the repository for storage. 692 4.5.4. Repository 694 The administrative interface SHOULD enable an administrator to: 696 1. Query which endpoints have reported SWID tags for a particular 697 application 699 2. Query which SWID tags are installed on an endpoint 701 3. Query tags based on characteristics, such as vendor, publisher, 702 etc. 704 5. IETF NETCONF EPCP Implementation for Network Device Endpoints 706 When EPCP is used, a NETCONF client that implements the posture 707 collection manager sends a query to target network device endpoint 708 requesting posture information over a secure channel. Once the 709 NETCONF server on the endpoint receives the request, it queries one 710 or more datastores for the posture information. The NETCONF server 711 then reports the information back to the NETCONF client where it can 712 be stored in a repository for use by other tools. This is shown in 713 Figure 3. 715 Posture Posture 716 Collection Collection 717 Manager Engine 718 +---------------+ +---------------+ 719 | | | | 720 | | | +-----------+ | 721 | | | | Data | | 722 | | | | Store(s) | | 723 | | | +-----------+ | 724 | | | | | 725 | | | | | 726 | +-----------+ | | +-----------+ | 727 | | NETCONF | | | | NETCONF | | 728 | | Client | |<------->| | Server | | 729 | +-----------+ | NETCONF | +-----------+ | 730 | | | | 731 +---------------+ +---------------+ 733 Figure 3: NETCONF Components 735 These requirements are written with a view to performing a posture 736 assessment on network device endpoints (routers, switches, etc.); as 737 the EPCP grows and evolves, these requirements will be expanded to 738 address issues that arise. 740 Note that these requirements refer to defined components of the 741 NETCONF architecture and map back to EPCP. As with the NETCONF 742 architecture, vendors have discretion as to how these NETCONF 743 components map to separate pieces of software or endpoints. 745 5.1. Endpoint Provisioning 747 For the posture manager to be able to query the datastores on the 748 endpoint, the endpoint MUST be configured to grant the posture 749 manager access to its datastores as described in [RFC6241]. The 750 posture manager is identified by its NETCONF username. The endpoint 751 is deployed on the network. 753 5.2. Posture Manager Provisioning 755 For the posture manager to be able to query the datastores on the 756 endpoint, the posture manager MUST be provisioned with a NETCONF 757 username that will be used to authenticate the posture manager to the 758 endpoint as described in [RFC6241]. The username generated will be 759 determined by the selected transport protocol. The posture manager 760 is deployed on the network. 762 5.3. Endpoint 764 An endpoint MUST conform to the requirements outlined for servers in 765 the NETCONF protocol as defined in [RFC6241]. This requires the 766 implementation of NETCONF over SSH [RFC6242]. An endpoint MAY 767 support the NETCONF protocol over other transports such as TLS 768 [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040]. 770 5.3.1. Datastore 772 A NETCONF datastore on an endpoint MUST support the operations 773 outlined in [RFC6241], but, the actual implementation of the 774 datastore is left to the endpoint vendor. 776 Datastores MUST support the YANG data modeling language [RFC7950] for 777 expressing endpoint posture information in a structured format. In 778 addition, datastores MAY support other data models such as XML (via 779 YIN) for representing posture information. 781 Datastores MUST support the compliance posture information specified 782 in [RFC7317]. Datastores MAY support other models standardized or 783 proprietary as deemed appropriate by the endpoint vendor. 785 5.4. Posture Manager 787 A posture manager MUST conform to the requirements specified for 788 clients in the NETCONF protocol as defined in [RFC6241]. This 789 requires the implementation of NETCONF over SSH [RFC6242]. A posture 790 manager MAY also support the NETCONF protocol over other transports 791 such as TLS [RFC7589]. In addition, a posture manager MAY support 792 the RESTCONF protocol as defined in [RFC8040]. 794 While ad-hoc fetch/polling via NETCONF and RESTCONF is useful for 795 assessing endpoint compliance, such solutions by themselves are not 796 able to detect changes as they occur on the endpoint. As a result, a 797 future revision of this document will support 798 [I-D.ietf-netconf-yang-push] to receive updates on YANG-modeled 799 posture information. Similarly, because not all posture information 800 is modeled in YANG, a future revision of this document will reference 801 [I-D.ietf-netconf-subscribed-notifications] once it is a standard to 802 support continuous streams of unstructured data from the endpoint to 803 the posture manager. 805 5.5. Repository 807 EPCP requires a simple administrative interface for the repository. 808 The posture collection manager on the posture manager receives the 809 target endpoint posture information via NETCONF [RFC6241] messages 810 sent from posture collection engine on the target endpoint. The 811 posture collection manager stores this information in the repository 812 linked to the identity of the target endpoint from which it was 813 collected. 815 6. Future Work 817 This section captures ideas for future work related to EPCP that 818 might be of interest to the IETF SACM WG. These ideas are listed in 819 no particular order. 821 o Integrate the IETF NETCONF Yang Push architecture. 823 o Add support endpoint types beyond workstations, servers, and 824 network infrastructure devices. 826 o Examine the integration of [I-D.ietf-mile-xmpp-grid]. 828 o Define a standard interface and API for interacting with the 829 repository. Requirements to consider include: creating a secure 830 channel between a publisher and the repository, creating a secure 831 channel between a subscriber and the repository, and the types of 832 interactions that must be supported between publishers and 833 subscribers to a repository. 835 o Define a standard interface for communications between the posture 836 broker client and posture transport client(s) as well as the 837 posture broker server and posture transport server(s). 839 o Retention of posture information on the target endpoint. 841 o Define an orchestrator component as well as publish/subscribe 842 interface for it. 844 o Define an evaluator component as well as an interface for it. 846 7. Acknowledgements 848 The authors wish to thank all of those in the TCG TNC work group who 849 contributed to development of the TNC ECP specification upon which 850 this document is based. 852 +-----------------------+-------------------------------------------+ 853 | Member | Organization | 854 +-----------------------+-------------------------------------------+ 855 | Padma Krishnaswamy | Battelle Memorial Institute | 856 | | | 857 | Eric Fleischman | Boeing | 858 | | | 859 | Richard Hill | Boeing | 860 | | | 861 | Steven Venema | Boeing | 862 | | | 863 | Nancy Cam-Winget | Cisco Systems | 864 | | | 865 | Scott Pope | Cisco Systems | 866 | | | 867 | Max Pritikin | Cisco Systems | 868 | | | 869 | Allan Thompson | Cisco Systems | 870 | | | 871 | Nicolai Kuntze | Fraunhofer Institute for Secure | 872 | | Information Technology (SIT) | 873 | | | 874 | Ira McDonald | High North | 875 | | | 876 | Dr. Andreas Steffen | HSR University of Applied Sciences | 877 | | Rapperswil | 878 | | | 879 | Josef von Helden | Hochschule Hannover | 880 | | | 881 | James Tan | Infoblox | 882 | | | 883 | Steve Hanna (TNC-WG | Juniper Networks | 884 | Co-Chair) | | 885 | | | 886 | Cliff Kahn | Juniper Networks | 887 | | | 888 | Lisa Lorenzin | Juniper Networks | 889 | | | 890 | Atul Shah (TNC-WG Co- | Microsoft | 891 | Chair) | | 892 | | | 893 | Jon Baker | MITRE | 894 | | | 895 | Charles Schmidt | MITRE | 896 | | | 897 | Rainer Enders | NCP Engineering | 898 | | | 899 | Dick Wilkins | Phoenix Technologies | 900 | | | 901 | David Waltermire | NIST | 902 | | | 903 | Mike Boyle | U.S. Government | 904 | | | 905 | Emily Doll | U.S. Government | 906 | | | 907 | Jessica Fitzgerald- | U.S. Government | 908 | McKay | | 909 | | | 910 | Mary Lessels | U.S. Government | 911 | | | 912 | Chris Salter | U.S. Government | 913 +-----------------------+-------------------------------------------+ 915 Table 1: Members of the TNC Work Group that Contributed to the 916 Document 918 8. IANA Considerations 920 This document does not define any new IANA registries. However, this 921 document does reference other documents that do define IANA 922 registries. As a result, the IANA Considerations section of the 923 referenced documents should be consulted. 925 9. Security Considerations 927 This Security Considerations section includes an analysis of the 928 attacks that may be mounted against systems that implement the EPCP 929 (Section 9.1) and the countermeasures that may be used to prevent or 930 mitigate these attacks (Section 9.2). Overall, a substantial 931 reduction in cyber risk can be achieved. 933 9.1. Threat Model 935 This section lists the attacks that can be mounted on a NEA 936 implementation of an EPCP environment. The following section 937 (Section 9.2) describes countermeasures. 939 Because the EPCP describes a specific use case for NEA components, 940 many security considerations for these components are addressed in 941 more detail in the technical specifications: [RFC8412], [IF-IMC], 942 [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV]. 944 9.1.1. Endpoint Attacks 946 While the EPCP provides substantial improvements in endpoint 947 security, endpoints can still be compromised. For this reason, all 948 parties must regard data coming from endpoints as potentially 949 unreliable or even malicious. An analogy can be drawn with human 950 testimony in an investigation or trial. Human testimony is essential 951 but must be regarded with suspicion. 953 o Compromise of endpoint: A compromised endpoint may report false 954 information to confuse or even provide maliciously crafted 955 information with a goal of infecting others. 957 o Putting bad information in SWID directory: Even if an endpoint is 958 not completely compromised, some of the software running on it may 959 be unreliable or even malicious. This software, potentially 960 including the SWID generation or discovery tool, or malicious 961 software pretending to be a SWID generation or discovery tool, can 962 place incorrect or maliciously crafted information into the SWID 963 directory. Endpoint users may even place such information in the 964 directory, whether motivated by curiosity or confusion or a desire 965 to bypass restrictions on their use of the endpoint. 967 o Identity spoofing (impersonation): A compromised endpoint may 968 attempt to impersonate another endpoint to gain its privileges or 969 to besmirch the reputation of that other endpoint. 971 9.1.2. Network Attacks 973 A variety of attacks can be mounted using the network. Generally, 974 the network cannot be trusted. 976 o Eavesdropping, modification, injection, replay, deletion 978 o Traffic analysis 980 o Denial of service and blocking traffic 982 9.1.3. Posture Manager Attacks 984 The posture manager is a critical security element and therefore 985 merits considerable scrutiny. 987 o Compromised trusted manager: A compromised posture manager or a 988 malicious party that is able to impersonate a posture manager can 989 incorrectly grant or deny access to endpoints, place incorrect 990 information into the repository, or send malicious messages to 991 endpoints. 993 o Misconfiguration of posture manager: Accidental or purposeful 994 misconfiguration of a trusted posture manager can cause effects 995 that are similar to those listed for compromised trusted posture 996 manager. 998 o Malicious untrusted posture manager: An untrusted posture manager 999 cannot mount any significant attacks because all properly 1000 implemented endpoints will refuse to engage in any meaningful 1001 dialog with such a posture manager. 1003 9.1.4. Repository Attacks 1005 The repository is also an important security element and therefore 1006 merits careful scrutiny. 1008 o Putting bad information into trusted repository: An authorized 1009 repository client such as a server may be able to put incorrect 1010 information into a trusted repository or delete or modify 1011 historical information, causing incorrect decisions about endpoint 1012 security. Placing maliciously crafted data in the repository 1013 could even lead to compromise of repository clients, if they fail 1014 to carefully check such data. 1016 o Compromised trusted repository: A compromised trusted repository 1017 or a malicious untrusted repository that is able to impersonate a 1018 trusted repository can lead to effects similar to those listed for 1019 "Putting bad information into trusted repository". Further, a 1020 compromised trusted repository can report different results to 1021 different repository clients or deny access to the repository for 1022 selected repository clients. 1024 o Misconfiguration of trusted repository: Accidental or purposeful 1025 misconfiguration of a trusted repository can deny access to the 1026 repository or result in loss of historical data. 1028 o Malicious untrusted repository: An untrusted repository cannot 1029 mount any significant attacks because all properly implemented 1030 repository clients will refuse to engage in any meaningful dialog 1031 with such a repository. 1033 9.2. Countermeasures 1035 This section lists the countermeasures that can be used in a NEA 1036 implementation of an EPCP environment. 1038 9.2.1. Countermeasures for Endpoint Attacks 1040 This profile is in and of itself a countermeasure for a compromised 1041 endpoint. A primary defense for an endpoint is to run up to date 1042 software configured to be run as safely as possible. 1044 Ensuring that anti-virus signatures are up to date and that a 1045 firewall is configured are also protections for an endpoint that are 1046 supported by the current NEA specifications. 1048 Endpoints that have hardware cryptographic modules that are 1049 provisioned by the enterprise, in accordance with [IEEE-802-1ar], can 1050 protect the private keys used for authentication and help prevent 1051 adversaries from stealing credentials that can be used for 1052 impersonation. Future versions of the EPCP may want to discuss in 1053 greater detail how to use a hardware cryptographic module, in 1054 accordance with [IEEE-802-1ar], to protect credentials and to protect 1055 the integrity of the code that executes during the bootstrap process. 1057 9.2.2. Countermeasures for Network Attacks 1059 To address network attacks, [RFC6876] includes required encryption, 1060 authentication, integrity protection, and replay protection. 1061 [Server-Discovery] also includes authorization checks to ensure that 1062 only authorized servers are trusted by endpoints. Any unspecified or 1063 not yet specified network protocols employed in the EPCP (e.g. the 1064 protocol used to interface with the repository) should include 1065 similar protections. 1067 These protections reduce the scope of the network threat to traffic 1068 analysis and denial of service. Countermeasures for traffic analysis 1069 (e.g. masking) are usually impractical but may be employed. 1070 Countermeasures for denial of service (e.g. detecting and blocking 1071 particular sources) SHOULD be used when appropriate to detect and 1072 block denial of service attacks. These are routine practices in 1073 network security. 1075 9.2.3. Countermeasures for Posture Manager Attacks 1077 Because of the serious consequences of posture manager compromise, 1078 posture managers SHOULD be especially well hardened against attack 1079 and minimized to reduce their attack surface. They SHOULD be 1080 monitored using the NEA protocols to ensure the integrity of the 1081 behavior and analysis data stored on the posture manager and SHOULD 1082 utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for 1083 identity and/or integrity measurements of the posture manager. They 1084 should be well managed to minimize vulnerabilities in the underlying 1085 platform and in systems upon which the posture manager depends. 1086 Network security measures such as firewalls or intrusion detection 1087 systems may be used to monitor and limit traffic to and from the 1088 posture manager. Personnel with administrative access to the posture 1089 manager should be carefully screened and monitored to detect problems 1090 as soon as possible. Posture manager administrators should not use 1091 password-based authentication but should instead use non-reusable 1092 credentials and multi-factor authentication (where available). 1093 Physical security measures should be employed to prevent physical 1094 attacks on posture managers. 1096 To ease detection of posture manager compromise, should it occur, 1097 posture manager behavior should be monitored to detect unusual 1098 behavior (such as a server reboot, unusual traffic patterns, or other 1099 odd behavior). Endpoints should log and/or notify users and/or 1100 administrators when peculiar posture manager behavior is detected. 1101 To aid forensic investigation, permanent read-only audit logs of 1102 security-relevant information pertaining to posture manager 1103 (especially administrative actions) should be maintained. If posture 1104 manager compromise is detected, the posture manager's certificate 1105 should be revoked and careful analysis should be performed of the 1106 source and impact of this compromise. Any reusable credentials that 1107 may have been compromised should be reissued. 1109 Endpoints can reduce the threat of server compromise by minimizing 1110 the number of trusted posture managers, using the mechanisms 1111 described in [Server-Discovery]. 1113 9.2.4. Countermeasures for Repository Attacks 1115 If the host for the repository is located on its own endpoint, it 1116 should be protected with the same measures taken to protect the 1117 posture manager. In this circumstance, all messages between the 1118 posture manager and repository should be protected with a mature 1119 security protocol such as TLS or IPsec. 1121 The repository can aid in the detection of compromised endpoints if 1122 an adversary cannot tamper with its contents. For instance, if an 1123 endpoint reports that it does not have an application with a known 1124 vulnerability installed, an administrator can check whether the 1125 endpoint might be lying by querying the repository for the history of 1126 what applications were installed on the endpoint. 1128 To help prevent tampering with the information in the repository: 1130 1. Only authorized parties should have privilege to run code on the 1131 endpoint and to change the repository. 1133 2. If a separate endpoint hosts the repository, then the 1134 functionality of that endpoint should be limited to hosting the 1135 repository. The firewall on the repository should only allow 1136 access to the posture manager and to any endpoint authorized for 1137 administration. 1139 3. The repository should ideally use "write once" media to archive 1140 the history of what was placed in the repository, to include a 1141 snapshot of the current status of applications on endpoints. 1143 10. Privacy Considerations 1145 The EPCP specifically addresses the collection of posture data from 1146 enterprise endpoints by an enterprise network. As such, privacy is 1147 not going to often arise as a concern for those deploying this 1148 solution. 1150 A possible exception may be the concerns a user may have when 1151 attempting to connect a personal endpoint (such as a phone or mobile 1152 endpoint) to an enterprise network. The user may not want to share 1153 certain details, such as an endpoint identifier or SWID tags, with 1154 the enterprise. The user can configure their NEA client to reject 1155 requests for this information; however, it is possible that the 1156 enterprise policy will not allow the user's endpoint to connect to 1157 the network without providing the requested data. 1159 11. References 1161 11.1. Informative References 1163 [CIS] http://www.cisecurity.org/controls/, "CIS Critical 1164 Security Controls". 1166 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1167 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1168 Protect Your ICT System", November 2012. 1170 [ECP] Trusted Computing Group, "TCG Trusted Network Connect 1171 Endpoint Compliance Profile, Version 1.10", December 2014. 1173 [IEEE-802-1ar] 1174 Institute of Electrical and Electronics Engineers, "IEEE 1175 802.1ar", December 2009. 1177 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1178 Tardo, "Network Endpoint Assessment (NEA): Overview and 1179 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1180 . 1182 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1183 Architecture for Interoperability, Version 1.5", February 1184 2012. 1186 11.2. Normative References 1188 [I-D.ietf-mile-xmpp-grid] 1189 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 1190 "Using XMPP for Security Information Exchange", draft- 1191 ietf-mile-xmpp-grid-04 (work in progress), October 2017. 1193 [I-D.ietf-netconf-subscribed-notifications] 1194 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1195 A. Tripathy, "Customized Subscriptions to a Publisher's 1196 Event Streams", draft-ietf-netconf-subscribed- 1197 notifications-13 (work in progress), June 2018. 1199 [I-D.ietf-netconf-yang-push] 1200 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1201 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1202 Subscription", draft-ietf-netconf-yang-push-12 (work in 1203 progress), December 2017. 1205 [I-D.ietf-sacm-terminology] 1206 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1207 Winget, "Terminology for Security Assessment", draft-ietf- 1208 sacm-terminology-05 (work in progress), August 2014. 1210 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1211 IF-IMC, Version 1.3", February 2013. 1213 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1214 IF-IMV, Version 1.4", December 2014. 1216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1217 Requirement Levels", BCP 14, RFC 2119, 1218 DOI 10.17487/RFC2119, March 1997, 1219 . 1221 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1222 (PA) Protocol Compatible with Trusted Network Connect 1223 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1224 . 1226 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1227 A Posture Broker (PB) Protocol Compatible with Trusted 1228 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1229 March 2010, . 1231 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1232 and A. Bierman, Ed., "Network Configuration Protocol 1233 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1234 . 1236 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1237 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1238 . 1240 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1241 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1242 DOI 10.17487/RFC6876, February 2013, 1243 . 1245 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1246 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1247 2014, . 1249 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1250 NETCONF Protocol over Transport Layer Security (TLS) with 1251 Mutual X.509 Authentication", RFC 7589, 1252 DOI 10.17487/RFC7589, June 2015, 1253 . 1255 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1256 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1257 . 1259 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1260 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1261 . 1263 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1264 J. Fitzgerald-McKay, "Software Inventory Message and 1265 Attributes (SWIMA) for PA-TNC", RFC 8412, 1266 DOI 10.17487/RFC8412, July 2018, 1267 . 1269 [Server-Discovery] 1270 Trusted Computing Group, "DRAFT: TCG Trusted Network 1271 Connect PDP Discovery and Validation, Version 1.0", 1272 October 2015. 1274 [SWID] "Information technology--Software asset management--Part 1275 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1277 Appendix A. Rationale for an EPCP Solution 1279 A.1. Preventative Posture Assessments 1281 The value of continuous endpoint posture assessment is well 1282 established. Security experts have identified asset management and 1283 vulnerability remediation as a critical step for preventing 1284 intrusions. Application whitelisting, patching applications and 1285 operating systems, and using the latest versions of applications top 1286 the Defense Signals Directorate's "Top 4 Mitigations to Protect Your 1287 ICT System". [DSD] "Inventory of Authorized and Unauthorized 1288 Endpoints", "Inventory of Authorized and Unauthorized Software", and 1289 "Continuous Vulnerability Assessment and Remediation" are Controls 1, 1290 2, and 3, respectively, of the CIS Controls [CIS]. While there are 1291 commercially available solutions that attempt to address these 1292 security controls, these solutions do not run on all types of 1293 endpoints; consistently interoperate with other tools that could make 1294 use of the data collected; collect posture information from all types 1295 of endpoints in a consistent, standardized schema; or require vetted, 1296 standardized protocols that have been evaluated by the international 1297 community for cryptographic soundness. 1299 As is true of most solutions offered today, the solution found in the 1300 EPCP does not attempt to solve the lying endpoint problem, or detect 1301 infected endpoints; rather, it focuses on ensuring that healthy 1302 endpoints remain healthy by keeping software up-to-date and patched. 1304 A.2. All Network-Connected Endpoints are Endpoints 1306 As defined by [I-D.ietf-sacm-terminology], an endpoint is any 1307 physical or virtual computing endpoint that can be connected to a 1308 network. Posture assessment against policy is equally, if not more, 1309 important for continuously connected endpoints, such as enterprise 1310 workstations and infrastructure endpoints, as it is for sporadically 1311 connected endpoints. Continuously connected endpoints are just as 1312 likely to fall out of compliance with policy, and a standardized 1313 posture assessment method is necessary to ensure they can be properly 1314 handled. 1316 A.3. All Endpoints on the Network Must be Uniquely Identified 1318 Many administrators struggle to identify what endpoints are connected 1319 to the network at any given time. By requiring a standardized method 1320 of endpoint identity, the EPCP will enable administrators to answer 1321 the basic question, "What is on my network?" In 1322 [I-D.ietf-sacm-terminology], SACM defines this set of endpoints on 1323 the network as the SACM domain. Unique endpoint identification also 1324 enables the comparison of current and past endpoint posture 1325 assessments, by allowing administrators to correlate assessments from 1326 the same endpoint. This makes it easier to flag suspicious changes 1327 in endpoint posture for manual or automatic review, and helps to 1328 swiftly identify malicious changes to endpoint applications. 1330 A.4. Standardized Data Models 1332 Meeting EPCP best practices requires the use of standardized data 1333 models for the exchange of posture information. This helps to ensure 1334 that the posture information sent from endpoints to the repository 1335 can be easily stored, due to their known format, and shared with 1336 authorized endpoints and users. 1338 Posture information must be sent over standardized protocols to 1339 ensure the confidentiality and authenticity of this data while in 1340 transit. Implementations of the EPCP include [RFC6876] and [RFC6241] 1341 for communication between the target endpoint and the posture 1342 manager. These protocols allow networks that implement this solution 1343 to collect large amounts of posture information from an endpoint to 1344 make decisions about that endpoint's compliance with some policy. 1345 The EPCP offers a solution for all endpoints already connected to the 1346 network. Periodic assessments and automated reporting of changes to 1347 endpoint posture allow for instantaneous identification of connected 1348 endpoints that are no longer compliant to some policy. 1350 A.5. Posture Information Must Be Stored 1352 Posture information must be stored by the repository and must be 1353 exposed to an interface at the posture manager. Standard data models 1354 enable standard queries from an interface exposed to an administrator 1355 at the posture manager console. A repository must retain any current 1356 posture information retrieved from the target endpoint and store it 1357 indexed by the unique identifier for the endpoint. Any posture 1358 collection manager specified by this profile must be able to 1359 ascertain from its corresponding posture collection engine whether 1360 the posture information is up to date. An interface on the posture 1361 manager must support a request to obtain up-to-date information when 1362 an endpoint is connected. This interface must also support the 1363 ability to make a standard set of queries about the posture 1364 information stored by the repository. In the future, some forms of 1365 posture information might be retained at the endpoint. The interface 1366 on the posture manager must accommodate the ability to make a request 1367 to the corresponding posture collection engine about the posture of 1368 the target endpoint. Standard data models and protocols also enable 1369 the security of posture assessment results. By storing these results 1370 indexed under the endpoint's unique identification, secure storage 1371 itself enables endpoint posture information correlation, and ensures 1372 that the enterprise's repositories always offer the freshest, most 1373 up-to-date view of the enterprise's endpoint posture information 1374 possible. 1376 A.6. Posture Information Can Be Shared 1378 By exposing posture information using a standard interface and API, 1379 other security and operational components have a high level of 1380 insight into the enterprise's endpoints and the software installed on 1381 them. This will support innovation in the areas of asset management, 1382 vulnerability scanning, and administrative interfaces, as any 1383 authorized infrastructure endpoint can interact with the posture 1384 information. 1386 A.7. Enterprise Asset Posture Information Belongs to the Enterprise 1388 Owners and administrators must have complete control of posture 1389 information, policy, and endpoint mitigation. Standardized data 1390 models, protocols and interfaces help to ensure that this posture 1391 information is not locked in proprietary databases, but is made 1392 available to its owners. This enables administrators to develop as 1393 nuanced a policy as necessary to keep their networks secure. Of 1394 course, there may be exceptions to this such as the case with 1395 privacy-related information (e.g., personally identifiable 1396 information). 1398 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 1400 B.1. Supported Use Cases 1402 The following sections describe the different use cases supported by 1403 the EPCP. 1405 B.1.1. Hardware Asset Management 1407 Using the administrative interface on the posture manager, an 1408 authorized user can learn: 1410 o what endpoints are connected to the network at any given time; and 1412 o what SWID tags were reported for the endpoints. 1414 The ability to answer these questions offers a standards-based 1415 approach to asset management, which is a vital part of enterprise 1416 processes such as compliance report generation for the Federal 1417 Information Security Modernization Act (FISMA), Payment Card Industry 1418 Data Security Standard (PCI DSS), Health Insurance Portability and 1419 Accountability Act (HIPAA), etc. 1421 B.1.2. Software Asset Management 1423 The administrative interface on the posture manager provides the 1424 ability for authorized users and infrastructure to know which 1425 software is installed on which endpoints on the enterprise's network. 1426 This allows the enterprise to answer questions about what software is 1427 installed to determine if it is licensed or prohibited. This 1428 information can also drive other use cases such as: 1430 o vulnerability management: knowing what software is installed 1431 supports the ability to determine which endpoints contain 1432 vulnerable software and need to be patched. 1434 o configuration management: knowing which security controls need to 1435 be applied to harden installed software and better protect 1436 endpoints. 1438 B.1.3. Vulnerability Management 1440 The administrative interface also provides the ability for authorized 1441 users or infrastructure to locate endpoints running software for 1442 which vulnerabilities have been announced. Because of 1444 1. the unique IDs assigned to each endpoint; and 1446 2. the rich application data provided in the endpoints' posture 1447 information, 1449 the repository can be queried to find all endpoints running a 1450 vulnerable application. Endpoints suspected of being vulnerable can 1451 be addressed by the administrator or flagged for further scrutiny. 1453 B.1.4. Threat Detection and Analysis 1455 The repository's standardized API allows authorized infrastructure 1456 endpoints and software to search endpoint posture assessment 1457 information for evidence that an endpoint's software inventory has 1458 changed, and can make endpoint software inventory data available to 1459 other endpoints. This automates security data sharing in a way that 1460 expedites the correlation of relevant network data, allowing 1461 administrators and infrastructure endpoints to identify odd endpoint 1462 behavior and configuration using secure, standards-based data models 1463 and protocols. 1465 B.2. Non-Supported Use Cases 1467 Several use cases, including but not limited to these, are not 1468 covered by the EPCP: 1470 o Gathering non-standardized types of posture information: The EPCP 1471 does not prevent administrators from collecting posture 1472 information in proprietary formats from the endpoint; however it 1473 does not set requirements for doing so. 1475 o Solving the lying endpoint problem: The EPCP does not address the 1476 lying endpoint problem; the Profile makes no assertions that it 1477 can catch an endpoint that is, either maliciously or accidentally, 1478 reporting false posture information to the posture manager. 1479 However, other solutions may be able to use the posture 1480 information collected using the capabilities described in this 1481 profile to catch an endpoint in a lie. For example, a sensor may 1482 be able to compare the posture information it has collected on an 1483 endpoint's activity on the network to what the endpoint reported 1484 to the server and flag discrepancies. However, these capabilities 1485 are not described in this profile. 1487 Appendix C. Endpoint Posture Collection Profile Examples 1489 The following subsections provide examples of the EPCP as implemented 1490 using components from the NEA architecture. 1492 C.1. Continuous Posture Assessment of an Endpoint 1494 Endpoint Posture Manager 1495 +---------------+ +---------------+ 1496 | | | | 1497 | +-----------+ | | +-----------+ | 1498 | | SWID | | | | SWID | | 1499 | | Posture | | | | Posture | | 1500 | | Collector | | | | Validator | | 1501 | +-----------+ | | +-----------+ | 1502 | | | | | | 1503 | | IF-IMC | | | IF-IMV | 1504 | | | | | | 1505 | +-----------+ | | +-----------+ | 1506 | | PB Client | | | | PB Server | | 1507 | +-----------+ | | +-----------+ | 1508 | | | | | | 1509 | | | | | | 1510 | | | | | | 1511 | +-----------+ | | +-----------+ | 1512 | | PT Client | |<------>| | PT Server | | 1513 | +-----------+ | PT-TLS | +-----------+ | 1514 | | | | 1515 +---------------+ +---------------+ 1517 Figure 4: Continuous Posture Assessment of an Endpoint 1519 C.1.1. Change on Endpoint Triggers Posture Assessment 1521 A new application is installed on the endpoint, and the SWID 1522 directory is updated. This triggers an update from the SWID posture 1523 collector to the SWID posture validator. The message is sent down 1524 the NEA stack, encapsulated by NEA protocols until it is sent by the 1525 posture transport client to the posture transport server. The 1526 posture transport server then forwards it up through the stack, where 1527 the layers of encapsulation are removed until the SWID Message 1528 arrives at the SWID posture validator. 1530 Endpoint Posture Manager 1531 +---------------+ +---------------+ 1532 | | | | 1533 | +-----------+ | | +-----------+ | 1534 | | SWID | | | | SWID | | 1535 | | Posture | | | | Posture | | 1536 | | Collector | | | | Validator | | 1537 | +-----------+ | | +-----------+ | 1538 | | | SWID Message | | | 1539 | | IF-IMC | for PA-TNC | | IF-IMV | 1540 | | | | | | 1541 | +-----------+ | | +-----------+ | 1542 | | PB Client | | | | PB Server | | 1543 | +-----------+ | | +-----------+ | 1544 | | | | | | 1545 | | | PB-TNC {SWID | | | 1546 | | | Message for | | | 1547 | | | PA-TNC} | | | 1548 | +-----------+ | | +-----------+ | 1549 | | PT Client | |<-------------->| | PT Server | | 1550 | +-----------+ | PT-TLS {PB-TNC | +-----------+ | 1551 | | {SWID Message | | 1552 +---------------+ for PA-TNC}} +---------------+ 1554 Figure 5: Compliance Protocol Encapsulation 1556 The SWID posture validator stores the new tag information in the 1557 repository. If the tag indicates that the endpoint is compliant to 1558 the policy, then the process is complete until the next time an 1559 update is needed (either because policy states that the endpoint must 1560 submit posture assessment results periodically or because an 1561 install/uninstall/update on the endpoint triggers a posture 1562 assessment). 1564 Endpoint Posture Manager 1565 +---------------+ +---------------+ 1566 | | | | 1567 | +-----------+ | | +-----------+ | 1568 | | SWID | | | | SWID |-|-+ 1569 | | Posture | | | | Posture | | | 1570 | | Collector | | | | Validator | | | 1571 | +-----------+ | | +-----------+ | | 1572 | | | | | | | Repository 1573 | | IF-IMC | | | IF-IMV | | +--------+ 1574 | | | | | | | | | 1575 | +-----------+ | | +-----------+ | | | | 1576 | | PB Client | | | | PB Server | | +---->| | 1577 | +-----------+ | | +-----------+ | | | 1578 | | | | | | +--------+ 1579 | | | | | | 1580 | | | | | | 1581 | +-----------+ | | +-----------+ | 1582 | | PT Client | |<------>| | PT Server | | 1583 | +-----------+ | PT-TLS | +-----------+ | 1584 | | | | 1585 +---------------+ +---------------+ 1587 Figure 6: Storing SWIDs in the Repository 1589 If the endpoint has fallen out of compliance with a policy, the 1590 posture manager can alert the administrator via the posture manager's 1591 administrative interface. The administrator can then take steps to 1592 address the problem. If the administrator has already established a 1593 policy for automatically addressing this problem, that policy will be 1594 followed. 1596 (") 1597 __|__ 1598 +-->| 1599 Endpoint Posture Manager | / \ 1600 +---------------+ +---------------+ | 1601 | | | | | 1602 | +-----------+ | | +-----------+ | | 1603 | | SWID | | | | SWID |-|-+ 1604 | | Posture | | | | Posture | | 1605 | | Collector | | | | Validator | | 1606 | +-----------+ | | +-----------+ | 1607 | | | | | | Repository 1608 | | IF-IMC | | | IF-IMV | +--------+ 1609 | | | | | | | | 1610 | +-----------+ | | +-----------+ | | | 1611 | | PB Client | | | | PB Server | | | | 1612 | +-----------+ | | +-----------+ | | | 1613 | | | | | | +--------+ 1614 | | | | | | 1615 | | | | | | 1616 | +-----------+ | | +-----------+ | 1617 | | PT Client | |<------>| | PT Server | | 1618 | +-----------+ | PT-TLS | +-----------+ | 1619 | | | | 1620 +---------------+ +---------------+ 1622 Figure 7: Server Alerts Network Admin 1624 C.2. Administrator Searches for Vulnerable Endpoints 1626 An announcement is made that a particular version of a piece of 1627 software has a vulnerability. The administrator uses the 1628 administrative interface on the server to search the repository for 1629 endpoints that reported the SWID tag for the vulnerable software. 1631 (") 1632 __|__ 1633 +-->| 1634 Endpoint Posture Manager | / \ 1635 +---------------+ +---------------+ | 1636 | | | | | 1637 | +-----------+ | | +-----------+ | | 1638 | | SWID | | | | SWID |-|-+ 1639 | | Posture | | | | Posture | | 1640 | | Collector | | | | Validator | | 1641 | +-----------+ | | +-----------+ | 1642 | | | | | | Repository 1643 | | IF-IMC | | | IF-IMV | +--------+ 1644 | | | | | | | | 1645 | +-----------+ | | +-----------+ | | | 1646 | | PB Client | | | | PB Server | |------>| | 1647 | +-----------+ | | +-----------+ | | | 1648 | | | | | | +--------+ 1649 | | | | | | 1650 | | | | | | 1651 | +-----------+ | | +-----------+ | 1652 | | PT Client | |<------>| | PT Server | | 1653 | +-----------+ | PT-TLS | +-----------+ | 1654 | | | | 1655 +---------------+ +---------------+ 1657 Figure 8: Admin Searches for Vulnerable Endpoints 1659 The repository returns a list of entries in the matching the 1660 administrator's search. The administrator can then address the 1661 vulnerable endpoints by taking some follow-up action such as removing 1662 it from the network, quarantining it, or updating the vulnerable 1663 software. 1665 Appendix D. Change Log 1667 D.1. -03 to -04 1669 Addressed various comments from the SACM WG. 1671 Refactored the document to better focus it on the communications 1672 between endpoints and the posture manager and the best practices for 1673 EPCP implementations. 1675 Made other editorial changes and improved consistency throughout the 1676 document. 1678 D.2. -02 to -03 1680 Addressed various comments from the SACM WG. 1682 Added a reference to TCG ECP 1.0. 1684 Removed text in the "SWID Posture Validator" section that states it 1685 performs evaluation. This was removed because it contradicts the 1686 posture manager not performing any evaluations. 1688 Expanded the "Provisioning" section of the "EPCP Transactions" 1689 section to include examples of endpoint identifiers and the need to 1690 provision endpoints with components and data models. 1692 Combined text for the capabilities of the Administrative Interface 1693 and API. 1695 Removed superfluous and introductory text from the "Security 1696 Considerations" section. 1698 Renamed section "Vulnerability Searches" to Vulnerability 1699 Management". 1701 Changed I-D category to BCP. 1703 Changed references to the NETMOD architecture to the NETCONF 1704 architecture because NETCONF represents the management protocol 1705 whereas NETMOD is focused on the definition of data models. 1707 Addressed various editorial suggestions. 1709 D.3. -01 to -02 1711 Addressed various comments from the SACM WG. 1713 Added a section for the collection of posture information from 1714 network devices using standards from the NETMOD WG. 1716 Updated EPCP component diagrams so they were not specific to a NEA- 1717 based implementation. 1719 Updated EPCP NEA example diagrams to reflect all the components in 1720 the NEA architecture. 1722 D.4. -00 to -01 1724 There are no textual changes associated with this revision. This 1725 revision simply reflects a resubmission of the document so that it 1726 remains in active status. 1728 D.5. -01 to -02 1730 Added references to the Software Inventory Message and Attributes 1731 (SWIMA) for PA-TNC I-D. 1733 Replaced references to PC-TNC with IF-IMC. 1735 Removed erroneous hyphens from a couple of section titles. 1737 Made a few minor editorial changes. 1739 D.6. -02 to -00 1741 Draft adopted by IETF SACM WG. 1743 D.7. -00 to -01 1745 Significant edits to up-level the draft to describe SACM collection 1746 over multiple different protocols. 1748 Replaced references to SANS with CIS. 1750 Made other minor editorial changes. 1752 Authors' Addresses 1754 Danny Haynes 1755 The MITRE Corporation 1756 202 Burlington Road 1757 Bedford, MA 01730 1758 USA 1760 Email: dhaynes@mitre.org 1762 Jessica Fitzgerald-McKay 1763 Department of Defense 1764 9800 Savage Road 1765 Ft. Meade, Maryland 1766 USA 1768 Email: jmfitz2@nsa.gov 1769 Lisa Lorenzin 1770 Pulse Secure 1771 2700 Zanker Rd., Suite 200 1772 San Jose, CA 95134 1773 US 1775 Email: llorenzin@pulsesecure.net