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:

• a standard administrative interface that allows data sharing with authorized parties;
• a standard API that allows data sharing with authorized infrastructure and software;
• a persistent account of endpoints that have connected to the network over a period of time set by the administrator;
• the identities provided by those endpoints; and
• what SWIDs were reported by the endpoint.

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

4.2.2.1. Asset Management

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

• what endpoints are connected to the network at any given time; and
• what SWID tags were reported for the endpoints.

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.

4.2.2.2. 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.

4.2.2.3. 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:

• Gathering other types of posture information: The Endpoint Compliance Profile does not prevent administrators from collecting other types of posture information other than SWIDs from the endpoint; however it does not set requirements for doing so.
• Solving the lying endpoint problem: The Endpoint Compliance Profile does not address the lying endpoint problem; the Profile makes no assertions that it can catch an endpoint that is, either maliciously or accidentally, reporting false posture information to the server. However, other solutions may be able to use the posture information collected using the capabilities described in this profile to catch an endpoint in a lie. For example, a sensor may be able to compare the posture information it has collected on an endpoint’s activity on the network to what the endpoint reported to the server and flag discrepancies. However, these particular capabilities are not described in this profile.
• Publish/subscribe repository interface: Future versions of the Endpoint Compliance Profile may specify a publish/subscribe interface for the repository, so infrastructure endpoint can subscribe to and receive published posture assessment results from the repository regarding endpoint configuration changes. However, the Endpoint Compliance Profile 1.0 includes no such requirements.

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.

• Meets the needs of the SACM architecture: The Endpoint Compliance Profile must support the use cases described in [RFC7632] as they apply to endpoint self-reporting and endpoint posture assessment.
• Efficient: To minimize user frustration, it is essential to minimize delays by making endpoint posture information collection, transmission, and assessment as brief and efficient as possible.
• Extensible: The Endpoint Compliance Profile needs to expand over time as new features are added to the SACM architecture. The solution must allow new features to be added easily, providing for a smooth transition and allowing newer and older architectural components to continue to work together. Further, the Endpoint Compliance Profile and the specifications referenced here must define safe extensibility mechanisms that enable innovation without breaking interoperability.
• Easy to implement: The Endpoint Compliance Profile should be easy for vendors to implement in their products, and should result in products that are easy for administrators to implement on their networks. Products conformant to the Endpoint Compliance Profile should interoperate seamlessly, and be simple to integrate into existing network infrastructure.
• Easy to use: The Endpoint Compliance Profile should describe a simple, integrated user interface that administrators can use to perform the activities listed in the profile’s use cases. The Endpoint Compliance Profile should not constrain innovation by specifying details of the user interface but rather functional requirements.
• Platform-independent: Since network environments may contain many different types of endpoints, the solution should operate independently of the endpoint platform.
• Scalable: The Endpoint Compliance Profile must be designed to scale to very large numbers of endpoints.

4.2.5. Assumptions

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

• Existence of a server and repository: The Endpoint Compliance Profile assumes that a server and repository exist.
• Endpoint SWID installation: The Endpoint Compliance Profile assumes that an endpoint has been pre-provisioned with Software Identification Tags for its applications, and that these SWID tags are formatted and stored in conformance with [SWID].
• Certificate provisioning: In order to implement the most secure endpoint identification option, the Endpoint Compliance Profile assumes that the enterprise has set up a certificate root authority, and has provisioned each endpoint with an endpoint identification certificate. This is not required if an enterprise chooses to use other endpoint authentication methods.

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

• All network-connected endpoints are endpoints: As defined by [I-D.ietf-sacm-terminology], an endpoint is any physical or virtual computing endpoint that can be connected to a network. Posture assessment against policy is equally, if not more, important for continuously connected endpoints, such as enterprise workstations and infrastructure endpoints, as it is for sporadically connected endpoints. Continuously connected endpoints are just as likely to fall out of compliance with policy, and a standardized posture assessment method is necessary to ensure they can be properly handled.
• All endpoints on the network must be uniquely identified: Many administrators struggle to identify what endpoints are connected at any given time. By requiring a standardized method of endpoint identity, the Endpoint Compliance Profile will enable administrators to answer the basic question, “What is on my network?” Unique endpoint identification also enables the comparison of current and past endpoint posture assessments, by allowing administrators to correlate assessments from the same endpoint. This makes it easier to flag suspicious changes in endpoint posture for manual or automatic review, and helps to swiftly identify malicious changes to endpoint applications.
• Posture assessments must occur over secure, standardized protocols: Endpoint identity and application information is very valuable, both to administrators and to attackers. Therefore, it must be kept confidential, using secure protocols to transport it from the endpoint to network infrastructure endpoints. Additionally, it is critical that only authorized parties be capable of requesting information, receiving information, or taking action to change an endpoint's connectivity status. Relying on standardized protocols to provide this security enables greater interoperability and compatibility between endpoints, and allows for the development of compliance testing to ensure that each endpoint operates securely and in conformance with appropriate specifications. A standards body provides a process for experts in protocols and cryptography to evaluate the soundness of protocols and security management procedures; a set of security standards allows an enterprise to make the most effective use of their investment in a security management infrastructure.
• Posture assessment results must be formatted using standardized schema: Well-known, standard schema allow for a universal language for generating compliance reports. With each endpoint speaking the same language, the Endpoint Compliance Profile enables information sharing between user endpoints and infrastructure endpoints, and between infrastructure endpoints that perform different security tasks.
• Posture information must be stored by the repository and must be exposed to an interface at the server: A standard schema enables standard queries from an interface exposed to an administrator at the server console. A repository must retain any current posture information retrieved from the endpoint and store it indexed by the unique identifier for the endpoint. Any PV specified by this profile must be able to ascertain from its corresponding PC whether the posture information is up to date. An interface on the server must support a request to the PV to obtain up-to-date information when an endpoint is connected. This interface must also support the ability to make a standard set of queries about the posture information stored by the repository. In the future, some forms of posture information might be retained at the endpoint. The interface on the server must accommodate the ability to make a request through the PV to the corresponding PC about the posture of the endpoint. Standard schema and protocols also enable the security of posture assessment results. By storing these results indexed under the endpoint’s unique identification, secure storage itself enables endpoint posture information correlation, and ensures that the enterprise’s Repositories always offer the freshest, most up-to-date view of the enterprise’s endpoint posture information possible.
• Posture information can be shared: By exposing posture information using a standard interface and API, other security and operational components have a high level of insight into the enterprise’s endpoints and the software installed on them. This will support innovation in the areas of asset management, vulnerability scanning, and administrative interfaces, as any authorized infrastructure endpoint can interact with the posture information.
• Owners and administrators must have complete control of posture information, policy, and endpoint mitigation: Enterprise asset posture information belongs to the enterprise. Standardized schema, protocols and interfaces help to ensure that this posture information is not locked in proprietary databases, but is made available to its owners. This enables administrators to develop as nuanced a policy as necessary to keep their networks secure.

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 software installer; or
• third-party software that creates tags based on the applications it sees installed on the endpoint.

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

5.2.1.1. 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.

5.2.1.2. 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:

• Can handle large volumes of data, which might require multiple roundtrips, to be sent while the endpoint is connected
• Allows either the NEAC or NEAS to initiate a connection
• Supports secure transport based on machine certificates at both ends of the connection

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:

• Query the repository
• Send commands to the PVs, requesting information from the associated PCs residing on network endpoints
• Update the policy that resides on the server

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:

• Query the repository

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 | +-----------+ |
|               |        |               |
+---------------+        +---------------+
          

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}}   +---------------+
            

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

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

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