SACM D. Haynes
Internet-Draft The MITRE Corporation
Intended status: Standards Track J. Fitzgerald-McKay
Expires: March 12, 2018 Department of Defense
L. Lorenzin
Pulse Secure
September 8, 2017

Endpoint Compliance Profile


This document specifies the Endpoint Compliance Profile, a high-level specification that describes a specific combination and application of IETF and TNC protocols and interfaces specifically designed to support ongoing assessment of endpoint posture and the controlled exposure of collected posture information to appropriate security applications. This document is a subset of the Trusted Computing Group's Endpoint Compliance Profile Version 1.0 specification.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 12, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The Endpoint Compliance Profile (ECP) builds on prior work from the IETF NEA WG, the Netmod WG, and the Trusted Network Communications (TNC) WG of the Trusted Computing Group [TNC], to standardize the collection, storage and sharing of posture information from network-connected endpointgs, including user endpoints, servers, and infrastructure. The first generation of this specification focuses on reducing the security exposure of a network by enabling event-driven posture collection, as well as standardized querying for additional endpoint data as needed. Standadrid collection improves network security by confirming that endpoints are known and authrosized, and are compliant with network policy.

When ECP is used, posture information is gathered by collectors running on the endpoint and is forwarded to a posture server, which stores it in a repository. This information is gathered while the endpoint is already connected to the network. Administrators will query the repository to determine the posture status of an endpoint. For example, if a vulnerability is discovered in a product, an administrator may query the repository to determine which endpoints have the vulnerable software installed and thus require some follow-up action.

The ECP then describes how to expose information—such as endpoint purpose, the software that is supposed to be running on an endpoint, and the activities an endpoint is supposed to be performing—to sensors that are looking for indicators of attacks and malicious activity on the network.

1.1. Preventative Posture Assessments

The value of continuous endpoint posture assessment is well established. Security experts have for years identified software updating and patching as a critical step for preventing intrusions. Application white listing, patching applications and operating systems, and using the latest versions of applications top the Defense Signals Directorate’s “Top 4 Mitigations to Protect Your ICT System”. [DSD] “Inventory of Authorized and Unauthorized Endpoints”, “Inventory of Authorized and Unauthorized Software”, and “Continuous Vulnerability Assessment and Remediation” are Critical Controls 1, 2, and 4, respectively, of the CIS “20 Critical Security Controls”. [CIS] While there are commercially available solutions that attempt to address these security controls, these solutions do not run on all types of endpoints; consistently interoperate with other tools that could make use of the data collected; collect posture information from all types of endpoints in a consistent, standardized schema; or require vetted, standardized protocols that have been evaluated by the international community for cryptographic soundness.

As is true of most solutions offered today, the solution found in the ECP does not attempt to solve the lying endpoint problem. An endpoint that has already been infected with malicious software can provide false information about its identity and the software it is running. The primary purpose of the ECP is not to detect infected endpoints; rather, it focuses on ensuring that healthy endpoints remain healthy by keeping software up-to-date and patched. The first goal of the ECP is to help an administrator be able to readily determine which endpoints require some follow-up action. By sharing posture informatino with sensors on the network, ECP aids in the detection of attacks on endpoints and drives follow-up actions.

1.2. Standardized Schema

The ECP requires the use of standardized schema for the exchange of posture information. This helps to ensure that the posture information sent from endpoints to the repository can be easily stored, due to their known format, and shared with authorized endpoints and users. Standardized schema also enable collection from myriad types of endpoints. Such standardization saves implementers time and money—time that does not have to be spent integrating new schema into the enterprise’s reporting mechanisms, and money that does not have to be spent on developing tools to parse information from each type of endpoint connected to the network. Standardized schema also enable the development of standardized client software. This allows endpoint vendors to include their own client software that can interoperate with posture assessment infrastructure and thus not have to introduce third party code in their products.

1.3. Secure Standardized Protocols

Posture information must be sent over mature, standardized protocols to ensure the confidentiality and authenticity of this data while in transit. Conformant implementations of the ECP include [RFC6876] for communication between the endpoint and the server. This protocol allows networks that implement this solution to collect large amounts of posture information from an endpoint in order to make decisions about that endpoint’s compliance to some policy. This Profile offers a solution for all endpoints already connected to the network. Periodic assessments and automated reporting of changes to endpoint posture allow for instantaneous identification of connected endpoints that are no longer compliant to some policy.

Endpoint                 Server
+---------------+        +---------------+
|               |        |               |
| +-----------+ |        | +-----------+ |     
| |           | |        | |           | |                  
| | Posture   | |        | | Posture   | |
| | Collector | |        | | Validator | |
| +-----------+ |        | +-----------+ |            
|      |        |        |      |        |     
|      |        |        |      |        |     Repository
|      |        |        |      |        |     +--------+
| +-----------+ |        | +-----------+ |     |        |
| | Posture   | |        | | Posture   | |     |        |
| | Client    | |        | | Server    | |---->|        |
| +-----------+ |        | +-----------+ |     |        |
|      |        |        |      |        |     |        |
|      |        |        |      |        |     +--------+
|      |        |        |      |        | 
| +-----------+ |        | +-----------+ |
| | Comms     | |        | | Comms     | |
| | Client    | |<------>| | Server    | |
| +-----------+ |        | +-----------+ |
|               |        |               |
+---------------+        +---------------+

Figure 1: The Endpoint Compliance Architecture

The IETF NEA WG has designed an architecture to support endpoint posture assessment. Figure 1 illustrates the architectural components used in the Endpoint Compliance Profile:

1.4. Keywords

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]. This specification does not distinguish blocks of informative comments and normative requirements. Therefore, for the sake of clarity, note that lower case instances of must, should, etc. do not indicate normative requirements.

2. Terminology

This document uses terms as defined in [I-D.ietf-sacm-terminology] unless otherwise specified.

3. Endpoint Compliance Profile

The Endpoint Compliance Profile describes how IETF and TNC data models and protocols can be used to support the posture assessment of endpoints on a network. This profile does not generate new schema or protocols; rather, it offers a full end-to-end solution for posture assessment, as well as a fresh perspective on how existing standards can be leveraged against vulnerabilities.

3.1. Posture Assessments

The Endpoint Compliance Profile 1.0 describes how IETF and TNC data modles and protocols make it possible to perform posture assessments against all network-connected endpoints by:

  1. uniquely identifying the endpoint;
  2. collecting and assessing posture based on data from the endpoint;
  3. creating a secure, authenticated, confidential channel between the endpoint and the server;
  4. enabling the endpoint to notify the server about changes to its configuration;
  5. enabling the posture server to request information about the configuration of the endpoint; and
  6. storing the posture information in a repository linked to the identifier for the endpoint.

3.2. Data Storage

The Endpoint Compliance Profile 1.0 focuses on being able to collect posture information from an endpoint and store it in a repository. This makes posture information from a network’s endpoints available to authorized parties. Uses of this data are innumerable—vulnerability management, asset management, software asset management, and configuration management solutions, analytics tools, endpoints that need to make connectivity decisions, and metrics reporting scripts, among others, are all able to reference the data stored in the repository to achieve their purposes.

3.3. Data Sharing


4. Background

4.1. Purpose of the Endpoint Compliance Profile

The Endpoint Compliance Profile describes a standard way to collect endpoint posture information s and to make it available to other authorized parties.

4.2. Supported Use Cases

The Endpoint Compliance Profile focuses on the posture assessment of enterprise endpoints on enterprise networks. Use cases supported by the Endpoint Compliance Profile 1.0 are as follows:

4.2.1. Connected and Compliant

A network-connected endpoint sends posture information using standard schemas an protocols.

Endpoint                     Server
+-------------------+        +---------------+
|                   |        |               |
| +---------+       |        |               |
| | Endpoint|       |        |               |
| | Posture |       |        | +-----------+ |
| | Data    |       |        | |           | |
| +---------+       |        | | Validator | |
|  |                |        | |           | |
|  |                |        | +-----------+ |
|  |  +-----------+ |        |      |        |     
|  +->|           | |        |      |        |                  
|     | Collector | |        |      |        |
|     |           | |        |      |        |
|     +-----------+ |        |      |        |            
|          |        |        |      |        |     
|          |        |        |      |        |     Repository
|          |        |        |      |        |     +--------+
|     +-----------+ |        | +-----------+ |     |        |
|     | Posture   | |        | | Posture   |       |        |
|     | Client    | |        | |  Server   | |---->|        |
|     +-----------+ |        | +-----------+ |     |        |
|               |   |        |      |        |     |        |
| +----------+  |   |        |      |        |     +--------+
| | Endpoint |  |   |        |      |        | 
| | ID       |  |   |        |      |        |
| +----------+  |   |        |      |        |  
|  |            |   |        |      |        |
|  |  +-----------+ |        | +-----------+ |
|  +->| Comms     | |        | | Comms     | |
|     | Client    | |<------>| |  Server   | |
|     +-----------+ |        | +-----------+ |
|                   |        |               |
+-------------------+        +---------------+             

Figure 2: Connected and Compliant Use Case

  1. If necessary, the endpoint finds and validates the server in compliance with [Server-Discovery].
  2. The Posture Transport Client (PTC) on the endpoint and Posture Transport Server (PTS) on the server complete a TLS handshake, during which endpoint identity information is exchanged.
  3. Either the NEA Server (NEAS) on the server or the NEA Client (NEAC) on the endpoint initiates a posture assessment. Checks may be triggered for multiple reasons, including:
    policy states that a previous assessment has aged out and become invalid;
    the NEAC notices that the relevant posture information on the endpoint has changed, (for example, due to application updates, deletions or additions); or
    the NEAS is alerted by a sensor or an administrator (via the server’s user interface) that an assessment must be completed.

    All information exchanges between the PCs and PVs are subject to the enterprise's policy, which may limit the content or size of information sent between the endpoint and the server.

  4. The SWID Posture Collector on the endpoint collects from the SWID tag directory on the endpoint. This data is sent via the NEAC and PTC to the server.
  5. Once the posture information is received by the PTS, it is forwarded to the SWID Posture Validator via the NEAS. The SWID Posture Validator also forwards the posture information to the repository. The posture information is stored along with past posture information collected about the endpoint.

4.2.2. Exposing Data to the Network

Endpoint                      Server
+--------------------+        +---------------+
|                    |        |               |
| +-------+          |        | +-----------+ |
| | SWIDs |          |        | | SWID      | |
| +-------+          |        | | Posture   | |
|  |                 |        | | Validator | |
|  |                 |        | +-----------+ |
|  |  +-----------+  |        |      |        |     
|  +->| SWID      |  |        |      |        |                   
|     | Posture   |  |        |      |        |
|     | Collector |  |        |      |        |
|     +-----------+  |        |      |        |            
|          |         |        |      |        |     
|          | IF-IMC  |        |      | IF-IMV |     Repository
|          |         |        |      |        |     +--------+
|     +-----------+  |        | +-----------+ |     |        |
|     | PB Client |  |        | | PB Server | |---->|        |
|     +-----------+  |        | +-----------+ |     |        |
|               |    |        |      |        |     |        |
| +----------+  |    |        |      |        |     +--------+
| | Endpoint |  |    |        |      |        | 
| | ID       |  |    |        |      |        |
| +----------+  |    |        |      |        |  
|  |            |    |        |      |        |
|  |  +-----------+  |        | +-----------+ |
|  +->| PT Client |  |<------>| | PT Server | |
|     +-----------+  | PT-TLS | +-----------+ |
|                    |        |               |
+--------------------+        +---------------+                         
                            | Administrative Interface and API |

Figure 3: Exposing Data to the Network

Because the endpoint posture information was sent in a standards-based schema (ISO/IEC 19770-2:2009) over secure, standardized protocols, and the SWID tags are stored in a centralized repository linked to unique endpoint identifiers, authorized parties are able to access the posture information. Such authorized parties may include, but are not limited to, administrators or endpoint owners (via the server's administrative interface), and other pieces of infrastructure that can make use of this data (via the server’s API). The server will provide:

The endpoint will publish updates as its local SWID directory changes, as well as each time it disconnects and reconnects to the network. Asset Management

Using the administrative interface on the server, an authorized user can learn:

The ability to answer these questions offers a standards-based approach to asset management, which is a vital part of enterprise processes such as compliance report generation for the Federal Information Security Modernization Act (FISMA), Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), etc. Vulnerability Searches

The administrative interface also provides the ability for authorized users or infrastructure to locate endpoints running software for which vulnerabilities have been announced. Because of

  1. the unique IDs assigned to each endpoint; and
  2. the rich application data provided in the endpoints’ posture information,

the repository can be queried to find all endpoints running a vulnerable application. Endpoints suspected of being vulnerable can be addressed by the administrator or flagged for further scrutiny. Threat Detection and Analysis

The repository’s standardized API allows authorized infrastructure endpoints and software to search endpoint posture assessment information for evidence that an endpoint’s software inventory has changed, and can make endpoint software inventory data available to other endpoints. This automates security data sharing in a way that expedites the correlation of relevant network data, allowing administrators and infrastructure endpoints to identify odd endpoint behavior and configuration using secure, standards-based schema and protocols.

4.2.3. Non-supported Use Cases

Several use cases, including but not limited to these, are not covered by the Endpoint Compliance Profile 1.0:

4.2.4. Profile Requirements

Here are the requirements that the Endpoint Compliance Profile protocol must meet in order to successfully fit in the SACM architecture.

4.2.5. Assumptions

Here are the assumptions that the Endpoint Compliance Profile makes about other components in the SACM architecture.

In addition, the Endpoint Compliance Profile makes the following assumptions about the SACM ecosystem:

5. Endpoint Compliance Requirements

These requirements are written with a view to performing a posture assessment on an endpoint; as the Endpoint Compliance Profile grows and evolves, these requirements will be expanded to address issues that arise. Note that these requirements refer to defined components of the NEA architecture. As with the NEA architecture, implementers have discretion as to how these NEA components map to separate pieces of software or endpoints.

5.1. Endpoint Pre-Provisioning

The following requirements assume that the platform or OS vendor supports the use of SWID tags and has identified a standard directory location for the SWID tags to be located as specified by [SWID].

5.1.1. SWID Tags

The primary content for the Endpoint Compliance Profile 1.0 is the information conveyed in the elements of a SWID tag.

The endpoint MUST have SWID tags stored in a directory specified in [SWID]. The tags SHOULD be provided by the software vendor; they MAY also be generated by: [SWID]. These tags, and the directory in which they are stored, MUST be updated as software is added, removed, or updated.

The elements in the SWID tag MUST be populated as specified in

5.1.2. Endpoint Identity and Machine Certificate

The endpoint SHOULD authenticate to the server using a machine certificate during the establishment of the outer tunnel achieved with PT. [IF-IMV] specifies how to pull an endpoint ID out of a machine certificate. An endpoint ID SHOULD be created in conformance with [IF-IMV] from a machine certificate sent via [RFC6876].

In the future, the identity could be a hardware certificate compliant with [IEEE-802-1ar]; ideally, this ID SHOULD be associated with the identity of a hardware cryptographic module, in accordance with [IEEE-802-1ar], if present on the endpoint. The enterprise SHOULD stand up a certificate root authority; install its root certificate on endpoints and on the server; and provision the endpoints and the server with machine certificates. The endpoint MAY authenticate to the server using a combination of the machine account and password; however, this is less secure and not recommended.

5.2. Posture Validators and Posture Collectors

Any PC used in an Endpoint Compliance Profile solution MUST be conformant with [IF-IMC]; an Internet-Draft, under development, that is a subset of the TCG TNC Integrity Measurement Collector interface [IF-IMC] and will be submitted in the near future. Any Posture Validator used in an Endpoint Compliance Profile solution MUST be conformant with [IF-IMV].

5.2.1. SWID Posture Collectors and Posture Validators The SWID Posture Collector

For the Endpoint Compliance Profile, the SWID Posture Collector MUST be conformant with [I-D.ietf-sacm-nea-swid-patnc], which includes requirements for:

  1. Collecting SWID tags from the SWID directory
  2. Monitoring the SWID directory for changes
  3. Initiating a session with the server to report changes to the directory
  4. Maintaining a list of changes to the SWID directory when updates take place and no PT-TLS connection can be created with the server
  5. Responding to a request for SWID tags from the SWID Posture Validator on the server
  6. Responding to a query from the SWID Posture Validator as to whether all updates have been sent

The SWID Posture Collector is not responsible for detecting that the SWID directory was not updated when an application was either installed or uninstalled. The SWID Posture Validator

Conformance to [I-D.ietf-sacm-nea-swid-patnc] enables the SWID Posture Validator to:

  1. Send messages to the SWID Posture Collector (at the behest of the administrator at the server console) requesting updates for SWID tags located on endpoint
  2. Ask the SWID Posture Collector whether all updates to the SWID directory located at the server have been sent
  3. Compare an endpoint’s SWID posture information to policy, and make a recommendation to the NEAS about the endpoint

In addition to these requirements, a SWID Posture Validator used in conformance with this profile MUST be capable of passing information from the posture assessment results and the endpoint identity associated with those results to the repository for storage.

5.3. NEA Client (NEAC) and NEA Server (NEAS)

[RFC5793] describes a standard way for the NEAC and the NEAS to exchange messages.

5.3.1. NEAC

The NEAC MUST conform to [RFC5793], which levies a number of requirements against the NEAC. A NEAC that complies with these requirements will be able to: [IF-IMC] to enable communications with the SWID Posture Collector.

  1. attempt to initiate a session with the NEAS if the SWID Posture Collector makes a request to send an update to the SWID directory to the server;
  2. notify the SWID Posture Collector if no PT-TLS session with the server can be created;
  3. notify the SWID Posture Collector when a PT-TLS session is established; and
  4. receive information from the PCs, forward this information to the server via the PTC.

The NEAC MUST also conform to

5.3.2. NEAS

The NEAS MUST conform to all requirements in the [RFC5793] and [IF-IMV] specifications. Conformance to [IF-IMV] enables the NEAS to obtain endpoint identity information from the PTS, and pass this information to any IMVs on the server.

5.4. Repository

ECP 1.0 requires a simple administrative interface for the repository. PVs on the server receive the endpoint data via PA-TNC [RFC5792] messages sent from corresponding PCs on an endpoint and store this information in the repository linked to the identity of the endpoint where the PCs are located.

The administrative interface SHOULD enable an administrator to:

  1. Query which endpoints have reported SWID tags for a particular application
  2. Query which SWID tags are installed on a particular endpoint
  3. Query tags based on characteristics, such as vendor, publisher, etc.

In the future, if SACM decides to develop an interface to the repository server, it should consider requirements for:

  1. Creating a secure channel between a publisher and the repository
  2. Creating a secure channel between a subscriber and the repository
  3. The types of interactions that must be supported between publishers and subscribers to a repository

6. Posture Transport Client (PTC) and Posture Transport Server (PTS)

The PT-TLS protocol provides a transport service for carrying the PB-TNC protocol messages between the endpoint and the server.

The PTC and PTS MUST implement PT-TLS, since a connection is needed that:

The PTC and PTS MUST support the use of machine certificates for TLS at each endpoint consistent with the requirements stipulated in [RFC6876] and [Server-Discovery].

The PTC MUST be able to locate an authorized server, and switch to a new server when required by the network, in conformance with [Server-Discovery].

7. Administrative Interface and API

An interface is necessary to allow administrators to manage the endpoints and software used in the Endpoint Compliance Profile. This interface SHOULD be accessible either on or through (as in the case of a remotely hosted interface) the server. Using this interface, an authorized user or administrator SHOULD be able to:

An API is necessary to allow infrastructure endpoints and software access to the information stored in the repository. Using this API, an authorized endpoint SHOULD be able to:

8. Endpoint Compliance Profile Examples

8.1. Continuous Posture Assessment of an Endpoint

Endpoint                 Server
+---------------+        +---------------+
|               |        |               |
| +-----------+ |        | +-----------+ |     
| | SWID      | |        | | SWID      | |                   
| | Posture   | |        | | Posture   | |
| | Collector | |        | | Validator | |
| +-----------+ |        | +-----------+ |            
|      |        |        |      |        |    
|      | IF-IMC |        |      | IF-IMV |   
|      |        |        |      |        |   
| +-----------+ |        | +-----------+ |   
| | PB Client | |        | | PB Server | |
| +-----------+ |        | +-----------+ |
|      |        |        |      |        |
|      |        |        |      |        |
|      |        |        |      |        | 
| +-----------+ |        | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
|               |        |               |
+---------------+        +---------------+

Figure 4: Continuous Posture Assessment of an Endpoint

8.1.1. Change on Endpoint Triggers Posture Assessment

A new application is installed on the endpoint, and the SWID directory is updated. This triggers an update from the SWID Posture Collector to the SWID Posture Validator. The message is sent down the NEA stack, encapsulated by NEA protocols until it is sent by the PTC to the PTS. The PTS then forwards it up through the stack, where the layers of encapsulation are removed until the SWID Message arrives at the SWID Posture Validator.

Endpoint                         Server
+---------------+                +---------------+
|               |                |               |
| +-----------+ |                | +-----------+ |     
| | SWID      | |                | | SWID      | |                   
| | Posture   | |                | | Posture   | | 
| | Collector | |                | | Validator | |
| +-----------+ |                | +-----------+ |            
|      |        | SWID Message   |      |        |    
|      | IF-IMC | for PA-TNC     |      | IF-IMV |   
|      |        |                |      |        |   
| +-----------+ |                | +-----------+ |   
| | PB Client | |                | | PB Server | |
| +-----------+ |                | +-----------+ |
|      |        |                |      |        |
|      |        | PB-TNC {SWID   |      |        |
|      |        | Message for    |      |        | 
|      |        | PA-TNC}        |      |        | 
| +-----------+ |                | +-----------+ |
| | PT Client | |<-------------->| | PT Server | |
| +-----------+ | PT-TLS {PB-TNC | +-----------+ |
|               | {SWID Message  |               |
+---------------+ for PA-TNC}}   +---------------+

Figure 5: Compliance Protocol Encapsulation

The SWID Posture Validator stores the new tag information in the repository. If the tag indicates that the endpoint is compliant to the policy, then the process is complete until the next time an update is needed (either because policy states that the endpoint must submit posture assessment results periodically or because an install/uninstall/update on the endpoint triggers a posture assessment).

Endpoint                 Server
+---------------+        +---------------+
|               |        |               |
| +-----------+ |        | +-----------+ |        
| | SWID      | |        | | SWID      |-|-+               
| | Posture   | |        | | Posture   | | |
| | Collector | |        | | Validator | | | 
| +-----------+ |        | +-----------+ | |             
|      |        |        |      |        | |     Repository
|      | IF-IMC |        |      | IF-IMV | |     +--------+
|      |        |        |      |        | |     |        |
| +-----------+ |        | +-----------+ | |     |        |
| | PB Client | |        | | PB Server | | +---->|        |
| +-----------+ |        | +-----------+ |       |        |
|      |        |        |      |        |       +--------+
|      |        |        |      |        |
|      |        |        |      |        | 
| +-----------+ |        | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
|               |        |               |
+---------------+        +---------------+

Figure 6: Storing SWIDs in the Repository

If the endpoint has fallen out of compliance with a policy, the server can alert the administrator via the server’s administrative interface. The administrator can then take steps to address the problem. If the administrator has already established a policy for automatically addressing this problem, that policy will be followed.

Endpoint                 Server            |  / \  
+---------------+        +---------------+ |
|               |        |               | |              
| +-----------+ |        | +-----------+ | |    
| | SWID      | |        | | SWID      |-|-+               
| | Posture   | |        | | Posture   | |
| | Collector | |        | | Validator | |
| +-----------+ |        | +-----------+ |             
|      |        |        |      |        |       Repository
|      | IF-IMC |        |      | IF-IMV |       +--------+
|      |        |        |      |        |       |        |
| +-----------+ |        | +-----------+ |       |        |
| | PB Client | |        | | PB Server | |       |        |
| +-----------+ |        | +-----------+ |       |        |
|      |        |        |      |        |       +--------+
|      |        |        |      |        |
|      |        |        |      |        | 
| +-----------+ |        | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
|               |        |               |
+---------------+        +---------------+

Figure 7: Server Alerts Network Admin

8.2. Administrator Searches for Vulnerable Endpoints

An announcement is made that a particular version of a piece of software has a vulnerability. The administrator uses the Administrative Interface on the server to search the repository for endpoints that reported the SWID tag for the vulnerable software.

Endpoint                 Server            |  / \  
+---------------+        +---------------+ |
|               |        |               | |              
| +-----------+ |        | +-----------+ | |    
| | SWID      | |        | | SWID      |-|-+               
| | Posture   | |        | | Posture   | |
| | Collector | |        | | Validator | |
| +-----------+ |        | +-----------+ |             
|      |        |        |      |        |       Repository
|      | IF-IMC |        |      | IF-IMV |       +--------+
|      |        |        |      |        |       |        |
| +-----------+ |        | +-----------+ |       |        |
| | PB Client | |        | | PB Server | |------>|        |
| +-----------+ |        | +-----------+ |       |        |
|      |        |        |      |        |       +--------+
|      |        |        |      |        |
|      |        |        |      |        | 
| +-----------+ |        | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
|               |        |               |
+---------------+        +---------------+

Figure 8: Admin Searches for Vulnerable Endpoints

The repository returns a list of entries in the matching the administrator’s search. The administrator can then address the vulnerable endpoints by taking some follow-up action such as removing it from the network, quarantining it, or updating the vulnerable software.

9. Acknowledgements

The authors wish to thank all of those in the TCG TNC work group who contributed to development of the TNC ECP specification upon which this document is based.

Members of the TNC Work Group that Contributed to the Document
Member Organization
Padma Krishnaswamy Battelle Memorial Institute
Eric Fleischman Boeing
Richard Hill Boeing
Steven Venema Boeing
Nancy Cam-Winget Cisco Systems
Scott Pope Cisco Systems
Max Pritikin Cisco Systems
Allan Thompson Cisco Systems
Nicolai Kuntze Fraunhofer Institute for Secure Information Technology (SIT)
Ira McDonald High North
Dr. Andreas Steffen HSR University of Applied Sciences Rapperswil
Josef von Helden Hochschule Hannover
James Tan Infoblox
Steve Hanna (TNC-WG Co-Chair) Juniper Networks
Cliff Kahn Juniper Networks
Lisa Lorenzin Juniper Networks
Atul Shah (TNC-WG Co-Chair) Microsoft
Jon Baker MITRE
Charles Schmidt MITRE
Rainer Enders NCP Engineering
Dick Wilkins Phoenix Technologies
David Waltermire NIST
Mike Boyle U.S. Government
Emily Doll U.S. Government
Jessica Fitzgerald-McKay U.S. Government
Mary Lessels U.S. Government
Chris Salter U.S. Government

10. IANA Considerations

This document does not define any new IANA registries. However, this document does reference other documents that do define IANA registries. As a result, the IANA Considerations section of the referenced documents should be consulted.

11. Security Considerations

The Endpoint Compliance Profile offers substantial improvements in endpoint security, as evidenced by the Australian Defense Signals Directorate’s analysis that 85% of targeted cyber intrusions can be prevented through application white listing, patching applications and operating systems, and using the latest versions of applications. [DSD] Despite these gains, some security risks continue to exist and must be considered.

To ensure that these benefits and risks are properly understood, this Security Considerations section includes an analysis of the benefits provided by the Endpoint Compliance Profile (Section 11.1), the attacks that may be mounted against systems that implement the Endpoint Compliance Profile (Section 11.2), and the countermeasures that may be used to prevent or mitigate these attacks (Section 11.3). Overall, a substantial reduction in cyber risk can be achieved.

11.1. Security Benefits of Endpoint Compliance Profile

Security weaknesses of the components for this profile should be considered in light of the practical considerations that must be addressed to have a viable solution.

Posture assessment has two parts: assessment and follow-up actions. The point of posture assessment is to ensure that authorized users are using authorized software configured to be as resilient as possible against an attack.

Posture assessment answers the question whether the endpoint is healthy. Our goal for posture assessment is to make it harder for an adversary to execute code on one of our endpoints. This profile represents an important first step in reaching that goal. If we keep our endpoints healthier, we are able to prevent more attacks on our endpoints and thus on our information systems.

The goal of ECP is to address posture assessment in stages. Stage 1 is the ability to ascertain whether all endpoints are authorized and whether all applications are authorized and up to date. Stage 2 will attempt to address the harder problem of whether all software is configured safely. Eventually, the goal is to also address remediation which is currently out-of-scope for the SACM WG; that presents a far greater security challenge than reporting, since remediation implies the ability of a remote party to modify software or its settings on endpoints.

A second security consideration is how to gain visibility over every type of endpoint and every piece of software installed on the endpoint. This is a problem of scaling and observation. A solution is needed that can report from every type of endpoint. All software on the endpoint has to be discovered. Information about the software has to be up to date and accurate. The information that is discovered has to be reported in a consistent format, so administrators do not have to squander time deciphering proprietary systems and the information can be made readily useful for other security automation purposes.

ECP is based on a model of a standards-based schema, a standards-based set of protocols and interfaces, and the existence of an oversight group, the IETF, that can update the schemas and protocols to meet new use cases and security issues that may be discovered.

The data elements in the schema determine what work can be done consistently for every endpoint and every piece of software. How the data gets populated is an important consideration. ECP leverages the SWID tags from ISO 19770-2 because the tag originates with a single authoritative source, the application vendor itself. Moreover, there is a natural incentive for the vendor to create this content, since it makes it easier for enterprises and vendors to track whether software is licensed. Practical considerations are security considerations. A sustainable business model for obtaining all the necessary content is a fundamental requirement.

The NEA model is based on having a NEAC run on an endpoint that publishes posture information to a server. The advantages are easy to list. A platform vendor can implement its own NEAC and have it be compatible with the NEAS from a different vendor. The interfaces are layered on top of mature protocols such as TLS. TLS is the protocol of choice for ECP, since:

Mature protocols that can be implemented on most types of endpoints and a standards-based schema with a sustainable business model are both critical security considerations for compliance.

Additionally, it is important to consider the future stages for ECP such as a posture assessment being followed up by some action (e.g. remediation, alert, etc.). Ensuring that clients are taking instructions only from authorized parties will be critical. Inasmuch as it is practical, enterprises will want to use the same infrastructure and investment in PKI to send those instructions to a client.

Likewise, as more information with more value is gathered from endpoints, we will also want to ensure that this information is only released to authorized applications and parties. For the next stage of ECP, SACM may want to define an interface on the repository that can be queried by other security automation applications to make it easier to detect attacks and for other security automation applications. This interface has to be standards-based for enterprises to reap the benefits of innovation that can be achieved by making the enterprise’s data available to other tools and services.

11.2. Threat Model

This section lists the attacks that can be mounted on an Endpoint Compliance Profile environment. The following section (Section 11.3) describes countermeasures.

Because the Endpoint Compliance Profile describes a specific use case for NEA components, many security considerations for these components are addressed in more detail in the technical specifications: [I-D.ietf-sacm-nea-swid-patnc], [IF-IMC], [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV].

11.2.1. Endpoint Attacks

While the Endpoint Compliance Profile provides substantial improvements in endpoint security as described in Section 11.1, a certain percentage of endpoints will always get compromised. For this reason, all parties must regard data coming from endpoints as potentially unreliable or even malicious. An analogy can be drawn with human testimony in an investigation or trial. Human testimony is essential but must be regarded with suspicion.

11.2.2. Network Attacks

A variety of attacks can be mounted using the network. Generally, the network cannot be trusted.

11.2.3. Server Attacks

The server is a critical security element and therefore merits considerable scrutiny.

11.2.4. Repository Attacks

The repository is also an important security element and therefore merits careful scrutiny.

11.3. Countermeasures

This section lists the countermeasures that can be used in an Endpoint Compliance Profile environment.

11.3.1. Countermeasures for Endpoint Attacks

This profile is in and of itself a countermeasure for a compromised endpoint. A primary defense for an endpoint is to run up to date software configured to be run as safely as possible.

Ensuring that anti-virus signatures are up to date and that a firewall is configured are also protections for an endpoint that are supported by the current NEA specifications.

Endpoints that have hardware cryptographic modules that are provisioned by the enterprise, in accordance with [IEEE-802-1ar], can protect the private keys used for authentication and help prevent adversaries from stealing credentials that can be used for impersonation. Future versions of the Endpoint Compliance Profile may want to discuss in greater detail how to use a hardware cryptographic module, in accordance with [IEEE-802-1ar], to protect credentials and to protect the integrity of the code that executes during the bootstrap process.

11.3.2. Countermeasures for Network Attacks

To address network attacks, [RFC6876] includes required encryption, authentication, integrity protection, and replay protection. [Server-Discovery] also includes authorization checks to ensure that only authorized servers are trusted by endpoints. Any unspecified or not yet specified network protocols employed in the Endpoint Compliance Profile (e.g. the protocol used to interface with the repository) should include similar protections.

These protections reduce the scope of the network threat to traffic analysis and denial of service. Countermeasures for traffic analysis (e.g. masking) are usually impractical but may be employed. Countermeasures for denial of service (e.g. detecting and blocking particular sources) SHOULD be used when appropriate to detect and block denial of service attacks. These are routine practices in network security.

11.3.3. Countermeasures for Server Attacks

Because of the serious consequences of server compromise, servers SHOULD be especially well hardened against attack and minimized to reduce their attack surface. They SHOULD be monitored using the NEA protocols to ensure the integrity of the behavior and analysis data stored on the server and SHOULD utilize a [IEEE-802-1ar] compliant hardware cryptographic module for identity and/or integrity measurements of the server. They should be well managed to minimize vulnerabilities in the underlying platform and in systems upon which the server depends. Network security measures such as firewalls or intrusion detection systems may be used to monitor and limit traffic to and from the server. Personnel with administrative access to the server should be carefully screened and monitored to detect problems as soon as possible. Server administrators should not use password-based authentication but should instead use non-reusable credentials and multi-factor authentication (where available). Physical security measures should be employed to prevent physical attacks on servers.

To ease detection of server compromise should it occur, server behavior should be monitored to detect unusual behavior (such as a server reboot, unusual traffic patterns, or other odd behavior). Endpoints should log and/or notify users and/or administrators when peculiar server behavior is detected. To aid forensic investigation, permanent read-only audit logs of security-relevant information pertaining to servers (especially administrative actions) should be maintained. If server compromise is detected, the server’s certificate should be revoked and careful analysis should be performed of the source and impact of this compromise. Any reusable credentials that may have been compromised should be reissued.

Endpoints can reduce the threat of server compromise by minimizing the number of trusted servers, using the mechanisms described in [Server-Discovery].

11.3.4. Countermeasures for Repository Attacks

If the host for the repository is located on its own endpoint, it should be protected with the same measures taken to protect the server. In this circumstance, all messages between the server and repository should be protected with a mature security protocol such as TLS or IPsec.

The repository can aid in the detection of compromised endpoints if an adversary cannot tamper with its contents. For instance, if an endpoint reports that it does not have an application with a known vulnerability installed, an administrator can check whether the endpoint might be lying by querying the repository for the history of what applications were installed on the endpoint.

To help prevent tampering with the information in the repository:

  1. Only authorized parties should have privilege to run code on the endpoint and to change the repository.
  2. If a separate endpoint hosts the repository, then the functionality of that endpoint should be limited to hosting the repository. The firewall on the repository should only allow access to the server and to any endpoint authorized for administration.
  3. The repository should ideally use “write once” media to archive the history of what was placed in the repository, to include a snapshot of the current status of applications on endpoints.

12. Privacy-Considerations

The Endpoint Compliance Profile specifically addresses the collection of posture data from enterprise endpoints by an enterprise network. As such, privacy is not going to often arise as a concern for those deploying this solution.

A possible exception may be the concerns a user may have when attempting to connect a personal endpoint (such as a phone or mobile endpoint) to an enterprise network. The user may not want to share certain details, such as an endpoint identifier or SWID tags, with the enterprise. The user can configure their NEAC to reject requests for this information; however, it is possible that the enterprise policy will not allow the user’s endpoint to connect to the network without providing the requested data.

13. Change Log

13.1. -00 to -01

There are no textual changes associated with this revision. This revision simply reflects a resubmission of the document so that it remains in active status.

13.2. -01 to -02

Added references to the Software Inventory Message and Attributes (SWIMA) for PA-TNC I-D.

Replaced references to PC-TNC with IF-IMC.

Removed erroneous hyphens from a couple of section titles.

Made a few minor editorial changes.

13.3. -02 to -00

Edited Absrtact through Figure 2 to remove references to SWIMA, and uplevel draft to describe SACM collection over multiple different protocols

Replaced references to SANS with CIS.

Made a few minor editorial changes.

14. References

14.1. Informative References

[CIS], "CIS Critical Security Controls"
[DSD], "Top 4 Mitigation Strategies to Protect Your ICT System", November 2012.
[IEEE-802-1ar] Institute of Electrical and Electronics Engineers, "IEEE 802.1ar", December 2009.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K. and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008.
[TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC Architecture for Interoperability, Version 1.5", February 2012.

14.2. Normative References

[I-D.ietf-sacm-nea-swid-patnc] Schmidt, C., Haynes, D., Coffin, C. and J. Fitzgerald-McKay, "Software Inventory Message and Attributes (SWIMA) for PA-TNC", Internet-Draft draft-ietf-sacm-nea-swid-patnc-00, January 2017.
[I-D.ietf-sacm-terminology] Waltermire, D., Montville, A., Harrington, D. and N. Cam-Winget, "Terminology for Security Assessment", Internet-Draft draft-ietf-sacm-terminology-05, August 2014.
[IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC IF-IMC, Version 1.3", February 2013.
[IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC IF-IMV, Version 1.4", December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010.
[RFC5793] Sahita, R., Hanna, S., Hurst, R. and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, March 2010.
[RFC6876] Sangster, P., Cam-Winget, N. and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015.
[Server-Discovery] Trusted Computing Group, "DRAFT: TCG Trusted Network Connect PDP Discovery and Validation, Version 1.0", October 2015.
[SWID] "Information technology—Software asset management—Part 2: Software identification tag", ISO/IEC 9899:1999, 2009.

Authors' Addresses

Danny Haynes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA EMail:
Jessica Fitzgerald-McKay Department of Defense 9800 Savage Road Ft. Meade, Maryland USA EMail:
Lisa Lorenzin Pulse Secure 2700 Zanker Rd., Suite 200 San Jose, CA 95134 US EMail: