idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 58 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2018) is 2278 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5209' is defined on line 1797, but no explicit reference was found in the text == Unused Reference: 'TNC' is defined on line 1802, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-mile-xmpp-grid-04 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-12 == Outdated reference: A later version (-05) exists of draft-ietf-sacm-nea-swima-patnc-01 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-05 ** Downref: Normative reference to an Informational draft: draft-ietf-sacm-terminology (ref. 'I-D.ietf-sacm-terminology') -- Possible downref: Non-RFC (?) normative reference: ref. 'IF-IMC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IF-IMV' ** Downref: Normative reference to an Informational RFC: RFC 7632 -- Possible downref: Non-RFC (?) normative reference: ref. 'Server-Discovery' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM D. Haynes 3 Internet-Draft The MITRE Corporation 4 Intended status: Standards Track J. Fitzgerald-McKay 5 Expires: August 3, 2018 Department of Defense 6 L. Lorenzin 7 Pulse Secure 8 January 30, 2018 10 Endpoint Compliance Profile 11 draft-ietf-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 IETF 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 an extension 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 https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 3, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Preventative Posture Assessments . . . . . . . . . . . . 4 59 1.2. All Network-Connected Endpoints are Endpoints . . . . . . 5 60 1.3. All Endpoints on the Network Must be Uniquely Identified 5 61 1.4. Standardized Data Models . . . . . . . . . . . . . . . . 6 62 1.5. Secure Standardized Protocols . . . . . . . . . . . . . . 6 63 1.6. Posture Information Must Be Stored . . . . . . . . . . . 6 64 1.7. Posture Information Can Be Shared . . . . . . . . . . . . 7 65 1.8. Enterprise Asset Posture Information Belongs to the 66 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 7 67 1.9. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Endpoint Compliance Profile . . . . . . . . . . . . . . . . . 10 71 4.1. Posture Assessments . . . . . . . . . . . . . . . . . . . 10 72 4.2. Data Storage . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 11 74 5. ECP Components . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.1.1. Posture Collector . . . . . . . . . . . . . . . . . . 12 77 5.1.2. Posture Collection Engine . . . . . . . . . . . . . . 13 78 5.2. Posture Manager . . . . . . . . . . . . . . . . . . . . . 13 79 5.2.1. Posture Validator . . . . . . . . . . . . . . . . . . 13 80 5.2.2. Posture Collection Manager . . . . . . . . . . . . . 13 81 5.3. Repository . . . . . . . . . . . . . . . . . . . . . . . 14 82 5.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 14 83 5.5. Orchestrator . . . . . . . . . . . . . . . . . . . . . . 14 84 6. ECP Transactions . . . . . . . . . . . . . . . . . . . . . . 15 85 6.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 15 86 6.2. Discovery and Validation . . . . . . . . . . . . . . . . 15 87 6.3. Event Driven Collection . . . . . . . . . . . . . . . . . 15 88 6.4. Querying . . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . 15 90 6.6. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 16 91 7. ECP Implementations . . . . . . . . . . . . . . . . . . . . . 17 92 7.1. IETF NEA ECP Implementation . . . . . . . . . . . . . . . 17 93 7.1.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 17 94 7.1.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 18 95 7.1.2.1. Posture Collector . . . . . . . . . . . . . . . . 18 96 7.1.2.2. Posture Collection Engine . . . . . . . . . . . . 18 98 7.1.3. Posture Manager . . . . . . . . . . . . . . . . . . . 19 99 7.1.3.1. Posture Validator . . . . . . . . . . . . . . . . 19 100 7.1.3.2. Posture Collection Manager . . . . . . . . . . . 19 101 7.1.4. Repository . . . . . . . . . . . . . . . . . . . . . 19 102 7.1.5. Administrative Interface and API . . . . . . . . . . 20 103 7.1.6. IETF SACM SWAM Extension to the IETF NEA ECP 104 Implementation . . . . . . . . . . . . . . . . . . . 20 105 7.1.6.1. Endpoint Pre-Provisioning . . . . . . . . . . . . 20 106 7.1.6.2. SWID Tags . . . . . . . . . . . . . . . . . . . . 20 107 7.1.6.3. SWID Posture Collectors and Posture Validators . 21 108 7.1.6.4. Repository . . . . . . . . . . . . . . . . . . . 22 109 7.2. IETF NETMOD ECP Implementation . . . . . . . . . . . . . 22 110 8. ECP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 22 111 8.1. Hardware Asset Management . . . . . . . . . . . . . . . . 22 112 8.2. Software Asset Management . . . . . . . . . . . . . . . . 23 113 8.3. Vulnerability Searches . . . . . . . . . . . . . . . . . 23 114 8.4. Threat Detection and Analysis . . . . . . . . . . . . . . 23 115 9. Non-supported Use Cases . . . . . . . . . . . . . . . . . . . 24 116 10. Endpoint Compliance Profile Examples . . . . . . . . . . . . 24 117 10.1. Continuous Posture Assessment of an Endpoint . . . . . . 24 118 10.1.1. Change on Endpoint Triggers Posture Assessment . . . 25 119 10.2. Administrator Searches for Vulnerable Endpoints . . . . 27 120 11. Profile Requirements . . . . . . . . . . . . . . . . . . . . 28 121 12. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 29 122 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 123 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 124 15. Security Considerations . . . . . . . . . . . . . . . . . . . 31 125 15.1. Security Benefits of Endpoint Compliance Profile . . . . 32 126 15.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 34 127 15.2.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 34 128 15.2.2. Network Attacks . . . . . . . . . . . . . . . . . . 35 129 15.2.3. Posture Manager Attacks . . . . . . . . . . . . . . 35 130 15.2.4. Repository Attacks . . . . . . . . . . . . . . . . . 35 131 15.3. Countermeasures . . . . . . . . . . . . . . . . . . . . 36 132 15.3.1. Countermeasures for Endpoint Attacks . . . . . . . . 36 133 15.3.2. Countermeasures for Network Attacks . . . . . . . . 37 134 15.3.3. Countermeasures for Posture Manager Attacks . . . . 37 135 15.3.4. Countermeasures for Repository Attacks . . . . . . . 38 136 16. Privacy-Considerations . . . . . . . . . . . . . . . . . . . 38 137 17. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 138 17.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39 139 17.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 39 140 17.3. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 39 141 17.4. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39 142 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 143 18.1. Informative References . . . . . . . . . . . . . . . . . 39 144 18.2. Normative References . . . . . . . . . . . . . . . . . . 40 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 147 1. Introduction 149 The Endpoint Compliance Profile (ECP) builds on prior work from the 150 IETF NEA WG, the IETF NETMOD WG, and the Trusted Computing Group 151 [TNC]Trusted Network Communications (TNC) WG to standardize the 152 collection, storage and sharing of posture information from network- 153 connected endpoints, including user endpoints, servers, and 154 infrastructure. The first generation of this specification focuses 155 on reducing the security exposure of a network by enabling event- 156 driven posture collection, as well as standardized querying for 157 additional endpoint data as needed. Standardized collection improves 158 network security by confirming that endpoints are known and 159 authorized, and are compliant with network policy. 161 When ECP is used, posture collectors running on the target endpoint 162 gather posture information as changes occur on the endpoint, and 163 forward this information to a posture manager, which stores it in a 164 repository. This information is gathered while the target endpoint 165 is already connected to the network. Administrators will query the 166 repository to determine the posture status of an endpoint. 168 Building and maintaining a continuously updated repository of 169 information using the ECP enables network owners and administrators 170 to perform the asset, vulnerability, and configuration management 171 tasks that are the basis for robust network security. 173 The ECP also describes how to expose information--such as endpoint 174 purpose, the software that is supposed to be running on an endpoint, 175 and the activities an endpoint is supposed to be performing--to 176 sensors that are looking for indicators of attacks and malicious 177 activity on the network. The ECP does not set requirements for this 178 future-leaning work; it instead sets requirements for building a data 179 repository that best enhances decision-making by these sensors. 180 Therefore, while data sharing components are included in ECP diagrams 181 and high-level capability descriptions, vendors are free to 182 experiment with best approaches for sharing data beyond the 183 repository. Suggestions and ideas for future integration are 184 captured in the Section 12 section of this document. 186 1.1. Preventative Posture Assessments 188 The value of continuous endpoint posture assessment is well 189 established. Security experts have for years identified asset 190 management and vulnerability remediation as a critical step for 191 preventing intrusions. Application whitelisting, patching 192 applications and operating systems, and using the latest versions of 193 applications top the Defense Signals Directorate's "Top 4 Mitigations 194 to Protect Your ICT System". [DSD] "Inventory of Authorized and 195 Unauthorized Endpoints", "Inventory of Authorized and Unauthorized 196 Software", and "Continuous Vulnerability Assessment and Remediation" 197 are Critical Controls 1, 2, and 4, respectively, of the CIS "20 198 Critical Security Controls". [CIS] While there are commercially 199 available solutions that attempt to address these security controls, 200 these solutions do not run on all types of endpoints; consistently 201 interoperate with other tools that could make use of the data 202 collected; collect posture information from all types of endpoints in 203 a consistent, standardized schema; or require vetted, standardized 204 protocols that have been evaluated by the international community for 205 cryptographic soundness. 207 As is true of most solutions offered today, the solution found in the 208 ECP does not attempt to solve the lying endpoint problem. An 209 endpoint that has already been infected with malicious software can 210 provide false information about its identity and the software it is 211 running. The primary purpose of the ECP is not to detect infected 212 endpoints; rather, it focuses on ensuring that healthy endpoints 213 remain healthy by keeping software up-to-date and patched. The first 214 goal of the ECP is to help an administrator easily determine which 215 endpoints require some follow-up action. By sharing posture 216 information with sensors on the network, ECP aids in the detection of 217 attacks on endpoints and drives follow-up actions. 219 1.2. All Network-Connected Endpoints are Endpoints 221 As defined by [I-D.ietf-sacm-terminology], an endpoint is any 222 physical or virtual computing endpoint that can be connected to a 223 network. Posture assessment against policy is equally, if not more, 224 important for continuously connected endpoints, such as enterprise 225 workstations and infrastructure endpoints, as it is for sporadically 226 connected endpoints. Continuously connected endpoints are just as 227 likely to fall out of compliance with policy, and a standardized 228 posture assessment method is necessary to ensure they can be properly 229 handled. 231 1.3. All Endpoints on the Network Must be Uniquely Identified 233 Many administrators struggle to identify what endpoints are connected 234 to the network at any given time. By requiring a standardized method 235 of endpoint identity, the Endpoint Compliance Profile will enable 236 administrators to answer the basic question, "What is on my network?" 237 Unique endpoint identification also enables the comparison of current 238 and past endpoint posture assessments, by allowing administrators to 239 correlate assessments from the same endpoint. This makes it easier 240 to flag suspicious changes in endpoint posture for manual or 241 automatic review, and helps to swiftly identify malicious changes to 242 endpoint applications. 244 1.4. Standardized Data Models 246 The ECP requires the use of standardized data models for the exchange 247 of posture information. This helps to ensure that the posture 248 information sent from endpoints to the repository can be easily 249 stored, due to their known format, and shared with authorized 250 endpoints and users. Standardized data models also enable collection 251 from myriad types of endpoints. Such standardization saves vendors 252 time and money--time that does not have to be spent integrating new 253 data models into the enterprise's reporting mechanisms, and money 254 that does not have to be spent on developing tools to parse 255 information from each type of endpoint connected to the network. 256 Standardized data models also enable the development of standardized 257 client software. This allows endpoint vendors to include their own 258 client software that can interoperate with posture assessment 259 infrastructure and thus not have to introduce third party code in 260 their products. 262 1.5. Secure Standardized Protocols 264 Posture information must be sent over mature, standardized protocols 265 to ensure the confidentiality and authenticity of this data while in 266 transit. Conformant implementations of the ECP include [RFC6876] and 267 [I-D.ietf-netconf-yang-push] for communication between the target 268 endpoint and the posture manager. These protocols allow networks 269 that implement this solution to collect large amounts of posture 270 information from an endpoint to make decisions about that endpoint's 271 compliance with some policy. The ECP offers a solution for all 272 endpoints already connected to the network. Periodic assessments and 273 automated reporting of changes to endpoint posture allow for 274 instantaneous identification of connected endpoints that are no 275 longer compliant to some policy. 277 1.6. Posture Information Must Be Stored 279 Posture information must be stored by the repository and must be 280 exposed to an interface at the posture manager. Standard data models 281 enable standard queries from an interface exposed to an administrator 282 at the posture manager console. A repository must retain any current 283 posture information retrieved from the target endpoint and store it 284 indexed by the unique identifier for the endpoint. Any posture 285 validator specified by this profile must be able to ascertain from 286 its corresponding posture collector whether the posture information 287 is up to date. An interface on the posture manager must support a 288 request to the posture validator to obtain up-to-date information 289 when an endpoint is connected. This interface must also support the 290 ability to make a standard set of queries about the posture 291 information stored by the repository. In the future, some forms of 292 posture information might be retained at the endpoint. The interface 293 on the server must accommodate the ability to make a request through 294 the posture validator to the corresponding posture collector about 295 the posture of the target endpoint. Standard data models and 296 protocols also enable the security of posture assessment results. By 297 storing these results indexed under the endpoint's unique 298 identification, secure storage itself enables endpoint posture 299 information correlation, and ensures that the enterprise's 300 repositories always offer the freshest, most up-to-date view of the 301 enterprise's endpoint posture information possible. 303 1.7. Posture Information Can Be Shared 305 By exposing posture information using a standard interface and API, 306 other security and operational components have a high level of 307 insight into the enterprise's endpoints and the software installed on 308 them. This will support innovation in the areas of asset management, 309 vulnerability scanning, and administrative interfaces, as any 310 authorized infrastructure endpoint can interact with the posture 311 information. 313 1.8. Enterprise Asset Posture Information Belongs to the Enterprise 315 Owners and administrators must have complete control of posture 316 information, policy, and endpoint mitigation. Standardized data 317 models, protocols and interfaces help to ensure that this posture 318 information is not locked in proprietary databases, but is made 319 available to its owners. This enables administrators to develop as 320 nuanced a policy as necessary to keep their networks secure. 322 1.9. Keywords 324 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 325 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 326 document are to be interpreted as described in [RFC2119]. This 327 specification does not distinguish blocks of informative comments and 328 normative requirements. Therefore, for the sake of clarity, note 329 that lower case instances of must, should, etc. do not indicate 330 normative requirements. 332 2. Terminology 334 This document uses terms as defined in [I-D.ietf-sacm-terminology] 335 unless otherwise specified. 337 3. Assumptions 339 Here are the assumptions that the Endpoint Compliance Profile makes 340 about other components in the SACM architecture. 342 o Existence of a posture manager and repository: The Endpoint 343 Compliance Profile assumes that a posture manager and repository 344 exist. 346 o Endpoint posture information availability: The Endpoint Compliance 347 Profile assumes that an endpoint has posture information in 348 standardized data model that can be communicated to the posture 349 manager. 351 o Certificate provisioning: In order to implement the most secure 352 endpoint identification option, the Endpoint Compliance Profile 353 assumes that the enterprise has set up a certificate root 354 authority, and has provisioned each endpoint with an endpoint 355 identification certificate. This is not required if an enterprise 356 chooses to use other endpoint authentication methods. 358 In addition, the Endpoint Compliance Profile makes the following 359 assumptions about the SACM ecosystem: 361 o All network-connected endpoints are endpoints: As defined by [I- 362 D.ietf-sacm-terminology], an endpoint is any physical or virtual 363 computing endpoint that can be connected to a network. Posture 364 assessment against policy is equally, if not more, important for 365 continuously connected endpoints, such as enterprise workstations 366 and infrastructure endpoints, as it is for sporadically connected 367 endpoints. Continuously connected endpoints are just as likely to 368 fall out of compliance with policy, and a standardized posture 369 assessment method is necessary to ensure they can be properly 370 handled. 372 o All endpoints on the network must be uniquely identified: Many 373 administrators struggle to identify what endpoints are connected 374 at any given time. By requiring a standardized method of endpoint 375 identity, the Endpoint Compliance Profile will enable 376 administrators to answer the basic question, "What is on my 377 network?" Unique endpoint identification also enables the 378 comparison of current and past endpoint posture assessments, by 379 allowing administrators to correlate assessments from the same 380 endpoint. This makes it easier to flag suspicious changes in 381 endpoint posture for manual or automatic review, and helps to 382 swiftly identify malicious changes to endpoint applications. 384 o Posture assessments must occur over secure, standardized 385 protocols: Endpoint identity and application information is very 386 valuable, both to administrators and to attackers. Therefore, it 387 must be kept confidential, using secure protocols to transport it 388 from the endpoint to the posture manager. Additionally, it is 389 critical that only authorized parties be capable of requesting 390 information, receiving information, or taking action to change an 391 endpoint's connectivity status. Relying on standardized protocols 392 to provide this security enables greater interoperability and 393 compatibility between endpoints, and allows for the development of 394 compliance testing to ensure that each endpoint operates securely 395 and in conformance with appropriate specifications. A standards 396 body provides a process for experts in protocols and cryptography 397 to evaluate the soundness of protocols and security management 398 procedures; a set of security standards allows an enterprise to 399 make the most effective use of their investment in a security 400 management infrastructure. 402 o Posture assessment results must be formatted using standardized 403 data models: Well-known, standard data models allow for a 404 universal language for generating compliance reports. With each 405 endpoint speaking the same language, the Endpoint Compliance 406 Profile enables information sharing between user endpoints and 407 infrastructure endpoints, and between infrastructure endpoints 408 that perform different security tasks. 410 o Posture information must be stored by the repository and must be 411 exposed to an interface at the posture manager: Standard data 412 models enable standard queries from an interface exposed to an 413 administrator at the posture manager console. A repository must 414 retain any current posture information retrieved from the endpoint 415 and store it indexed by the unique identifier for the endpoint. 416 Any posture validator specified by this profile must be able to 417 ascertain from its corresponding posture collector whether the 418 posture information is up to date. An interface on the posture 419 manager must support a request to the posture validator to obtain 420 up-to-date information when an endpoint is connected. This 421 interface must also support the ability to make a standard set of 422 queries about the posture information stored by the repository. 423 In the future, some forms of posture information might be retained 424 at the endpoint. The interface on the posture manager must 425 accommodate the ability to make a request through the posture 426 validator to the corresponding posture collector about the posture 427 of the endpoint. Standard data models and protocols also enable 428 the security of posture assessment results. By storing these 429 results indexed under the endpoint's unique identifier, secure 430 storage itself enables endpoint posture information correlation, 431 and ensures that the enterprise's repositories always offer the 432 freshest, most up-to-date view of the enterprise's endpoint 433 posture information possible. 435 o Posture information can be shared: By exposing posture information 436 using a standard interface and API, other security and operational 437 components have a high level of insight into the enterprise's 438 endpoints and the software installed on them. This will support 439 innovation in the areas of asset management, vulnerability 440 scanning, and administrative interfaces, as any authorized 441 infrastructure endpoint can interact with the posture information. 443 o Owners and administrators must have complete control of posture 444 information, policy, and endpoint mitigation: Enterprise asset 445 posture information belongs to the enterprise. Standardized data 446 models, protocols and interfaces help to ensure that this posture 447 information is not locked in proprietary databases, but is made 448 available to its owners. This enables administrators to develop 449 as nuanced a policy as necessary to keep their networks secure. 451 4. Endpoint Compliance Profile 453 The Endpoint Compliance Profile describes how IETF data models and 454 protocols can be used to support the posture assessment of endpoints 455 on a network. This profile does not generate new data models or 456 protocols; rather, it offers a full end-to-end solution for posture 457 assessment, as well as a fresh perspective on how existing standards 458 can be leveraged against vulnerabilities. 460 4.1. Posture Assessments 462 The Endpoint Compliance Profile 1.0 describes how IETF and TNC data 463 models and protocols make it possible to perform posture assessments 464 against all network-connected endpoints by: 466 1. uniquely identifying the endpoint; 468 2. collecting and assessing posture based on data from the endpoint; 470 3. creating a secure, authenticated, confidential channel between 471 the endpoint and the posture manager; 473 4. enabling the endpoint to notify the posture manager about changes 474 to its configuration; 476 5. enabling the posture manager to request information about the 477 configuration of the endpoint; and 479 6. storing the posture information in a repository linked to the 480 identifier for the endpoint. 482 4.2. Data Storage 484 The Endpoint Compliance Profile 1.0 focuses on being able to collect 485 posture information from an endpoint and store it in a repository. 486 This makes posture information from a network's endpoints available 487 to authorized parties. Uses of this data are innumerable - 488 vulnerability management, asset management, software asset 489 management, and configuration management solutions, analytics tools, 490 endpoints that need to make connectivity decisions, and metrics 491 reporting scripts, among others, are all able to reference the data 492 stored in the repository to achieve their purposes. Currently, the 493 Endpoint Compliance Profile 1.0 does not specify a protocol or 494 interfaces to access stored posture information. This needs to be 495 addressed in a future revision to make collected posture information 496 accessible to components in a standardized manner. Until then, 497 vendors are free to implement a repository and the protocols and 498 interfaces used to interact with it in a way that makes the most 499 sense for them. 501 4.3. Data Sharing 503 The Endpoint Compliance Profile 1.0 aims to facilitate the sharing of 504 posture information between components to enable asset management, 505 software asset management, and configuration management use cases as 506 well as support analytic, access control, remediation, and reporting 507 processes. However, the Endpoint Compliance Profile 1.0 does not 508 currently specify a protocol for communicating this information 509 between components to support these use cases and processes. This 510 needs to be addressed in a future revision. 511 [I-D.ietf-mile-xmpp-grid] which is publish/subscribe protocol being 512 developed in the IETF MILE WG may be a potential candidate for 513 sharing information between components. 515 5. ECP Components 517 To perform posture assessment, data storage, and data sharing, ECP 518 defines a number of components. Some of these components reside on 519 the target endpoint. Others reside on a posture manager that manages 520 communications with the target endpoint and stores the target 521 endpoint's posture information in a repository. 523 Posture Manager Endpoint 524 Orchestrator +---------------+ +---------------+ 525 +--------+ | | | | 526 | | | +-----------+ | | +-----------+ | 527 | |<---->| | Posture | | | | Posture | | 528 | | pub/ | | Validator | | | | Collector | | 529 | | sub | +-----------+ | | +-----------+ | 530 +--------+ | | | | | | 531 | | | | | | 532 Evaluator Repository | | | | | | 533 +------+ +--------+ | +-----------+ |<-------| +-----------+ | 534 | | | | | | Posture | | report | | Posture | | 535 | | | | | | Collection| | | | Collection| | 536 | |<-----> | |<---->| | Manager | | query | | Engine | | 537 | |request/| | store| +-----------+ |------->| +-----------+ | 538 | |respond | | | | | | 539 | | | | | | | | 540 +------+ +--------+ +---------------+ +---------------+ 542 Figure 1: ECP Components 544 5.1. Endpoint 546 An endpoint is defined in [RFC6876]. In the Endpoint Compliance 547 Profile, the endpoint is monitored by the enterprise and is the 548 target of posture assessments. To support these posture assessments, 549 posture information is collected via posture collectors. 551 5.1.1. Posture Collector 553 A posture collector is responsible for monitoring and gathering 554 posture information from the target endpoint. This component reports 555 changes to posture information as they occur. This event-driven 556 collection provides network administrators up-to-date insight into 557 the state of the network as the network state changes, which enables 558 continuous monitoring of the network. Posture collectors can also be 559 queried supporting ad-hoc collection, addressed below as "querying" 560 which can be used to refresh information about the target endpoint, 561 or to ask a specific question about posture information. 562 Furthermore, a posture collector may process posture information 563 before it is communicated to the posture manager. An endpoint may 564 have one or more posture collectors depending on the type of endpoint 565 and what posture information is being monitored and collected. 567 5.1.2. Posture Collection Engine 569 The posture collection engine is located on the target endpoint. It 570 receives queries from a posture collection manager and directs them 571 to the appropriate posture collector on the target endpoint. It also 572 sends collected posture information to the posture manager where it 573 can be received by the posture collection manager and distributed to 574 the appropriate posture validator where it can be sanity checked and 575 stored in the repository. The posture collection engine also 576 contains a capability that sets up exchanges between the target 577 endpoint and posture manager. This capability makes the posture 578 collection engine responsible for performing the client-side portion 579 of encryption handshakes, and for locating authorized posture 580 managers with which to communicate. 582 5.2. Posture Manager 584 The posture manager is an endpoint that collects, validates, and 585 enriches posture information received about a target endpoint. It 586 also stores the posture information it receives in the repository. 587 The posture manager does not evaluate the posture information. 589 5.2.1. Posture Validator 591 A posture validator receives data from a posture collector, performs 592 basic sanity checking, and stores that data in the repository. It 593 can also send queries to a posture collector. There is a posture 594 validator for every posture collector. 596 5.2.2. Posture Collection Manager 598 A posture collection manager is a lightweight and extensible 599 component that facilitates the coordination and execution of posture 600 collection requests using collection mechanisms deployed across the 601 enterprise. The posture collection manager may query and retrieve 602 guidance from the repository to guide the collection of posture 603 information from the target endpoint. 605 The posture collection manager also contains a capability that sets 606 up exchanges between the target endpoint and the posture manager, and 607 manages data sent to and from posture validators. It is also 608 responsible for performing the server-side portion of encryption 609 handshakes. It is also responsible for performing the server-side 610 portion of encryption handshakes. 612 5.3. Repository 614 The repository hosts guidance, endpoint identification information, 615 and posture information reported by target endpoints where it is made 616 available to authorized components and persisted over a period of 617 time set by the administrator. Information stored in the repository 618 will be accessible to authorized parties via a standard 619 administrative interface as well as through a standardized API. The 620 repository may be a standalone component or may be located on the 621 posture manager. 623 Currently, the Endpoint Compliance Profile does not provide a 624 standardized interface or API for accessing the information contained 625 within the repository. A future revision of the Endpoint Compliance 626 Profile may specify a standardized interface and API for components 627 to interact with the repository. 629 5.4. Evaluator 631 The evaluator assesses the posture status of a target endpoint by 632 comparing collected posture information against the desired state of 633 the target endpoint specified in guidance. The evaluator queries and 634 retrieves the appropriate guidance from the repository as well as 635 queries and retrieves the posture information required for the 636 assessment from the repository. If the required posture information 637 is not available in the repository, the evaluator may request the 638 posture information from the posture collection engine, which will 639 result in the collection of additional posture information from the 640 target endpoint. This information is subsequently stored in the 641 repository where it is made available to the evaluator and other 642 components. The results of the assessment are stored in the 643 repository where they are available to tools and administrators for 644 follow-up actions, further evaluation, and historical purposes. 646 5.5. Orchestrator 648 The orchestrator provides a publish/subscribe interface for the 649 repository so that infrastructure endpoints can subscribe to and 650 receive published posture assessment results from the repository 651 regarding endpoint posture changes. 653 The Endpoint Compliance Profile 1.0 does not currently define an 654 orchestrator component nor does it specify a standardized publish/ 655 subscribe interface for this purpose. Future revisions of the 656 Endpoint Compliance Profile may specify such an interface. 658 6. ECP Transactions 660 6.1. Provisioning 662 An endpoint is provisioned with one or more attributes that will 663 serve as its unique identifier on the network as well as the 664 components necessary to interact with the posture manager. The 665 endpoint is deployed on the network. 667 NOTE: TO BE EXPANDED 669 6.2. Discovery and Validation 671 If necessary, the target endpoint finds and validates the posture 672 manager. The posture collection engine on the target endpoint and 673 posture collection manager on the posture manager complete a TLS 674 handshake, during which endpoint identity information is exchanged. 676 6.3. Event Driven Collection 678 The posture assessment is initiated when a posture collector on the 679 target endpoint notices that relevant posture information on the 680 endpoint has changed. The posture collector notified the posture 681 collection engine, which initiates a posture assessment information 682 exchange with the posture collection manager. 684 6.4. Querying 686 The posture assessment is initiated by the posture validator. This 687 can occur because: 689 1. policy states that a previous assessment has aged out or become 690 invalid, or 692 2. the posture validator is alerted by a sensor or an administrator 693 (via the posture manager's user interface) that an assessment 694 must be completed 696 6.5. Data Storage 698 Once posture information is received by the posture manager, it is 699 forwarded to the repository. The repository could be co-located with 700 the posture manager, or there could be direct or brokered 701 communication between the posture manager and the repository. The 702 posture information is stored in the repository along with past 703 posture information collected about the target endpoint. 705 6.6. Data Sharing 707 Because the target endpoint posture information was sent in 708 standards-based data models over secure, standardized protocols, and 709 then stored in a centralized repository linked to unique endpoint 710 identifiers, authorized parties are able to access the posture 711 information. Such authorized parties may include, but are not 712 limited to, administrators or endpoint owners (via the server's 713 administrative interface), evaluators that access the repository 714 directly, and orchestrators that rely on publish/subscribe 715 communications with the repository. 717 Posture Manager Endpoint 718 Orchestrator +---------------+ +---------------+ 719 +--------+ | | | | 720 | | | +-----------+ | | +-----------+ | 721 | |<---->| | Posture | | | | Posture | | 722 | | pub/ | | Validator | | | | Collector | | 723 | | sub | +-----------+ | | +-----------+ | 724 +--------+ | | | | | | 725 | | | | | | 726 Evaluator Repository | | | | | | 727 +------+ +--------+ | +-----------+ |<-------| +-----------+ | 728 | | | | | | Posture | | report | | Posture | | 729 | | | | | | Collection| | | | Collection| | 730 | |<-----> | |<-----| | Manager | | query | | Engine | | 731 | |request/| | store| +-----------+ |------->| +-----------+ | 732 | |respond | | | | | | 733 | | | | | | | | 734 +------+ +--------+ +---------------+ +---------------+ 736 +--------------------------------+ 737 | Administrative Interface | 738 | and API | 739 +--------------------------------+ 741 Figure 2: Exposing Data to the Network 743 It should be noted that the neither the Endpoint Compliance Profile 744 nor the protocols, interfaces, and data models that it references 745 provide solutions to the repository, evaluator, and orchestrator 746 components and capabilities listed above. However, these 747 capabilities are useful and solutions for them should be pursued in 748 the future. 750 7. ECP Implementations 752 The following sections describe implementations of the Endpoint 753 Compliance Profile leveraging the IETF NEA and IETF NETMOD 754 architectures. 756 7.1. IETF NEA ECP Implementation 758 These requirements are written with a view to performing a posture 759 assessment on an endpoint; as the Endpoint Compliance Profile grows 760 and evolves, these requirements will be expanded to address issues 761 that arise. Note that these requirements refer to defined components 762 of the NEA architecture. As with the NEA architecture, vendors have 763 discretion as to how these NEA components map to separate pieces of 764 software or endpoints. 766 7.1.1. Endpoint Pre-Provisioning 768 An endpoint is provisioned with a machine certificate that will serve 769 as its unique identifier on the network as well as the components 770 necessary to interact with the posture manager. This includes a 771 posture collection engine to manage requests from the posture manager 772 and the posture collectors necessary to collect the posture 773 information of importance to the enterprise. The endpoint is 774 deployed on the network. 776 The target endpoint SHOULD authenticate to the posture manager using 777 a machine certificate during the establishment of the outer tunnel 778 achieved with the posture transport protocol defined in [RFC6876]. 779 [IF-IMV] specifies how to pull an endpoint identifier out of a 780 machine certificate. An endpoint identifier SHOULD be created in 781 conformance with [IF-IMV] from a machine certificate sent via 782 [RFC6876]. 784 In the future, the identity could be a hardware certificate compliant 785 with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated 786 with the identity of a hardware cryptographic module, in accordance 787 with [IEEE-802-1ar], if present on the endpoint. The enterprise 788 SHOULD stand up a certificate root authority; install its root 789 certificate on endpoints and on the posture manager; and provision 790 the endpoints and the posture manager with machine certificates. The 791 target endpoint MAY authenticate to the posture manager using a 792 combination of the machine account and password; however, this is 793 less secure and not recommended. 795 7.1.2. Endpoint 797 The endpoint MUST conform to [RFC5793], which levies a number of 798 requirements against the endpoint. An endpoint that complies with 799 these requirements will be able to: 801 1. attempt to initiate a session with the posture manager if the 802 posture makes a request to send an update to posture manager; 804 2. notify the posture collector if no PT-TLS session with the 805 posture manager can be created; 807 3. notify the posture collector when a PT-TLS session is 808 established; and 810 4. receive information from the posture collectors, forward this 811 information to the server via the posture collection engine. 813 7.1.2.1. Posture Collector 815 Any posture collector used in an Endpoint Compliance Profile solution 816 MUST be conformant with [IF-IMC]; an Internet-Draft, under 817 development, that is a subset of the TCG TNC Integrity Measurement 818 Collector interface [IF-IMC] and will be submitted in the near 819 future. 821 7.1.2.2. Posture Collection Engine 823 In the original IETF NEA ECP implementation, the endpoint contained 824 posture collector(s), a posture broker client, and posture transport 825 client(s). However, in this draft, the functionality of the posture 826 broker client and posture transport client(s) have been combined into 827 what is now called the posture collection engine. This was done 828 because there is currently no standard interface to handle the 829 communication between the posture broker client and posture transport 830 client(s) meaning vendors will need to define proprietary interfaces 831 that will not be interoperable. 833 The endpoint MUST conform to [IF-IMC] to enable communications 834 between the posture collection engine and the posture collectors on 835 the endpoint. 837 The posture collection engine MUST implement PT-TLS. 839 The posture collection engine MUST support the use of machine 840 certificates for TLS at each endpoint consistent with the 841 requirements stipulated in [RFC6876] and [Server-Discovery]. 843 The posture collection engine MUST be able to locate an authorized 844 posture manager, and switch to a new posture manager when required by 845 the network, in conformance with [Server-Discovery]. 847 7.1.3. Posture Manager 849 The posture manager MUST conform to all requirements in the 850 [RFC5793]. 852 7.1.3.1. Posture Validator 854 Any posture validator used in an Endpoint Compliance Profile solution 855 MUST be conformant with [IF-IMV]; an Internet-Draft, under 856 development, that is a subset of the TCG TNC Integrity Measurement 857 Verifier interface [IF-IMV] and will be submitted in the near future. 859 7.1.3.2. Posture Collection Manager 861 In the original IETF NEA ECP implementation, the posture manager 862 contained posture validators(s), a posture broker server, and posture 863 transport servers(s). Similar to the approach take on the endpoint, 864 in this draft, the functionality of the posture broker server and 865 posture transport servers(s) have been combined into what is now 866 called the posture collection manager. This was done because there 867 is currently no standard interface to handle the communication 868 between the posture broker server and posture transport servers(s) 869 meaning vendors will need to define proprietary interfaces that will 870 not be interoperable. 872 The posture manager MUST conform to [IF-IMV]. Conformance to 873 [IF-IMV] enables the posture manager to obtain endpoint identity 874 information from the posture collection manager, and pass this 875 information to any posture validators on the posture manager. 877 The posture collection manager MUST implement PT-TLS. 879 The posture collection manager MUST support the use of machine 880 certificates for TLS at each endpoint consistent with the 881 requirements stipulated in [RFC6876] and [Server-Discovery]. 883 7.1.4. Repository 885 ECP 1.0 requires a simple administrative interface for the 886 repository. Posture validators on the posture manager receive the 887 target endpoint posture information via PA-TNC [RFC5792] messages 888 sent from corresponding posture collectors on the target endpoint and 889 store this information in the repository linked to the identity of 890 the target endpoint where the posture collectors are located. 892 7.1.5. Administrative Interface and API 894 An interface is necessary to allow administrators to manage the 895 endpoints and software used in the Endpoint Compliance Profile. This 896 interface SHOULD be accessible either on or through (as in the case 897 of a remotely hosted interface) the posture manager. Using this 898 interface, an authorized user or administrator SHOULD be able to: 900 o Query the repository 902 o Send commands to the posture validators, requesting information 903 from the associated posture collectors residing on network 904 endpoints 906 o Update the policy that resides on the posture manager 908 An API is necessary to allow infrastructure endpoints and software 909 access to the information stored in the repository. Using this API, 910 an authorized endpoint SHOULD be able to: 912 o Query the repository 914 7.1.6. IETF SACM SWAM Extension to the IETF NEA ECP Implementation 916 This section defines the requirements associated with the software 917 asset management extension [I-D.ietf-sacm-nea-swima-patnc] to the 918 IETF NEA ECP implementation. 920 7.1.6.1. Endpoint Pre-Provisioning 922 This section defines the requirements associated with implementing 923 SWIMA. 925 The following requirements assume that the platform or OS vendor 926 supports the use of SWID tags and has identified a standard directory 927 location for the SWID tags to be located as specified by [SWID]. 929 7.1.6.2. SWID Tags 931 The primary content for the Endpoint Compliance Profile 1.0 is the 932 information conveyed in the elements of a SWID tag. 934 The endpoint MUST have SWID tags stored in a directory specified in 935 [SWID]. The tags SHOULD be provided by the software vendor; they MAY 936 also be generated by: 938 o the software installer; or 939 o third-party software that creates tags based on the applications 940 it sees installed on the endpoint. 942 The elements in the SWID tag MUST be populated as specified in 943 [SWID]. These tags, and the directory in which they are stored, MUST 944 be updated as software is added, removed, or updated. 946 7.1.6.3. SWID Posture Collectors and Posture Validators 948 7.1.6.3.1. The SWID Posture Collector 950 For the Endpoint Compliance Profile, the SWID posture collector MUST 951 be conformant with [I-D.ietf-sacm-nea-swima-patnc], which includes 952 requirements for: 954 1. Collecting SWID tags from the SWID directory 956 2. Monitoring the SWID directory for changes 958 3. Initiating a session with the posture manager to report changes 959 to the directory 961 4. Maintaining a list of changes to the SWID directory when updates 962 take place and no PT-TLS connection can be created with the 963 posture manager 965 5. Responding to a request for SWID tags from the SWID Posture 966 Validator on the posture manager 968 6. Responding to a query from the SWID posture validator as to 969 whether all updates have been sent 971 The SWID posture collector is not responsible for detecting that the 972 SWID directory was not updated when an application was either 973 installed or uninstalled. 975 7.1.6.3.2. The SWID Posture Validator 977 Conformance to [I-D.ietf-sacm-nea-swima-patnc] enables the SWID 978 posture validator to: 980 1. Send messages to the SWID posture collector (at the behest of the 981 administrator at the posture manager console) requesting updates 982 for SWID tags located on endpoint 984 2. Ask the SWID posture collector whether all updates to the SWID 985 directory located at the posture manager have been sent 987 3. Compare an endpoint's SWID posture information to policy, and 988 make a recommendation to the NEA server about the endpoint 990 In addition to these requirements, a SWID posture validator used in 991 conformance with this profile MUST be capable of passing information 992 from the posture assessment results and the endpoint identity 993 associated with those results to the repository for storage. 995 7.1.6.4. Repository 997 The administrative interface SHOULD enable an administrator to: 999 1. Query which endpoints have reported SWID tags for a particular 1000 application 1002 2. Query which SWID tags are installed on an endpoint 1004 3. Query tags based on characteristics, such as vendor, publisher, 1005 etc. 1007 7.2. IETF NETMOD ECP Implementation 1009 NOTE: TO BE WRITTEN 1011 8. ECP Use Cases 1013 The following sections describe the different use cases supported by 1014 the Endpoint Compliance Profile. 1016 8.1. Hardware Asset Management 1018 Using the administrative interface on the posture manager, an 1019 authorized user can learn: 1021 o what endpoints are connected to the network at any given time; and 1023 o what SWID tags were reported for the endpoints. 1025 The ability to answer these questions offers a standards-based 1026 approach to asset management, which is a vital part of enterprise 1027 processes such as compliance report generation for the Federal 1028 Information Security Modernization Act (FISMA), Payment Card Industry 1029 Data Security Standard (PCI DSS), Health Insurance Portability and 1030 Accountability Act (HIPAA), etc. 1032 8.2. Software Asset Management 1034 The administrative interface on the posture manager provides the 1035 ability for authorized users and infrastructure to know which 1036 software is installed on which endpoints on the enterprise's network. 1037 This allows the enterprise to answer questions about what software is 1038 installed to determine if it is licensed or prohibited. This 1039 information can also drive other use cases such as: 1041 o vulnerability management: knowing what software is installed 1042 supports the ability to determine which endpoints contain 1043 vulnerable software and need to be patched. 1045 o configuration management: knowing which security controls need to 1046 be applied to harden installed software and better protect 1047 endpoints. 1049 8.3. Vulnerability Searches 1051 The administrative interface also provides the ability for authorized 1052 users or infrastructure to locate endpoints running software for 1053 which vulnerabilities have been announced. Because of 1055 1. the unique IDs assigned to each endpoint; and 1057 2. the rich application data provided in the endpoints' posture 1058 information, 1060 the repository can be queried to find all endpoints running a 1061 vulnerable application. Endpoints suspected of being vulnerable can 1062 be addressed by the administrator or flagged for further scrutiny. 1064 8.4. Threat Detection and Analysis 1066 The repository's standardized API allows authorized infrastructure 1067 endpoints and software to search endpoint posture assessment 1068 information for evidence that an endpoint's software inventory has 1069 changed, and can make endpoint software inventory data available to 1070 other endpoints. This automates security data sharing in a way that 1071 expedites the correlation of relevant network data, allowing 1072 administrators and infrastructure endpoints to identify odd endpoint 1073 behavior and configuration using secure, standards-based data models 1074 and protocols. 1076 9. Non-supported Use Cases 1078 Several use cases, including but not limited to these, are not 1079 covered by the Endpoint Compliance Profile 1.0: 1081 o Gathering non-standardized types of posture information: The 1082 Endpoint Compliance Profile does not prevent administrators from 1083 collecting posture information in proprietary formats from the 1084 endpoint; however it does not set requirements for doing so. 1086 o Solving the lying endpoint problem: The Endpoint Compliance 1087 Profile does not address the lying endpoint problem; the Profile 1088 makes no assertions that it can catch an endpoint that is, either 1089 maliciously or accidentally, reporting false posture information 1090 to the posture manager. However, other solutions may be able to 1091 use the posture information collected using the capabilities 1092 described in this profile to catch an endpoint in a lie. For 1093 example, a sensor may be able to compare the posture information 1094 it has collected on an endpoint's activity on the network to what 1095 the endpoint reported to the server and flag discrepancies. 1096 However, these capabilities are not described in this profile. 1098 10. Endpoint Compliance Profile Examples 1100 10.1. Continuous Posture Assessment of an Endpoint 1102 Endpoint Posture Manager 1103 +----------------+ +----------------+ 1104 | | | | 1105 | +------------+ | | +------------+ | 1106 | | SWID | | | | SWID | | 1107 | | Posture | | | | Posture | | 1108 | | Collector | | | | Validator | | 1109 | +------------+ | | +------------+ | 1110 | | | | | | 1111 | | IF-IMC | | | IF-IMV | 1112 | | | | | | 1113 | +------------+ | | +------------+ | 1114 | | Posture | | | | Posture | | 1115 | | Collection | | | | Collection | | 1116 | | Engine | |<------>| | Manager | | 1117 | +------------+ | PT-TLS | +------------+ | 1118 | | | | 1119 +----------------+ +----------------+ 1121 Figure 3: Continuous Posture Assessment of an Endpoint 1123 10.1.1. Change on Endpoint Triggers Posture Assessment 1125 A new application is installed on the endpoint, and the SWID 1126 directory is updated. This triggers an update from the SWID posture 1127 collector to the SWID posture validator. The message is sent down 1128 the NEA stack, encapsulated by NEA protocols until it is sent by the 1129 posture transport client to the posture transport server. The 1130 posture transport server then forwards it up through the stack, where 1131 the layers of encapsulation are removed until the SWID Message 1132 arrives at the SWID posture validator. 1134 Endpoint Posture Manager 1135 +----------------+ +----------------+ 1136 | | | | 1137 | +------------+ | | +------------+ | 1138 | | SWID | | | | SWID | | 1139 | | Posture | | | | Posture | | 1140 | | Collector | | | | Validator | | 1141 | +------------+ | | +------------+ | 1142 | | | SWIMA for | | | 1143 | | IF-IMC | PA-TNC | | IF-IMV | 1144 | | | | | | 1145 | +------------+ | PB-TNC {SWIMA | +------------+ | 1146 | | Posture | | for PA-TNC} | | Posture | | 1147 | | Collection | |<--------------->| | Collection | | 1148 | | Engine | | PT-TLS {PB-TNC | | Manager | | 1149 | +------------+ | {SWIMA for | +------------+ | 1150 | | PA-TNC}} | | 1151 +----------------+ +----------------+ 1153 Figure 4: Compliance Protocol Encapsulation 1155 The SWID posture validator stores the new tag information in the 1156 repository. If the tag indicates that the endpoint is compliant to 1157 the policy, then the process is complete until the next time an 1158 update is needed (either because policy states that the endpoint must 1159 submit posture assessment results periodically or because an 1160 install/uninstall/update on the endpoint triggers a posture 1161 assessment). 1163 Endpoint Posture Manager 1164 +----------------+ +----------------+ 1165 | | | | 1166 | +------------+ | | +------------+ | 1167 | | SWID | | | | SWID |-|-+ 1168 | | Posture | | | | Posture | | | 1169 | | Collector | | | | Validator | | | 1170 | +------------+ | | +------------+ | | 1171 | | | | | | | Repository 1172 | | IF-IMC | | | IF-IMV | | +--------+ 1173 | | | | | | | | | 1174 | +------------+ | | +------------+ | | | | 1175 | | Posture | | | | Posture | | +---->| | 1176 | | Collection | | | | Collection | | | | 1177 | | Engine | |<------>| | Manager | | | | 1178 | +------------+ | | +------------+ | | | 1179 | | | | +--------+ 1180 +----------------+ +----------------+ 1182 Figure 5: Storing SWIDs in the Repository 1184 If the endpoint has fallen out of compliance with a policy, the 1185 server can alert the administrator via the posture manager's 1186 administrative interface. The administrator can then take steps to 1187 address the problem. If the administrator has already established a 1188 policy for automatically addressing this problem, that policy will be 1189 followed. 1191 (") 1192 __|__ 1193 +-->| 1194 Endpoint Posture Manager | / \ 1195 +----------------+ +----------------+ | 1196 | | | | | 1197 | +------------+ | | +------------+ | | 1198 | | SWID | | | | SWID |-|-+ 1199 | | Posture | | | | Posture | | 1200 | | Collector | | | | Validator | | 1201 | +------------+ | | +------------+ | 1202 | | | | | | Repository 1203 | | IF-IMC | | | IF-IMV | +--------+ 1204 | | | | | | | | 1205 | +------------+ | | +------------+ | | | 1206 | | Posture | | | | Posture | | | | 1207 | | Collection | | | | Collection | | | | 1208 | | Engine | |<------>| | Manager | | +--------+ 1209 | +------------+ | | +------------+ | 1210 | | | | 1211 +----------------+ +----------------+ 1213 Figure 6: Server Alerts Network Admin 1215 10.2. Administrator Searches for Vulnerable Endpoints 1217 An announcement is made that a particular version of a piece of 1218 software has a vulnerability. The administrator uses the 1219 Administrative Interface on the server to search the repository for 1220 endpoints that reported the SWID tag for the vulnerable software. 1222 (") 1223 __|__ 1224 +-->| 1225 Endpoint Posture Manager | / \ 1226 +----------------+ +----------------+ | 1227 | | | | | 1228 | +------------+ | | +------------+ | | 1229 | | SWID | | | | SWID |-|-+ 1230 | | Posture | | | | Posture | | 1231 | | Collector | | | | Validator | | 1232 | +------------+ | | +------------+ | 1233 | | | | | | Repository 1234 | | IF-IMC | | | IF-IMV | +--------+ 1235 | | | | | | | | 1236 | +------------+ | | +------------+ | | | 1237 | | Posture | | | | Posture | |------>| | 1238 | | Collection | | | | Collection | | | | 1239 | | Engine | |<------>| | Manager | | | | 1240 | +------------+ | | +------------+ | +--------+ 1241 | | | | 1242 +----------------+ +----------------+ 1244 Figure 7: Admin Searches for Vulnerable Endpoints 1246 The repository returns a list of entries in the matching the 1247 administrator's search. The administrator can then address the 1248 vulnerable endpoints by taking some follow-up action such as removing 1249 it from the network, quarantining it, or updating the vulnerable 1250 software. 1252 11. Profile Requirements 1254 Here are the requirements that the Endpoint Compliance Profile 1255 protocol must meet in order to successfully fit in the SACM 1256 architecture. 1258 o Meets the needs of SACM use cases: The Endpoint Compliance Profile 1259 must support the use cases described in [RFC7632] as they apply to 1260 endpoint self-reporting and endpoint posture assessment. 1262 o Efficient: To minimize user frustration, it is essential to 1263 minimize delays by making endpoint posture information collection, 1264 transmission, and assessment as brief and efficient as possible. 1266 o Extensible: The Endpoint Compliance Profile needs to expand over 1267 time as new features are added to the SACM architecture. The 1268 solution must allow new features to be added easily, providing for 1269 a smooth transition and allowing newer and older architectural 1270 components to continue to work together. Further, the Endpoint 1271 Compliance Profile and the specifications referenced here must 1272 define safe extensibility mechanisms that enable innovation 1273 without breaking interoperability. 1275 o Easy to implement: The Endpoint Compliance Profile should be easy 1276 for vendors to implement in their products, and should result in 1277 products that are easy for administrators to implement on their 1278 networks. Products conformant to the Endpoint Compliance Profile 1279 should interoperate seamlessly, and be simple to integrate into 1280 existing network infrastructure. 1282 o Easy to use: The Endpoint Compliance Profile should describe a 1283 simple, integrated user interface that administrators can use to 1284 perform the activities listed in the profile's use cases. The 1285 Endpoint Compliance Profile should not constrain innovation by 1286 specifying details of the user interface but rather functional 1287 requirements. 1289 o Platform-independent: Since network environments may contain many 1290 different types of endpoints, the solution should operate 1291 independently of the endpoint platform. 1293 o Scalable: The Endpoint Compliance Profile must be designed to 1294 scale to very large numbers of endpoints. 1296 12. Future Work 1298 This section captures ideas for future work related to ECP that might 1299 be of interest to the IETF SACM WG. These ideas are listed in no 1300 particular order. 1302 o Integratate the IETF NETMOD Yang Push architecture. 1304 o Add support endpoint types beyond workstations, servers, and 1305 network infrastructure devices. 1307 o Examine the integration of [I-D.ietf-mile-xmpp-grid]. 1309 o Define a standard interface and API for interacting with the 1310 repository. Requirements to consider include: creating a secure 1311 channel between a publisher and the repository, creating a secure 1312 channel between a subscriber and the repository, and the types of 1313 interactions that must be supported between publishers and 1314 subscribers to a repository. 1316 o Define a standard interface for communications between the posture 1317 broker client and posture transport client(s) as well as the 1318 posture broker server and posture transport server(s). 1320 o Retention of posture information on the target endpoint. 1322 o Define an orchestrator component as well as publish/subscribe 1323 interface for it. 1325 o Define an evaluator component as well as an interface for it. 1327 13. Acknowledgements 1329 The authors wish to thank all of those in the TCG TNC work group who 1330 contributed to development of the TNC ECP specification upon which 1331 this document is based. 1333 +-----------------------+-------------------------------------------+ 1334 | Member | Organization | 1335 +-----------------------+-------------------------------------------+ 1336 | Padma Krishnaswamy | Battelle Memorial Institute | 1337 | | | 1338 | Eric Fleischman | Boeing | 1339 | | | 1340 | Richard Hill | Boeing | 1341 | | | 1342 | Steven Venema | Boeing | 1343 | | | 1344 | Nancy Cam-Winget | Cisco Systems | 1345 | | | 1346 | Scott Pope | Cisco Systems | 1347 | | | 1348 | Max Pritikin | Cisco Systems | 1349 | | | 1350 | Allan Thompson | Cisco Systems | 1351 | | | 1352 | Nicolai Kuntze | Fraunhofer Institute for Secure | 1353 | | Information Technology (SIT) | 1354 | | | 1355 | Ira McDonald | High North | 1356 | | | 1357 | Dr. Andreas Steffen | HSR University of Applied Sciences | 1358 | | Rapperswil | 1359 | | | 1360 | Josef von Helden | Hochschule Hannover | 1361 | | | 1362 | James Tan | Infoblox | 1363 | | | 1364 | Steve Hanna (TNC-WG | Juniper Networks | 1365 | Co-Chair) | | 1366 | | | 1367 | Cliff Kahn | Juniper Networks | 1368 | | | 1369 | Lisa Lorenzin | Juniper Networks | 1370 | | | 1371 | Atul Shah (TNC-WG Co- | Microsoft | 1372 | Chair) | | 1373 | | | 1374 | Jon Baker | MITRE | 1375 | | | 1376 | Charles Schmidt | MITRE | 1377 | | | 1378 | Rainer Enders | NCP Engineering | 1379 | | | 1380 | Dick Wilkins | Phoenix Technologies | 1381 | | | 1382 | David Waltermire | NIST | 1383 | | | 1384 | Mike Boyle | U.S. Government | 1385 | | | 1386 | Emily Doll | U.S. Government | 1387 | | | 1388 | Jessica Fitzgerald- | U.S. Government | 1389 | McKay | | 1390 | | | 1391 | Mary Lessels | U.S. Government | 1392 | | | 1393 | Chris Salter | U.S. Government | 1394 +-----------------------+-------------------------------------------+ 1396 Table 1: Members of the TNC Work Group that Contributed to the 1397 Document 1399 14. IANA Considerations 1401 This document does not define any new IANA registries. However, this 1402 document does reference other documents that do define IANA 1403 registries. As a result, the IANA Considerations section of the 1404 referenced documents should be consulted. 1406 15. Security Considerations 1408 The Endpoint Compliance Profile offers substantial improvements in 1409 endpoint security, as evidenced by the Australian Defense Signals 1410 Directorate's analysis that 85% of targeted cyber intrusions can be 1411 prevented through application whitelisting, patching applications and 1412 operating systems, and using the latest versions of applications. 1413 [DSD] Despite these gains, some security risks continue to exist and 1414 must be considered. 1416 To ensure that these benefits and risks are properly understood, this 1417 Security Considerations section includes an analysis of the benefits 1418 provided by the Endpoint Compliance Profile (Section 15.1), the 1419 attacks that may be mounted against systems that implement the 1420 Endpoint Compliance Profile (Section 15.2), and the countermeasures 1421 that may be used to prevent or mitigate these attacks (Section 15.3). 1422 Overall, a substantial reduction in cyber risk can be achieved. 1424 15.1. Security Benefits of Endpoint Compliance Profile 1426 Security weaknesses of the components for this profile should be 1427 considered in light of the practical considerations that must be 1428 addressed to have a viable solution. 1430 Posture assessment has two parts: assessment and follow-up actions. 1431 The point of posture assessment is to ensure that authorized users 1432 are using authorized software configured to be as resilient as 1433 possible against an attack. 1435 Posture assessment answers the question whether the endpoint is 1436 healthy. Our goal for posture assessment is to make it harder for an 1437 adversary to execute code on one of our endpoints. This profile 1438 represents an important first step in reaching that goal. If we keep 1439 our endpoints healthier, we are able to prevent more attacks on our 1440 endpoints and thus on our information systems. 1442 The goal of ECP is to address posture assessment in stages. Stage 1 1443 is the ability to ascertain whether all endpoints are authorized and 1444 whether all applications are authorized and up to date. Stage 2 will 1445 attempt to address the harder problem of whether all software is 1446 configured safely. Eventually, the goal is to also address 1447 remediation which is currently out-of-scope for the SACM WG; that 1448 presents a far greater security challenge than reporting, since 1449 remediation implies the ability of a remote party to modify software 1450 or its settings on endpoints. 1452 A second security consideration is how to gain visibility over every 1453 type of endpoint and every piece of software installed on the 1454 endpoint. This is a problem of scaling and observation. A solution 1455 is needed that can report from every type of endpoint. All software 1456 on the endpoint has to be discovered. Information about the software 1457 has to be up to date and accurate. The information that is 1458 discovered has to be reported in a consistent format, so 1459 administrators do not have to squander time deciphering proprietary 1460 systems and the information can be made readily useful for other 1461 security automation purposes. 1463 ECP is based on a model of a standards-based schema, a standards- 1464 based set of protocols and interfaces, and the existence of an 1465 oversight group, the IETF, that can update the data models and 1466 protocols to meet new use cases and security issues that may be 1467 discovered. 1469 The data elements in the schema determine what work can be done 1470 consistently for every endpoint and every piece of software. How the 1471 data gets populated is an important consideration. ECP leverages the 1472 SWID tags from ISO 19770-2 because the tag originates with a single 1473 authoritative source, the application vendor itself. Moreover, there 1474 is a natural incentive for the vendor to create this content, since 1475 it makes it easier for enterprises and vendors to track whether 1476 software is licensed. Practical considerations are security 1477 considerations. A sustainable business model for obtaining all the 1478 necessary content is a fundamental requirement. 1480 The NEA model is based on having a NEA client run on an endpoint that 1481 publishes posture information to a server. The advantages are easy 1482 to list. A platform vendor can implement its own NEA client and have 1483 it be compatible with the NEA server from a different vendor. The 1484 interfaces are layered on top of mature protocols such as TLS. TLS 1485 is the protocol of choice for ECP, since: 1487 o it has proven secure properties, 1489 o it can be implemented on most types of endpoints, 1491 o it allows the gathering of large amounts of information when a 1492 endpoint is connected, and 1494 o it enables use of a mechanism to ensure that the client is 1495 authenticated (authorized) - a client certificate - which also 1496 provides a consistent identifier. 1498 Mature protocols that can be implemented on most types of endpoints 1499 and a standards-based schema with a sustainable business model are 1500 both critical security considerations for compliance. 1502 Additionally, it is important to consider the future stages for ECP 1503 such as a posture assessment being followed up by some action (e.g. 1504 remediation, alert, etc.). Ensuring that clients are taking 1505 instructions only from authorized parties will be critical. Inasmuch 1506 as it is practical, enterprises will want to use the same 1507 infrastructure and investment in PKI to send those instructions to a 1508 client. 1510 Likewise, as more information with more value is gathered from 1511 endpoints, we will also want to ensure that this information is only 1512 released to authorized applications and parties. For the next stage 1513 of ECP, SACM may want to define an interface on the repository that 1514 can be queried by other security automation applications to make it 1515 easier to detect attacks and for other security automation 1516 applications. This interface has to be standards-based for 1517 enterprises to reap the benefits of innovation that can be achieved 1518 by making the enterprise's data available to other tools and 1519 services. 1521 15.2. Threat Model 1523 This section lists the attacks that can be mounted on an Endpoint 1524 Compliance Profile environment. The following section (Section 15.3) 1525 describes countermeasures. 1527 Because the Endpoint Compliance Profile describes a specific use case 1528 for NEA components, many security considerations for these components 1529 are addressed in more detail in the technical specifications: 1530 [I-D.ietf-sacm-nea-swima-patnc], [IF-IMC], [RFC5793], 1531 [Server-Discovery], [RFC6876], [IF-IMV]. 1533 15.2.1. Endpoint Attacks 1535 While the Endpoint Compliance Profile provides substantial 1536 improvements in endpoint security as described in Section 15.1, a 1537 certain percentage of endpoints will always get compromised. For 1538 this reason, all parties must regard data coming from endpoints as 1539 potentially unreliable or even malicious. An analogy can be drawn 1540 with human testimony in an investigation or trial. Human testimony 1541 is essential but must be regarded with suspicion. 1543 o Compromise of endpoint: A compromised endpoint may report false 1544 information to confuse or even provide maliciously crafted 1545 information with a goal of infecting others. 1547 o Putting bad information in SWID directory: Even if an endpoint is 1548 not completely compromised, some of the software running on it may 1549 be unreliable or even malicious. This software, potentially 1550 including the SWID generation or discovery tool, or malicious 1551 software pretending to be a SWID generation or discovery tool, can 1552 place incorrect or maliciously crafted information into the SWID 1553 directory. Endpoint users may even place such information in the 1554 directory, whether motivated by curiosity or confusion or a desire 1555 to bypass restrictions on their use of the endpoint. 1557 o Identity spoofing (impersonation): A compromised endpoint may 1558 attempt to impersonate another endpoint to gain its privileges or 1559 to besmirch the reputation of that other endpoint. 1561 15.2.2. Network Attacks 1563 A variety of attacks can be mounted using the network. Generally, 1564 the network cannot be trusted. 1566 o Eavesdropping, modification, injection, replay, deletion 1568 o Traffic analysis 1570 o Denial of service and blocking traffic 1572 15.2.3. Posture Manager Attacks 1574 The posture manager is a critical security element and therefore 1575 merits considerable scrutiny. 1577 o Compromised trusted manager: A compromised posture manager or a 1578 malicious party that is able to impersonate a posture manager can 1579 incorrectly grant or deny access to endpoints, place incorrect 1580 information into the repository, or send malicious messages to 1581 endpoints. 1583 o Misconfiguration of posture manager: Accidental or purposeful 1584 misconfiguration of a trusted posture manager can cause effects 1585 that are similar to those listed for compromised trusted posture 1586 manager. 1588 o Malicious untrusted posture manager: An untrusted posture manager 1589 cannot mount any significant attacks because all properly 1590 implemented endpoints will refuse to engage in any meaningful 1591 dialog with such a posture manager. 1593 15.2.4. Repository Attacks 1595 The repository is also an important security element and therefore 1596 merits careful scrutiny. 1598 o Putting bad information into trusted repository: An authorized 1599 repository client such as a server may be able to put incorrect 1600 information into a trusted repository or delete or modify 1601 historical information, causing incorrect decisions about endpoint 1602 security. Placing maliciously crafted data in the repository 1603 could even lead to compromise of repository clients, if they fail 1604 to carefully check such data. 1606 o Compromised trusted repository: A compromised trusted repository 1607 or a malicious untrusted repository that is able to impersonate a 1608 trusted repository can lead to effects similar to those listed for 1609 "Putting bad information into trusted repository". Further, a 1610 compromised trusted repository can report different results to 1611 different repository clients or deny access to the repository for 1612 selected repository clients. 1614 o Misconfiguration of trusted repository: Accidental or purposeful 1615 misconfiguration of a trusted repository can deny access to the 1616 repository or result in loss of historical data. 1618 o Malicious untrusted repository: An untrusted repository cannot 1619 mount any significant attacks because all properly implemented 1620 repository clients will refuse to engage in any meaningful dialog 1621 with such a repository. 1623 15.3. Countermeasures 1625 This section lists the countermeasures that can be used in an 1626 Endpoint Compliance Profile environment. 1628 15.3.1. Countermeasures for Endpoint Attacks 1630 This profile is in and of itself a countermeasure for a compromised 1631 endpoint. A primary defense for an endpoint is to run up to date 1632 software configured to be run as safely as possible. 1634 Ensuring that anti-virus signatures are up to date and that a 1635 firewall is configured are also protections for an endpoint that are 1636 supported by the current NEA specifications. 1638 Endpoints that have hardware cryptographic modules that are 1639 provisioned by the enterprise, in accordance with [IEEE-802-1ar], can 1640 protect the private keys used for authentication and help prevent 1641 adversaries from stealing credentials that can be used for 1642 impersonation. Future versions of the Endpoint Compliance Profile 1643 may want to discuss in greater detail how to use a hardware 1644 cryptographic module, in accordance with [IEEE-802-1ar], to protect 1645 credentials and to protect the integrity of the code that executes 1646 during the bootstrap process. 1648 15.3.2. Countermeasures for Network Attacks 1650 To address network attacks, [RFC6876] includes required encryption, 1651 authentication, integrity protection, and replay protection. 1652 [Server-Discovery] also includes authorization checks to ensure that 1653 only authorized servers are trusted by endpoints. Any unspecified or 1654 not yet specified network protocols employed in the Endpoint 1655 Compliance Profile (e.g. the protocol used to interface with the 1656 repository) should include similar protections. 1658 These protections reduce the scope of the network threat to traffic 1659 analysis and denial of service. Countermeasures for traffic analysis 1660 (e.g. masking) are usually impractical but may be employed. 1661 Countermeasures for denial of service (e.g. detecting and blocking 1662 particular sources) SHOULD be used when appropriate to detect and 1663 block denial of service attacks. These are routine practices in 1664 network security. 1666 15.3.3. Countermeasures for Posture Manager Attacks 1668 Because of the serious consequences of posture manager compromise, 1669 posture managers SHOULD be especially well hardened against attack 1670 and minimized to reduce their attack surface. They SHOULD be 1671 monitored using the NEA protocols to ensure the integrity of the 1672 behavior and analysis data stored on the posture manager and SHOULD 1673 utilize a [IEEE-802-1ar]compliant hardware cryptographic module for 1674 identity and/or integrity measurements of the posture manager. They 1675 should be well managed to minimize vulnerabilities in the underlying 1676 platform and in systems upon which the posture manager depends. 1677 Network security measures such as firewalls or intrusion detection 1678 systems may be used to monitor and limit traffic to and from the 1679 posture manager. Personnel with administrative access to the posture 1680 manager should be carefully screened and monitored to detect problems 1681 as soon as possible. Posture manager administrators should not use 1682 password-based authentication but should instead use non-reusable 1683 credentials and multi-factor authentication (where available). 1684 Physical security measures should be employed to prevent physical 1685 attacks on posture managers. 1687 To ease detection of posture manager compromise should it occur, 1688 posture manager behavior should be monitored to detect unusual 1689 behavior (such as a server reboot, unusual traffic patterns, or other 1690 odd behavior). Endpoints should log and/or notify users and/or 1691 administrators when peculiar posture manager behavior is detected. 1692 To aid forensic investigation, permanent read-only audit logs of 1693 security-relevant information pertaining to posture manager 1694 (especially administrative actions) should be maintained. If posture 1695 manager compromise is detected, the posture manager's certificate 1696 should be revoked and careful analysis should be performed of the 1697 source and impact of this compromise. Any reusable credentials that 1698 may have been compromised should be reissued. 1700 Endpoints can reduce the threat of server compromise by minimizing 1701 the number of trusted posture managers, using the mechanisms 1702 described in [Server-Discovery]. 1704 15.3.4. Countermeasures for Repository Attacks 1706 If the host for the repository is located on its own endpoint, it 1707 should be protected with the same measures taken to protect the 1708 posture manager. In this circumstance, all messages between the 1709 posture manager and repository should be protected with a mature 1710 security protocol such as TLS or IPsec. 1712 The repository can aid in the detection of compromised endpoints if 1713 an adversary cannot tamper with its contents. For instance, if an 1714 endpoint reports that it does not have an application with a known 1715 vulnerability installed, an administrator can check whether the 1716 endpoint might be lying by querying the repository for the history of 1717 what applications were installed on the endpoint. 1719 To help prevent tampering with the information in the repository: 1721 1. Only authorized parties should have privilege to run code on the 1722 endpoint and to change the repository. 1724 2. If a separate endpoint hosts the repository, then the 1725 functionality of that endpoint should be limited to hosting the 1726 repository. The firewall on the repository should only allow 1727 access to the posture manager and to any endpoint authorized for 1728 administration. 1730 3. The repository should ideally use "write once" media to archive 1731 the history of what was placed in the repository, to include a 1732 snapshot of the current status of applications on endpoints. 1734 16. Privacy-Considerations 1736 The Endpoint Compliance Profile specifically addresses the collection 1737 of posture data from enterprise endpoints by an enterprise network. 1738 As such, privacy is not going to often arise as a concern for those 1739 deploying this solution. 1741 A possible exception may be the concerns a user may have when 1742 attempting to connect a personal endpoint (such as a phone or mobile 1743 endpoint) to an enterprise network. The user may not want to share 1744 certain details, such as an endpoint identifier or SWID tags, with 1745 the enterprise. The user can configure their NEA client to reject 1746 requests for this information; however, it is possible that the 1747 enterprise policy will not allow the user's endpoint to connect to 1748 the network without providing the requested data. 1750 17. Change Log 1752 17.1. -00 to -01 1754 There are no textual changes associated with this revision. This 1755 revision simply reflects a resubmission of the document so that it 1756 remains in active status. 1758 17.2. -01 to -02 1760 Added references to the Software Inventory Message and Attributes 1761 (SWIMA) for PA-TNC I-D. 1763 Replaced references to PC-TNC with IF-IMC. 1765 Removed erroneous hyphens from a couple of section titles. 1767 Made a few minor editorial changes. 1769 17.3. -02 to -00 1771 Draft adopted by IETF SACM WG. 1773 17.4. -00 to -01 1775 Significant edits to up-level the draft to describe SACM collection 1776 over multiple different protocols. 1778 Replaced references to SANS with CIS. 1780 Made other minor editorial changes. 1782 18. References 1784 18.1. Informative References 1786 [CIS] http://www.cisecurity.org/controls/, "CIS Critical 1787 Security Controls". 1789 [DSD] http://www.dsd.gov.au/publications/csocprotect/ 1790 top_4_mitigations.htm, "Top 4 Mitigation Strategies to 1791 Protect Your ICT System", November 2012. 1793 [IEEE-802-1ar] 1794 Institute of Electrical and Electronics Engineers, "IEEE 1795 802.1ar", December 2009. 1797 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1798 Tardo, "Network Endpoint Assessment (NEA): Overview and 1799 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1800 . 1802 [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1803 Architecture for Interoperability, Version 1.5", February 1804 2012. 1806 18.2. Normative References 1808 [I-D.ietf-mile-xmpp-grid] 1809 Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, 1810 "Using XMPP for Security Information Exchange", draft- 1811 ietf-mile-xmpp-grid-04 (work in progress), October 2017. 1813 [I-D.ietf-netconf-yang-push] 1814 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1815 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1816 Subscription", draft-ietf-netconf-yang-push-12 (work in 1817 progress), December 2017. 1819 [I-D.ietf-sacm-nea-swima-patnc] 1820 Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 1821 J. Fitzgerald-McKay, "Software Inventory Message and 1822 Attributes (SWIMA) for PA-TNC", draft-ietf-sacm-nea-swima- 1823 patnc-01 (work in progress), September 2017. 1825 [I-D.ietf-sacm-terminology] 1826 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1827 Winget, "Terminology for Security Assessment", draft-ietf- 1828 sacm-terminology-05 (work in progress), August 2014. 1830 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 1831 IF-IMC, Version 1.3", February 2013. 1833 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 1834 IF-IMV, Version 1.4", December 2014. 1836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1837 Requirement Levels", BCP 14, RFC 2119, 1838 DOI 10.17487/RFC2119, March 1997, 1839 . 1841 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1842 (PA) Protocol Compatible with Trusted Network Connect 1843 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1844 . 1846 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1847 A Posture Broker (PB) Protocol Compatible with Trusted 1848 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 1849 March 2010, . 1851 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1852 Transport Protocol over TLS (PT-TLS)", RFC 6876, 1853 DOI 10.17487/RFC6876, February 2013, 1854 . 1856 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 1857 Posture Assessment: Enterprise Use Cases", RFC 7632, 1858 DOI 10.17487/RFC7632, September 2015, 1859 . 1861 [Server-Discovery] 1862 Trusted Computing Group, "DRAFT: TCG Trusted Network 1863 Connect PDP Discovery and Validation, Version 1.0", 1864 October 2015. 1866 [SWID] "Information technology--Software asset management--Part 1867 2: Software identification tag", ISO/IEC 9899:1999, 2009. 1869 Authors' Addresses 1871 Danny Haynes 1872 The MITRE Corporation 1873 202 Burlington Road 1874 Bedford, MA 01730 1875 USA 1877 Email: dhaynes@mitre.org 1879 Jessica Fitzgerald-McKay 1880 Department of Defense 1881 9800 Savage Road 1882 Ft. Meade, Maryland 1883 USA 1885 Email: jmfitz2@nsa.gov 1886 Lisa Lorenzin 1887 Pulse Secure 1888 2700 Zanker Rd., Suite 200 1889 San Jose, CA 95134 1890 US 1892 Email: llorenzin@pulsesecure.net