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