idnits 2.17.1 draft-ietf-sacm-ecp-02.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 42 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5209' is defined on line 1732, but no explicit reference was found in the text == Unused Reference: 'RFC7632' is defined on line 1816, 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 (-05) exists of draft-ietf-sacm-nea-swima-patnc-01 == 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: 3 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM D. Haynes 3 Internet-Draft The MITRE Corporation 4 Intended status: Standards Track J. Fitzgerald-McKay 5 Expires: January 3, 2019 Department of Defense 6 L. Lorenzin 7 Pulse Secure 8 July 2, 2018 10 Endpoint Posture Collection Profile 11 draft-ietf-sacm-ecp-02 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. 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 January 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 19 105 6.2. IETF NETMOD EPCP Implementation for Network Device 106 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 19 107 6.2.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . 22 115 7.1. Hardware Asset Management . . . . . . . . . . . . . . . . 22 116 7.2. Software Asset Management . . . . . . . . . . . . . . . . 22 117 7.3. Vulnerability Searches . . . . . . . . . . . . . . . . . 22 118 7.4. Threat Detection and Analysis . . . . . . . . . . . . . . 23 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. Security Benefits of Endpoint Posture Collection Profile 31 129 13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 33 130 13.2.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 33 131 13.2.2. Network Attacks . . . . . . . . . . . . . . . . . . 34 132 13.2.3. Posture Manager Attacks . . . . . . . . . . . . . . 34 133 13.2.4. Repository Attacks . . . . . . . . . . . . . . . . . 34 134 13.3. Countermeasures . . . . . . . . . . . . . . . . . . . . 35 135 13.3.1. Countermeasures for Endpoint Attacks . . . . . . . . 35 136 13.3.2. Countermeasures for Network Attacks . . . . . . . . 36 137 13.3.3. Countermeasures for Posture Manager Attacks . . . . 36 138 13.3.4. Countermeasures for Repository Attacks . . . . . . . 37 139 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 140 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 141 15.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 38 142 15.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 38 143 15.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 38 144 15.4. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 38 145 15.5. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 38 146 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 147 16.1. Informative References . . . . . . . . . . . . . . . . . 39 148 16.2. Normative References . . . . . . . . . . . . . . . . . . 39 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 151 1. Introduction 153 The Endpoint Posture Collection Profile (EPCP) builds on prior work 154 from the IETF NEA WG, the IETF NETMOD 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 4, 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 a number of components. Some of these components reside on 357 the 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 necessary to interact with the posture manager. The 479 endpoint is deployed on the network. 481 NOTE: TO BE EXPANDED 483 5.2. Discovery and Validation 485 If necessary, the target endpoint finds and validates the posture 486 manager. The posture collection engine on the target endpoint and 487 posture collection manager on the posture manager complete an 488 encryption handshake, during which endpoint identity information is 489 exchanged. 491 5.3. Event Driven Collection 493 The posture assessment is initiated when the posture collector engine 494 on the target endpoint notices that relevant posture information on 495 the endpoint has changed. Then, the posture collection engine 496 initiates a posture assessment information exchange with the posture 497 collection manager. 499 5.4. Querying 501 The posture assessment is initiated by the posture collection 502 manager. This can occur because: 504 1. policy states that a previous assessment has aged out or become 505 invalid, or 507 2. the posture collection manager is alerted by a sensor or an 508 administrator (via the posture manager's administrative 509 interface) that an assessment must be completed 511 5.5. Data Storage 513 Once posture information is received by the posture manager, it is 514 forwarded to the repository. The repository could be co-located with 515 the posture manager, or there could be direct or brokered 516 communication between the posture manager and the repository. The 517 posture information is stored in the repository along with past 518 posture information collected about the target endpoint. 520 5.6. Data Sharing 522 Because the target endpoint posture information was sent in 523 standards-based data models over secure, standardized protocols, and 524 then stored in a centralized repository linked to unique endpoint 525 identifiers, authorized parties are able to access the posture 526 information. Such authorized parties may include, but are not 527 limited to, administrators or endpoint owners (via the posture 528 manager's administrative interface), evaluators that access the 529 repository directly, and orchestrators that rely on publish/subscribe 530 communications with the repository. 532 Posture Manager Endpoint 533 Orchestrator +----------------+ +----------------+ 534 +--------+ | | | | 535 | | | | | | 536 | |<---->| | | | 537 | | pub/ | | | | 538 | | sub | +------------+ | | +------------+ | 539 +--------+ | | | | | | | | 540 | | Posture | | | | Posture | | 541 Evaluator Repository | | Collection | | | | Collection | | 542 +------+ +--------+ | | Manager | |<-------| | Engine | | 543 | | | | | | | | report | | | | 544 | | | | | +------------+ | | +------------+ | 545 | |<-----> | |<---->| | query | | 546 | |request/| | store| |------->| | 547 | |respond | | | | | | 548 | | | | | | | | 549 +------+ +--------+ +----------------+ +----------------+ 550 | ^ 551 | query | 552 +-------------------------------------+ 553 +--------------------------------+ 554 | Administrative Interface | 555 | and API | 556 +--------------------------------+ 558 Figure 2: Exposing Data to the Network 560 6. EPCP Implementations 562 The following sections describe implementations of the EPCP 563 leveraging the IETF NEA and IETF NETMOD architectures. 565 6.1. IETF NEA EPCP Implementation for Traditional Endpoints 567 When EPCP is used, posture collectors running on the target endpoint 568 gather posture information as changes occur on the endpoint. The 569 data is aggregated by the posture broker client and forwarded to a 570 posture manager, over a secure channel, via the posture transport 571 client. Once received by the posture transport server on the posture 572 manager, the posture information is directed by the posture broker 573 server to the appropriate posture validators where it can be 574 processed and stored in a repository. There the posture information 575 can be used by other tools to carry out assessment tasks. Posture 576 collectors can also be queried by posture validators to refresh 577 posture information about the target endpoint or to ask a specific 578 question about posture information. This is shown in Figure 3. 580 Posture Posture 581 Collection Collection 582 Manager Engine 583 +---------------+ +---------------+ 584 | | | | 585 | +-----------+ | PA-TNC | +-----------+ | 586 | | Posture | |--------| | Posture | | 587 | | Validator | | | | Collector | | 588 | +-----------+ | | +-----------+ | 589 | | | | | | 590 | | IF-IMV | | | IF-IMC | 591 | | | | | | 592 | +-----------+ | PB-TNC | +-----------+ | 593 | | PB Server | |--------| | PB Client | | 594 | +-----------+ | | +-----------+ | 595 | | | | | | 596 | | | | | | 597 | | | | | | 598 | +-----------+ | | +-----------+ | 599 | | PT Server | |<------>| | PT Client | | 600 | +-----------+ | PT-TLS | +-----------+ | 601 | | | | 602 +---------------+ +---------------+ 604 Figure 3: NEA Components 606 These requirements are written with a view to performing a posture 607 assessment on an endpoint; as the EPCP grows and evolves, these 608 requirements will be expanded to address issues that arise. Note 609 that these requirements refer to defined components of the NEA 610 architecture. As with the NEA architecture, vendors have discretion 611 as to how these NEA components map to separate pieces of software or 612 endpoints. 614 It should be noted that the posture broker client and posture 615 transport client components of the posture collection engine and the 616 posture broker server and posture transport server components of the 617 posture collection manager would likely need to be implemented by a 618 single vendor because there are no standardized interfaces between 619 the respective components and would not be interoperable. 621 6.1.1. Endpoint Pre-Provisioning 623 An endpoint is provisioned with a machine certificate that will serve 624 as its unique identifier on the network as well as the components 625 necessary to interact with the posture manager. This includes a 626 posture collection engine to manage requests from the posture manager 627 and the posture collectors necessary to collect the posture 628 information of importance to the enterprise. The endpoint is 629 deployed on the network. 631 The target endpoint SHOULD authenticate to the posture manager using 632 a machine certificate during the establishment of the outer tunnel 633 achieved with the posture transport protocol defined in [RFC6876]. 634 [IF-IMV] specifies how to pull an endpoint identifier out of a 635 machine certificate. An endpoint identifier SHOULD be created in 636 conformance with [IF-IMV] from a machine certificate sent via 637 [RFC6876]. 639 In the future, the identity could be a hardware certificate compliant 640 with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated 641 with the identity of a hardware cryptographic module, in accordance 642 with [IEEE-802-1ar], if present on the endpoint. The enterprise 643 SHOULD stand up a certificate root authority; install its root 644 certificate on endpoints and on the posture manager; and provision 645 the endpoints and the posture manager with machine certificates. The 646 target endpoint MAY authenticate to the posture manager using a 647 combination of the machine account and password; however, this is 648 less secure and not recommended. 650 6.1.2. Endpoint 652 The endpoint MUST conform to [RFC5793], which levies a number of 653 requirements against the endpoint. An endpoint that complies with 654 these requirements will be able to: 656 1. attempt to initiate a session with the posture manager if the 657 posture makes a request to send an update to posture manager; 659 2. notify the posture collector if no PT-TLS session with the 660 posture manager can be created; 662 3. notify the posture collector when a PT-TLS session is 663 established; and 665 4. receive information from the posture collectors, forward this 666 information to the posture manager via the posture collection 667 engine. 669 6.1.2.1. Posture Collector 671 Any posture collector used in an EPCP solution MUST be conformant 672 with [IF-IMC]; an Internet-Draft, under development, that is a subset 673 of the TCG TNC Integrity Measurement Collector interface [IF-IMC] and 674 will be submitted in the near future. 676 6.1.2.2. Posture Broker Client 678 The posture broker client MUST conform to [IF-IMC] to enable 679 communications between the posture broker client and the posture 680 collectors on the endpoint. 682 6.1.2.3. Posture Transport Client 684 The posture transport client MUST implement PT-TLS. 686 The posture transport client MUST support the use of machine 687 certificates for TLS at each endpoint consistent with the 688 requirements stipulated in [RFC6876] and [Server-Discovery]. 690 The posture transport client MUST be able to locate an authorized 691 posture manager, and switch to a new posture manager when required by 692 the network, in conformance with [Server-Discovery]. 694 6.1.3. Posture Manager 696 The posture manager MUST conform to all requirements in the 697 [RFC5793]. 699 6.1.3.1. Posture Validator 701 Any posture validator used in an EPCP solution MUST be conformant 702 with [IF-IMV]; an Internet-Draft, under development, that is a subset 703 of the TCG TNC Integrity Measurement Verifier interface [IF-IMV] and 704 will be submitted in the near future. 706 6.1.3.2. Posture Broker Server 708 The posture broker server MUST conform to [IF-IMV]. Conformance to 709 [IF-IMV] enables the posture broker server to obtain endpoint 710 identity information from the posture transport server, and pass this 711 information to any posture validators on the posture manager. 713 6.1.3.3. Posture Transport Server 715 The posture transport server MUST implement PT-TLS. 717 The posture transport server MUST support the use of machine 718 certificates for TLS at each endpoint consistent with the 719 requirements stipulated in [RFC6876] and [Server-Discovery]. 721 6.1.4. Repository 723 EPCP requires a simple administrative interface for the repository. 724 Posture validators on the posture manager receive the target endpoint 725 posture information via PA-TNC [RFC5792] messages sent from 726 corresponding posture collectors on the target endpoint. The posture 727 validators store this information in the repository linked to the 728 identity of the target endpoint where the posture collectors are 729 located. 731 6.1.5. IETF SACM SWAM Extension to the IETF NEA EPCP Implementation 733 This section defines the requirements associated with the software 734 asset management extension [I-D.ietf-sacm-nea-swima-patnc] to the 735 IETF NEA EPCP implementation. 737 6.1.5.1. Endpoint Pre-Provisioning 739 This section defines the requirements associated with implementing 740 SWIMA. 742 The following requirements assume that the platform or OS vendor 743 supports the use of SWID tags and has identified a standard directory 744 location for the SWID tags to be located as specified by [SWID]. 746 6.1.5.2. SWID Tags 748 The primary content for the EPCP is the information conveyed in the 749 elements of a SWID tag. 751 The endpoint MUST have SWID tags stored in a directory specified in 752 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 753 also be generated by: 755 o the software installer; or 757 o third-party software that creates tags based on the applications 758 it sees installed on the endpoint. 760 The elements in the SWID tag MUST be populated as specified in 761 [SWID]. These tags, and the directory in which they are stored, MUST 762 be updated as software is added, removed, or updated. 764 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 [I-D.ietf-sacm-nea-swima-patnc], which includes requirements for: 770 1. Collecting SWID tags from the SWID directory 772 2. Monitoring the SWID directory for changes 774 3. Initiating a session with the posture manager to report changes 775 to the directory 777 4. Maintaining a list of changes to the SWID directory when updates 778 take place and no PT-TLS connection can be created with the 779 posture manager 781 5. Responding to a request for SWID tags from the SWID Posture 782 Validator on the posture manager 784 6. Responding to a query from the SWID posture validator as to 785 whether all updates have been sent 787 The SWID posture collector is not responsible for detecting that the 788 SWID directory was not updated when an application was either 789 installed or uninstalled. 791 6.1.5.3.2. The SWID Posture Validator 793 Conformance to [I-D.ietf-sacm-nea-swima-patnc] enables the SWID 794 posture validator to: 796 1. Send messages to the SWID posture collector (at the behest of the 797 administrator at the posture manager console) requesting updates 798 for SWID tags located on endpoint 800 2. Ask the SWID posture collector whether all updates to the SWID 801 directory located at the posture manager have been sent 803 3. Compare an endpoint's SWID posture information to policy, and 804 make a recommendation to the posture manager about the endpoint 806 In addition to these requirements, a SWID posture validator used in 807 conformance with this profile MUST be capable of passing information 808 from the posture assessment results and the endpoint identity 809 associated with those results to the repository for storage. 811 6.1.5.4. Repository 813 The administrative interface SHOULD enable an administrator to: 815 1. Query which endpoints have reported SWID tags for a particular 816 application 818 2. Query which SWID tags are installed on an endpoint 820 3. Query tags based on characteristics, such as vendor, publisher, 821 etc. 823 6.2. IETF NETMOD EPCP Implementation for Network Device Endpoints 825 When EPCP is used, a NETCONF client that implements the posture 826 collection manager sends a query to target network device endpoint 827 requesting posture information over a secure channel. Once the 828 NETCONF server on the endpoint receives the request, it queries one 829 or more datastores for the posture information. The NETCONF server 830 then reports the information back to the NETCONF client where it can 831 be stored in a repository for use by other tools. This is shown in 832 Figure 4. 834 Posture Posture 835 Collection Collection 836 Manager Engine 837 +---------------+ +---------------+ 838 | | | | 839 | | | +-----------+ | 840 | | | | Data | | 841 | | | | Store(s) | | 842 | | | +-----------+ | 843 | | | | | 844 | | | | | 845 | +-----------+ | | +-----------+ | 846 | | NETCONF | | | | NETCONF | | 847 | | Client | |<------->| | Server | | 848 | +-----------+ | NETCONF | +-----------+ | 849 | | | | 850 +---------------+ +---------------+ 852 Figure 4: NETMOD Components 854 These requirements are written with a view to performing a posture 855 assessment on network device endpoints (routers, switches, etc.); as 856 the EPCP grows and evolves, these requirements will be expanded to 857 address issues that arise. 859 Note that these requirements refer to defined components of the 860 NETMOD architecture and map back to EPCP. As with the NETMOD 861 architecture, vendors have discretion as to how these NETMOD 862 components map to separate pieces of software or endpoints. 864 6.2.1. Endpoint Pre-Provisioning 866 For the posture manager to be able to query the datastores on the 867 endpoint, the endpoint MUST be configured to grant the posture 868 manager access to its datastores as described in [RFC6241]. The 869 posture manager is identified by its NETCONF username. 871 6.2.2. Posture Manager Pre-Provisioning 873 For the posture manager to be able to query the datastores on the 874 endpoint, the posture manager MUST be provisioned with a NETCONF 875 username that will be used to authenticate the posture manager to the 876 endpoint as described in [RFC6241]. The username generated will be 877 determined by the selected transport protocol. 879 6.2.3. Endpoint 881 An endpoint MUST conform to the requirements outlined for servers in 882 the NETCONF protocol as defined in [RFC6241]. This requires the 883 implementation of NETCONF over SSH [RFC6242]. An endpoint MAY 884 support the NETCONF protocol over other transports such as TLS 885 [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040]. 887 6.2.3.1. Datastore 889 A NETCONF datastore on an endpoint MUST support the operations 890 outlined in [RFC6241], but, the actual implementation of the 891 datastore is left to the endpoint vendor. 893 Datastores MUST support the YANG data modeling language [RFC7950] for 894 expressing endpoint posture information in a structured format. In 895 addition, datastores MAY support other data models such as XML (via 896 YIN) for representing posture information. 898 Datastores MUST support the compliance posture information specified 899 in [RFC7317]. Datastores MAY support other models standardized or 900 proprietary as deemed appropriate by the endpoint vendor. 902 6.2.4. Posture Manager 904 A posture manager MUST conform to the requirements specified for 905 clients in the NETCONF protocol as defined in [RFC6241]. This 906 requires the implementation of NETCONF over SSH [RFC6242]. A posture 907 manager MAY also support the NETCONF protocol over other transports 908 such as TLS [RFC7589]. In addition, a posture manager MAY support 909 the RESTCONF protocol as defined in [RFC8040]. 911 While ad-hoc fetch/polling via NETCONF and RESTCONF is useful for 912 assessing endpoint compliance, such solutions by themselves are not 913 able to detect changes as they occur on the endpoint. As a result, a 914 future revision of this document will support 915 [I-D.ietf-netconf-yang-push] to receive updates on YANG-modeled 916 posture information. Similarly, because not all posture information 917 is modeled in YANG, a future revision of this document will reference 918 [I-D.ietf-netconf-subscribed-notifications] once it is a standard to 919 support continuous streams of unstructured data from the endpoint to 920 the posture manager. 922 6.2.5. Repository 924 EPCP requires a simple administrative interface for the repository. 925 The posture collection manager on the posture manager receives the 926 target endpoint posture information via NETCONF [RFC6241] messages 927 sent from posture collection engine on the target endpoint. The 928 posture collection manager stores this information in the repository 929 linked to the identity of the target endpoint from which it was 930 collected. 932 6.3. Administrative Interface and API 934 An interface is necessary to allow administrators to manage the 935 endpoints and software used in the EPCP. This interface SHOULD be 936 accessible either on or through (as in the case of a remotely hosted 937 interface) the posture manager. Using this interface, an authorized 938 user or administrator SHOULD be able to: 940 o Query the repository 942 o Send commands to the posture collection managers, requesting 943 information from the associated posture collection engines 944 residing on endpoints 946 o Update the policy that resides on the posture manager 948 An API is necessary to allow infrastructure endpoints and software 949 access to the information stored in the repository. Using this API, 950 an authorized endpoint SHOULD be able to: 952 o Query the repository 954 7. EPCP Use Cases 956 The following sections describe the different use cases supported by 957 the EPCP. 959 7.1. Hardware Asset Management 961 Using the administrative interface on the posture manager, an 962 authorized user can learn: 964 o what endpoints are connected to the network at any given time; and 966 o what SWID tags were reported for the endpoints. 968 The ability to answer these questions offers a standards-based 969 approach to asset management, which is a vital part of enterprise 970 processes such as compliance report generation for the Federal 971 Information Security Modernization Act (FISMA), Payment Card Industry 972 Data Security Standard (PCI DSS), Health Insurance Portability and 973 Accountability Act (HIPAA), etc. 975 7.2. Software Asset Management 977 The administrative interface on the posture manager provides the 978 ability for authorized users and infrastructure to know which 979 software is installed on which endpoints on the enterprise's network. 980 This allows the enterprise to answer questions about what software is 981 installed to determine if it is licensed or prohibited. This 982 information can also drive other use cases such as: 984 o vulnerability management: knowing what software is installed 985 supports the ability to determine which endpoints contain 986 vulnerable software and need to be patched. 988 o configuration management: knowing which security controls need to 989 be applied to harden installed software and better protect 990 endpoints. 992 7.3. Vulnerability Searches 994 The administrative interface also provides the ability for authorized 995 users or infrastructure to locate endpoints running software for 996 which vulnerabilities have been announced. Because of 998 1. the unique IDs assigned to each endpoint; and 1000 2. the rich application data provided in the endpoints' posture 1001 information, 1003 the repository can be queried to find all endpoints running a 1004 vulnerable application. Endpoints suspected of being vulnerable can 1005 be addressed by the administrator or flagged for further scrutiny. 1007 7.4. Threat Detection and Analysis 1009 The repository's standardized API allows authorized infrastructure 1010 endpoints and software to search endpoint posture assessment 1011 information for evidence that an endpoint's software inventory has 1012 changed, and can make endpoint software inventory data available to 1013 other endpoints. This automates security data sharing in a way that 1014 expedites the correlation of relevant network data, allowing 1015 administrators and infrastructure endpoints to identify odd endpoint 1016 behavior and configuration using secure, standards-based data models 1017 and protocols. 1019 8. Non-supported Use Cases 1021 Several use cases, including but not limited to these, are not 1022 covered by the EPCP: 1024 o Gathering non-standardized types of posture information: The EPCP 1025 does not prevent administrators from collecting posture 1026 information in proprietary formats from the endpoint; however it 1027 does not set requirements for doing so. 1029 o Solving the lying endpoint problem: The EPCP does not address the 1030 lying endpoint problem; the Profile makes no assertions that it 1031 can catch an endpoint that is, either maliciously or accidentally, 1032 reporting false posture information to the posture manager. 1033 However, other solutions may be able to use the posture 1034 information collected using the capabilities described in this 1035 profile to catch an endpoint in a lie. For example, a sensor may 1036 be able to compare the posture information it has collected on an 1037 endpoint's activity on the network to what the endpoint reported 1038 to the server and flag discrepancies. However, these capabilities 1039 are not described in this profile. 1041 9. Endpoint Posture Collection Profile Examples 1043 The following subsections provide examples of the EPCP as implemented 1044 using components from the NEA architecture. 1046 9.1. Continuous Posture Assessment of an Endpoint 1047 Endpoint Posture Manager 1048 +---------------+ +---------------+ 1049 | | | | 1050 | +-----------+ | | +-----------+ | 1051 | | SWID | | | | SWID | | 1052 | | Posture | | | | Posture | | 1053 | | Collector | | | | Validator | | 1054 | +-----------+ | | +-----------+ | 1055 | | | | | | 1056 | | IF-IMC | | | IF-IMV | 1057 | | | | | | 1058 | +-----------+ | | +-----------+ | 1059 | | PB Client | | | | PB Server | | 1060 | +-----------+ | | +-----------+ | 1061 | | | | | | 1062 | | | | | | 1063 | | | | | | 1064 | +-----------+ | | +-----------+ | 1065 | | PT Client | |<------>| | PT Server | | 1066 | +-----------+ | PT-TLS | +-----------+ | 1067 | | | | 1068 +---------------+ +---------------+ 1070 Figure 5: Continuous Posture Assessment of an Endpoint 1072 9.1.1. Change on Endpoint Triggers Posture Assessment 1074 A new application is installed on the endpoint, and the SWID 1075 directory is updated. This triggers an update from the SWID posture 1076 collector to the SWID posture validator. The message is sent down 1077 the NEA stack, encapsulated by NEA protocols until it is sent by the 1078 posture transport client to the posture transport server. The 1079 posture transport server then forwards it up through the stack, where 1080 the layers of encapsulation are removed until the SWID Message 1081 arrives at the SWID posture validator. 1083 Endpoint Posture Manager 1084 +---------------+ +---------------+ 1085 | | | | 1086 | +-----------+ | | +-----------+ | 1087 | | SWID | | | | SWID | | 1088 | | Posture | | | | Posture | | 1089 | | Collector | | | | Validator | | 1090 | +-----------+ | | +-----------+ | 1091 | | | SWID Message | | | 1092 | | IF-IMC | for PA-TNC | | IF-IMV | 1093 | | | | | | 1094 | +-----------+ | | +-----------+ | 1095 | | PB Client | | | | PB Server | | 1096 | +-----------+ | | +-----------+ | 1097 | | | | | | 1098 | | | PB-TNC {SWID | | | 1099 | | | Message for | | | 1100 | | | PA-TNC} | | | 1101 | +-----------+ | | +-----------+ | 1102 | | PT Client | |<-------------->| | PT Server | | 1103 | +-----------+ | PT-TLS {PB-TNC | +-----------+ | 1104 | | {SWID Message | | 1105 +---------------+ for PA-TNC}} +---------------+ 1107 Figure 6: Compliance Protocol Encapsulation 1109 The SWID posture validator stores the new tag information in the 1110 repository. If the tag indicates that the endpoint is compliant to 1111 the policy, then the process is complete until the next time an 1112 update is needed (either because policy states that the endpoint must 1113 submit posture assessment results periodically or because an 1114 install/uninstall/update on the endpoint triggers a posture 1115 assessment). 1117 Endpoint Posture Manager 1118 +---------------+ +---------------+ 1119 | | | | 1120 | +-----------+ | | +-----------+ | 1121 | | SWID | | | | SWID |-|-+ 1122 | | Posture | | | | Posture | | | 1123 | | Collector | | | | Validator | | | 1124 | +-----------+ | | +-----------+ | | 1125 | | | | | | | Repository 1126 | | IF-IMC | | | IF-IMV | | +--------+ 1127 | | | | | | | | | 1128 | +-----------+ | | +-----------+ | | | | 1129 | | PB Client | | | | PB Server | | +---->| | 1130 | +-----------+ | | +-----------+ | | | 1131 | | | | | | +--------+ 1132 | | | | | | 1133 | | | | | | 1134 | +-----------+ | | +-----------+ | 1135 | | PT Client | |<------>| | PT Server | | 1136 | +-----------+ | PT-TLS | +-----------+ | 1137 | | | | 1138 +---------------+ +---------------+ 1140 Figure 7: Storing SWIDs in the Repository 1142 If the endpoint has fallen out of compliance with a policy, the 1143 posture manager can alert the administrator via the posture manager's 1144 administrative interface. The administrator can then take steps to 1145 address the problem. If the administrator has already established a 1146 policy for automatically addressing this problem, that policy will be 1147 followed. 1149 (") 1150 __|__ 1151 +-->| 1152 Endpoint Posture Manager | / \ 1153 +---------------+ +---------------+ | 1154 | | | | | 1155 | +-----------+ | | +-----------+ | | 1156 | | SWID | | | | SWID |-|-+ 1157 | | Posture | | | | Posture | | 1158 | | Collector | | | | Validator | | 1159 | +-----------+ | | +-----------+ | 1160 | | | | | | Repository 1161 | | IF-IMC | | | IF-IMV | +--------+ 1162 | | | | | | | | 1163 | +-----------+ | | +-----------+ | | | 1164 | | PB Client | | | | PB Server | | | | 1165 | +-----------+ | | +-----------+ | | | 1166 | | | | | | +--------+ 1167 | | | | | | 1168 | | | | | | 1169 | +-----------+ | | +-----------+ | 1170 | | PT Client | |<------>| | PT Server | | 1171 | +-----------+ | PT-TLS | +-----------+ | 1172 | | | | 1173 +---------------+ +---------------+ 1175 Figure 8: Server Alerts Network Admin 1177 9.2. Administrator Searches for Vulnerable Endpoints 1179 An announcement is made that a particular version of a piece of 1180 software has a vulnerability. The administrator uses the 1181 administrative interface on the server to search the repository for 1182 endpoints that reported the SWID tag for the vulnerable software. 1184 (") 1185 __|__ 1186 +-->| 1187 Endpoint Posture Manager | / \ 1188 +---------------+ +---------------+ | 1189 | | | | | 1190 | +-----------+ | | +-----------+ | | 1191 | | SWID | | | | SWID |-|-+ 1192 | | Posture | | | | Posture | | 1193 | | Collector | | | | Validator | | 1194 | +-----------+ | | +-----------+ | 1195 | | | | | | Repository 1196 | | IF-IMC | | | IF-IMV | +--------+ 1197 | | | | | | | | 1198 | +-----------+ | | +-----------+ | | | 1199 | | PB Client | | | | PB Server | |------>| | 1200 | +-----------+ | | +-----------+ | | | 1201 | | | | | | +--------+ 1202 | | | | | | 1203 | | | | | | 1204 | +-----------+ | | +-----------+ | 1205 | | PT Client | |<------>| | PT Server | | 1206 | +-----------+ | PT-TLS | +-----------+ | 1207 | | | | 1208 +---------------+ +---------------+ 1210 Figure 9: Admin Searches for Vulnerable Endpoints 1212 The repository returns a list of entries in the matching the 1213 administrator's search. The administrator can then address the 1214 vulnerable endpoints by taking some follow-up action such as removing 1215 it from the network, quarantining it, or updating the vulnerable 1216 software. 1218 10. Future Work 1220 This section captures ideas for future work related to EPCP that 1221 might be of interest to the IETF SACM WG. These ideas are listed in 1222 no particular order. 1224 o Integrate the IETF NETMOD Yang Push architecture. 1226 o Add support endpoint types beyond workstations, servers, and 1227 network infrastructure devices. 1229 o Examine the integration of [I-D.ietf-mile-xmpp-grid]. 1231 o Define a standard interface and API for interacting with the 1232 repository. Requirements to consider include: creating a secure 1233 channel between a publisher and the repository, creating a secure 1234 channel between a subscriber and the repository, and the types of 1235 interactions that must be supported between publishers and 1236 subscribers to a repository. 1238 o Define a standard interface for communications between the posture 1239 broker client and posture transport client(s) as well as the 1240 posture broker server and posture transport server(s). 1242 o Retention of posture information on the target endpoint. 1244 o Define an orchestrator component as well as publish/subscribe 1245 interface for it. 1247 o Define an evaluator component as well as an interface for it. 1249 11. Acknowledgements 1251 The authors wish to thank all of those in the TCG TNC work group who 1252 contributed to development of the TNC ECP specification upon which 1253 this document is based. 1255 +-----------------------+-------------------------------------------+ 1256 | Member | Organization | 1257 +-----------------------+-------------------------------------------+ 1258 | Padma Krishnaswamy | Battelle Memorial Institute | 1259 | | | 1260 | Eric Fleischman | Boeing | 1261 | | | 1262 | Richard Hill | Boeing | 1263 | | | 1264 | Steven Venema | Boeing | 1265 | | | 1266 | Nancy Cam-Winget | Cisco Systems | 1267 | | | 1268 | Scott Pope | Cisco Systems | 1269 | | | 1270 | Max Pritikin | Cisco Systems | 1271 | | | 1272 | Allan Thompson | Cisco Systems | 1273 | | | 1274 | Nicolai Kuntze | Fraunhofer Institute for Secure | 1275 | | Information Technology (SIT) | 1276 | | | 1277 | Ira McDonald | High North | 1278 | | | 1279 | Dr. Andreas Steffen | HSR University of Applied Sciences | 1280 | | Rapperswil | 1281 | | | 1282 | Josef von Helden | Hochschule Hannover | 1283 | | | 1284 | James Tan | Infoblox | 1285 | | | 1286 | Steve Hanna (TNC-WG | Juniper Networks | 1287 | Co-Chair) | | 1288 | | | 1289 | Cliff Kahn | Juniper Networks | 1290 | | | 1291 | Lisa Lorenzin | Juniper Networks | 1292 | | | 1293 | Atul Shah (TNC-WG Co- | Microsoft | 1294 | Chair) | | 1295 | | | 1296 | Jon Baker | MITRE | 1297 | | | 1298 | Charles Schmidt | MITRE | 1299 | | | 1300 | Rainer Enders | NCP Engineering | 1301 | | | 1302 | Dick Wilkins | Phoenix Technologies | 1303 | | | 1304 | David Waltermire | NIST | 1305 | | | 1306 | Mike Boyle | U.S. Government | 1307 | | | 1308 | Emily Doll | U.S. Government | 1309 | | | 1310 | Jessica Fitzgerald- | U.S. Government | 1311 | McKay | | 1312 | | | 1313 | Mary Lessels | U.S. Government | 1314 | | | 1315 | Chris Salter | U.S. Government | 1316 +-----------------------+-------------------------------------------+ 1318 Table 1: Members of the TNC Work Group that Contributed to the 1319 Document 1321 12. IANA Considerations 1323 This document does not define any new IANA registries. However, this 1324 document does reference other documents that do define IANA 1325 registries. As a result, the IANA Considerations section of the 1326 referenced documents should be consulted. 1328 13. Security Considerations 1330 The EPCP offers substantial improvements in endpoint security, as 1331 evidenced by the Australian Defense Signals Directorate's analysis 1332 that 85% of targeted cyber intrusions can be prevented through 1333 application whitelisting, patching applications and operating 1334 systems, and using the latest versions of applications. [DSD] 1335 Despite these gains, some security risks continue to exist and must 1336 be considered. 1338 To ensure that these benefits and risks are properly understood, this 1339 Security Considerations section includes an analysis of the benefits 1340 provided by the EPCP (Section 13.1), the attacks that may be mounted 1341 against systems that implement the EPCP (Section 13.2), and the 1342 countermeasures that may be used to prevent or mitigate these attacks 1343 (Section 13.3). Overall, a substantial reduction in cyber risk can 1344 be achieved. 1346 13.1. Security Benefits of Endpoint Posture Collection Profile 1348 Security weaknesses of the components for this profile should be 1349 considered in light of the practical considerations that must be 1350 addressed to have a viable solution. 1352 Posture assessment has two parts: assessment and follow-up actions. 1353 The point of posture assessment is to ensure that authorized users 1354 are using authorized software configured to be as resilient as 1355 possible against an attack. 1357 Posture assessment answers the question whether the endpoint is 1358 healthy. Our goal for posture assessment is to make it harder for an 1359 adversary to execute code on one of our endpoints. This profile 1360 represents an important first step in reaching that goal. If we keep 1361 our endpoints healthier, we are able to prevent more attacks on our 1362 endpoints and thus on our information systems. 1364 The goal of EPCP is to address posture assessment in stages. Stage 1 1365 is the ability to ascertain whether all endpoints are authorized and 1366 whether all applications are authorized and up to date. Stage 2 will 1367 attempt to address the harder problem of whether all software is 1368 configured safely. Eventually, the goal is to also address 1369 remediation which is currently out-of-scope for the SACM WG; that 1370 presents a far greater security challenge than reporting, since 1371 remediation implies the ability of a remote party to modify software 1372 or its settings on endpoints. 1374 A second security consideration is how to gain visibility over every 1375 type of endpoint and every piece of software installed on the 1376 endpoint. This is a problem of scaling and observation. A solution 1377 is needed that can report from every type of endpoint. All software 1378 on the endpoint has to be discovered. Information about the software 1379 has to be up to date and accurate. The information that is 1380 discovered has to be reported in a consistent format, so 1381 administrators do not have to squander time deciphering proprietary 1382 systems and the information can be made readily useful for other 1383 security automation purposes. 1385 EPCP is based on a model of a standards-based schema, a standards- 1386 based set of protocols and interfaces, and the existence of an 1387 oversight group, the IETF, that can update the data models and 1388 protocols to meet new use cases and security issues that may be 1389 discovered. 1391 The data elements in the schema determine what work can be done 1392 consistently for every endpoint and every piece of software. How the 1393 data gets populated is an important consideration. EPCP leverages 1394 the SWID tags from ISO 19770-2 because the tag originates with a 1395 single authoritative source, the application vendor itself. 1396 Moreover, there is a natural incentive for the vendor to create this 1397 content, since it makes it easier for enterprises and vendors to 1398 track whether software is licensed. Practical considerations are 1399 security considerations. A sustainable business model for obtaining 1400 all the necessary content is a fundamental requirement. 1402 The NEA implementation of EPCP is based on having a NEA client run on 1403 an endpoint that publishes posture information to a server. The 1404 advantages are easy to list. A platform vendor can implement its own 1405 NEA client and have it be compatible with the NEA server from a 1406 different vendor. The interfaces are layered on top of mature 1407 protocols such as TLS. TLS is the protocol of choice for EPCP, 1408 since: 1410 o it has proven secure properties, 1412 o it can be implemented on most types of endpoints, 1414 o it allows the gathering of large amounts of information when a 1415 endpoint is connected, and 1417 o it enables use of a mechanism to ensure that the client is 1418 authenticated (authorized) - a client certificate - which also 1419 provides a consistent identifier. 1421 Mature protocols that can be implemented on most types of endpoints 1422 and a standards-based schema with a sustainable business model are 1423 both critical security considerations for compliance. 1425 Additionally, it is important to consider the future stages for EPCP 1426 such as a posture assessment being followed up by some action (e.g. 1427 remediation, alert, etc.). Ensuring that clients are taking 1428 instructions only from authorized parties will be critical. Inasmuch 1429 as it is practical, enterprises will want to use the same 1430 infrastructure and investment in PKI to send those instructions to a 1431 client. 1433 Likewise, as more information with more value is gathered from 1434 endpoints, we will also want to ensure that this information is only 1435 released to authorized applications and parties. For the next stage 1436 of EPCP, SACM may want to define an interface on the repository that 1437 can be queried by other security automation applications to make it 1438 easier to detect attacks and for other security automation 1439 applications. This interface has to be standards-based for 1440 enterprises to reap the benefits of innovation that can be achieved 1441 by making the enterprise's data available to other tools and 1442 services. 1444 13.2. Threat Model 1446 This section lists the attacks that can be mounted on a NEA 1447 implementation of an EPCP environment. The following section 1448 (Section 13.3) describes countermeasures. 1450 Because the EPCP describes a specific use case for NEA components, 1451 many security considerations for these components are addressed in 1452 more detail in the technical specifications: 1453 [I-D.ietf-sacm-nea-swima-patnc], [IF-IMC], [RFC5793], 1454 [Server-Discovery], [RFC6876], [IF-IMV]. 1456 13.2.1. Endpoint Attacks 1458 While the EPCP provides substantial improvements in endpoint security 1459 as described in Section 13.1, a certain percentage of endpoints will 1460 always get compromised. For this reason, all parties must regard 1461 data coming from endpoints as potentially unreliable or even 1462 malicious. An analogy can be drawn with human testimony in an 1463 investigation or trial. Human testimony is essential but must be 1464 regarded with suspicion. 1466 o Compromise of endpoint: A compromised endpoint may report false 1467 information to confuse or even provide maliciously crafted 1468 information with a goal of infecting others. 1470 o Putting bad information in SWID directory: Even if an endpoint is 1471 not completely compromised, some of the software running on it may 1472 be unreliable or even malicious. This software, potentially 1473 including the SWID generation or discovery tool, or malicious 1474 software pretending to be a SWID generation or discovery tool, can 1475 place incorrect or maliciously crafted information into the SWID 1476 directory. Endpoint users may even place such information in the 1477 directory, whether motivated by curiosity or confusion or a desire 1478 to bypass restrictions on their use of the endpoint. 1480 o Identity spoofing (impersonation): A compromised endpoint may 1481 attempt to impersonate another endpoint to gain its privileges or 1482 to besmirch the reputation of that other endpoint. 1484 13.2.2. Network Attacks 1486 A variety of attacks can be mounted using the network. Generally, 1487 the network cannot be trusted. 1489 o Eavesdropping, modification, injection, replay, deletion 1491 o Traffic analysis 1493 o Denial of service and blocking traffic 1495 13.2.3. Posture Manager Attacks 1497 The posture manager is a critical security element and therefore 1498 merits considerable scrutiny. 1500 o Compromised trusted manager: A compromised posture manager or a 1501 malicious party that is able to impersonate a posture manager can 1502 incorrectly grant or deny access to endpoints, place incorrect 1503 information into the repository, or send malicious messages to 1504 endpoints. 1506 o Misconfiguration of posture manager: Accidental or purposeful 1507 misconfiguration of a trusted posture manager can cause effects 1508 that are similar to those listed for compromised trusted posture 1509 manager. 1511 o Malicious untrusted posture manager: An untrusted posture manager 1512 cannot mount any significant attacks because all properly 1513 implemented endpoints will refuse to engage in any meaningful 1514 dialog with such a posture manager. 1516 13.2.4. Repository Attacks 1518 The repository is also an important security element and therefore 1519 merits careful scrutiny. 1521 o Putting bad information into trusted repository: An authorized 1522 repository client such as a server may be able to put incorrect 1523 information into a trusted repository or delete or modify 1524 historical information, causing incorrect decisions about endpoint 1525 security. Placing maliciously crafted data in the repository 1526 could even lead to compromise of repository clients, if they fail 1527 to carefully check such data. 1529 o Compromised trusted repository: A compromised trusted repository 1530 or a malicious untrusted repository that is able to impersonate a 1531 trusted repository can lead to effects similar to those listed for 1532 "Putting bad information into trusted repository". Further, a 1533 compromised trusted repository can report different results to 1534 different repository clients or deny access to the repository for 1535 selected repository clients. 1537 o Misconfiguration of trusted repository: Accidental or purposeful 1538 misconfiguration of a trusted repository can deny access to the 1539 repository or result in loss of historical data. 1541 o Malicious untrusted repository: An untrusted repository cannot 1542 mount any significant attacks because all properly implemented 1543 repository clients will refuse to engage in any meaningful dialog 1544 with such a repository. 1546 13.3. Countermeasures 1548 This section lists the countermeasures that can be used in a NEA 1549 implementation of an EPCP environment. 1551 13.3.1. Countermeasures for Endpoint Attacks 1553 This profile is in and of itself a countermeasure for a compromised 1554 endpoint. A primary defense for an endpoint is to run up to date 1555 software configured to be run as safely as possible. 1557 Ensuring that anti-virus signatures are up to date and that a 1558 firewall is configured are also protections for an endpoint that are 1559 supported by the current NEA specifications. 1561 Endpoints that have hardware cryptographic modules that are 1562 provisioned by the enterprise, in accordance with [IEEE-802-1ar], can 1563 protect the private keys used for authentication and help prevent 1564 adversaries from stealing credentials that can be used for 1565 impersonation. Future versions of the EPCP may want to discuss in 1566 greater detail how to use a hardware cryptographic module, in 1567 accordance with [IEEE-802-1ar], to protect credentials and to protect 1568 the integrity of the code that executes during the bootstrap process. 1570 13.3.2. Countermeasures for Network Attacks 1572 To address network attacks, [RFC6876] includes required encryption, 1573 authentication, integrity protection, and replay protection. 1574 [Server-Discovery] also includes authorization checks to ensure that 1575 only authorized servers are trusted by endpoints. Any unspecified or 1576 not yet specified network protocols employed in the EPCP (e.g. the 1577 protocol used to interface with the repository) should include 1578 similar protections. 1580 These protections reduce the scope of the network threat to traffic 1581 analysis and denial of service. Countermeasures for traffic analysis 1582 (e.g. masking) are usually impractical but may be employed. 1583 Countermeasures for denial of service (e.g. detecting and blocking 1584 particular sources) SHOULD be used when appropriate to detect and 1585 block denial of service attacks. These are routine practices in 1586 network security. 1588 13.3.3. Countermeasures for Posture Manager Attacks 1590 Because of the serious consequences of posture manager compromise, 1591 posture managers SHOULD be especially well hardened against attack 1592 and minimized to reduce their attack surface. They SHOULD be 1593 monitored using the NEA protocols to ensure the integrity of the 1594 behavior and analysis data stored on the posture manager and SHOULD 1595 utilize a [IEEE-802-1ar]compliant hardware cryptographic module for 1596 identity and/or integrity measurements of the posture manager. They 1597 should be well managed to minimize vulnerabilities in the underlying 1598 platform and in systems upon which the posture manager depends. 1599 Network security measures such as firewalls or intrusion detection 1600 systems may be used to monitor and limit traffic to and from the 1601 posture manager. Personnel with administrative access to the posture 1602 manager should be carefully screened and monitored to detect problems 1603 as soon as possible. Posture manager administrators should not use 1604 password-based authentication but should instead use non-reusable 1605 credentials and multi-factor authentication (where available). 1606 Physical security measures should be employed to prevent physical 1607 attacks on posture managers. 1609 To ease detection of posture manager compromise should it occur, 1610 posture manager behavior should be monitored to detect unusual 1611 behavior (such as a server reboot, unusual traffic patterns, or other 1612 odd behavior). Endpoints should log and/or notify users and/or 1613 administrators when peculiar posture manager behavior is detected. 1614 To aid forensic investigation, permanent read-only audit logs of 1615 security-relevant information pertaining to posture manager 1616 (especially administrative actions) should be maintained. If posture 1617 manager compromise is detected, the posture manager's certificate 1618 should be revoked and careful analysis should be performed of the 1619 source and impact of this compromise. Any reusable credentials that 1620 may have been compromised should be reissued. 1622 Endpoints can reduce the threat of server compromise by minimizing 1623 the number of trusted posture managers, using the mechanisms 1624 described in [Server-Discovery]. 1626 13.3.4. Countermeasures for Repository Attacks 1628 If the host for the repository is located on its own endpoint, it 1629 should be protected with the same measures taken to protect the 1630 posture manager. In this circumstance, all messages between the 1631 posture manager and repository should be protected with a mature 1632 security protocol such as TLS or IPsec. 1634 The repository can aid in the detection of compromised endpoints if 1635 an adversary cannot tamper with its contents. For instance, if an 1636 endpoint reports that it does not have an application with a known 1637 vulnerability installed, an administrator can check whether the 1638 endpoint might be lying by querying the repository for the history of 1639 what applications were installed on the endpoint. 1641 To help prevent tampering with the information in the repository: 1643 1. Only authorized parties should have privilege to run code on the 1644 endpoint and to change the repository. 1646 2. If a separate endpoint hosts the repository, then the 1647 functionality of that endpoint should be limited to hosting the 1648 repository. The firewall on the repository should only allow 1649 access to the posture manager and to any endpoint authorized for 1650 administration. 1652 3. The repository should ideally use "write once" media to archive 1653 the history of what was placed in the repository, to include a 1654 snapshot of the current status of applications on endpoints. 1656 14. Privacy Considerations 1658 The EPCP specifically addresses the collection of posture data from 1659 enterprise endpoints by an enterprise network. As such, privacy is 1660 not going to often arise as a concern for those deploying this 1661 solution. 1663 A possible exception may be the concerns a user may have when 1664 attempting to connect a personal endpoint (such as a phone or mobile 1665 endpoint) to an enterprise network. The user may not want to share 1666 certain details, such as an endpoint identifier or SWID tags, with 1667 the enterprise. The user can configure their NEA client to reject 1668 requests for this information; however, it is possible that the 1669 enterprise policy will not allow the user's endpoint to connect to 1670 the network without providing the requested data. 1672 15. Change Log 1674 15.1. -01 to -02 1676 Addressed various comments from the SACM WG. 1678 Added a section for the collection of posture information from 1679 network devices using standards from the NETMOD WG. 1681 Updated EPCP component diagrams so they were not specific to a NEA- 1682 based implementation. 1684 Updated EPCP NEA example diagrams to reflect all the components in 1685 the NEA architecture. 1687 15.2. -00 to -01 1689 There are no textual changes associated with this revision. This 1690 revision simply reflects a resubmission of the document so that it 1691 remains in active status. 1693 15.3. -01 to -02 1695 Added references to the Software Inventory Message and Attributes 1696 (SWIMA) for PA-TNC I-D. 1698 Replaced references to PC-TNC with IF-IMC. 1700 Removed erroneous hyphens from a couple of section titles. 1702 Made a few minor editorial changes. 1704 15.4. -02 to -00 1706 Draft adopted by IETF SACM WG. 1708 15.5. -00 to -01 1710 Significant edits to up-level the draft to describe SACM collection 1711 over multiple different protocols. 1713 Replaced references to SANS with CIS. 1715 Made other minor editorial changes. 1717 16. References 1719 16.1. Informative References 1721 [CIS] http://www.cisecurity.org/controls/, "CIS Critical 1722 Security Controls". 1724 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1725 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1726 Protect Your ICT System", November 2012. 1728 [IEEE-802-1ar] 1729 Institute of Electrical and Electronics Engineers, "IEEE 1730 802.1ar", December 2009. 1732 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1733 Tardo, "Network Endpoint Assessment (NEA): Overview and 1734 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1735 . 1737 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1738 Architecture for Interoperability, Version 1.5", February 1739 2012. 1741 16.2. Normative References 1743 [I-D.ietf-mile-xmpp-grid] 1744 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 1745 "Using XMPP for Security Information Exchange", draft- 1746 ietf-mile-xmpp-grid-04 (work in progress), October 2017. 1748 [I-D.ietf-netconf-subscribed-notifications] 1749 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1750 A. Tripathy, "Customized Subscriptions to a Publisher's 1751 Event Streams", draft-ietf-netconf-subscribed- 1752 notifications-13 (work in progress), June 2018. 1754 [I-D.ietf-netconf-yang-push] 1755 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1756 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1757 Subscription", draft-ietf-netconf-yang-push-12 (work in 1758 progress), December 2017. 1760 [I-D.ietf-sacm-nea-swima-patnc] 1761 Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1762 J. Fitzgerald-McKay, "Software Inventory Message and 1763 Attributes (SWIMA) for PA-TNC", draft-ietf-sacm-nea-swima- 1764 patnc-01 (work in progress), September 2017. 1766 [I-D.ietf-sacm-terminology] 1767 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1768 Winget, "Terminology for Security Assessment", draft-ietf- 1769 sacm-terminology-05 (work in progress), August 2014. 1771 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1772 IF-IMC, Version 1.3", February 2013. 1774 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1775 IF-IMV, Version 1.4", December 2014. 1777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1778 Requirement Levels", BCP 14, RFC 2119, 1779 DOI 10.17487/RFC2119, March 1997, 1780 . 1782 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1783 (PA) Protocol Compatible with Trusted Network Connect 1784 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1785 . 1787 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1788 A Posture Broker (PB) Protocol Compatible with Trusted 1789 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1790 March 2010, . 1792 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1793 and A. Bierman, Ed., "Network Configuration Protocol 1794 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1795 . 1797 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1798 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1799 . 1801 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1802 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1803 DOI 10.17487/RFC6876, February 2013, 1804 . 1806 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1807 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1808 2014, . 1810 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1811 NETCONF Protocol over Transport Layer Security (TLS) with 1812 Mutual X.509 Authentication", RFC 7589, 1813 DOI 10.17487/RFC7589, June 2015, 1814 . 1816 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 1817 Posture Assessment: Enterprise Use Cases", RFC 7632, 1818 DOI 10.17487/RFC7632, September 2015, 1819 . 1821 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1822 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1823 . 1825 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1826 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1827 . 1829 [Server-Discovery] 1830 Trusted Computing Group, "DRAFT: TCG Trusted Network 1831 Connect PDP Discovery and Validation, Version 1.0", 1832 October 2015. 1834 [SWID] "Information technology--Software asset management--Part 1835 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1837 Authors' Addresses 1839 Danny Haynes 1840 The MITRE Corporation 1841 202 Burlington Road 1842 Bedford, MA 01730 1843 USA 1845 Email: dhaynes@mitre.org 1846 Jessica Fitzgerald-McKay 1847 Department of Defense 1848 9800 Savage Road 1849 Ft. Meade, Maryland 1850 USA 1852 Email: jmfitz2@nsa.gov 1854 Lisa Lorenzin 1855 Pulse Secure 1856 2700 Zanker Rd., Suite 200 1857 San Jose, CA 95134 1858 US 1860 Email: llorenzin@pulsesecure.net