idnits 2.17.1 draft-ietf-sacm-ecp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 48 instances of too long lines in the document, the longest one being 4 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 (September 7, 2018) is 2051 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) == Unused Reference: 'RFC5209' is defined on line 1653, but no explicit reference was found in the text == Unused Reference: 'RFC7632' is defined on line 1731, but no explicit reference was found in the text == 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' ** Downref: Normative reference to an Informational RFC: RFC 7632 -- Possible downref: Non-RFC (?) normative reference: ref. 'Server-Discovery' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' Summary: 4 errors (**), 0 flaws (~~), 8 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: March 11, 2019 Department of Defense 6 L. Lorenzin 7 Pulse Secure 8 September 7, 2018 10 Endpoint Posture Collection Profile 11 draft-ietf-sacm-ecp-03 13 Abstract 15 This document specifies the Endpoint Posture Collection Profile, 16 which describes the best practices for the application of IETF and 17 TNC protocols and interfaces to support the on-going collection, 18 communication, and assessment of endpoint posture, as well as the 19 controlled exposure of endpoint posture to other tools. This 20 document is an extension of the Trusted Computing Group's Endpoint 21 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 March 11, 2019. 40 Copyright Notice 42 Copyright (c) 2018 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 1.1. Preventative Posture Assessments . . . . . . . . . . . . 4 59 1.2. All Network-Connected Endpoints are Endpoints . . . . . . 5 60 1.3. All Endpoints on the Network Must be Uniquely Identified 5 61 1.4. Standardized Data Models . . . . . . . . . . . . . . . . 5 62 1.5. Posture Information Must Be Stored . . . . . . . . . . . 6 63 1.6. Posture Information Can Be Shared . . . . . . . . . . . . 6 64 1.7. Enterprise Asset Posture Information Belongs to the 65 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 6 66 1.8. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Endpoint Posture Collection Profile . . . . . . . . . . . . . 7 69 3.1. Posture Assessments . . . . . . . . . . . . . . . . . . . 7 70 3.2. Data Storage . . . . . . . . . . . . . . . . . . . . . . 8 71 3.3. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 8 72 4. EPCP Components . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.1. Posture Collection Engine . . . . . . . . . . . . . . 9 75 4.2. Posture Manager . . . . . . . . . . . . . . . . . . . . . 9 76 4.2.1. Posture Collection Manager . . . . . . . . . . . . . 10 77 4.3. Repository . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.5. Orchestrator . . . . . . . . . . . . . . . . . . . . . . 11 80 5. EPCP Transactions . . . . . . . . . . . . . . . . . . . . . . 11 81 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2. Discovery and Validation . . . . . . . . . . . . . . . . 11 83 5.3. Event Driven Collection . . . . . . . . . . . . . . . . . 11 84 5.4. Querying . . . . . . . . . . . . . . . . . . . . . . . . 12 85 5.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . 12 86 5.6. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 12 87 6. EPCP Implementations . . . . . . . . . . . . . . . . . . . . 13 88 6.1. IETF NEA EPCP Implementation for Traditional Endpoints . 13 89 6.1.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 14 90 6.1.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 15 91 6.1.2.1. Posture Collector . . . . . . . . . . . . . . . . 15 92 6.1.2.2. Posture Broker Client . . . . . . . . . . . . . . 16 93 6.1.2.3. Posture Transport Client . . . . . . . . . . . . 16 94 6.1.3. Posture Manager . . . . . . . . . . . . . . . . . . . 16 95 6.1.3.1. Posture Validator . . . . . . . . . . . . . . . . 16 96 6.1.3.2. Posture Broker Server . . . . . . . . . . . . . . 16 97 6.1.3.3. Posture Transport Server . . . . . . . . . . . . 16 98 6.1.4. Repository . . . . . . . . . . . . . . . . . . . . . 16 99 6.1.5. IETF SACM SWAM Extension to the IETF NEA EPCP 100 Implementation . . . . . . . . . . . . . . . . . . . 17 101 6.1.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . 17 102 6.1.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . 17 103 6.1.5.3. SWID Posture Collectors and Posture Validators . 17 104 6.1.5.4. Repository . . . . . . . . . . . . . . . . . . . 18 105 6.2. IETF NETCONF EPCP Implementation for Network Device 106 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 19 107 6.2.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 19 108 6.2.2. Posture Manager Pre-Provisioning . . . . . . . . . . 20 109 6.2.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 20 110 6.2.3.1. Datastore . . . . . . . . . . . . . . . . . . . . 20 111 6.2.4. Posture Manager . . . . . . . . . . . . . . . . . . . 20 112 6.2.5. Repository . . . . . . . . . . . . . . . . . . . . . 21 113 6.3. Administrative Interface and API . . . . . . . . . . . . 21 114 7. EPCP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 21 115 7.1. Hardware Asset Management . . . . . . . . . . . . . . . . 21 116 7.2. Software Asset Management . . . . . . . . . . . . . . . . 22 117 7.3. Vulnerability Management . . . . . . . . . . . . . . . . 22 118 7.4. Threat Detection and Analysis . . . . . . . . . . . . . . 22 119 8. Non-supported Use Cases . . . . . . . . . . . . . . . . . . . 23 120 9. Endpoint Posture Collection Profile Examples . . . . . . . . 23 121 9.1. Continuous Posture Assessment of an Endpoint . . . . . . 23 122 9.1.1. Change on Endpoint Triggers Posture Assessment . . . 24 123 9.2. Administrator Searches for Vulnerable Endpoints . . . . . 27 124 10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 28 125 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 126 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 127 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 128 13.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 31 129 13.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 31 130 13.1.2. Network Attacks . . . . . . . . . . . . . . . . . . 32 131 13.1.3. Posture Manager Attacks . . . . . . . . . . . . . . 32 132 13.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 32 133 13.2. Countermeasures . . . . . . . . . . . . . . . . . . . . 33 134 13.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 33 135 13.2.2. Countermeasures for Network Attacks . . . . . . . . 33 136 13.2.3. Countermeasures for Posture Manager Attacks . . . . 34 137 13.2.4. Countermeasures for Repository Attacks . . . . . . . 35 138 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 139 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36 140 15.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 36 141 15.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 36 142 15.3. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 37 143 15.4. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 37 144 15.5. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 37 145 15.6. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 37 146 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 147 16.1. Informative References . . . . . . . . . . . . . . . . . 37 148 16.2. Normative References . . . . . . . . . . . . . . . . . . 38 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 151 1. Introduction 153 The Endpoint Posture Collection Profile (EPCP) builds on prior work 154 from the IETF NEA WG, the IETF NETCONF WG, and the Trusted Computing 155 Group [TNC] Trusted Network Communications (TNC) WG to describe the 156 best practices for the collection, communication, and sharing of 157 posture information from network-connected endpoints. The first 158 generation of this document focuses on reducing the security exposure 159 of a network by enabling event-driven posture collection, 160 standardized querying of additional endpoint data as needed, and the 161 communication of that data to a posture manager. 163 Future revisions of this document may include support for the 164 collection of endpoint posture from other endpoint types and a 165 standardized interface for repositories among other capabilities. 166 Additional information about this future work can be found in 167 Section 10 of this document. 169 1.1. Preventative Posture Assessments 171 The value of continuous endpoint posture assessment is well 172 established. Security experts have identified asset management and 173 vulnerability remediation as a critical step for preventing 174 intrusions. Application whitelisting, patching applications and 175 operating systems, and using the latest versions of applications top 176 the Defense Signals Directorate's "Top 4 Mitigations to Protect Your 177 ICT System". [DSD] "Inventory of Authorized and Unauthorized 178 Endpoints", "Inventory of Authorized and Unauthorized Software", and 179 "Continuous Vulnerability Assessment and Remediation" are Controls 1, 180 2, and 3, respectively, of the CIS Controls [CIS]. While there are 181 commercially available solutions that attempt to address these 182 security controls, these solutions do not run on all types of 183 endpoints; consistently interoperate with other tools that could make 184 use of the data collected; collect posture information from all types 185 of endpoints in a consistent, standardized schema; or require vetted, 186 standardized protocols that have been evaluated by the international 187 community for cryptographic soundness. 189 As is true of most solutions offered today, the solution found in the 190 EPCP does not attempt to solve the lying endpoint problem, or detect 191 infected endpoints; rather, it focuses on ensuring that healthy 192 endpoints remain healthy by keeping software up-to-date and patched. 194 1.2. All Network-Connected Endpoints are Endpoints 196 As defined by [I-D.ietf-sacm-terminology], an endpoint is any 197 physical or virtual computing endpoint that can be connected to a 198 network. Posture assessment against policy is equally, if not more, 199 important for continuously connected endpoints, such as enterprise 200 workstations and infrastructure endpoints, as it is for sporadically 201 connected endpoints. Continuously connected endpoints are just as 202 likely to fall out of compliance with policy, and a standardized 203 posture assessment method is necessary to ensure they can be properly 204 handled. 206 1.3. All Endpoints on the Network Must be Uniquely Identified 208 Many administrators struggle to identify what endpoints are connected 209 to the network at any given time. By requiring a standardized method 210 of endpoint identity, the EPCP will enable administrators to answer 211 the basic question, "What is on my network?" In 212 [I-D.ietf-sacm-terminology], SACM defines this set of endpoints on 213 the network as the SACM domain. Unique endpoint identification also 214 enables the comparison of current and past endpoint posture 215 assessments, by allowing administrators to correlate assessments from 216 the same endpoint. This makes it easier to flag suspicious changes 217 in endpoint posture for manual or automatic review, and helps to 218 swiftly identify malicious changes to endpoint applications. 220 1.4. Standardized Data Models 222 Meeting EPCP best practices requires the use of standardized data 223 models for the exchange of posture information. This helps to ensure 224 that the posture information sent from endpoints to the repository 225 can be easily stored, due to their known format, and shared with 226 authorized endpoints and users. 228 Posture information must be sent over standardized protocols to 229 ensure the confidentiality and authenticity of this data while in 230 transit. Implementations of the EPCP include [RFC6876] and [RFC6241] 231 for communication between the target endpoint and the posture 232 manager. These protocols allow networks that implement this solution 233 to collect large amounts of posture information from an endpoint to 234 make decisions about that endpoint's compliance with some policy. 235 The EPCP offers a solution for all endpoints already connected to the 236 network. Periodic assessments and automated reporting of changes to 237 endpoint posture allow for instantaneous identification of connected 238 endpoints that are no longer compliant to some policy. 240 1.5. Posture Information Must Be Stored 242 Posture information must be stored by the repository and must be 243 exposed to an interface at the posture manager. Standard data models 244 enable standard queries from an interface exposed to an administrator 245 at the posture manager console. A repository must retain any current 246 posture information retrieved from the target endpoint and store it 247 indexed by the unique identifier for the endpoint. Any posture 248 collection manager specified by this profile must be able to 249 ascertain from its corresponding posture collection engine whether 250 the posture information is up to date. An interface on the posture 251 manager must support a request to obtain up-to-date information when 252 an endpoint is connected. This interface must also support the 253 ability to make a standard set of queries about the posture 254 information stored by the repository. In the future, some forms of 255 posture information might be retained at the endpoint. The interface 256 on the posture manager must accommodate the ability to make a request 257 to the corresponding posture collection engine about the posture of 258 the target endpoint. Standard data models and protocols also enable 259 the security of posture assessment results. By storing these results 260 indexed under the endpoint's unique identification, secure storage 261 itself enables endpoint posture information correlation, and ensures 262 that the enterprise's repositories always offer the freshest, most 263 up-to-date view of the enterprise's endpoint posture information 264 possible. 266 1.6. Posture Information Can Be Shared 268 By exposing posture information using a standard interface and API, 269 other security and operational components have a high level of 270 insight into the enterprise's endpoints and the software installed on 271 them. This will support innovation in the areas of asset management, 272 vulnerability scanning, and administrative interfaces, as any 273 authorized infrastructure endpoint can interact with the posture 274 information. 276 1.7. Enterprise Asset Posture Information Belongs to the Enterprise 278 Owners and administrators must have complete control of posture 279 information, policy, and endpoint mitigation. Standardized data 280 models, protocols and interfaces help to ensure that this posture 281 information is not locked in proprietary databases, but is made 282 available to its owners. This enables administrators to develop as 283 nuanced a policy as necessary to keep their networks secure. 285 1.8. Keywords 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 289 document are to be interpreted as described in [RFC2119]. This 290 specification does not distinguish blocks of informative comments and 291 normative requirements. Therefore, for the sake of clarity, note 292 that lower case instances of must, should, etc. do not indicate 293 normative requirements. 295 2. Terminology 297 This document uses terms as defined in [I-D.ietf-sacm-terminology] 298 unless otherwise specified. 300 3. Endpoint Posture Collection Profile 302 The EPCP describes how IETF data models and protocols can be used to 303 support the posture assessment of endpoints on a network. This 304 profile does not generate new data models or protocols; rather, it 305 offers best practices for a full end-to-end solution for posture 306 assessment, as well as a fresh perspective on how existing standards 307 can be leveraged against vulnerabilities. 309 3.1. Posture Assessments 311 The EPCP describes how IETF and TNC data models and protocols make it 312 possible to perform posture assessments against all network-connected 313 endpoints by: 315 1. uniquely identifying the endpoint; 317 2. collecting and evaluating posture based on data from the 318 endpoint; 320 3. creating a secure, authenticated, confidential channel between 321 the endpoint and the posture manager; 323 4. enabling the endpoint to notify the posture manager about changes 324 to its configuration; 326 5. enabling the posture manager to request information about the 327 configuration of the endpoint; and 329 6. storing the posture information in a repository linked to the 330 identifier for the endpoint. 332 3.2. Data Storage 334 The EPCP focuses on being able to collect posture information from an 335 endpoint, store it, and make it available to authorized parties. 336 Currently, the EPCP does not specify a protocol or interfaces to 337 access stored posture information. This needs to be addressed in a 338 future revision. Until then, vendors are free to implement a 339 repository and the protocols and interfaces used to interact with it 340 in a way that makes the most sense for them. 342 3.3. Data Sharing 344 The EPCP aims to facilitate the sharing of posture information 345 between components to enable asset management, software asset 346 management, and configuration management use cases as well as support 347 analytic, access control, remediation, and reporting processes. 348 However, the EPCP does not currently specify a protocol for 349 communicating this information between components to support these 350 use cases and processes. This needs to be addressed in a future 351 revision. 353 4. EPCP Components 355 To perform posture assessment, data storage, and data sharing, EPCP 356 defines several components. Some of these components reside on the 357 target endpoint. Others reside on a posture manager that manages 358 communications with the target endpoint and stores the target 359 endpoint's posture information in a repository. 361 Posture Manager Endpoint 362 Orchestrator +----------------+ +----------------+ 363 +--------+ | | | | 364 | | | | | | 365 | |<---->| | | | 366 | | pub/ | | | | 367 | | sub | +------------+ | | +------------+ | 368 +--------+ | | | | | | | | 369 | | Posture | | | | Posture | | 370 Evaluator Repository | | Collection | | | | Collection | | 371 +------+ +--------+ | | Manager | |<-------| | Engine | | 372 | | | | | | | | report | | | | 373 | | | | | +------------+ | | +------------+ | 374 | |<-----> | |<---->| | query | | 375 | |request/| | store| |------->| | 376 | |respond | | | | | | 377 | | | | | | | | 378 +------+ +--------+ +----------------+ +----------------+ 379 | ^ 380 | query | 381 +-------------------------------------+ 383 Figure 1: EPCP Components 385 4.1. Endpoint 387 An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is 388 monitored by the enterprise and is the target of posture assessments. 389 To support these posture assessments, posture information is 390 collected via a posture collection engine. 392 4.1.1. Posture Collection Engine 394 The posture collection engine is located on the target endpoint and 395 receives queries from a posture collection manager. It also sends 396 collected posture information to the posture manager where it can be 397 sanity checked and stored in the repository. The posture collection 398 engine also contains a capability that sets up exchanges between the 399 target endpoint and posture manager. This capability makes the 400 posture collection engine responsible for performing the client-side 401 portion of encryption handshakes, and for locating authorized posture 402 managers with which to communicate. 404 4.2. Posture Manager 406 The posture manager is an endpoint that collects, validates, and 407 enriches posture information received about a target endpoint. It 408 also stores the posture information it receives in the repository. 409 The posture manager does not evaluate the posture information. 411 4.2.1. Posture Collection Manager 413 A posture collection manager is a lightweight and extensible 414 component that facilitates the coordination and execution of posture 415 collection requests using collection mechanisms deployed across the 416 enterprise. The posture collection manager may query and retrieve 417 guidance from the repository to guide the collection of posture 418 information from the target endpoint. 420 The posture collection manager also contains a capability that sets 421 up exchanges between the target endpoint and the posture manager, and 422 manages data sent to and from posture collection engine. It is also 423 responsible for performing the server-side portion of encryption 424 handshakes. 426 4.3. Repository 428 The repository hosts guidance, endpoint identification information, 429 and posture information reported by target endpoints where it is made 430 available to authorized components and persisted over a period of 431 time set by the administrator. Information stored in the repository 432 will be accessible to authorized parties via a standard 433 administrative interface as well as through a standardized API. The 434 repository may be a standalone component or may be located on the 435 posture manager. Furthermore, an implementation is not restricted to 436 a single repository and may leverage several repositories to provide 437 this functionality. 439 Currently, the EPCP does not provide a standardized interface or API 440 for accessing the information contained within the repository. A 441 future revision of the EPCP may specify a standardized interface and 442 API for components to interact with the repository. 444 4.4. Evaluator 446 The evaluator assesses the posture status of a target endpoint by 447 comparing collected posture information against the desired state of 448 the target endpoint specified in guidance. The evaluator queries and 449 retrieves the appropriate guidance from the repository as well as 450 queries and retrieves the posture information required for the 451 assessment from the repository. If the required posture information 452 is not available in the repository, the evaluator may request the 453 posture information from the posture collection manager, which will 454 result in the collection of additional posture information from the 455 target endpoint. This information is subsequently stored in the 456 repository where it is made available to the evaluator and other 457 components. The results of the assessment are stored in the 458 repository where they are available to tools and administrators for 459 follow-up actions, further evaluation, and historical purposes. 461 4.5. Orchestrator 463 The orchestrator provides a publish/subscribe interface for the 464 repository so that infrastructure endpoints can subscribe to and 465 receive published posture assessment results from the repository 466 regarding endpoint posture changes. 468 The EPCP does not currently define an orchestrator component nor does 469 it specify a standardized publish/subscribe interface for this 470 purpose. Future revisions of the EPCP may specify such an interface. 472 5. EPCP Transactions 474 5.1. Provisioning 476 An endpoint is provisioned with one or more attributes that will 477 serve as its unique identifier on the network as well as the 478 components and data models necessary to interact with the posture 479 manager. Examples of such identifiers include MAC addresses, serial 480 numbers, hardware certificates compliant with [IEEE-802-1ar], and the 481 identities of hardware cryptographic modules among others. Once 482 provisioning is complete, the endpoint is deployed on the network. 483 Over time, components and data models may need to be added to the 484 endpoint or updated to support the collection needs of an enterprise. 486 5.2. Discovery and Validation 488 If necessary, the target endpoint finds and validates the posture 489 manager. The posture collection engine on the target endpoint and 490 posture collection manager on the posture manager complete an 491 encryption handshake, during which endpoint identity information is 492 exchanged. 494 5.3. Event Driven Collection 496 The posture assessment is initiated when the posture collector engine 497 on the target endpoint notices that relevant posture information on 498 the endpoint has changed. Then, the posture collection engine 499 initiates a posture assessment information exchange with the posture 500 collection manager. 502 5.4. Querying 504 The posture assessment is initiated by the posture collection 505 manager. This can occur because: 507 1. policy states that a previous assessment has aged out or become 508 invalid, or 510 2. the posture collection manager is alerted by a sensor or an 511 administrator (via the posture manager's administrative 512 interface) that an assessment must be completed 514 5.5. Data Storage 516 Once posture information is received by the posture manager, it is 517 forwarded to the repository. The repository could be co-located with 518 the posture manager, or there could be direct or brokered 519 communication between the posture manager and the repository. The 520 posture information is stored in the repository along with past 521 posture information collected about the target endpoint. 523 5.6. Data Sharing 525 Because the target endpoint posture information was sent in 526 standards-based data models over secure, standardized protocols, and 527 then stored in a centralized repository linked to unique endpoint 528 identifiers, authorized parties are able to access the posture 529 information. Such authorized parties may include, but are not 530 limited to, administrators or endpoint owners (via the posture 531 manager's administrative interface), evaluators that access the 532 repository directly, and orchestrators that rely on publish/subscribe 533 communications with the repository. 535 Posture Manager Endpoint 536 Orchestrator +----------------+ +----------------+ 537 +--------+ | | | | 538 | | | | | | 539 | |<---->| | | | 540 | | pub/ | | | | 541 | | sub | +------------+ | | +------------+ | 542 +--------+ | | | | | | | | 543 | | Posture | | | | Posture | | 544 Evaluator Repository | | Collection | | | | Collection | | 545 +------+ +--------+ | | Manager | |<-------| | Engine | | 546 | | | | | | | | report | | | | 547 | | | | | +------------+ | | +------------+ | 548 | |<-----> | |<---->| | query | | 549 | |request/| | store| |------->| | 550 | |respond | | | | | | 551 | | | | | | | | 552 +------+ +--------+ +----------------+ +----------------+ 553 | ^ 554 | query | 555 +-------------------------------------+ 556 +--------------------------------+ 557 | Administrative Interface | 558 | and API | 559 +--------------------------------+ 561 Figure 2: Exposing Data to the Network 563 6. EPCP Implementations 565 The following sections describe implementations of the EPCP 566 leveraging the IETF NEA and IETF NETCONF architectures. 568 6.1. IETF NEA EPCP Implementation for Traditional Endpoints 570 When EPCP is used, posture collectors running on the target endpoint 571 gather posture information as changes occur on the endpoint. The 572 data is aggregated by the posture broker client and forwarded to a 573 posture manager, over a secure channel, via the posture transport 574 client. Once received by the posture transport server on the posture 575 manager, the posture information is directed by the posture broker 576 server to the appropriate posture validators where it can be 577 processed and stored in a repository. There the posture information 578 can be used by other tools to carry out assessment tasks. Posture 579 collectors can also be queried by posture validators to refresh 580 posture information about the target endpoint or to ask a specific 581 question about posture information. This is shown in Figure 3. 583 Posture Posture 584 Collection Collection 585 Manager Engine 586 +---------------+ +---------------+ 587 | | | | 588 | +-----------+ | PA-TNC | +-----------+ | 589 | | Posture | |--------| | Posture | | 590 | | Validator | | | | Collector | | 591 | +-----------+ | | +-----------+ | 592 | | | | | | 593 | | IF-IMV | | | IF-IMC | 594 | | | | | | 595 | +-----------+ | PB-TNC | +-----------+ | 596 | | PB Server | |--------| | PB Client | | 597 | +-----------+ | | +-----------+ | 598 | | | | | | 599 | | | | | | 600 | | | | | | 601 | +-----------+ | | +-----------+ | 602 | | PT Server | |<------>| | PT Client | | 603 | +-----------+ | PT-TLS | +-----------+ | 604 | | | | 605 +---------------+ +---------------+ 607 Figure 3: NEA Components 609 These requirements are written with a view to performing a posture 610 assessment on an endpoint; as the EPCP grows and evolves, these 611 requirements will be expanded to address issues that arise. Note 612 that these requirements refer to defined components of the NEA 613 architecture. As with the NEA architecture, vendors have discretion 614 as to how these NEA components map to separate pieces of software or 615 endpoints. 617 It should be noted that the posture broker client and posture 618 transport client components of the posture collection engine and the 619 posture broker server and posture transport server components of the 620 posture collection manager would likely need to be implemented by a 621 single vendor because there are no standardized interfaces between 622 the respective components and would not be interoperable. 624 6.1.1. Endpoint Pre-Provisioning 626 An endpoint is provisioned with a machine certificate that will serve 627 as its unique identifier on the network as well as the components 628 necessary to interact with the posture manager. This includes a 629 posture collection engine to manage requests from the posture manager 630 and the posture collectors necessary to collect the posture 631 information of importance to the enterprise. The endpoint is 632 deployed on the network. 634 The target endpoint SHOULD authenticate to the posture manager using 635 a machine certificate during the establishment of the outer tunnel 636 achieved with the posture transport protocol defined in [RFC6876]. 637 [IF-IMV] specifies how to pull an endpoint identifier out of a 638 machine certificate. An endpoint identifier SHOULD be created in 639 conformance with [IF-IMV] from a machine certificate sent via 640 [RFC6876]. 642 In the future, the identity could be a hardware certificate compliant 643 with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated 644 with the identity of a hardware cryptographic module, in accordance 645 with [IEEE-802-1ar], if present on the endpoint. The enterprise 646 SHOULD stand up a certificate root authority; install its root 647 certificate on endpoints and on the posture manager; and provision 648 the endpoints and the posture manager with machine certificates. The 649 target endpoint MAY authenticate to the posture manager using a 650 combination of the machine account and password; however, this is 651 less secure and not recommended. 653 6.1.2. Endpoint 655 The endpoint MUST conform to [RFC5793], which levies several 656 requirements against the endpoint. An endpoint that complies with 657 these requirements will be able to: 659 1. attempt to initiate a session with the posture manager if the 660 posture makes a request to send an update to posture manager; 662 2. notify the posture collector if no PT-TLS session with the 663 posture manager can be created; 665 3. notify the posture collector when a PT-TLS session is 666 established; and 668 4. receive information from the posture collectors, forward this 669 information to the posture manager via the posture collection 670 engine. 672 6.1.2.1. Posture Collector 674 Any posture collector used in an EPCP solution MUST be conformant 675 with the TCG TNC Integrity Measurement Collector interface [IF-IMC]. 677 6.1.2.2. Posture Broker Client 679 The posture broker client MUST conform to [IF-IMC] to enable 680 communications between the posture broker client and the posture 681 collectors on the endpoint. 683 6.1.2.3. Posture Transport Client 685 The posture transport client MUST implement PT-TLS. 687 The posture transport client MUST support the use of machine 688 certificates for TLS at each endpoint consistent with the 689 requirements stipulated in [RFC6876] and [Server-Discovery]. 691 The posture transport client MUST be able to locate an authorized 692 posture manager, and switch to a new posture manager when required by 693 the network, in conformance with [Server-Discovery]. 695 6.1.3. Posture Manager 697 The posture manager MUST conform to all requirements in the 698 [RFC5793]. 700 6.1.3.1. Posture Validator 702 Any posture validator used in an EPCP solution MUST be conformant 703 with the TCG TNC Integrity Measurement Verifier interface [IF-IMV]. 705 6.1.3.2. Posture Broker Server 707 The posture broker server MUST conform to [IF-IMV]. Conformance to 708 [IF-IMV] enables the posture broker server to obtain endpoint 709 identity information from the posture transport server, and pass this 710 information to any posture validators on the posture manager. 712 6.1.3.3. Posture Transport Server 714 The posture transport server MUST implement PT-TLS. 716 The posture transport server MUST support the use of machine 717 certificates for TLS at each endpoint consistent with the 718 requirements stipulated in [RFC6876] and [Server-Discovery]. 720 6.1.4. Repository 722 EPCP requires a simple administrative interface for the repository. 723 Posture validators on the posture manager receive the target endpoint 724 posture information via PA-TNC [RFC5792] messages sent from 725 corresponding posture collectors on the target endpoint. The posture 726 validators store this information in the repository linked to the 727 identity of the target endpoint where the posture collectors are 728 located. 730 6.1.5. IETF SACM SWAM Extension to the IETF NEA EPCP Implementation 732 This section defines the requirements associated with the software 733 asset management extension [RFC8412] to the IETF NEA EPCP 734 implementation. 736 6.1.5.1. Endpoint Pre-Provisioning 738 This section defines the requirements associated with implementing 739 SWIMA. 741 The following requirements assume that the platform or OS vendor 742 supports the use of SWID tags and has identified a standard directory 743 location for the SWID tags to be located as specified by [SWID]. 745 6.1.5.2. SWID Tags 747 The primary content for the EPCP is the information conveyed in the 748 elements of a SWID tag. 750 The endpoint MUST have SWID tags stored in a directory specified in 751 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 752 also be generated by: 754 o the software installer; or 756 o third-party software that creates tags based on the applications 757 it sees installed on the endpoint. 759 The elements in the SWID tag MUST be populated as specified in 760 [SWID]. These tags, and the directory in which they are stored, MUST 761 be updated as software is added, removed, or updated. 763 6.1.5.3. SWID Posture Collectors and Posture Validators 765 6.1.5.3.1. The SWID Posture Collector 767 For the EPCP, the SWID posture collector MUST be conformant with 768 [RFC8412], which includes requirements for: 770 1. Collecting SWID tags from the SWID directory 772 2. Monitoring the SWID directory for changes 773 3. Initiating a session with the posture manager to report changes 774 to the directory 776 4. Maintaining a list of changes to the SWID directory when updates 777 take place and no PT-TLS connection can be created with the 778 posture manager 780 5. Responding to a request for SWID tags from the SWID Posture 781 Validator on the posture manager 783 6. Responding to a query from the SWID posture validator as to 784 whether all updates have been sent 786 The SWID posture collector is not responsible for detecting that the 787 SWID directory was not updated when an application was either 788 installed or uninstalled. 790 6.1.5.3.2. The SWID Posture Validator 792 Conformance to [RFC8412] enables the SWID posture validator to: 794 1. Send messages to the SWID posture collector (at the behest of the 795 administrator at the posture manager console) requesting updates 796 for SWID tags located on endpoint 798 2. Ask the SWID posture collector whether all updates to the SWID 799 directory located at the posture manager have been sent 801 3. Perform any validation and processing on the collected SWID 802 posture information prior to storage 804 In addition to these requirements, a SWID posture validator used in 805 conformance with this profile MUST be capable of passing this SWID 806 posture information as well as the associated endpoint identity to 807 the repository for storage. 809 6.1.5.4. Repository 811 The administrative interface SHOULD enable an administrator to: 813 1. Query which endpoints have reported SWID tags for a particular 814 application 816 2. Query which SWID tags are installed on an endpoint 818 3. Query tags based on characteristics, such as vendor, publisher, 819 etc. 821 6.2. IETF NETCONF EPCP Implementation for Network Device Endpoints 823 When EPCP is used, a NETCONF client that implements the posture 824 collection manager sends a query to target network device endpoint 825 requesting posture information over a secure channel. Once the 826 NETCONF server on the endpoint receives the request, it queries one 827 or more datastores for the posture information. The NETCONF server 828 then reports the information back to the NETCONF client where it can 829 be stored in a repository for use by other tools. This is shown in 830 Figure 4. 832 Posture Posture 833 Collection Collection 834 Manager Engine 835 +---------------+ +---------------+ 836 | | | | 837 | | | +-----------+ | 838 | | | | Data | | 839 | | | | Store(s) | | 840 | | | +-----------+ | 841 | | | | | 842 | | | | | 843 | +-----------+ | | +-----------+ | 844 | | NETCONF | | | | NETCONF | | 845 | | Client | |<------->| | Server | | 846 | +-----------+ | NETCONF | +-----------+ | 847 | | | | 848 +---------------+ +---------------+ 850 Figure 4: NETCONF Components 852 These requirements are written with a view to performing a posture 853 assessment on network device endpoints (routers, switches, etc.); as 854 the EPCP grows and evolves, these requirements will be expanded to 855 address issues that arise. 857 Note that these requirements refer to defined components of the 858 NETCONF architecture and map back to EPCP. As with the NETCONF 859 architecture, vendors have discretion as to how these NETCONF 860 components map to separate pieces of software or endpoints. 862 6.2.1. Endpoint Pre-Provisioning 864 For the posture manager to be able to query the datastores on the 865 endpoint, the endpoint MUST be configured to grant the posture 866 manager access to its datastores as described in [RFC6241]. The 867 posture manager is identified by its NETCONF username. 869 6.2.2. Posture Manager Pre-Provisioning 871 For the posture manager to be able to query the datastores on the 872 endpoint, the posture manager MUST be provisioned with a NETCONF 873 username that will be used to authenticate the posture manager to the 874 endpoint as described in [RFC6241]. The username generated will be 875 determined by the selected transport protocol. 877 6.2.3. Endpoint 879 An endpoint MUST conform to the requirements outlined for servers in 880 the NETCONF protocol as defined in [RFC6241]. This requires the 881 implementation of NETCONF over SSH [RFC6242]. An endpoint MAY 882 support the NETCONF protocol over other transports such as TLS 883 [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040]. 885 6.2.3.1. Datastore 887 A NETCONF datastore on an endpoint MUST support the operations 888 outlined in [RFC6241], but, the actual implementation of the 889 datastore is left to the endpoint vendor. 891 Datastores MUST support the YANG data modeling language [RFC7950] for 892 expressing endpoint posture information in a structured format. In 893 addition, datastores MAY support other data models such as XML (via 894 YIN) for representing posture information. 896 Datastores MUST support the compliance posture information specified 897 in [RFC7317]. Datastores MAY support other models standardized or 898 proprietary as deemed appropriate by the endpoint vendor. 900 6.2.4. Posture Manager 902 A posture manager MUST conform to the requirements specified for 903 clients in the NETCONF protocol as defined in [RFC6241]. This 904 requires the implementation of NETCONF over SSH [RFC6242]. A posture 905 manager MAY also support the NETCONF protocol over other transports 906 such as TLS [RFC7589]. In addition, a posture manager MAY support 907 the RESTCONF protocol as defined in [RFC8040]. 909 While ad-hoc fetch/polling via NETCONF and RESTCONF is useful for 910 assessing endpoint compliance, such solutions by themselves are not 911 able to detect changes as they occur on the endpoint. As a result, a 912 future revision of this document will support 913 [I-D.ietf-netconf-yang-push] to receive updates on YANG-modeled 914 posture information. Similarly, because not all posture information 915 is modeled in YANG, a future revision of this document will reference 916 [I-D.ietf-netconf-subscribed-notifications] once it is a standard to 917 support continuous streams of unstructured data from the endpoint to 918 the posture manager. 920 6.2.5. Repository 922 EPCP requires a simple administrative interface for the repository. 923 The posture collection manager on the posture manager receives the 924 target endpoint posture information via NETCONF [RFC6241] messages 925 sent from posture collection engine on the target endpoint. The 926 posture collection manager stores this information in the repository 927 linked to the identity of the target endpoint from which it was 928 collected. 930 6.3. Administrative Interface and API 932 An interface is necessary to allow administrators to query the 933 repository and manage the endpoints and software used in the EPCP via 934 the posture manager. Similarly, an API is necessary to allow 935 infrastructure endpoints and software access to the information 936 stored in the repository and to manage the endpoints and software 937 used in the EPCP. 939 Using this interface or API, authorized users, infrastructure 940 endpoints, and software SHOULD be able to: 942 o Query the repository 944 o Send commands to the posture collection managers, requesting 945 information from the associated posture collection engines 946 residing on endpoints 948 o Establish and update the policy that resides on the posture 949 manager 951 7. EPCP Use Cases 953 The following sections describe the different use cases supported by 954 the EPCP. 956 7.1. Hardware Asset Management 958 Using the administrative interface on the posture manager, an 959 authorized user can learn: 961 o what endpoints are connected to the network at any given time; and 963 o what SWID tags were reported for the endpoints. 965 The ability to answer these questions offers a standards-based 966 approach to asset management, which is a vital part of enterprise 967 processes such as compliance report generation for the Federal 968 Information Security Modernization Act (FISMA), Payment Card Industry 969 Data Security Standard (PCI DSS), Health Insurance Portability and 970 Accountability Act (HIPAA), etc. 972 7.2. Software Asset Management 974 The administrative interface on the posture manager provides the 975 ability for authorized users and infrastructure to know which 976 software is installed on which endpoints on the enterprise's network. 977 This allows the enterprise to answer questions about what software is 978 installed to determine if it is licensed or prohibited. This 979 information can also drive other use cases such as: 981 o vulnerability management: knowing what software is installed 982 supports the ability to determine which endpoints contain 983 vulnerable software and need to be patched. 985 o configuration management: knowing which security controls need to 986 be applied to harden installed software and better protect 987 endpoints. 989 7.3. Vulnerability Management 991 The administrative interface also provides the ability for authorized 992 users or infrastructure to locate endpoints running software for 993 which vulnerabilities have been announced. Because of 995 1. the unique IDs assigned to each endpoint; and 997 2. the rich application data provided in the endpoints' posture 998 information, 1000 the repository can be queried to find all endpoints running a 1001 vulnerable application. Endpoints suspected of being vulnerable can 1002 be addressed by the administrator or flagged for further scrutiny. 1004 7.4. Threat Detection and Analysis 1006 The repository's standardized API allows authorized infrastructure 1007 endpoints and software to search endpoint posture assessment 1008 information for evidence that an endpoint's software inventory has 1009 changed, and can make endpoint software inventory data available to 1010 other endpoints. This automates security data sharing in a way that 1011 expedites the correlation of relevant network data, allowing 1012 administrators and infrastructure endpoints to identify odd endpoint 1013 behavior and configuration using secure, standards-based data models 1014 and protocols. 1016 8. Non-supported Use Cases 1018 Several use cases, including but not limited to these, are not 1019 covered by the EPCP: 1021 o Gathering non-standardized types of posture information: The EPCP 1022 does not prevent administrators from collecting posture 1023 information in proprietary formats from the endpoint; however it 1024 does not set requirements for doing so. 1026 o Solving the lying endpoint problem: The EPCP does not address the 1027 lying endpoint problem; the Profile makes no assertions that it 1028 can catch an endpoint that is, either maliciously or accidentally, 1029 reporting false posture information to the posture manager. 1030 However, other solutions may be able to use the posture 1031 information collected using the capabilities described in this 1032 profile to catch an endpoint in a lie. For example, a sensor may 1033 be able to compare the posture information it has collected on an 1034 endpoint's activity on the network to what the endpoint reported 1035 to the server and flag discrepancies. However, these capabilities 1036 are not described in this profile. 1038 9. Endpoint Posture Collection Profile Examples 1040 The following subsections provide examples of the EPCP as implemented 1041 using components from the NEA architecture. 1043 9.1. Continuous Posture Assessment of an Endpoint 1044 Endpoint Posture Manager 1045 +---------------+ +---------------+ 1046 | | | | 1047 | +-----------+ | | +-----------+ | 1048 | | SWID | | | | SWID | | 1049 | | Posture | | | | Posture | | 1050 | | Collector | | | | Validator | | 1051 | +-----------+ | | +-----------+ | 1052 | | | | | | 1053 | | IF-IMC | | | IF-IMV | 1054 | | | | | | 1055 | +-----------+ | | +-----------+ | 1056 | | PB Client | | | | PB Server | | 1057 | +-----------+ | | +-----------+ | 1058 | | | | | | 1059 | | | | | | 1060 | | | | | | 1061 | +-----------+ | | +-----------+ | 1062 | | PT Client | |<------>| | PT Server | | 1063 | +-----------+ | PT-TLS | +-----------+ | 1064 | | | | 1065 +---------------+ +---------------+ 1067 Figure 5: Continuous Posture Assessment of an Endpoint 1069 9.1.1. Change on Endpoint Triggers Posture Assessment 1071 A new application is installed on the endpoint, and the SWID 1072 directory is updated. This triggers an update from the SWID posture 1073 collector to the SWID posture validator. The message is sent down 1074 the NEA stack, encapsulated by NEA protocols until it is sent by the 1075 posture transport client to the posture transport server. The 1076 posture transport server then forwards it up through the stack, where 1077 the layers of encapsulation are removed until the SWID Message 1078 arrives at the SWID posture validator. 1080 Endpoint Posture Manager 1081 +---------------+ +---------------+ 1082 | | | | 1083 | +-----------+ | | +-----------+ | 1084 | | SWID | | | | SWID | | 1085 | | Posture | | | | Posture | | 1086 | | Collector | | | | Validator | | 1087 | +-----------+ | | +-----------+ | 1088 | | | SWID Message | | | 1089 | | IF-IMC | for PA-TNC | | IF-IMV | 1090 | | | | | | 1091 | +-----------+ | | +-----------+ | 1092 | | PB Client | | | | PB Server | | 1093 | +-----------+ | | +-----------+ | 1094 | | | | | | 1095 | | | PB-TNC {SWID | | | 1096 | | | Message for | | | 1097 | | | PA-TNC} | | | 1098 | +-----------+ | | +-----------+ | 1099 | | PT Client | |<-------------->| | PT Server | | 1100 | +-----------+ | PT-TLS {PB-TNC | +-----------+ | 1101 | | {SWID Message | | 1102 +---------------+ for PA-TNC}} +---------------+ 1104 Figure 6: Compliance Protocol Encapsulation 1106 The SWID posture validator stores the new tag information in the 1107 repository. If the tag indicates that the endpoint is compliant to 1108 the policy, then the process is complete until the next time an 1109 update is needed (either because policy states that the endpoint must 1110 submit posture assessment results periodically or because an 1111 install/uninstall/update on the endpoint triggers a posture 1112 assessment). 1114 Endpoint Posture Manager 1115 +---------------+ +---------------+ 1116 | | | | 1117 | +-----------+ | | +-----------+ | 1118 | | SWID | | | | SWID |-|-+ 1119 | | Posture | | | | Posture | | | 1120 | | Collector | | | | Validator | | | 1121 | +-----------+ | | +-----------+ | | 1122 | | | | | | | Repository 1123 | | IF-IMC | | | IF-IMV | | +--------+ 1124 | | | | | | | | | 1125 | +-----------+ | | +-----------+ | | | | 1126 | | PB Client | | | | PB Server | | +---->| | 1127 | +-----------+ | | +-----------+ | | | 1128 | | | | | | +--------+ 1129 | | | | | | 1130 | | | | | | 1131 | +-----------+ | | +-----------+ | 1132 | | PT Client | |<------>| | PT Server | | 1133 | +-----------+ | PT-TLS | +-----------+ | 1134 | | | | 1135 +---------------+ +---------------+ 1137 Figure 7: Storing SWIDs in the Repository 1139 If the endpoint has fallen out of compliance with a policy, the 1140 posture manager can alert the administrator via the posture manager's 1141 administrative interface. The administrator can then take steps to 1142 address the problem. If the administrator has already established a 1143 policy for automatically addressing this problem, that policy will be 1144 followed. 1146 (") 1147 __|__ 1148 +-->| 1149 Endpoint Posture Manager | / \ 1150 +---------------+ +---------------+ | 1151 | | | | | 1152 | +-----------+ | | +-----------+ | | 1153 | | SWID | | | | SWID |-|-+ 1154 | | Posture | | | | Posture | | 1155 | | Collector | | | | Validator | | 1156 | +-----------+ | | +-----------+ | 1157 | | | | | | Repository 1158 | | IF-IMC | | | IF-IMV | +--------+ 1159 | | | | | | | | 1160 | +-----------+ | | +-----------+ | | | 1161 | | PB Client | | | | PB Server | | | | 1162 | +-----------+ | | +-----------+ | | | 1163 | | | | | | +--------+ 1164 | | | | | | 1165 | | | | | | 1166 | +-----------+ | | +-----------+ | 1167 | | PT Client | |<------>| | PT Server | | 1168 | +-----------+ | PT-TLS | +-----------+ | 1169 | | | | 1170 +---------------+ +---------------+ 1172 Figure 8: Server Alerts Network Admin 1174 9.2. Administrator Searches for Vulnerable Endpoints 1176 An announcement is made that a particular version of a piece of 1177 software has a vulnerability. The administrator uses the 1178 administrative interface on the server to search the repository for 1179 endpoints that reported the SWID tag for the vulnerable software. 1181 (") 1182 __|__ 1183 +-->| 1184 Endpoint Posture Manager | / \ 1185 +---------------+ +---------------+ | 1186 | | | | | 1187 | +-----------+ | | +-----------+ | | 1188 | | SWID | | | | SWID |-|-+ 1189 | | Posture | | | | Posture | | 1190 | | Collector | | | | Validator | | 1191 | +-----------+ | | +-----------+ | 1192 | | | | | | Repository 1193 | | IF-IMC | | | IF-IMV | +--------+ 1194 | | | | | | | | 1195 | +-----------+ | | +-----------+ | | | 1196 | | PB Client | | | | PB Server | |------>| | 1197 | +-----------+ | | +-----------+ | | | 1198 | | | | | | +--------+ 1199 | | | | | | 1200 | | | | | | 1201 | +-----------+ | | +-----------+ | 1202 | | PT Client | |<------>| | PT Server | | 1203 | +-----------+ | PT-TLS | +-----------+ | 1204 | | | | 1205 +---------------+ +---------------+ 1207 Figure 9: Admin Searches for Vulnerable Endpoints 1209 The repository returns a list of entries in the matching the 1210 administrator's search. The administrator can then address the 1211 vulnerable endpoints by taking some follow-up action such as removing 1212 it from the network, quarantining it, or updating the vulnerable 1213 software. 1215 10. Future Work 1217 This section captures ideas for future work related to EPCP that 1218 might be of interest to the IETF SACM WG. These ideas are listed in 1219 no particular order. 1221 o Integrate the IETF NETCONF Yang Push architecture. 1223 o Add support endpoint types beyond workstations, servers, and 1224 network infrastructure devices. 1226 o Examine the integration of [I-D.ietf-mile-xmpp-grid]. 1228 o Define a standard interface and API for interacting with the 1229 repository. Requirements to consider include: creating a secure 1230 channel between a publisher and the repository, creating a secure 1231 channel between a subscriber and the repository, and the types of 1232 interactions that must be supported between publishers and 1233 subscribers to a repository. 1235 o Define a standard interface for communications between the posture 1236 broker client and posture transport client(s) as well as the 1237 posture broker server and posture transport server(s). 1239 o Retention of posture information on the target endpoint. 1241 o Define an orchestrator component as well as publish/subscribe 1242 interface for it. 1244 o Define an evaluator component as well as an interface for it. 1246 11. Acknowledgements 1248 The authors wish to thank all of those in the TCG TNC work group who 1249 contributed to development of the TNC ECP specification upon which 1250 this document is based. 1252 +-----------------------+-------------------------------------------+ 1253 | Member | Organization | 1254 +-----------------------+-------------------------------------------+ 1255 | Padma Krishnaswamy | Battelle Memorial Institute | 1256 | | | 1257 | Eric Fleischman | Boeing | 1258 | | | 1259 | Richard Hill | Boeing | 1260 | | | 1261 | Steven Venema | Boeing | 1262 | | | 1263 | Nancy Cam-Winget | Cisco Systems | 1264 | | | 1265 | Scott Pope | Cisco Systems | 1266 | | | 1267 | Max Pritikin | Cisco Systems | 1268 | | | 1269 | Allan Thompson | Cisco Systems | 1270 | | | 1271 | Nicolai Kuntze | Fraunhofer Institute for Secure | 1272 | | Information Technology (SIT) | 1273 | | | 1274 | Ira McDonald | High North | 1275 | | | 1276 | Dr. Andreas Steffen | HSR University of Applied Sciences | 1277 | | Rapperswil | 1278 | | | 1279 | Josef von Helden | Hochschule Hannover | 1280 | | | 1281 | James Tan | Infoblox | 1282 | | | 1283 | Steve Hanna (TNC-WG | Juniper Networks | 1284 | Co-Chair) | | 1285 | | | 1286 | Cliff Kahn | Juniper Networks | 1287 | | | 1288 | Lisa Lorenzin | Juniper Networks | 1289 | | | 1290 | Atul Shah (TNC-WG Co- | Microsoft | 1291 | Chair) | | 1292 | | | 1293 | Jon Baker | MITRE | 1294 | | | 1295 | Charles Schmidt | MITRE | 1296 | | | 1297 | Rainer Enders | NCP Engineering | 1298 | | | 1299 | Dick Wilkins | Phoenix Technologies | 1300 | | | 1301 | David Waltermire | NIST | 1302 | | | 1303 | Mike Boyle | U.S. Government | 1304 | | | 1305 | Emily Doll | U.S. Government | 1306 | | | 1307 | Jessica Fitzgerald- | U.S. Government | 1308 | McKay | | 1309 | | | 1310 | Mary Lessels | U.S. Government | 1311 | | | 1312 | Chris Salter | U.S. Government | 1313 +-----------------------+-------------------------------------------+ 1315 Table 1: Members of the TNC Work Group that Contributed to the 1316 Document 1318 12. IANA Considerations 1320 This document does not define any new IANA registries. However, this 1321 document does reference other documents that do define IANA 1322 registries. As a result, the IANA Considerations section of the 1323 referenced documents should be consulted. 1325 13. Security Considerations 1327 This Security Considerations section includes an analysis of the 1328 attacks that may be mounted against systems that implement the EPCP 1329 (Section 13.1) and the countermeasures that may be used to prevent or 1330 mitigate these attacks (Section 13.2). Overall, a substantial 1331 reduction in cyber risk can be achieved. 1333 13.1. Threat Model 1335 This section lists the attacks that can be mounted on a NEA 1336 implementation of an EPCP environment. The following section 1337 (Section 13.2) describes countermeasures. 1339 Because the EPCP describes a specific use case for NEA components, 1340 many security considerations for these components are addressed in 1341 more detail in the technical specifications: [RFC8412], [IF-IMC], 1342 [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV]. 1344 13.1.1. Endpoint Attacks 1346 While the EPCP provides substantial improvements in endpoint 1347 security, endpoints can still be compromised. For this reason, all 1348 parties must regard data coming from endpoints as potentially 1349 unreliable or even malicious. An analogy can be drawn with human 1350 testimony in an investigation or trial. Human testimony is essential 1351 but must be regarded with suspicion. 1353 o Compromise of endpoint: A compromised endpoint may report false 1354 information to confuse or even provide maliciously crafted 1355 information with a goal of infecting others. 1357 o Putting bad information in SWID directory: Even if an endpoint is 1358 not completely compromised, some of the software running on it may 1359 be unreliable or even malicious. This software, potentially 1360 including the SWID generation or discovery tool, or malicious 1361 software pretending to be a SWID generation or discovery tool, can 1362 place incorrect or maliciously crafted information into the SWID 1363 directory. Endpoint users may even place such information in the 1364 directory, whether motivated by curiosity or confusion or a desire 1365 to bypass restrictions on their use of the endpoint. 1367 o Identity spoofing (impersonation): A compromised endpoint may 1368 attempt to impersonate another endpoint to gain its privileges or 1369 to besmirch the reputation of that other endpoint. 1371 13.1.2. Network Attacks 1373 A variety of attacks can be mounted using the network. Generally, 1374 the network cannot be trusted. 1376 o Eavesdropping, modification, injection, replay, deletion 1378 o Traffic analysis 1380 o Denial of service and blocking traffic 1382 13.1.3. Posture Manager Attacks 1384 The posture manager is a critical security element and therefore 1385 merits considerable scrutiny. 1387 o Compromised trusted manager: A compromised posture manager or a 1388 malicious party that is able to impersonate a posture manager can 1389 incorrectly grant or deny access to endpoints, place incorrect 1390 information into the repository, or send malicious messages to 1391 endpoints. 1393 o Misconfiguration of posture manager: Accidental or purposeful 1394 misconfiguration of a trusted posture manager can cause effects 1395 that are similar to those listed for compromised trusted posture 1396 manager. 1398 o Malicious untrusted posture manager: An untrusted posture manager 1399 cannot mount any significant attacks because all properly 1400 implemented endpoints will refuse to engage in any meaningful 1401 dialog with such a posture manager. 1403 13.1.4. Repository Attacks 1405 The repository is also an important security element and therefore 1406 merits careful scrutiny. 1408 o Putting bad information into trusted repository: An authorized 1409 repository client such as a server may be able to put incorrect 1410 information into a trusted repository or delete or modify 1411 historical information, causing incorrect decisions about endpoint 1412 security. Placing maliciously crafted data in the repository 1413 could even lead to compromise of repository clients, if they fail 1414 to carefully check such data. 1416 o Compromised trusted repository: A compromised trusted repository 1417 or a malicious untrusted repository that is able to impersonate a 1418 trusted repository can lead to effects similar to those listed for 1419 "Putting bad information into trusted repository". Further, a 1420 compromised trusted repository can report different results to 1421 different repository clients or deny access to the repository for 1422 selected repository clients. 1424 o Misconfiguration of trusted repository: Accidental or purposeful 1425 misconfiguration of a trusted repository can deny access to the 1426 repository or result in loss of historical data. 1428 o Malicious untrusted repository: An untrusted repository cannot 1429 mount any significant attacks because all properly implemented 1430 repository clients will refuse to engage in any meaningful dialog 1431 with such a repository. 1433 13.2. Countermeasures 1435 This section lists the countermeasures that can be used in a NEA 1436 implementation of an EPCP environment. 1438 13.2.1. Countermeasures for Endpoint Attacks 1440 This profile is in and of itself a countermeasure for a compromised 1441 endpoint. A primary defense for an endpoint is to run up to date 1442 software configured to be run as safely as possible. 1444 Ensuring that anti-virus signatures are up to date and that a 1445 firewall is configured are also protections for an endpoint that are 1446 supported by the current NEA specifications. 1448 Endpoints that have hardware cryptographic modules that are 1449 provisioned by the enterprise, in accordance with [IEEE-802-1ar], can 1450 protect the private keys used for authentication and help prevent 1451 adversaries from stealing credentials that can be used for 1452 impersonation. Future versions of the EPCP may want to discuss in 1453 greater detail how to use a hardware cryptographic module, in 1454 accordance with [IEEE-802-1ar], to protect credentials and to protect 1455 the integrity of the code that executes during the bootstrap process. 1457 13.2.2. Countermeasures for Network Attacks 1459 To address network attacks, [RFC6876] includes required encryption, 1460 authentication, integrity protection, and replay protection. 1461 [Server-Discovery] also includes authorization checks to ensure that 1462 only authorized servers are trusted by endpoints. Any unspecified or 1463 not yet specified network protocols employed in the EPCP (e.g. the 1464 protocol used to interface with the repository) should include 1465 similar protections. 1467 These protections reduce the scope of the network threat to traffic 1468 analysis and denial of service. Countermeasures for traffic analysis 1469 (e.g. masking) are usually impractical but may be employed. 1470 Countermeasures for denial of service (e.g. detecting and blocking 1471 particular sources) SHOULD be used when appropriate to detect and 1472 block denial of service attacks. These are routine practices in 1473 network security. 1475 13.2.3. Countermeasures for Posture Manager Attacks 1477 Because of the serious consequences of posture manager compromise, 1478 posture managers SHOULD be especially well hardened against attack 1479 and minimized to reduce their attack surface. They SHOULD be 1480 monitored using the NEA protocols to ensure the integrity of the 1481 behavior and analysis data stored on the posture manager and SHOULD 1482 utilize a [IEEE-802-1ar]compliant hardware cryptographic module for 1483 identity and/or integrity measurements of the posture manager. They 1484 should be well managed to minimize vulnerabilities in the underlying 1485 platform and in systems upon which the posture manager depends. 1486 Network security measures such as firewalls or intrusion detection 1487 systems may be used to monitor and limit traffic to and from the 1488 posture manager. Personnel with administrative access to the posture 1489 manager should be carefully screened and monitored to detect problems 1490 as soon as possible. Posture manager administrators should not use 1491 password-based authentication but should instead use non-reusable 1492 credentials and multi-factor authentication (where available). 1493 Physical security measures should be employed to prevent physical 1494 attacks on posture managers. 1496 To ease detection of posture manager compromise, should it occur, 1497 posture manager behavior should be monitored to detect unusual 1498 behavior (such as a server reboot, unusual traffic patterns, or other 1499 odd behavior). Endpoints should log and/or notify users and/or 1500 administrators when peculiar posture manager behavior is detected. 1501 To aid forensic investigation, permanent read-only audit logs of 1502 security-relevant information pertaining to posture manager 1503 (especially administrative actions) should be maintained. If posture 1504 manager compromise is detected, the posture manager's certificate 1505 should be revoked and careful analysis should be performed of the 1506 source and impact of this compromise. Any reusable credentials that 1507 may have been compromised should be reissued. 1509 Endpoints can reduce the threat of server compromise by minimizing 1510 the number of trusted posture managers, using the mechanisms 1511 described in [Server-Discovery]. 1513 13.2.4. Countermeasures for Repository Attacks 1515 If the host for the repository is located on its own endpoint, it 1516 should be protected with the same measures taken to protect the 1517 posture manager. In this circumstance, all messages between the 1518 posture manager and repository should be protected with a mature 1519 security protocol such as TLS or IPsec. 1521 The repository can aid in the detection of compromised endpoints if 1522 an adversary cannot tamper with its contents. For instance, if an 1523 endpoint reports that it does not have an application with a known 1524 vulnerability installed, an administrator can check whether the 1525 endpoint might be lying by querying the repository for the history of 1526 what applications were installed on the endpoint. 1528 To help prevent tampering with the information in the repository: 1530 1. Only authorized parties should have privilege to run code on the 1531 endpoint and to change the repository. 1533 2. If a separate endpoint hosts the repository, then the 1534 functionality of that endpoint should be limited to hosting the 1535 repository. The firewall on the repository should only allow 1536 access to the posture manager and to any endpoint authorized for 1537 administration. 1539 3. The repository should ideally use "write once" media to archive 1540 the history of what was placed in the repository, to include a 1541 snapshot of the current status of applications on endpoints. 1543 14. Privacy Considerations 1545 The EPCP specifically addresses the collection of posture data from 1546 enterprise endpoints by an enterprise network. As such, privacy is 1547 not going to often arise as a concern for those deploying this 1548 solution. 1550 A possible exception may be the concerns a user may have when 1551 attempting to connect a personal endpoint (such as a phone or mobile 1552 endpoint) to an enterprise network. The user may not want to share 1553 certain details, such as an endpoint identifier or SWID tags, with 1554 the enterprise. The user can configure their NEA client to reject 1555 requests for this information; however, it is possible that the 1556 enterprise policy will not allow the user's endpoint to connect to 1557 the network without providing the requested data. 1559 15. Change Log 1561 15.1. -02 to -03 1563 Addressed various comments from the SACM WG. 1565 Added a reference to TCG ECP 1.0. 1567 Removed text in the "SWID Posture Validator" section that states it 1568 performs evaluation. This was removed because it contradicts the 1569 posture manager not performing any evaluations. 1571 Expanded the "Provisioning" section of the "EPCP Transactions" 1572 section to include examples of endpoint identifiers and the need to 1573 provision endpoints with components and data models. 1575 Combined text for the capabilities of the Administrative Interface 1576 and API. 1578 Removed superfluous and introductory text from the "Security 1579 Considerations" section. 1581 Renamed section "Vulnerability Searches" to Vulnerability 1582 Management". 1584 Changed I-D category to BCP. 1586 Changed references to the NETMOD architecture to the NETCONF 1587 architecture because NETCONF represents the management protocol 1588 whereas NETMOD is focused on the definition of data models. 1590 Addressed various editorial suggestions. 1592 15.2. -01 to -02 1594 Addressed various comments from the SACM WG. 1596 Added a section for the collection of posture information from 1597 network devices using standards from the NETMOD WG. 1599 Updated EPCP component diagrams so they were not specific to a NEA- 1600 based implementation. 1602 Updated EPCP NEA example diagrams to reflect all the components in 1603 the NEA architecture. 1605 15.3. -00 to -01 1607 There are no textual changes associated with this revision. This 1608 revision simply reflects a resubmission of the document so that it 1609 remains in active status. 1611 15.4. -01 to -02 1613 Added references to the Software Inventory Message and Attributes 1614 (SWIMA) for PA-TNC I-D. 1616 Replaced references to PC-TNC with IF-IMC. 1618 Removed erroneous hyphens from a couple of section titles. 1620 Made a few minor editorial changes. 1622 15.5. -02 to -00 1624 Draft adopted by IETF SACM WG. 1626 15.6. -00 to -01 1628 Significant edits to up-level the draft to describe SACM collection 1629 over multiple different protocols. 1631 Replaced references to SANS with CIS. 1633 Made other minor editorial changes. 1635 16. References 1637 16.1. Informative References 1639 [CIS] http://www.cisecurity.org/controls/, "CIS Critical 1640 Security Controls". 1642 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1643 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1644 Protect Your ICT System", November 2012. 1646 [ECP] Trusted Computing Group, "TCG Trusted Network Connect 1647 Endpoint Compliance Profile, Version 1.10", December 2014. 1649 [IEEE-802-1ar] 1650 Institute of Electrical and Electronics Engineers, "IEEE 1651 802.1ar", December 2009. 1653 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1654 Tardo, "Network Endpoint Assessment (NEA): Overview and 1655 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1656 . 1658 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1659 Architecture for Interoperability, Version 1.5", February 1660 2012. 1662 16.2. Normative References 1664 [I-D.ietf-mile-xmpp-grid] 1665 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 1666 "Using XMPP for Security Information Exchange", draft- 1667 ietf-mile-xmpp-grid-04 (work in progress), October 2017. 1669 [I-D.ietf-netconf-subscribed-notifications] 1670 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1671 A. Tripathy, "Customized Subscriptions to a Publisher's 1672 Event Streams", draft-ietf-netconf-subscribed- 1673 notifications-13 (work in progress), June 2018. 1675 [I-D.ietf-netconf-yang-push] 1676 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1677 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1678 Subscription", draft-ietf-netconf-yang-push-12 (work in 1679 progress), December 2017. 1681 [I-D.ietf-sacm-terminology] 1682 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1683 Winget, "Terminology for Security Assessment", draft-ietf- 1684 sacm-terminology-05 (work in progress), August 2014. 1686 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1687 IF-IMC, Version 1.3", February 2013. 1689 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1690 IF-IMV, Version 1.4", December 2014. 1692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1693 Requirement Levels", BCP 14, RFC 2119, 1694 DOI 10.17487/RFC2119, March 1997, 1695 . 1697 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1698 (PA) Protocol Compatible with Trusted Network Connect 1699 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1700 . 1702 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1703 A Posture Broker (PB) Protocol Compatible with Trusted 1704 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1705 March 2010, . 1707 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1708 and A. Bierman, Ed., "Network Configuration Protocol 1709 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1710 . 1712 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1713 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1714 . 1716 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1717 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1718 DOI 10.17487/RFC6876, February 2013, 1719 . 1721 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1722 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1723 2014, . 1725 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1726 NETCONF Protocol over Transport Layer Security (TLS) with 1727 Mutual X.509 Authentication", RFC 7589, 1728 DOI 10.17487/RFC7589, June 2015, 1729 . 1731 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 1732 Posture Assessment: Enterprise Use Cases", RFC 7632, 1733 DOI 10.17487/RFC7632, September 2015, 1734 . 1736 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1737 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1738 . 1740 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1741 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1742 . 1744 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1745 J. Fitzgerald-McKay, "Software Inventory Message and 1746 Attributes (SWIMA) for PA-TNC", RFC 8412, 1747 DOI 10.17487/RFC8412, July 2018, 1748 . 1750 [Server-Discovery] 1751 Trusted Computing Group, "DRAFT: TCG Trusted Network 1752 Connect PDP Discovery and Validation, Version 1.0", 1753 October 2015. 1755 [SWID] "Information technology--Software asset management--Part 1756 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1758 Authors' Addresses 1760 Danny Haynes 1761 The MITRE Corporation 1762 202 Burlington Road 1763 Bedford, MA 01730 1764 USA 1766 Email: dhaynes@mitre.org 1768 Jessica Fitzgerald-McKay 1769 Department of Defense 1770 9800 Savage Road 1771 Ft. Meade, Maryland 1772 USA 1774 Email: jmfitz2@nsa.gov 1776 Lisa Lorenzin 1777 Pulse Secure 1778 2700 Zanker Rd., Suite 200 1779 San Jose, CA 95134 1780 US 1782 Email: llorenzin@pulsesecure.net