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