idnits 2.17.1 draft-haynes-sacm-ecp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2016) is 2965 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) == Missing Reference: 'SWID-Message-for-PA-TNC' is mentioned on line 820, but not defined == 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: 2 errors (**), 0 flaws (~~), 3 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: September 8, 2016 Department of Defense 6 L. Lorenzin 7 Pulse Secure 8 March 7, 2016 10 Endpoint Compliance Profile 11 draft-haynes-sacm-ecp-00 13 Abstract 15 This document specifies the Endpoint Compliance Profile, a high-level 16 specification that describes a specific combination and application 17 of NEA and TNC protocols and interfaces specifically designed to 18 support ongoing assessment of endpoint posture and the controlled 19 exposure of collected posture information to appropriate security 20 applications. This document is a subset of the Trusted Computing 21 Group's Endpoint 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 http://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 September 8, 2016. 40 Copyright Notice 42 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Preventative Posture Assessments . . . . . . . . . . . . 4 59 1.2. Standardized Schema . . . . . . . . . . . . . . . . . . . 4 60 1.3. Secure Standardized Protocols . . . . . . . . . . . . . . 5 61 1.4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Endpoint Compliance Profile . . . . . . . . . . . . . . . . . 7 64 3.1. Posture Assessments . . . . . . . . . . . . . . . . . . . 7 65 3.2. Data Storage . . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Follow-up Actions . . . . . . . . . . . . . . . . . . . . 8 67 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Purpose of the Endpoint Compliance Profile . . . . . . . 8 69 4.2. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8 70 4.2.1. Connected-and-Compliant . . . . . . . . . . . . . . . 8 71 4.2.2. Exposing Data to the Network . . . . . . . . . . . . 10 72 4.2.2.1. Asset Management . . . . . . . . . . . . . . . . 12 73 4.2.2.2. Vulnerability Searches . . . . . . . . . . . . . 12 74 4.2.2.3. Threat Detection and Analysis . . . . . . . . . . 12 75 4.2.3. Non-supported Use Cases . . . . . . . . . . . . . . . 12 76 4.2.4. Profile Requirements . . . . . . . . . . . . . . . . 13 77 4.2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . 14 78 5. Endpoint Compliance Requirements . . . . . . . . . . . . . . 16 79 5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . . . 17 80 5.1.1. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 17 81 5.1.2. Endpoint Identity and Machine Certificate . . . . . . 17 82 5.2. Posture Validators and Posture Collectors . . . . . . . . 17 83 5.2.1. SWID-Posture-Collectors-and-Posture-Validators . . . 18 84 5.2.1.1. The-SWID-Posture-Collector . . . . . . . . . . . 18 85 5.2.1.2. The SWID Posture Validator . . . . . . . . . . . 18 86 5.3. NEA Client (NEAC) and NEA Server (NEAS) . . . . . . . . . 19 87 5.3.1. NEAC . . . . . . . . . . . . . . . . . . . . . . . . 19 88 5.3.2. NEAS . . . . . . . . . . . . . . . . . . . . . . . . 19 89 5.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 19 90 6. Posture Transport Client (PTC) and Posture Transport Server 91 (PTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 7. Administrative Interface and API . . . . . . . . . . . . . . 20 93 8. Endpoint Compliance Profile Examples . . . . . . . . . . . . 21 94 8.1. Continuous Posture Assessment of an Endpoint . . . . . . 21 95 8.1.1. Change on Endpoint Triggers Posture Assessment . . . 22 96 8.2. Administrator Searches for Vulnerable Endpoints . . . . . 24 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 99 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 11.1. Security Benefits of Endpoint Compliance Profile . . . . 27 102 11.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 29 103 11.2.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 30 104 11.2.2. Network Attacks . . . . . . . . . . . . . . . . . . 30 105 11.2.3. Server Attacks . . . . . . . . . . . . . . . . . . . 30 106 11.2.4. Repository Attacks . . . . . . . . . . . . . . . . . 31 107 11.3. Countermeasures . . . . . . . . . . . . . . . . . . . . 31 108 11.3.1. Countermeasures for Endpoint Attacks . . . . . . . . 31 109 11.3.2. Countermeasures for Network Attacks . . . . . . . . 32 110 11.3.3. Countermeasures for Server Attacks . . . . . . . . . 32 111 11.3.4. Countermeasures for Repository Attacks . . . . . . . 33 112 12. Privacy-Considerations . . . . . . . . . . . . . . . . . . . 34 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 114 13.1. Informative References . . . . . . . . . . . . . . . . . 34 115 13.2. Normative References . . . . . . . . . . . . . . . . . . 34 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 118 1. Introduction 120 The IETF NEA WG has defined an open architecture for network 121 security, including standard protocols for endpoint posture 122 assessment. The Endpoint Compliance Profile (ECP) builds on the NEA 123 protocols, along with complementary interfaces from the Trusted 124 Network Communications (TNC) WG of the Trusted Computing Group [TNC], 125 to determine the posture of any type of endpoint on a network 126 including user endpoints, servers, and infrastructure. The first 127 generation of this specification focuses on reducing the security 128 exposure of a network by confirming that all network-connected 129 endpoints are: 131 o known and authorized 133 o running applications that are known and authorized 135 o running applications that are patched and up-to-date; and, 137 o applications with known vulnerabilities can be located and patched 139 When ECP is used, posture information is gathered by the NEA Client 140 (NEAC) running on the endpoint and is forwarded to the NEA Server 141 (NEAS), which stores it in a repository. This information is 142 gathered while the endpoint is already connected to the network. 143 Administrators will query the repository to determine the compliance 144 status of an endpoint. For example, if a vulnerability is discovered 145 in a product, an administrator may query the repository to determine 146 which endpoints have the vulnerable software installed and thus 147 require some follow-up action. 149 Future versions of the ECP may want to address how to expose 150 information--such as endpoint purpose, the software that is supposed 151 to be running on an endpoint, and the activities an endpoint is 152 supposed to be performing--to sensors that are looking for indicators 153 of attacks and malicious activity on the network. 155 1.1. Preventative Posture Assessments 157 The value of continuous endpoint posture assessment is well 158 established. Security experts have for years identified software 159 updating and patching as a critical step for preventing intrusions. 160 Application white listing, patching applications and operating 161 systems, and using the latest versions of applications top the 162 Defense Signals Directorate's "Top 4 Mitigations to Protect Your ICT 163 System". [DSD] "Inventory of Authorized and Unauthorized Endpoints", 164 "Inventory of Authorized and Unauthorized Software", and "Continuous 165 Vulnerability Assessment and Remediation" are Critical Controls 1, 2, 166 and 4, respectively, of the SANS "20 Critical Security Controls". 167 [SANS] While there are commercially available solutions that attempt 168 to address these security controls, these solutions do not run on all 169 types of endpoints; consistently interoperate with other tools that 170 could make use of the data collected; collect posture information 171 from all types of endpoints in a consistent, standardized schema; or 172 require vetted, standardized protocols that have been evaluated by 173 the international community for cryptographic soundness. 175 As is true of most solutions offered today, the solution found in the 176 ECP does not attempt to solve the lying endpoint problem. An 177 endpoint that has already been infected with malicious software can 178 provide false information about its identity and the software it is 179 running. The primary purpose of the ECP is not to detect infected 180 endpoints; rather, it focuses on ensuring that healthy endpoints 181 remain healthy by keeping software up-to-date and patched. The first 182 goal of the ECP is to help an administrator be able to readily 183 determine which endpoints require some follow-up action. Future 184 versions of the ECP may want to address how to expose posture 185 information to sensors to aid the detection of attacks on endpoints 186 and drive follow-up actions. 188 1.2. Standardized Schema 190 The ECP requires the use of standardized schema for the exchange of 191 posture information. This helps to ensure that the posture 192 information sent from endpoints to the repository can be easily 193 stored, due to their known format, and shared with authorized 194 endpoints and users. Standardized schema also enable collection from 195 myriad types of endpoints. Such standardization saves implementers 196 time and money--time that does not have to be spent integrating new 197 schema into the enterprise's reporting mechanisms, and money that 198 does not have to be spent on developing tools to parse information 199 from each type of endpoint connected to the network. Standardized 200 schema also enable the development of standardized client software. 201 This allows endpoint vendors to include their own client software 202 that can interoperate with posture assessment infrastructure and thus 203 not have to introduce third party code in their products. 205 1.3. Secure Standardized Protocols 207 Posture information must be sent over mature, standardized protocols 208 to ensure the confidentiality and authenticity of this data while in 209 transit. The ECP requires use of the NEA PT-TLS protocol [RFC6876] 210 for communication between the endpoint and the server. This protocol 211 allows networks that implement this solution to collect large amounts 212 of posture information from an endpoint in order to make decisions 213 about that endpoint's compliance to some policy. This Profile offers 214 a solution for all endpoints already connected to the network. 215 Periodic assessments and automated reporting of changes to installed 216 software allow for instantaneous identification of connected 217 endpoints that are no longer compliant to some policy. 219 The IETF NEA WG has designed an architecture to support endpoint 220 posture assessment. Figure 1 illustrates the architectural 221 components used in the Endpoint Compliance Profile: 223 Endpoint Server 224 +---------------+ +---------------+ 225 | | | | 226 | +-----------+ | | +-----------+ | 227 | | SWID | | | | SWID | | 228 | | Posture | | | | Posture | | 229 | | Collector | | | | Validator | | 230 | +-----------+ | | +-----------+ | 231 | | | | | | 232 | | PC-TNC | | | IF-IMV | Repository 233 | | | | | | +--------+ 234 | +-----------+ | | +-----------+ | | | 235 | | PB Client | | | | PB Server | |---->| | 236 | +-----------+ | | +-----------+ | | | 237 | | | | | | | | 238 | | | | | | +--------+ 239 | | | | | | 240 | +-----------+ | | +-----------+ | 241 | | PT Client | |<------>| | PT Server | | 242 | +-----------+ | PT-TLS | +-----------+ | 243 | | | | 244 +---------------+ +---------------+ 246 Figure 1: The Endpoint Compliance Architecture 248 Note that the SWID Posture Collector and SWID Posture Validator are 249 implementations of NEA's Posture Collector (PC) and Posture Validator 250 (PV) architectural components, respectively. Requirements for each 251 of the components in the diagram above are contained in this profile. 252 The reader should consult [RFC5209] for additional information on 253 these components. All current repository requirements are contained 254 within the Endpoint Compliance Profile. 256 1.4. Keywords 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in [RFC2119]. This 261 specification does not distinguish blocks of informative comments and 262 normative requirements. Therefore, for the sake of clarity, note 263 that lower case instances of must, should, etc. do not indicate 264 normative requirements. 266 2. Terminology 268 This document uses terms as defined in [I-D.ietf-sacm-terminology] 269 unless otherwise specified. 271 3. Endpoint Compliance Profile 273 The Endpoint Compliance Profile describes how NEA and TNC 274 specifications can be used to support the posture assessment of 275 endpoints on a network. This profile does not generate new schema or 276 protocols; rather, it offers a full end-to-end solution for posture 277 assessment, as well as a fresh perspective on how existing standards 278 can be leveraged against vulnerabilities. 280 3.1. Posture Assessments 282 The Endpoint Compliance Profile 1.0 describes how NEA and TNC 283 specifications make it possible to perform posture assessments 284 against all network-connected endpoints by: 286 1. uniquely identifying the endpoint; 288 2. collecting and assessing posture based on data from the endpoint; 290 3. creating a secure, authenticated, confidential channel between 291 the endpoint and the server; 293 4. enabling the endpoint to notify the server about changes to its 294 configuration; 296 5. enabling the server to request information about the 297 configuration of the endpoint; and 299 6. storing the posture information in a repository linked to the 300 identifier for the endpoint. 302 3.2. Data Storage 304 The ISO/IEC Software Identification Tag standard [SWID] has defined a 305 schema for identifying applications installed on endpoints and their 306 patch status. The Endpoint Compliance Profile 1.0 focuses on being 307 able to collect this information from an endpoint and store it in a 308 repository. This makes posture information from a network's 309 endpoints available to authorized parties. Uses of this data are 310 innumerable--vulnerability management, asset management, software 311 asset management, and configuration management solutions, analytics 312 tools, endpoints that need to make connectivity decisions, and 313 metrics reporting scripts, among others, are all able to reference 314 the data stored in the repository to achieve their purposes. 316 3.3. Follow-up Actions 318 The ability of the endpoint to notify the server whenever a 319 modification is made to the endpoint enables immediate identification 320 of endpoints that fall out of compliance. The Endpoint Compliance 321 Profile 1.0 does not specify requirements for how these endpoints 322 should be addressed. However, the TNC specifications do support the 323 ability to send instructions that drive access control enforcement 324 decisions for a non-compliant endpoint. Additional information about 325 the types of follow-up actions an enterprise may want to support can 326 be found in [RFC7632]. 328 There is a clear need for nuanced, automated instructions sent from 329 the server to the endpoint (for example, to update an endpoint's 330 software, or remove a piece of non-compliant software). Those 331 messages are complicated to define and may have to be tailored to a 332 particular operating system. Future versions of this specification 333 may want to address which instructions can be defined based on the 334 configuration content that is collected from endpoints. 336 4. Background 338 4.1. Purpose of the Endpoint Compliance Profile 340 The Endpoint Compliance Profile describes a standard way to 341 communicate endpoint posture information such as software identity 342 and software version and to make it available to other authorized 343 parties. The Endpoint Compliance Profile 1.0 focuses on collecting 344 the application information available in SWID tags, as specified in 345 [SWID]. Future versions of the Endpoint Compliance Profile could 346 describe how additional types of posture information can be collected 347 and communicated in a standardized way. 349 4.2. Supported Use Cases 351 The Endpoint Compliance Profile focuses on the posture assessment of 352 enterprise endpoints on enterprise networks. Use cases supported by 353 the Endpoint Compliance Profile 1.0 are as follows: 355 4.2.1. Connected-and-Compliant 357 A network-connected endpoint sends posture information using standard 358 schemas such as SWID over NEA protocols. 360 Endpoint Server 361 +-------------------+ +---------------+ 362 | | | | 363 | +-------+ | | +-----------+ | 364 | | SWIDs | | | | SWID | | 365 | +-------+ | | | Posture | | 366 | | | | | Validator | | 367 | | | | +-----------+ | 368 | | +-----------+ | | | | 369 | +->| SWID | | | | | 370 | | Posture | | | | | 371 | | Collector | | | | | 372 | +-----------+ | | | | 373 | | | | | | 374 | | PC-TNC | | | IF-IMV | Repository 375 | | | | | | +--------+ 376 | +-----------+ | | +-----------+ | | | 377 | | PB Client | | | | PB Server | |---->| | 378 | +-----------+ | | +-----------+ | | | 379 | | | | | | | | 380 | +----------+ | | | | | +--------+ 381 | | Endpoint | | | | | | 382 | | ID | | | | | | 383 | +----------+ | | | | | 384 | | | | | | | 385 | | +-----------+ | | +-----------+ | 386 | +->| PT Client | |<------>| | PT Server | | 387 | +-----------+ | PT-TLS | +-----------+ | 388 | | | | 389 +-------------------+ +---------------+ 391 Figure 2: Connected and Compliant Use Case 393 1. If necessary, the endpoint finds and validates the server in 394 compliance with [Server-Discovery]. 396 2. The Posture Transport Client (PTC) on the endpoint and Posture 397 Transport Server (PTS) on the server complete a TLS handshake, 398 during which endpoint identity information is exchanged. 400 3. Either the NEA Server (NEAS) on the server or the NEA Client 401 (NEAC) on the endpoint initiates a posture assessment. Checks 402 may be triggered for multiple reasons, including: 404 (a) policy states that a previous assessment has aged out and 405 become invalid; 407 (b) the NEAC notices that the relevant posture information on 408 the endpoint has changed, (for example, due to application 409 updates, deletions or additions); or 411 (c) the NEAS is alerted by a sensor or an administrator (via the 412 server's user interface) that an assessment must be 413 completed. 415 All information exchanges between the PCs and PVs are subject to 416 the enterprise's policy, which may limit the content or size of 417 information sent between the endpoint and the server. 419 4. The SWID Posture Collector on the endpoint collects from the SWID 420 tag directory on the endpoint. This data is sent via the NEAC 421 and PTC to the server. 423 5. Once the posture information is received by the PTS, it is 424 forwarded to the SWID Posture Validator via the NEAS. The SWID 425 Posture Validator also forwards the posture information to the 426 repository. The posture information is stored along with past 427 posture information collected about the endpoint. 429 4.2.2. Exposing Data to the Network 431 Because the endpoint posture information was sent in a standards- 432 based schema (ISO/IEC 19770-2:2009) over secure, standardized 433 protocols, and the SWID tags are stored in a centralized repository 434 linked to unique endpoint identifiers, authorized parties are able to 435 access the posture information. Such authorized parties may include, 436 but are not limited to, administrators or endpoint owners (via the 437 server's administrative interface), and other pieces of 438 infrastructure that can make use of this data (via the server's API). 439 The server will provide: 441 o a standard administrative interface that allows data sharing with 442 authorized parties; 444 o a standard API that allows data sharing with authorized 445 infrastructure and software; 447 o a persistent account of endpoints that have connected to the 448 network over a period of time set by the administrator; 450 o the identities provided by those endpoints; and 452 o what SWIDs were reported by the endpoint. 454 The endpoint will publish updates as its local SWID directory 455 changes, as well as each time it disconnects and reconnects to the 456 network. 458 Endpoint Server 459 +--------------------+ +---------------+ 460 | | | | 461 | +-------+ | | +-----------+ | 462 | | SWIDs | | | | SWID | | 463 | +-------+ | | | Posture | | 464 | | | | | Validator | | 465 | | | | +-----------+ | 466 | | +-----------+ | | | | 467 | +->| SWID | | | | | 468 | | Posture | | | | | 469 | | Collector | | | | | 470 | +-----------+ | | | | 471 | | | | | | 472 | | PC-TNC | | | IF-IMV | Repository 473 | | | | | | +--------+ 474 | +-----------+ | | +-----------+ | | | 475 | | PB Client | | | | PB Server | |---->| | 476 | +-----------+ | | +-----------+ | | | 477 | | | | | | | | 478 | +----------+ | | | | | +--------+ 479 | | Endpoint | | | | | | 480 | | ID | | | | | | 481 | +----------+ | | | | | 482 | | | | | | | 483 | | +-----------+ | | +-----------+ | 484 | +->| PT Client | |<------>| | PT Server | | 485 | +-----------+ | PT-TLS | +-----------+ | 486 | | | | 487 +--------------------+ +---------------+ 488 +----------------------------------+ 489 | Administrative Interface and API | 490 +----------------------------------+ 492 Figure 3: Exposing Data to the Network 494 It should be noted that the neither the Endpoint Compliance Profile 495 nor the protocols, interfaces, and data models that it references 496 provide solutions to the server capabilities listed above. However, 497 these capabilities are useful and solutions for them should be 498 pursued in the future. 500 4.2.2.1. Asset Management 502 Using the administrative interface on the server, an authorized user 503 can learn: 505 o what endpoints are connected to the network at any given time; and 507 o what SWID tags were reported for the endpoints. 509 The ability to answer these questions offers a standards-based 510 approach to asset management, which is a vital part of enterprise 511 processes such as compliance report generation for the Federal 512 Information Security Modernization Act (FISMA), Payment Card Industry 513 Data Security Standard (PCI DSS), Health Insurance Portability and 514 Accountability Act (HIPAA), etc. 516 4.2.2.2. Vulnerability Searches 518 The administrative interface also provides the ability for authorized 519 users or infrastructure to locate endpoints running software for 520 which vulnerabilities have been announced. Because of 522 1. the unique IDs assigned to each endpoint; and 524 2. the rich application data provided in the endpoints' posture 525 information, 527 the repository can be queried to find all endpoints running a 528 vulnerable application. Endpoints suspected of being vulnerable can 529 be addressed by the administrator or flagged for further scrutiny. 531 4.2.2.3. Threat Detection and Analysis 533 The repository's standardized API allows authorized infrastructure 534 endpoints and software to search endpoint posture assessment 535 information for evidence that an endpoint's software inventory has 536 changed, and can make endpoint software inventory data available to 537 other endpoints. This automates security data sharing in a way that 538 expedites the correlation of relevant network data, allowing 539 administrators and infrastructure endpoints to identify odd endpoint 540 behavior and configuration using secure, standards-based schema and 541 protocols. 543 4.2.3. Non-supported Use Cases 545 Several use cases, including but not limited to these, are not 546 covered by the Endpoint Compliance Profile 1.0: 548 o Gathering other types of posture information: The Endpoint 549 Compliance Profile does not prevent administrators from collecting 550 other types of posture information other than SWIDs from the 551 endpoint; however it does not set requirements for doing so. 553 o Solving the lying endpoint problem: The Endpoint Compliance 554 Profile does not address the lying endpoint problem; the Profile 555 makes no assertions that it can catch an endpoint that is, either 556 maliciously or accidentally, reporting false posture information 557 to the server. However, other solutions may be able to use the 558 posture information collected using the capabilities described in 559 this profile to catch an endpoint in a lie. For example, a sensor 560 may be able to compare the posture information it has collected on 561 an endpoint's activity on the network to what the endpoint 562 reported to the server and flag discrepancies. However, these 563 particular capabilities are not described in this profile. 565 o Publish/subscribe repository interface: Future versions of the 566 Endpoint Compliance Profile may specify a publish/subscribe 567 interface for the repository, so infrastructure endpoint can 568 subscribe to and receive published posture assessment results from 569 the repository regarding endpoint configuration changes. However, 570 the Endpoint Compliance Profile 1.0 includes no such requirements. 572 4.2.4. Profile Requirements 574 Here are the requirements that the Endpoint Compliance Profile 575 protocol must meet in order to successfully fit in the SACM 576 architecture. 578 o Meets the needs of the SACM architecture: The Endpoint Compliance 579 Profile must support the use cases described in [RFC7632] as they 580 apply to endpoint self-reporting and endpoint posture assessment. 582 o Efficient: To minimize user frustration, it is essential to 583 minimize delays by making endpoint posture information collection, 584 transmission, and assessment as brief and efficient as possible. 586 o Extensible: The Endpoint Compliance Profile needs to expand over 587 time as new features are added to the SACM architecture. The 588 solution must allow new features to be added easily, providing for 589 a smooth transition and allowing newer and older architectural 590 components to continue to work together. Further, the Endpoint 591 Compliance Profile and the specifications referenced here must 592 define safe extensibility mechanisms that enable innovation 593 without breaking interoperability. 595 o Easy to implement: The Endpoint Compliance Profile should be easy 596 for vendors to implement in their products, and should result in 597 products that are easy for administrators to implement on their 598 networks. Products conformant to the Endpoint Compliance Profile 599 should interoperate seamlessly, and be simple to integrate into 600 existing network infrastructure. 602 o Easy to use: The Endpoint Compliance Profile should describe a 603 simple, integrated user interface that administrators can use to 604 perform the activities listed in the profile's use cases. The 605 Endpoint Compliance Profile should not constrain innovation by 606 specifying details of the user interface but rather functional 607 requirements. 609 o Platform-independent: Since network environments may contain many 610 different types of endpoints, the solution should operate 611 independently of the endpoint platform. 613 o Scalable: The Endpoint Compliance Profile must be designed to 614 scale to very large numbers of endpoints. 616 4.2.5. Assumptions 618 Here are the assumptions that the Endpoint Compliance Profile makes 619 about other components in the SACM architecture. 621 o Existence of a server and repository: The Endpoint Compliance 622 Profile assumes that a server and repository exist. 624 o Endpoint SWID installation: The Endpoint Compliance Profile 625 assumes that an endpoint has been pre-provisioned with Software 626 Identification Tags for its applications, and that these SWID tags 627 are formatted and stored in conformance with [SWID]. 629 o Certificate provisioning: In order to implement the most secure 630 endpoint identification option, the Endpoint Compliance Profile 631 assumes that the enterprise has set up a certificate root 632 authority, and has provisioned each endpoint with an endpoint 633 identification certificate. This is not required if an enterprise 634 chooses to use other endpoint authentication methods. 636 In addition, the Endpoint Compliance Profile makes the following 637 assumptions about the SACM ecosystem: 639 o All network-connected endpoints are endpoints: As defined by 640 [I-D.ietf-sacm-terminology], an endpoint is any physical or 641 virtual computing endpoint that can be connected to a network. 642 Posture assessment against policy is equally, if not more, 643 important for continuously connected endpoints, such as enterprise 644 workstations and infrastructure endpoints, as it is for 645 sporadically connected endpoints. Continuously connected 646 endpoints are just as likely to fall out of compliance with 647 policy, and a standardized posture assessment method is necessary 648 to ensure they can be properly handled. 650 o All endpoints on the network must be uniquely identified: Many 651 administrators struggle to identify what endpoints are connected 652 at any given time. By requiring a standardized method of endpoint 653 identity, the Endpoint Compliance Profile will enable 654 administrators to answer the basic question, "What is on my 655 network?" Unique endpoint identification also enables the 656 comparison of current and past endpoint posture assessments, by 657 allowing administrators to correlate assessments from the same 658 endpoint. This makes it easier to flag suspicious changes in 659 endpoint posture for manual or automatic review, and helps to 660 swiftly identify malicious changes to endpoint applications. 662 o Posture assessments must occur over secure, standardized 663 protocols: Endpoint identity and application information is very 664 valuable, both to administrators and to attackers. Therefore, it 665 must be kept confidential, using secure protocols to transport it 666 from the endpoint to network infrastructure endpoints. 667 Additionally, it is critical that only authorized parties be 668 capable of requesting information, receiving information, or 669 taking action to change an endpoint's connectivity status. 670 Relying on standardized protocols to provide this security enables 671 greater interoperability and compatibility between endpoints, and 672 allows for the development of compliance testing to ensure that 673 each endpoint operates securely and in conformance with 674 appropriate specifications. A standards body provides a process 675 for experts in protocols and cryptography to evaluate the 676 soundness of protocols and security management procedures; a set 677 of security standards allows an enterprise to make the most 678 effective use of their investment in a security management 679 infrastructure. 681 o Posture assessment results must be formatted using standardized 682 schema: Well-known, standard schema allow for a universal language 683 for generating compliance reports. With each endpoint speaking 684 the same language, the Endpoint Compliance Profile enables 685 information sharing between user endpoints and infrastructure 686 endpoints, and between infrastructure endpoints that perform 687 different security tasks. 689 o Posture information must be stored by the repository and must be 690 exposed to an interface at the server: A standard schema enables 691 standard queries from an interface exposed to an administrator at 692 the server console. A repository must retain any current posture 693 information retrieved from the endpoint and store it indexed by 694 the unique identifier for the endpoint. Any PV specified by this 695 profile must be able to ascertain from its corresponding PC 696 whether the posture information is up to date. An interface on 697 the server must support a request to the PV to obtain up-to-date 698 information when an endpoint is connected. This interface must 699 also support the ability to make a standard set of queries about 700 the posture information stored by the repository. In the future, 701 some forms of posture information might be retained at the 702 endpoint. The interface on the server must accommodate the 703 ability to make a request through the PV to the corresponding PC 704 about the posture of the endpoint. Standard schema and protocols 705 also enable the security of posture assessment results. By 706 storing these results indexed under the endpoint's unique 707 identification, secure storage itself enables endpoint posture 708 information correlation, and ensures that the enterprise's 709 Repositories always offer the freshest, most up-to-date view of 710 the enterprise's endpoint posture information possible. 712 o Posture information can be shared: By exposing posture information 713 using a standard interface and API, other security and operational 714 components have a high level of insight into the enterprise's 715 endpoints and the software installed on them. This will support 716 innovation in the areas of asset management, vulnerability 717 scanning, and administrative interfaces, as any authorized 718 infrastructure endpoint can interact with the posture information. 720 o Owners and administrators must have complete control of posture 721 information, policy, and endpoint mitigation: Enterprise asset 722 posture information belongs to the enterprise. Standardized 723 schema, protocols and interfaces help to ensure that this posture 724 information is not locked in proprietary databases, but is made 725 available to its owners. This enables administrators to develop 726 as nuanced a policy as necessary to keep their networks secure. 728 5. Endpoint Compliance Requirements 730 These requirements are written with a view to performing a posture 731 assessment on an endpoint; as the Endpoint Compliance Profile grows 732 and evolves, these requirements will be expanded to address issues 733 that arise. Note that these requirements refer to defined components 734 of the NEA architecture. As with the NEA architecture, implementers 735 have discretion as to how these NEA components map to separate pieces 736 of software or endpoints. 738 5.1. Endpoint Pre-Provisioning 740 The following requirements assume that the platform or OS vendor 741 supports the use of SWID tags and has identified a standard directory 742 location for the SWID tags to be located as specified by [SWID]. 744 5.1.1. SWID Tags 746 The primary content for the Endpoint Compliance Profile 1.0 is the 747 information conveyed in the elements of a SWID tag. 749 The endpoint MUST have SWID tags stored in a directory specified in 750 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 751 also be generated by: 753 o the software installer; or 755 o third-party software that creates tags based on the applications 756 it sees installed on the endpoint. 758 The elements in the SWID tag MUST be populated as specified in 759 [SWID]. These tags, and the directory in which they are stored, MUST 760 be updated as software is added, removed, or updated. 762 5.1.2. Endpoint Identity and Machine Certificate 764 The endpoint SHOULD authenticate to the server using a machine 765 certificate during the establishment of the outer tunnel achieved 766 with PT. [IF-IMV] specifies how to pull an endpoint ID out of a 767 machine certificate. An endpoint ID SHOULD be created in conformance 768 with [IF-IMV] from a machine certificate sent via [RFC6876]. 770 In the future, the identity could be a hardware certificate compliant 771 with [IEEE-802-1ar]; ideally, this ID SHOULD be associated with the 772 identity of a hardware cryptographic module, in accordance with 773 [IEEE-802-1ar], if present on the endpoint. The enterprise SHOULD 774 stand up a certificate root authority; install its root certificate 775 on endpoints and on the server; and provision the endpoints and the 776 server with machine certificates. The endpoint MAY authenticate to 777 the server using a combination of the machine account and password; 778 however, this is less secure and not recommended. 780 5.2. Posture Validators and Posture Collectors 782 Any PC used in an Endpoint Compliance Profile solution MUST be 783 conformant with PC-TNC; an Internet-Draft, under development, that is 784 a subset of the TCG TNC Integrity Measurement Collector interface 785 [IF-IMC] and will be submitted in the near future. Any Posture 786 Validator used in an Endpoint Compliance Profile solution MUST be 787 conformant with [IF-IMV]. 789 5.2.1. SWID-Posture-Collectors-and-Posture-Validators 791 5.2.1.1. The-SWID-Posture-Collector 793 For the Endpoint Compliance Profile, the SWID Posture Collector MUST 794 be conformant with [SWID-Message-for-PA-TNC], which includes 795 requirements for: 797 1. Collecting SWID tags from the SWID directory 799 2. Monitoring the SWID directory for changes 801 3. Initiating a session with the server to report changes to the 802 directory 804 4. Maintaining a list of changes to the SWID directory when updates 805 take place and no PT-TLS connection can be created with the 806 server 808 5. Responding to a request for SWID tags from the SWID Posture 809 Validator on the server 811 6. Responding to a query from the SWID Posture Validator as to 812 whether all updates have been sent 814 The SWID Posture Collector is not responsible for detecting that the 815 SWID directory was not updated when an application was either 816 installed or uninstalled. 818 5.2.1.2. The SWID Posture Validator 820 Conformance to [SWID-Message-for-PA-TNC] enables the SWID Posture 821 Validator to: 823 1. Send messages to the SWID Posture Collector (at the behest of the 824 administrator at the server console) requesting updates for SWID 825 tags located on endpoint 827 2. Ask the SWID Posture Collector whether all updates to the SWID 828 directory located at the server have been sent 830 3. Compare an endpoint's SWID posture information to policy, and 831 make a recommendation to the NEAS about the endpoint 833 In addition to these requirements, a SWID Posture Validator used in 834 conformance with this profile MUST be capable of passing information 835 from the posture assessment results and the endpoint identity 836 associated with those results to the repository for storage. 838 5.3. NEA Client (NEAC) and NEA Server (NEAS) 840 [RFC5793] describes a standard way for the NEAC and the NEAS to 841 exchange messages. 843 5.3.1. NEAC 845 The NEAC MUST conform to [RFC5793], which levies a number of 846 requirements against the NEAC. A NEAC that complies with these 847 requirements will be able to: 849 1. attempt to initiate a session with the NEAS if the SWID Posture 850 Collector makes a request to send an update to the SWID directory 851 to the server; 853 2. notify the SWID Posture Collector if no PT-TLS session with the 854 server can be created; 856 3. notify the SWID Posture Collector when a PT-TLS session is 857 established; and 859 4. receive information from the PCs, forward this information to the 860 server via the PTC. 862 The NEAC MUST also conform to PC-TNC to enable communications with 863 the SWID Posture Collector. 865 5.3.2. NEAS 867 The NEAS MUST conform to all requirements in the [RFC5793] and 868 [IF-IMV] specifications. Conformance to [IF-IMV] enables the NEAS to 869 obtain endpoint identity information from the PTS, and pass this 870 information to any IMVs on the server. 872 5.4. Repository 874 ECP 1.0 requires a simple administrative interface for the 875 repository. PVs on the server receive the endpoint data via PA-TNC 876 [RFC5792] messages sent from corresponding PCs on an endpoint and 877 store this information in the repository linked to the identity of 878 the endpoint where the PCs are located. 880 The administrative interface SHOULD enable an administrator to: 882 1. Query which endpoints have reported SWID tags for a particular 883 application 885 2. Query which SWID tags are installed on a particular endpoint 887 3. Query tags based on characteristics, such as vendor, publisher, 888 etc. 890 In the future, if SACM decides to develop an interface to the 891 repository server, it should consider requirements for: 893 1. Creating a secure channel between a publisher and the repository 895 2. Creating a secure channel between a subscriber and the repository 897 3. The types of interactions that must be supported between 898 publishers and subscribers to a repository 900 6. Posture Transport Client (PTC) and Posture Transport Server (PTS) 902 The PT-TLS protocol provides a transport service for carrying the PB- 903 TNC protocol messages between the endpoint and the server. 905 The PTC and PTS MUST implement PT-TLS, since a connection is needed 906 that: 908 o Can handle large volumes of data, which might require multiple 909 roundtrips, to be sent while the endpoint is connected 911 o Allows either the NEAC or NEAS to initiate a connection 913 o Supports secure transport based on machine certificates at both 914 ends of the connection 916 The PTC and PTS MUST support the use of machine certificates for TLS 917 at each endpoint consistent with the requirements stipulated in 918 [RFC6876] and [Server-Discovery]. 920 The PTC MUST be able to locate an authorized server, and switch to a 921 new server when required by the network, in conformance with 922 [Server-Discovery]. 924 7. Administrative Interface and API 926 An interface is necessary to allow administrators to manage the 927 endpoints and software used in the Endpoint Compliance Profile. This 928 interface SHOULD be accessible either on or through (as in the case 929 of a remotely hosted interface) the server. Using this interface, an 930 authorized user or administrator SHOULD be able to: 932 o Query the repository 934 o Send commands to the PVs, requesting information from the 935 associated PCs residing on network endpoints 937 o Update the policy that resides on the server 939 An API is necessary to allow infrastructure endpoints and software 940 access to the information stored in the repository. Using this API, 941 an authorized endpoint SHOULD be able to: 943 o Query the repository 945 8. Endpoint Compliance Profile Examples 947 8.1. Continuous Posture Assessment of an Endpoint 949 Endpoint Server 950 +---------------+ +---------------+ 951 | | | | 952 | +-----------+ | | +-----------+ | 953 | | SWID | | | | SWID | | 954 | | Posture | | | | Posture | | 955 | | Collector | | | | Validator | | 956 | +-----------+ | | +-----------+ | 957 | | | | | | 958 | | PC-TNC | | | IF-IMV | 959 | | | | | | 960 | +-----------+ | | +-----------+ | 961 | | PB Client | | | | PB Server | | 962 | +-----------+ | | +-----------+ | 963 | | | | | | 964 | | | | | | 965 | | | | | | 966 | +-----------+ | | +-----------+ | 967 | | PT Client | |<------>| | PT Server | | 968 | +-----------+ | PT-TLS | +-----------+ | 969 | | | | 970 +---------------+ +---------------+ 972 Figure 4: Continuous Posture Assessment of an Endpoint 974 8.1.1. Change on Endpoint Triggers Posture Assessment 976 A new application is installed on the endpoint, and the SWID 977 directory is updated. This triggers an update from the SWID Posture 978 Collector to the SWID Posture Validator. The message is sent down 979 the NEA stack, encapsulated by NEA protocols until it is sent by the 980 PTC to the PTS. The PTS then forwards it up through the stack, where 981 the layers of encapsulation are removed until the SWID Message 982 arrives at the SWID Posture Validator. 984 Endpoint Server 985 +---------------+ +---------------+ 986 | | | | 987 | +-----------+ | | +-----------+ | 988 | | SWID | | | | SWID | | 989 | | Posture | | | | Posture | | 990 | | Collector | | | | Validator | | 991 | +-----------+ | | +-----------+ | 992 | | | SWID Message | | | 993 | | PC-TNC | for PA-TNC | | IF-IMV | 994 | | | | | | 995 | +-----------+ | | +-----------+ | 996 | | PB Client | | | | PB Server | | 997 | +-----------+ | | +-----------+ | 998 | | | | | | 999 | | | PB-TNC {SWID | | | 1000 | | | Message for | | | 1001 | | | PA-TNC | | | 1002 | +-----------+ | | +-----------+ | 1003 | | PT Client | |<-------------->| | PT Server | | 1004 | +-----------+ | PT-TLS {PB-TNC | +-----------+ | 1005 | | {SWID Message | | 1006 +---------------+ for PA-TNC}} +---------------+ 1008 Figure 5: Compliance Protocol Encapsulation 1010 The SWID Posture Validator stores the new tag information in the 1011 repository. If the tag indicates that the endpoint is compliant to 1012 the policy, then the process is complete until the next time an 1013 update is needed (either because policy states that the endpoint must 1014 submit posture assessment results periodically or because an 1015 install/uninstall/update on the endpoint triggers a posture 1016 assessment). 1018 Endpoint Server 1019 +---------------+ +---------------+ 1020 | | | | 1021 | +-----------+ | | +-----------+ | 1022 | | SWID | | | | SWID |-|-+ 1023 | | Posture | | | | Posture | | | 1024 | | Collector | | | | Validator | | | 1025 | +-----------+ | | +-----------+ | | 1026 | | | | | | | Repository 1027 | | PC-TNC | | | IF-IMV | | +--------+ 1028 | | | | | | | | | 1029 | +-----------+ | | +-----------+ | | | | 1030 | | PB Client | | | | PB Server | | +---->| | 1031 | +-----------+ | | +-----------+ | | | 1032 | | | | | | +--------+ 1033 | | | | | | 1034 | | | | | | 1035 | +-----------+ | | +-----------+ | 1036 | | PT Client | |<------>| | PT Server | | 1037 | +-----------+ | PT-TLS | +-----------+ | 1038 | | | | 1039 +---------------+ +---------------+ 1041 Figure 6: Storing SWIDs in the Repository 1043 If the endpoint has fallen out of compliance with a policy, the 1044 server can alert the administrator via the server's administrative 1045 interface. The administrator can then take steps to address the 1046 problem. If the administrator has already established a policy for 1047 automatically addressing this problem, that policy will be followed. 1049 (") 1050 __|__ 1051 +-->| 1052 Endpoint Server | / \ 1053 +---------------+ +---------------+ | 1054 | | | | | 1055 | +-----------+ | | +-----------+ | | 1056 | | SWID | | | | SWID |-|-+ 1057 | | Posture | | | | Posture | | 1058 | | Collector | | | | Validator | | 1059 | +-----------+ | | +-----------+ | 1060 | | | | | | Repository 1061 | | PC-TNC | | | IF-IMV | +--------+ 1062 | | | | | | | | 1063 | +-----------+ | | +-----------+ | | | 1064 | | PB Client | | | | PB Server | | | | 1065 | +-----------+ | | +-----------+ | | | 1066 | | | | | | +--------+ 1067 | | | | | | 1068 | | | | | | 1069 | +-----------+ | | +-----------+ | 1070 | | PT Client | |<------>| | PT Server | | 1071 | +-----------+ | PT-TLS | +-----------+ | 1072 | | | | 1073 +---------------+ +---------------+ 1075 Figure 7: Server Alerts Network Admin 1077 8.2. Administrator Searches for Vulnerable Endpoints 1079 An announcement is made that a particular version of a piece of 1080 software has a vulnerability. The administrator uses the 1081 Administrative Interface on the server to search the repository for 1082 endpoints that reported the SWID tag for the vulnerable software. 1084 (") 1085 __|__ 1086 +-->| 1087 Endpoint Server | / \ 1088 +---------------+ +---------------+ | 1089 | | | | | 1090 | +-----------+ | | +-----------+ | | 1091 | | SWID | | | | SWID |-|-+ 1092 | | Posture | | | | Posture | | 1093 | | Collector | | | | Validator | | 1094 | +-----------+ | | +-----------+ | 1095 | | | | | | Repository 1096 | | PC-TNC | | | IF-IMV | +--------+ 1097 | | | | | | | | 1098 | +-----------+ | | +-----------+ | | | 1099 | | PB Client | | | | PB Server | |------>| | 1100 | +-----------+ | | +-----------+ | | | 1101 | | | | | | +--------+ 1102 | | | | | | 1103 | | | | | | 1104 | +-----------+ | | +-----------+ | 1105 | | PT Client | |<------>| | PT Server | | 1106 | +-----------+ | PT-TLS | +-----------+ | 1107 | | | | 1108 +---------------+ +---------------+ 1110 Figure 8: Admin Searches for Vulnerable Endpoints 1112 The repository returns a list of entries in the matching the 1113 administrator's search. The administrator can then address the 1114 vulnerable endpoints by taking some follow-up action such as removing 1115 it from the network, quarantining it, or updating the vulnerable 1116 software. 1118 9. Acknowledgements 1120 The authors wish to thank all of those in the TCG TNC work group who 1121 contributed to development of the TNC ECP specification upon which 1122 this document is based. 1124 +-----------------------+-------------------------------------------+ 1125 | Member | Organization | 1126 +-----------------------+-------------------------------------------+ 1127 | Padma Krishnaswamy | Battelle Memorial Institute | 1128 | | | 1129 | Eric Fleischman | Boeing | 1130 | | | 1131 | Richard Hill | Boeing | 1132 | | | 1133 | Steven Venema | Boeing | 1134 | | | 1135 | Nancy Cam-Winget | Cisco Systems | 1136 | | | 1137 | Scott Pope | Cisco Systems | 1138 | | | 1139 | Max Pritikin | Cisco Systems | 1140 | | | 1141 | Allan Thompson | Cisco Systems | 1142 | | | 1143 | Nicolai Kuntze | Fraunhofer Institute for Secure | 1144 | | Information Technology (SIT) | 1145 | | | 1146 | Ira McDonald | High North | 1147 | | | 1148 | Dr. Andreas Steffen | HSR University of Applied Sciences | 1149 | | Rapperswil | 1150 | | | 1151 | Josef von Helden | Hochschule Hannover | 1152 | | | 1153 | James Tan | Infoblox | 1154 | | | 1155 | Steve Hanna (TNC-WG | Juniper Networks | 1156 | Co-Chair) | | 1157 | | | 1158 | Cliff Kahn | Juniper Networks | 1159 | | | 1160 | Lisa Lorenzin | Juniper Networks | 1161 | | | 1162 | Atul Shah (TNC-WG Co- | Microsoft | 1163 | Chair) | | 1164 | | | 1165 | Jon Baker | MITRE | 1166 | | | 1167 | Charles Schmidt | MITRE | 1168 | | | 1169 | Rainer Enders | NCP Engineering | 1170 | | | 1171 | Dick Wilkins | Phoenix Technologies | 1172 | | | 1173 | David Waltermire | NIST | 1174 | | | 1175 | Mike Boyle | U.S. Government | 1176 | | | 1177 | Emily Doll | U.S. Government | 1178 | | | 1179 | Jessica Fitzgerald- | U.S. Government | 1180 | McKay | | 1181 | | | 1182 | Mary Lessels | U.S. Government | 1183 | | | 1184 | Chris Salter | U.S. Government | 1185 +-----------------------+-------------------------------------------+ 1187 Table 1: Members of the TNC that Contributed to the Document 1189 10. IANA Considerations 1191 This document does not define any new IANA registries. However, this 1192 document does reference other documents that do define IANA 1193 registries. As a result, the IANA Considerations section of the 1194 referenced documents should be consulted. 1196 11. Security Considerations 1198 The Endpoint Compliance Profile offers substantial improvements in 1199 endpoint security, as evidenced by the Australian Defense Signals 1200 Directorate's analysis that 85% of targeted cyber intrusions can be 1201 prevented through application white listing, patching applications 1202 and operating systems, and using the latest versions of applications. 1203 [DSD] Despite these gains, some security risks continue to exist and 1204 must be considered. 1206 To ensure that these benefits and risks are properly understood, this 1207 Security Considerations section includes an analysis of the benefits 1208 provided by the Endpoint Compliance Profile (Section 11.1), the 1209 attacks that may be mounted against systems that implement the 1210 Endpoint Compliance Profile (Section 11.2), and the countermeasures 1211 that may be used to prevent or mitigate these attacks (Section 11.3). 1212 Overall, a substantial reduction in cyber risk can be achieved. 1214 11.1. Security Benefits of Endpoint Compliance Profile 1216 Security weaknesses of the components for this profile should be 1217 considered in light of the practical considerations that must be 1218 addressed to have a viable solution. 1220 Posture assessment has two parts: assessment and follow-up actions. 1221 The point of posture assessment is to ensure that authorized users 1222 are using authorized software configured to be as resilient as 1223 possible against an attack. 1225 Posture assessment answers the question whether the endpoint is 1226 healthy. Our goal for posture assessment is to make it harder for an 1227 adversary to execute code on one of our endpoints. This profile 1228 represents an important first step in reaching that goal. If we keep 1229 our endpoints healthier, we are able to prevent more attacks on our 1230 endpoints and thus on our information systems. 1232 The goal of ECP is to address posture assessment in stages. Stage 1 1233 is the ability to ascertain whether all endpoints are authorized and 1234 whether all applications are authorized and up to date. Stage 2 will 1235 attempt to address the harder problem of whether all software is 1236 configured safely. Eventually, the goal is to also address 1237 remediation which is currently out-of-scope for the SACM WG; that 1238 presents a far greater security challenge than reporting, since 1239 remediation implies the ability of a remote party to modify software 1240 or its settings on endpoints. 1242 A second security consideration is how to gain visibility over every 1243 type of endpoint and every piece of software installed on the 1244 endpoint. This is a problem of scaling and observation. A solution 1245 is needed that can report from every type of endpoint. All software 1246 on the endpoint has to be discovered. Information about the software 1247 has to be up to date and accurate. The information that is 1248 discovered has to be reported in a consistent format, so 1249 administrators do not have to squander time deciphering proprietary 1250 systems and the information can be made readily useful for other 1251 security automation purposes. 1253 ECP is based on a model of a standards-based schema, a standards- 1254 based set of protocols and interfaces, and the existence of an 1255 oversight group, the IETF, that can update the schemas and protocols 1256 to meet new use cases and security issues that may be discovered. 1258 The data elements in the schema determine what work can be done 1259 consistently for every endpoint and every piece of software. How the 1260 data gets populated is an important consideration. ECP leverages the 1261 SWID tags from ISO 19770-2 because the tag originates with a single 1262 authoritative source, the application vendor itself. Moreover, there 1263 is a natural incentive for the vendor to create this content, since 1264 it makes it easier for enterprises and vendors to track whether 1265 software is licensed. Practical considerations are security 1266 considerations. A sustainable business model for obtaining all the 1267 necessary content is a fundamental requirement. 1269 The NEA model is based on having a NEAC run on an endpoint that 1270 publishes posture information to a server. The advantages are easy 1271 to list. A platform vendor can implement its own NEAC and have it be 1272 compatible with the NEAS from a different vendor. The interfaces are 1273 layered on top of mature protocols such as TLS. TLS is the protocol 1274 of choice for ECP, since: 1276 o it has proven secure properties, 1278 o it can be implemented on most types of endpoints, 1280 o it allows the gathering of large amounts of information when a 1281 endpoint is connected, and 1283 o it enables use of a mechanism to ensure that the client is 1284 authenticated (authorized) - a client certificate - which also 1285 provides a consistent identifier. 1287 Mature protocols that can be implemented on most types of endpoints 1288 and a standards-based schema with a sustainable business model are 1289 both critical security considerations for compliance. 1291 Additionally, it is important to consider the future stages for ECP 1292 such as a posture assessment being followed up by some action (e.g. 1293 remediation, alert, etc.). Ensuring that clients are taking 1294 instructions only from authorized parties will be critical. Inasmuch 1295 as it is practical, enterprises will want to use the same 1296 infrastructure and investment in PKI to send those instructions to a 1297 client. 1299 Likewise, as more information with more value is gathered from 1300 endpoints, we will also want to ensure that this information is only 1301 released to authorized applications and parties. For the next stage 1302 of ECP, SACM may want to define an interface on the repository that 1303 can be queried by other security automation applications to make it 1304 easier to detect attacks and for other security automation 1305 applications. This interface has to be standards-based for 1306 enterprises to reap the benefits of innovation that can be achieved 1307 by making the enterprise's data available to other tools and 1308 services. 1310 11.2. Threat Model 1312 This section lists the attacks that can be mounted on an Endpoint 1313 Compliance Profile environment. The following section (Section 11.3) 1314 describes countermeasures. 1316 Because the Endpoint Compliance Profile describes a specific use case 1317 for NEA components, many security considerations for these components 1318 are addressed in more detail in the technical specifications: [SWID- 1319 Message-for-PA-TNC], PC-TNC, [RFC5793], [Server-Discovery], 1320 [RFC6876], [IF-IMV]. 1322 11.2.1. Endpoint Attacks 1324 While the Endpoint Compliance Profile provides substantial 1325 improvements in endpoint security as described in Section 11.1, a 1326 certain percentage of endpoints will always get compromised. For 1327 this reason, all parties must regard data coming from endpoints as 1328 potentially unreliable or even malicious. An analogy can be drawn 1329 with human testimony in an investigation or trial. Human testimony 1330 is essential but must be regarded with suspicion. 1332 o Compromise of endpoint: A compromised endpoint may report false 1333 information to confuse or even provide maliciously crafted 1334 information with a goal of infecting others. 1336 o Putting bad information in SWID directory: Even if an endpoint is 1337 not completely compromised, some of the software running on it may 1338 be unreliable or even malicious. This software, potentially 1339 including the SWID generation or discovery tool, or malicious 1340 software pretending to be a SWID generation or discovery tool, can 1341 place incorrect or maliciously crafted information into the SWID 1342 directory. Endpoint users may even place such information in the 1343 directory, whether motivated by curiosity or confusion or a desire 1344 to bypass restrictions on their use of the endpoint. 1346 o Identity spoofing (impersonation): A compromised endpoint may 1347 attempt to impersonate another endpoint to gain its privileges or 1348 to besmirch the reputation of that other endpoint. 1350 11.2.2. Network Attacks 1352 A variety of attacks can be mounted using the network. Generally, 1353 the network cannot be trusted. 1355 o Eavesdropping, modification, injection, replay, deletion 1357 o Traffic analysis 1359 o Denial of service and blocking traffic 1361 11.2.3. Server Attacks 1363 The server is a critical security element and therefore merits 1364 considerable scrutiny. 1366 o Compromised trusted server: A compromised server or a malicious 1367 party that is able to impersonate a server can incorrectly grant 1368 or deny access to endpoints, place incorrect information into the 1369 repository, or send malicious messages to endpoints 1371 o Misconfiguration of trusted server: Accidental or purposeful 1372 misconfiguration of a trusted server can cause effects that are 1373 similar to those listed for compromised trusted server. 1375 o Malicious untrusted server: An untrusted server cannot mount any 1376 significant attacks because all properly implemented endpoints 1377 will refuse to engage in any meaningful dialog with such a server. 1379 11.2.4. Repository Attacks 1381 The repository is also an important security element and therefore 1382 merits careful scrutiny. 1384 o Putting bad information into trusted repository: An authorized 1385 repository client such as a server may be able to put incorrect 1386 information into a trusted repository or delete or modify 1387 historical information, causing incorrect decisions about endpoint 1388 security. Placing maliciously crafted data in the repository 1389 could even lead to compromise of repository clients, if they fail 1390 to carefully check such data. 1392 o Compromised trusted repository: A compromised trusted repository 1393 or a malicious untrusted repository that is able to impersonate a 1394 trusted repository can lead to effects similar to those listed for 1395 "Putting bad information into trusted repository". Further, a 1396 compromised trusted repository can report different results to 1397 different repository clients or deny access to the repository for 1398 selected repository clients. 1400 o Misconfiguration of trusted repository: Accidental or purposeful 1401 misconfiguration of a trusted repository can deny access to the 1402 repository or result in loss of historical data. 1404 o Malicious untrusted repository: An untrusted repository cannot 1405 mount any significant attacks because all properly implemented 1406 repository clients will refuse to engage in any meaningful dialog 1407 with such a repository. 1409 11.3. Countermeasures 1411 This section lists the countermeasures that can be used in an 1412 Endpoint Compliance Profile environment. 1414 11.3.1. Countermeasures for Endpoint Attacks 1416 This profile is in and of itself a countermeasure for a compromised 1417 endpoint. A primary defense for an endpoint is to run up to date 1418 software configured to be run as safely as possible. 1420 Ensuring that anti-virus signatures are up to date and that a 1421 firewall is configured are also protections for an endpoint that are 1422 supported by the current NEA specifications. 1424 Endpoints that have hardware cryptographic modules that are 1425 provisioned by the enterprise, in accordance with [IEEE-802-1ar], can 1426 protect the private keys used for authentication and help prevent 1427 adversaries from stealing credentials that can be used for 1428 impersonation. Future versions of the Endpoint Compliance Profile 1429 may want to discuss in greater detail how to use a hardware 1430 cryptographic module, in accordance with [IEEE-802-1ar], to protect 1431 credentials and to protect the integrity of the code that executes 1432 during the bootstrap process. 1434 11.3.2. Countermeasures for Network Attacks 1436 To address network attacks, [RFC6876] includes required encryption, 1437 authentication, integrity protection, and replay protection. 1438 [Server-Discovery] also includes authorization checks to ensure that 1439 only authorized servers are trusted by endpoints. Any unspecified or 1440 not yet specified network protocols employed in the Endpoint 1441 Compliance Profile (e.g. the protocol used to interface with the 1442 repository) should include similar protections. 1444 These protections reduce the scope of the network threat to traffic 1445 analysis and denial of service. Countermeasures for traffic analysis 1446 (e.g. masking) are usually impractical but may be employed. 1447 Countermeasures for denial of service (e.g. detecting and blocking 1448 particular sources) SHOULD be used when appropriate to detect and 1449 block denial of service attacks. These are routine practices in 1450 network security. 1452 11.3.3. Countermeasures for Server Attacks 1454 Because of the serious consequences of server compromise, servers 1455 SHOULD be especially well hardened against attack and minimized to 1456 reduce their attack surface. They SHOULD be monitored using the NEA 1457 protocols to ensure the integrity of the behavior and analysis data 1458 stored on the server and SHOULD utilize a [IEEE-802-1ar] compliant 1459 hardware cryptographic module for identity and/or integrity 1460 measurements of the server. They should be well managed to minimize 1461 vulnerabilities in the underlying platform and in systems upon which 1462 the server depends. Network security measures such as firewalls or 1463 intrusion detection systems may be used to monitor and limit traffic 1464 to and from the server. Personnel with administrative access to the 1465 server should be carefully screened and monitored to detect problems 1466 as soon as possible. Server administrators should not use password- 1467 based authentication but should instead use non-reusable credentials 1468 and multi-factor authentication (where available). Physical security 1469 measures should be employed to prevent physical attacks on servers. 1471 To ease detection of server compromise should it occur, server 1472 behavior should be monitored to detect unusual behavior (such as a 1473 server reboot, unusual traffic patterns, or other odd behavior). 1474 Endpoints should log and/or notify users and/or administrators when 1475 peculiar server behavior is detected. To aid forensic investigation, 1476 permanent read-only audit logs of security-relevant information 1477 pertaining to servers (especially administrative actions) should be 1478 maintained. If server compromise is detected, the server's 1479 certificate should be revoked and careful analysis should be 1480 performed of the source and impact of this compromise. Any reusable 1481 credentials that may have been compromised should be reissued. 1483 Endpoints can reduce the threat of server compromise by minimizing 1484 the number of trusted servers, using the mechanisms described in 1485 [Server-Discovery]. 1487 11.3.4. Countermeasures for Repository Attacks 1489 If the host for the repository is located on its own endpoint, it 1490 should be protected with the same measures taken to protect the 1491 server. In this circumstance, all messages between the server and 1492 repository should be protected with a mature security protocol such 1493 as TLS or IPsec. 1495 The repository can aid in the detection of compromised endpoints if 1496 an adversary cannot tamper with its contents. For instance, if an 1497 endpoint reports that it does not have an application with a known 1498 vulnerability installed, an administrator can check whether the 1499 endpoint might be lying by querying the repository for the history of 1500 what applications were installed on the endpoint. 1502 To help prevent tampering with the information in the repository: 1504 1. Only authorized parties should have privilege to run code on the 1505 endpoint and to change the repository. 1507 2. If a separate endpoint hosts the repository, then the 1508 functionality of that endpoint should be limited to hosting the 1509 repository. The firewall on the repository should only allow 1510 access to the server and to any endpoint authorized for 1511 administration. 1513 3. The repository should ideally use "write once" media to archive 1514 the history of what was placed in the repository, to include a 1515 snapshot of the current status of applications on endpoints. 1517 12. Privacy-Considerations 1519 The Endpoint Compliance Profile specifically addresses the collection 1520 of posture data from enterprise endpoints by an enterprise network. 1521 As such, privacy is not going to often arise as a concern for those 1522 deploying this solution. 1524 A possible exception may be the concerns a user may have when 1525 attempting to connect a personal endpoint (such as a phone or mobile 1526 endpoint) to an enterprise network. The user may not want to share 1527 certain details, such as an endpoint identifier or SWID tags, with 1528 the enterprise. The user can configure their NEAC to reject requests 1529 for this information; however, it is possible that the enterprise 1530 policy will not allow the user's endpoint to connect to the network 1531 without providing the requested data. 1533 13. References 1535 13.1. Informative References 1537 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1538 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1539 Protect Your ICT System", November 2012. 1541 [IEEE-802-1ar] 1542 Institute of Electrical and Electronics Engineers, "IEEE 1543 802.1ar", December 2009. 1545 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1546 Tardo, "Network Endpoint Assessment (NEA): Overview and 1547 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1548 . 1550 [SANS] http://www.sans.org/critical-security-controls/, "CIS 1551 Critical Security Controls". 1553 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1554 Architecture for Interoperability, Version 1.5", February 1555 2012. 1557 13.2. Normative References 1559 [I-D.ietf-sacm-terminology] 1560 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1561 Winget, "Terminology for Security Assessment", draft-ietf- 1562 sacm-terminology-05 (work in progress), August 2014. 1564 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1565 IF-IMC, Version 1.3", February 2013. 1567 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1568 IF-IMV, Version 1.4", December 2014. 1570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1571 Requirement Levels", BCP 14, RFC 2119, 1572 DOI 10.17487/RFC2119, March 1997, 1573 . 1575 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1576 (PA) Protocol Compatible with Trusted Network Connect 1577 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1578 . 1580 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1581 A Posture Broker (PB) Protocol Compatible with Trusted 1582 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1583 March 2010, . 1585 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1586 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1587 DOI 10.17487/RFC6876, February 2013, 1588 . 1590 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 1591 Posture Assessment: Enterprise Use Cases", RFC 7632, 1592 DOI 10.17487/RFC7632, September 2015, 1593 . 1595 [Server-Discovery] 1596 Trusted Computing Group, "DRAFT: TCG Trusted Network 1597 Connect PDP Discovery and Validation, Version 1.0", 1598 October 2015. 1600 [SWID] "Information technology--Software asset management--Part 1601 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1603 Authors' Addresses 1605 Danny Haynes 1606 The MITRE Corporation 1607 202 Burlington Road 1608 Bedford, MA 01730 1609 USA 1611 Email: dhaynes@mitre.org 1612 Jessica Fitzgerald-McKay 1613 Department of Defense 1614 9800 Savage Road 1615 Ft. Meade, Maryland 1616 USA 1618 Email: jmfitz2@nsa.gov 1620 Lisa Lorenzin 1621 Pulse Secure 1622 2700 Zanker Rd., Suite 200 1623 San Jose, CA 95134 1624 US 1626 Email: llorenzin@pulsesecure.net