Endpoint Compliance Standard

This document proposes leveraging the Network Enterprise Assessment (NEA) architecture , work from the Trusted Computing Group's (TCG) Trusted Network Connect (TNC) Work Group, and the ISO Software Identification (SWID) Tag Standard as a starting place for building an endpoint compliance solution. The SACM Information Model defines an internal collector to gather posture attributes from an endpoint. These posture attributes must be communicated to a server that can store the attributes in a data repository. This repository of endpoint identities and attributes is where work can take place to validate the attributes. The NEA architecture was originally designed for access control use cases. Using the TLS-based Posture Transport Protocol (PT-TLS) , the same architecture can be reused to collect large amounts of compliance data. Work from the TCG's TNC work group expands on this, enabling standardized communication of SWID Tags to a NEA server. Based on these standards, SACM can define actions that can be performed on endpoint posture attributes to ensure compliance, including: ensuring that all network-connected endpoints are known, and authorized to access network resources; confirming that only authorized applications are running on the endpoint; knowing that all applications are patched and up-to-date; and, ensuring that applications with known vulnerabilities can be located and patched.

In light of SACM's new focus and the need for quick wins that get SACM closer to its goals, we would like to open discussion on standardizing the collection, communication and evaluation of endpoint software load reports. This meets a number of SACM use cases . Many of these standards already exist and are captured in the TCG's Endpoint Compliance Profile . Implementations are also publically available, such as the strongSwan TNC implementation .

The Trusted Computing Group's TNC Work Group has additional standards that could be incorporated into the NEA architecture to specify how internal data collection can be used for security automation. The Integrity Measurement Collector Interface (IF-IMC) could be used to describe a standardized interface between a posture collector and a NEA client on an endpoint. Likewise, the Integrity Measurement Verifier Interface (IF-IMV) could provide an interface between a posture validator and a NEA Server. Both of these standards are critical additions to the NEA architecture that improve the security and interoperability of the messaging between components. The SACM Information Model calls out a number of components that tie directly to the existing NEA architecture. The Posture Collector described by NEA is a SACM Internal Collector, and the Posture Validator is a SACM evaluator. The PT-TLS protocol standardized by NEA addresses the SACM Information Model's security considerations by providing an authenticated, confidential channel through which posture attribute-value pairs can be communicated, with assurance that the communicated data has not been modified. In recent years, TNC has worked to specify SWID Message and Attributes for IF-M . This standard uses NEA and TCG architectural elements to collect and validate software identities using the ISO Software Identification Tag Standard. It also enables a NEA server to automate the storage of SWID tags for later evaluation, separating collection and evaluation roles. Server Discovery and Validation ensures that the endpoint only communicates with trusted servers.

Using these standards, we can begin to build an architecture for internal data collection that addresses SACM's use cases. An endpoint is connected to the network, and using the Server Discovery and Validation protocol, locates a trusted server, and connects to it over PT-TLS. A SWID Collector gathers SWID tags from a directory on the endpoint, and communicates them over IF-IMC to the Posture Broker (PB) Client. The Posture Broker Client then communicates this data to the Posture Transport Server via the Posture Broker Protocol . While NEA included validation capabilities on its server, SACM requires the separation of collection and evaluation. Certain features of Posture Attribute validators, such as the evaluation of collected data against network policy or guidance, will be best performed at the data repository. Other features, such as the ability to request data from an endpoint, should remain on the server. SACM will have to decide how to best separate these function. For now, a SACM Server will work as a place holder for the PB Server plus any functionality from the NEA Posture Validator that the group chooses to retain on the server. The SACM Server will also be responsible for storing collected data in a data repository, where it will be made available to evaluators.

This collection of standards provides a reasonable basis upon which we can build a SACM solution that focuses on the applications that are running on different types of endpoints, and the work that can be performed on this data when it is collected securely by an authorized server and stored in an data repository. We intend, in the coming months, to ask the TNC to submit these standards to SACM for inclusion in our first version solution, as they meet our newly scoped goals of collecting state information from a subset of endpoint types. More work is needed to build out the capabilities in this set of standards. Agreeing to use them as a starting point will clarify our work and help scope out future efforts.

This memo includes no request to IANA.

Each of the standards referenced in this internet draft contains its own security considerations section. This internet draft does not itself propose any new security considerations.