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

                      Endpoint Compliance Profile
                         draft-ietf-sacm-ecp-00
                         draft-ietf-sacm-ecp-01

Abstract

   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 an extension 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 https://datatracker.ietf.org/drafts/current/.

   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, August 3, 2018.

Copyright Notice

   Copyright (c) 2017 2018 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
   (https://trustee.ietf.org/license-info) 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  . . . . . . . . . . . . . . . . . . . . . . . .   3   4
     1.1.  Preventative Posture Assessments  . . . . . . . . . . . .   4
     1.2.  Standardized Schema  All Network-Connected Endpoints are Endpoints . . . . . .   5
     1.3.  All Endpoints on the Network Must be Uniquely Identified    5
     1.4.  Standardized Data Models  . . . . . . . . . . . . . . . .   4
     1.3.   6
     1.5.  Secure Standardized Protocols . . . . . . . . . . . . . .   5
     1.4.  Keywords   6
     1.6.  Posture Information Must Be Stored  . . . . . . . . . . .   6
     1.7.  Posture Information Can Be Shared . . . . . . . . . . . .   7
     1.8.  Enterprise Asset Posture Information Belongs to the
           Enterprise  .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . .   7
     1.9.  Keywords  . . .   6
   3.  Endpoint Compliance Profile . . . . . . . . . . . . . . . . .   6
     3.1.  Posture Assessments . . . .   7
   2.  Terminology . . . . . . . . . . . . . . .   7
     3.2.  Data Storage . . . . . . . . . .   7
   3.  Assumptions . . . . . . . . . . . .   7
     3.3.  Data Sharing . . . . . . . . . . . . .   8
   4.  Endpoint Compliance Profile . . . . . . . . .   7
   4.  Background . . . . . . . .  10
     4.1.  Posture Assessments . . . . . . . . . . . . . . . . .   7
     4.1.  Purpose of the Endpoint Compliance Profile . .  10
     4.2.  Data Storage  . . . . .   7
     4.2.  Supported Use Cases . . . . . . . . . . . . . . . . .  11
     4.3.  Data Sharing  . .   8
       4.2.1.  Connected and Compliant . . . . . . . . . . . . . . .   8
       4.2.2.  Exposing Data to the Network . . . . .  11
   5.  ECP Components  . . . . . . .   9
         4.2.2.1.  Asset Management . . . . . . . . . . . . . . . .  11
         4.2.2.2.  Vulnerability Searches
     5.1.  Endpoint  . . . . . . . . . . . . . .  12
         4.2.2.3.  Threat Detection and Analysis . . . . . . . . . .  12
       4.2.3.  Non-supported Use Cases
       5.1.1.  Posture Collector . . . . . . . . . . . . . . .  12
       4.2.4.  Profile Requirements . . .  12
       5.1.2.  Posture Collection Engine . . . . . . . . . . . . . .  13
       4.2.5.  Assumptions
     5.2.  Posture Manager . . . . . . . . . . . . . . . . . . . . .  14
   5.  Endpoint Compliance Requirements  13
       5.2.1.  Posture Validator . . . . . . . . . . . . . .  16
     5.1.  Endpoint Pre-Provisioning . . . .  13
       5.2.2.  Posture Collection Manager  . . . . . . . . . . . .  16
       5.1.1.  SWID Tags .  13
     5.3.  Repository  . . . . . . . . . . . . . . . . . . . . .  17
       5.1.2.  Endpoint Identity and Machine Certificate . .  14
     5.4.  Evaluator . . . .  17
     5.2.  Posture Validators and Posture Collectors . . . . . . . .  17
       5.2.1.  SWID Posture Collectors and Posture Validators . . .  18
         5.2.1.1.  The SWID Posture Collector . . . . . . . . .  14
     5.5.  Orchestrator  . .  18
         5.2.1.2.  The SWID Posture Validator . . . . . . . . . . .  18
     5.3.  NEA Client (NEAC) and NEA Server (NEAS) . . . . . . . . .  19
       5.3.1.  NEAC  14
   6.  ECP Transactions  . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Provisioning  . .  19
       5.3.2.  NEAS . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Discovery and Validation  . . . .  19
     5.4.  Repository . . . . . . . . . . . .  15
     6.3.  Event Driven Collection . . . . . . . . . . .  19
   6.  Posture Transport Client (PTC) and Posture Transport Server
       (PTS) . . . . . .  15
     6.4.  Querying  . . . . . . . . . . . . . . . . . . . . . .  20
   7.  Administrative Interface and API . .  15
     6.5.  Data Storage  . . . . . . . . . . . .  20
   8.  Endpoint Compliance Profile Examples . . . . . . . . . .  15
     6.6.  Data Sharing  . .  21
     8.1.  Continuous Posture Assessment of an Endpoint . . . . . .  21
       8.1.1.  Change on Endpoint Triggers Posture Assessment . . .  21
     8.2.  Administrator Searches for Vulnerable Endpoints . . . . .  24

   9.  Acknowledgements . . . . . .  16
   7.  ECP Implementations . . . . . . . . . . . . . . . .  25
   10. IANA Considerations . . . . .  17
     7.1.  IETF NEA ECP Implementation . . . . . . . . . . . . . . .  17
       7.1.1.  Endpoint Pre-Provisioning .  27
   11. Security Considerations . . . . . . . . . . . . .  17
       7.1.2.  Endpoint  . . . . . .  27
     11.1.  Security Benefits of Endpoint Compliance Profile . . . .  27
     11.2.  Threat Model . . . . . . . . . . . .  18
         7.1.2.1.  Posture Collector . . . . . . . . . .  29
       11.2.1.  Endpoint Attacks . . . . . .  18
         7.1.2.2.  Posture Collection Engine . . . . . . . . . . . .  30
       11.2.2.  Network Attacks  18

       7.1.3.  Posture Manager . . . . . . . . . . . . . . . . . .  30
       11.2.3.  Server Attacks .  19
         7.1.3.1.  Posture Validator . . . . . . . . . . . . . . . .  19
         7.1.3.2.  Posture Collection Manager  . . .  30
       11.2.4. . . . . . . . .  19
       7.1.4.  Repository Attacks  . . . . . . . . . . . . . . . . .  31
     11.3.  Countermeasures . . . .  19
       7.1.5.  Administrative Interface and API  . . . . . . . . . .  20
       7.1.6.  IETF SACM SWAM Extension to the IETF NEA ECP
               Implementation  . . . . . . . . . . . . .  31
       11.3.1.  Countermeasures for . . . . . .  20
         7.1.6.1.  Endpoint Attacks Pre-Provisioning . . . . . . . .  31
       11.3.2.  Countermeasures for Network Attacks . . . .  20
         7.1.6.2.  SWID Tags . . . .  32
       11.3.3.  Countermeasures for Server Attacks . . . . . . . . .  32
       11.3.4.  Countermeasures for . . . . . . .  20
         7.1.6.3.  SWID Posture Collectors and Posture Validators  .  21
         7.1.6.4.  Repository Attacks  . . . . . . .  33
   12. Privacy-Considerations . . . . . . . . . . . .  22
     7.2.  IETF NETMOD ECP Implementation  . . . . . . .  34
   13. Change Log . . . . . .  22
   8.  ECP Use Cases . . . . . . . . . . . . . . . . . . .  34
     13.1.  -00 to -01 . . . . .  22
     8.1.  Hardware Asset Management . . . . . . . . . . . . . . . .  22
     8.2.  Software Asset Management . .  34
     13.2.  -01 to -02 . . . . . . . . . . . . . .  23
     8.3.  Vulnerability Searches  . . . . . . . . .  34
     13.3.  -02 to -00 . . . . . . . .  23
     8.4.  Threat Detection and Analysis . . . . . . . . . . . . . .  23
   9.  Non-supported Use Cases .  34
   14. References . . . . . . . . . . . . . . . . . .  24
   10. Endpoint Compliance Profile Examples  . . . . . . .  35
     14.1.  Informative References . . . . .  24
     10.1.  Continuous Posture Assessment of an Endpoint . . . . . .  24
       10.1.1.  Change on Endpoint Triggers Posture Assessment . . .  25
     10.2.  Administrator Searches for Vulnerable Endpoints  . . .  35
     14.2.  Normative References .  27
   11. Profile Requirements  . . . . . . . . . . . . . . . . .  35
   Authors' Addresses . . .  28
   12. Future Work . . . . . . . . . . . . . . . . . . . .  36

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 . . . . .  29
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  30
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  31
     15.1.  Security Benefits of Endpoint Compliance Profile . . . .  32
     15.2.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  34
       15.2.1.  Endpoint Attacks . . . . . . . . . . . . . . . . . .  34
       15.2.2.  Network Attacks  . . . . . . . . . . . . . . . . . .  35
       15.2.3.  Posture Manager Attacks  . . . . . . . . . . . . . .  35
       15.2.4.  Repository Attacks . . . . . . . . . . . . . . . . .  35
     15.3.  Countermeasures  . . . . . . . . . . . . . . . . . . . .  36
       15.3.1.  Countermeasures for Endpoint Attacks . . . . . . . .  36
       15.3.2.  Countermeasures for Network Attacks  . . . . . . . .  37
       15.3.3.  Countermeasures for Posture Manager Attacks  . . . .  37
       15.3.4.  Countermeasures for Repository Attacks . . . . . . .  38
   16. Privacy-Considerations  . . . . . . . . . . . . . . . . . . .  38
   17. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  39
     17.1.  -00 to -01 . . . . . . . . . . . . . . . . . . . . . . .  39
     17.2.  -01 to -02 . . . . . . . . . . . . . . . . . . . . . . .  39
     17.3.  -02 to -00 . . . . . . . . . . . . . . . . . . . . . . .  39
     17.4.  -00 to -01 . . . . . . . . . . . . . . . . . . . . . . .  39
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  39
     18.1.  Informative References . . . . . . . . . . . . . . . . .  39
     18.2.  Normative References . . . . . . . . . . . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41

1.  Introduction

   The Endpoint Compliance Profile (ECP) builds on prior work from the
   IETF NEA WG, the IETF NETMOD WG, and the Trusted Computing Group
   [TNC]Trusted Network Communications (TNC) WG to standardize the
   collection, storage and sharing of posture information from network-
   connected endpointgs, endpoints, 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  Standardized collection improves
   network security by confirming that endpoints are known and
   authrosized,
   authorized, and are compliant with network policy.

   When ECP is used, posture information is gathered by collectors running on the target endpoint
   gather posture information as changes occur on the endpoint, and is forwarded
   forward this information to a posture server, manager, which stores it in a
   repository.  This information is gathered while the target 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

   Building and maintaining a product, an
   administrator may query the continuously updated repository of
   information using the ECP enables network owners and administrators
   to determine which endpoints
   have perform the vulnerable software installed asset, vulnerability, and thus require some follow-
   up action. configuration management
   tasks that are the basis for robust network security.

   The ECP then also 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.  The ECP does not set requirements for this
   future-leaning work; it instead sets requirements for building a data
   repository that best enhances decision-making by these sensors.
   Therefore, while data sharing components are included in ECP diagrams
   and high-level capability descriptions, vendors are free to
   experiment with best approaches for sharing data beyond the
   repository.  Suggestions and ideas for future integration are
   captured in the Section 12 section of this document.

1.1.  Preventative Posture Assessments

   The value of continuous endpoint posture assessment is well
   established.  Security experts have for years identified software
   updating asset
   management and patching vulnerability remediation as a critical step for
   preventing intrusions.  Application white listing, whitelisting, 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 easily determine which
   endpoints require some follow-up action.  By sharing posture informatino
   information with sensors on the network, ECP aids in the
   detection of attacks on endpoints the detection of
   attacks on endpoints and drives follow-up actions.

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

1.3.  All Endpoints on the Network Must be Uniquely Identified

   Many administrators struggle to identify what endpoints are connected
   to the network 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 drives follow-up actions.

1.2. helps to swiftly identify malicious changes to
   endpoint applications.

1.4.  Standardized Schema Data Models

   The ECP requires the use of standardized schema data models 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 data models also enable collection
   from myriad types of endpoints.  Such standardization saves implementers vendors
   time and money--time that does not have to be spent integrating new
   schema
   data models 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 data models 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.

1.5.  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] and
   [I-D.ietf-netconf-yang-push] for communication between the target
   endpoint and the server.  This protocol
   allows posture manager.  These protocols allow 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 with some policy.  This Profile  The ECP 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.

   The IETF NEA WG has designed

1.6.  Posture Information Must Be Stored

   Posture information must be stored by the repository and must be
   exposed to an interface at the posture manager.  Standard data models
   enable standard queries from an architecture interface exposed to an administrator
   at the posture manager console.  A repository must retain any current
   posture information retrieved from the target endpoint and store it
   indexed by the unique identifier for the endpoint.  Any posture
   validator specified by this profile must be able to ascertain from
   its corresponding posture collector whether the posture information
   is up to date.  An interface on the posture manager must support a
   request to the posture validator 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 posture validator to the corresponding posture collector about
   the posture of the target endpoint.  Standard data models 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 assessment.  Figure 1 illustrates
   information correlation, and ensures that the architectural enterprise's
   repositories always offer the freshest, most up-to-date view of the
   enterprise's endpoint posture information possible.

1.7.  Posture Information Can Be Shared

   By exposing posture information using a standard interface and API,
   other security and operational components used have a high level of
   insight into the enterprise's endpoints and the software installed on
   them.  This will support innovation in the Endpoint Compliance Profile:

   Endpoint                 Server
   +---------------+        +---------------+
   |               |        |               |
   | +-----------+ |        | +-----------+ |
   | |           | |        | |           | |
   | | Posture   | |        | | Posture   | |
   | | Collector | |        | | Validator | |
   | +-----------+ |        | +-----------+ |
   |      |        |        |      |        |
   |      |        |        |      |        |     Repository
   |      |        |        |      |        |     +--------+
   | +-----------+ |        | +-----------+ |     |        |
   | | Posture   | |        | | areas of asset management,
   vulnerability scanning, and administrative interfaces, as any
   authorized infrastructure endpoint can interact with the posture
   information.

1.8.  Enterprise Asset Posture   | |     |        |
   | | Client    | |        | | Server    | |---->|        |
   | +-----------+ |        | +-----------+ |     |        |
   |      |        |        |      |        |     |        |
   |      |        |        |      |        |     +--------+
   |      |        |        |      |        |
   | +-----------+ |        | +-----------+ |
   | | Comms     | |        | | Comms     | |
   | | Client    | |<------>| | Server    | |
   | +-----------+ |        | +-----------+ |
   |               |        |               |
   +---------------+        +---------------+

              Figure 1: The Endpoint Compliance Architecture

1.4. Information Belongs to the Enterprise

   Owners and administrators must have complete control of posture
   information, policy, and endpoint mitigation.  Standardized data
   models, 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.

1.9.  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.  Assumptions

   Here are the assumptions that the Endpoint Compliance Profile

   The Endpoint Compliance Profile describes how IETF and TNC data
   models and protocols can be used to support makes
   about other components in the posture assessment SACM architecture.

   o  Existence 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 manager and repository: The Endpoint
      Compliance Profile 1.0 describes how IETF and TNC data
   modles and protocols make it possible to perform assumes that a posture assessments
   against all network-connected endpoints by:

   1.  uniquely identifying the endpoint;

   2.  collecting manager and assessing repository
      exist.

   o  Endpoint posture based on data from the endpoint;

   3.  creating a secure, authenticated, confidential channel between
       the endpoint and the server;

   4.  enabling the information availability: The Endpoint Compliance
      Profile assumes that an endpoint has posture information in
      standardized data model that can be communicated to notify the server about changes to its
       configuration;

   5.  enabling the posture server
      manager.

   o  Certificate provisioning: In order to request information about implement the
       configuration of most secure
      endpoint identification option, the endpoint; and

   6.  storing Endpoint Compliance Profile
      assumes that the posture information in enterprise has set up a repository linked 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
       identifier for the endpoint.

3.2.  Data Storage

   The Endpoint Compliance Profile 1.0 focuses on being able to collect
   posture information from makes the following
   assumptions about the SACM ecosystem:

   o  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 store infrastructure endpoints, as it in a repository.
   This makes posture information from a network's is for sporadically connected
      endpoints.  Continuously connected 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 just as likely to make connectivity decisions,
      fall out of compliance with policy, and metrics
   reporting scripts, among others, are all able a standardized posture
      assessment method is necessary to reference the data
   stored in ensure they can be properly
      handled.

   o  All endpoints on the repository network must be uniquely identified: Many
      administrators struggle to achieve their purposes.

3.3.  Data Sharing

   TBD

4.  Background

4.1.  Purpose identify what endpoints are connected
      at any given time.  By requiring a standardized method of endpoint
      identity, the Endpoint Compliance Profile

   The Endpoint Compliance Profile describes a standard way 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 collect flag suspicious changes in
      endpoint posture for manual or automatic review, and helps to
      swiftly identify malicious changes to endpoint applications.

   o  Posture assessments must occur over secure, standardized
      protocols: Endpoint identity and application information s is very
      valuable, both to administrators and to make attackers.  Therefore, it available
      must be kept confidential, using secure protocols to transport it
      from the endpoint to other
   authorized parties.

4.2.  Supported Use Cases

   The Endpoint Compliance Profile focuses on the posture assessment manager.  Additionally, it is
      critical that only authorized parties be capable of
   enterprise endpoints requesting
      information, receiving information, or taking action to change an
      endpoint's connectivity status.  Relying on enterprise networks.  Use cases supported by
   the Endpoint Compliance Profile 1.0 are as follows:

4.2.1.  Connected standardized protocols
      to provide this security enables greater interoperability and Compliant

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

   Endpoint                     Server
   +-------------------+        +---------------+
   |                   |        |               |
   | +---------+       |        |               |
   | | Endpoint|       |        |               |
   | | Posture |       |        | +-----------+ |
   | | Data    |       |        | |           | |
   | +---------+       |        | | Validator | |
   |  |                |        | |           | |
   |  |                |        | +-----------+ |
   |  |  +-----------+ |        |      |        |
   |  +->|           | |        |      |        |
   |     | Collector | |        |      |        |
   |     |           | |        |      |        |
   |     +-----------+ |        |      |        |
   |          |        |        |      |        |
   |          |        |        |      |        |     Repository
   |          |        |        |      |        |     +--------+
   |     +-----------+ |        | +-----------+ |     |        |
   |     | Posture   | |        | |
      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.

   o  Posture   |       |        |
   |     | Client    | |        | |  Server   | |---->|        |
   |     +-----------+ |        | +-----------+ |     |        |
   |               |   |        |      |        |     |        |
   | +----------+  |   |        |      |        |     +--------+
   | | assessment results must be formatted using standardized
      data models: Well-known, standard data models allow for a
      universal language for generating compliance reports.  With each
      endpoint speaking the same language, the Endpoint |  |   |        |      |        |
   | | ID       |  |   |        |      |        |
   | +----------+  |   |        |      |        |
   |  |            |   |        |      |        |
   |  |  +-----------+ |        | +-----------+ |
   |  +->| Comms     | |        | | Comms     | |
   |     | Client    | |<------>| |  Server   | |
   |     +-----------+ |        | +-----------+ |
   |                   |        |               |
   +-------------------+        +---------------+

                Figure 2: Connected Compliance
      Profile enables information sharing between user endpoints and Compliant Use Case

   1.  If necessary,
      infrastructure endpoints, and between infrastructure endpoints
      that perform different security tasks.

   o  Posture information must be stored by the repository and must be
      exposed to an interface at the posture manager: Standard data
      models enable standard queries from an interface exposed to an
      administrator at the posture manager console.  A repository must
      retain any current posture information retrieved from the endpoint finds
      and validates store it indexed by the server in
       compliance with [Server-Discovery].

   2.  The Posture Transport Client (PTC) unique identifier for the endpoint.
      Any posture validator specified by this profile must be able to
      ascertain from its corresponding posture collector whether the
      posture information is up to date.  An interface on the posture
      manager must support a request to the posture validator to obtain
      up-to-date information when an endpoint and Posture
       Transport Server (PTS) 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 complete posture manager must
      accommodate the ability to make a TLS handshake,
       during which request through the posture
      validator to the corresponding posture collector about the posture
      of the endpoint.  Standard data models and protocols also enable
      the security of posture assessment results.  By storing these
      results indexed under the endpoint's unique identifier, secure
      storage itself enables endpoint identity posture information is exchanged.

   3.  Either correlation,
      and ensures that the NEA Server (NEAS) on enterprise's repositories always offer the server or
      freshest, most up-to-date view of the NEA Client
       (NEAC) enterprise's endpoint
      posture information possible.

   o  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 initiates a can interact with the posture information.

   o  Owners and administrators must have complete control of posture assessment.  Checks
       may be triggered for multiple reasons, including:

       (a)  policy states that a previous assessment has aged out
      information, policy, and
            become invalid;

       (b)  the NEAC notices that the relevant endpoint mitigation: Enterprise asset
      posture information on
            the endpoint has changed, (for example, due belongs to application
            updates, deletions or additions); or

       (c) the NEAS enterprise.  Standardized data
      models, protocols and interfaces help to ensure that this posture
      information is alerted by not locked in proprietary databases, but is made
      available to its owners.  This enables administrators to develop
      as nuanced a sensor or an administrator (via policy as necessary to keep their networks secure.

4.  Endpoint Compliance Profile

   The Endpoint Compliance Profile describes how IETF data models and
   protocols can be used to support the
            server's user interface) that an posture assessment must of endpoints
   on a network.  This profile does not generate new data models 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
            completed.

       All information exchanges between the PCs leveraged against vulnerabilities.

4.1.  Posture Assessments

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

   1.  uniquely identifying the enterprise's policy, which may limit endpoint;

   2.  collecting and assessing posture based on data from the content or size of
       information sent endpoint;

   3.  creating a secure, authenticated, confidential channel between
       the endpoint and the server. posture manager;

   4.  The SWID Posture Collector on  enabling 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 notify the posture information is received by manager about changes
       to its configuration;

   5.  enabling the PTS, it is
       forwarded posture manager to request information about the SWID Posture Validator via
       configuration of the NEAS.  The SWID
       Posture Validator also forwards endpoint; and

   6.  storing the posture information in a repository linked to the
       repository.  The posture information is stored along with past
       posture information collected about
       identifier for the endpoint.

4.2.2.  Exposing

4.2.  Data Storage

   The Endpoint Compliance Profile 1.0 focuses on being able to the Network

   Because the endpoint collect
   posture information was sent from an endpoint and store it in a standards-
   based schema (ISO/IEC 19770-2:2009) over secure, standardized
   protocols, 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 the SWID tags 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 a centralized the repository
   linked to unique endpoint identifiers, authorized parties are able achieve their purposes.  Currently, the
   Endpoint Compliance Profile 1.0 does not specify a protocol or
   interfaces to access the stored posture information.  Such authorized parties may include,
   but  This needs to be
   addressed in a future revision to make collected posture information
   accessible to components in a standardized manner.  Until then,
   vendors are not limited to, administrators or endpoint owners (via free to implement a repository and the
   server's administrative interface), protocols and other pieces of
   infrastructure
   interfaces used to interact with it in a way that can make use makes the most
   sense for them.

4.3.  Data Sharing

   The Endpoint Compliance Profile 1.0 aims to facilitate the sharing of
   posture information between components to enable asset management,
   software asset management, and configuration management use cases as
   well as support analytic, access control, remediation, and reporting
   processes.  However, the Endpoint Compliance Profile 1.0 does not
   currently specify a protocol for communicating this data (via information
   between components to support these use cases and processes.  This
   needs to be addressed in a future revision.
   [I-D.ietf-mile-xmpp-grid] which is publish/subscribe protocol being
   developed in the server's API).
   The server will provide:

   o IETF MILE WG may be a standard administrative interface that allows data potential candidate for
   sharing with
      authorized parties;

   o  a standard API that allows information between components.

5.  ECP Components

   To perform posture assessment, data sharing with authorized
      infrastructure storage, and software;

   o data sharing, ECP
   defines a persistent account number of endpoints that have connected to the
      network over a period components.  Some of time set by the administrator;

   o  the identities provided by those endpoints; and

   o  what SWIDs were reported by these components reside on
   the target endpoint.

   The  Others reside on a posture manager that manages
   communications with the target endpoint will publish updates as its local SWID directory
   changes, as well as each time it disconnects and reconnects to stores the
   network. target
   endpoint's posture information in a repository.

                                Posture Manager          Endpoint                      Server
   +--------------------+
               Orchestrator     +---------------+        +---------------+
                +--------+      |               |        |               |
                | +-------+        |      | +-----------+ |        | +-----------+ | SWIDs |          |        | | SWID
                |        |<---->| | Posture   | +-------+ |        | | Posture   | |
                |        |                 | pub/ | | Validator | |        | |                 |        | +-----------+ |
   |  |  +-----------+  |        |      |        |
   |  +->| SWID      |  |        |      |        |
   |     | Posture   |  |        |      |        |
   |     | Collector | |
                |        |        | sub  | +-----------+ |        | +-----------+ |
                +--------+      |      |        |        |      |        |
                                |      |        | IF-IMC  |        |      | IF-IMV        |
Evaluator       Repository      |      |        |        |      |        |
+------+        +--------+      | +-----------+  |        | +-----------+ |     |        |
   |     | PB Client |  |        | | PB Server | |---->|        |
   |     +-----------+  |        | |<-------| +-----------+ |
|      |        |        |      | | Posture   | | report | |
   | +----------+  |    |        |      |        |     +--------+
   | | Endpoint |  |    |        |      |        | Posture   | | ID
|      |        |        |      | | Collection| | +----------+        | | Collection| |
|      |<-----> |        |<---->| | Manager   | | query  | | Engine    | |
|      |request/|        | store| +-----------+  |        | |------->| +-----------+ |
|  +->| PT Client      |respond |  |<------>|        | PT Server      |               |        |     +-----------+               | PT-TLS
| +-----------+      |        |        |      |               |
   +--------------------+        +---------------+
                               +----------------------------------+        | Administrative Interface and API               |
                               +----------------------------------+

                  Figure 3: Exposing Data to the Network

   It should be noted that the neither
+------+        +--------+      +---------------+        +---------------+

                         Figure 1: ECP Components

5.1.  Endpoint

   An endpoint is defined in [RFC6876].  In the Endpoint Compliance Profile
   nor
   Profile, the protocols, interfaces, endpoint is monitored by the enterprise and data models that it references
   provide solutions to is the server capabilities listed above.  However,
   target of posture assessments.  To support these capabilities are useful and solutions posture assessments,
   posture information is collected via posture collectors.

5.1.1.  Posture Collector

   A posture collector is responsible for them should be
   pursued in monitoring and gathering
   posture information from the future.

4.2.2.1.  Asset Management

   Using target endpoint.  This component reports
   changes to posture information as they occur.  This event-driven
   collection provides network administrators up-to-date insight into
   the administrative interface on state of the server, an authorized user
   can learn:

   o  what endpoints are connected to network as the network at any given time; and
   o  what SWID tags were reported for state changes, which enables
   continuous monitoring of the endpoints.

   The ability network.  Posture collectors can also be
   queried supporting ad-hoc collection, addressed below as "querying"
   which can be used to answer these questions offers refresh information about the target endpoint,
   or to ask a standards-based
   approach specific question about posture information.
   Furthermore, a posture collector may process posture information
   before it is communicated to asset management, which the posture manager.  An endpoint may
   have one or more posture collectors depending on the type of endpoint
   and what posture information is being monitored and collected.

5.1.2.  Posture Collection Engine

   The posture collection engine is located on the target endpoint.  It
   receives queries from a vital part of enterprise
   processes such as compliance report generation for posture collection manager and directs them
   to the Federal
   Information Security Modernization Act (FISMA), Payment Card Industry
   Data Security Standard (PCI DSS), Health Insurance Portability appropriate posture collector on the target endpoint.  It also
   sends collected posture information to the posture manager where it
   can be received by the posture collection manager and
   Accountability Act (HIPAA), etc.

4.2.2.2.  Vulnerability Searches distributed to
   the appropriate posture validator where it can be sanity checked and
   stored in the repository.  The administrative interface posture collection engine also provides
   contains a capability that sets up exchanges between the ability target
   endpoint and posture manager.  This capability makes the posture
   collection engine responsible for authorized
   users or infrastructure to locate endpoints running software performing the client-side portion
   of encryption handshakes, and for locating authorized posture
   managers with which vulnerabilities have been announced.  Because of

   1.  the unique IDs assigned to each endpoint; communicate.

5.2.  Posture Manager

   The posture manager is an endpoint that collects, validates, and

   2.
   enriches posture information received about a target endpoint.  It
   also stores the rich application data provided posture information it receives in the endpoints' repository.
   The posture
       information, manager does not evaluate the repository posture information.

5.2.1.  Posture Validator

   A posture validator receives data from a posture collector, performs
   basic sanity checking, and stores that data in the repository.  It
   can be queried also send queries to find all endpoints running a
   vulnerable application.  Endpoints suspected of being vulnerable can
   be addressed by the administrator or flagged posture collector.  There is a posture
   validator for further scrutiny.

4.2.2.3.  Threat Detection every posture collector.

5.2.2.  Posture Collection Manager

   A posture collection manager is a lightweight and Analysis extensible
   component that facilitates the coordination and execution of posture
   collection requests using collection mechanisms deployed across the
   enterprise.  The repository's standardized API allows authorized infrastructure
   endpoints posture collection manager may query and software retrieve
   guidance from the repository to search endpoint guide the collection of posture assessment
   information for evidence from the target endpoint.

   The posture collection manager also contains a capability that an endpoint's software inventory has
   changed, and can make sets
   up exchanges between the target endpoint software inventory and the posture manager, and
   manages data available sent to
   other endpoints.  This automates security data sharing in a way that
   expedites and from posture validators.  It is also
   responsible for performing the correlation server-side portion of relevant network data, allowing
   administrators encryption
   handshakes.  It is also responsible for performing the server-side
   portion of encryption handshakes.

5.3.  Repository

   The repository hosts guidance, endpoint identification information,
   and infrastructure posture information reported by target endpoints where it is made
   available to identify odd endpoint
   behavior and configuration using secure, standards-based schema authorized components and
   protocols.

4.2.3.  Non-supported Use Cases

   Several use cases, including but not limited to these, are not
   covered persisted over a period of
   time set by the Endpoint Compliance Profile 1.0:

   o  Gathering other types of posture information: administrator.  Information stored in the repository
   will be accessible to authorized parties via a standard
   administrative interface as well as through a standardized API.  The
   repository may be a standalone component or may be located on the
   posture manager.

   Currently, the Endpoint Compliance Profile does not prevent administrators from collecting
      other types of posture provide a
   standardized interface or API for accessing the information other than SWIDs from contained
   within the
      endpoint; however it does not set requirements for doing so.

   o  Solving repository.  A future revision of the lying endpoint problem: The Endpoint Compliance
   Profile does not address may specify a standardized interface and API for components
   to interact with the lying repository.

5.4.  Evaluator

   The evaluator assesses the posture status of a target endpoint problem; by
   comparing collected posture information against the Profile
      makes no assertions that it can catch an desired state of
   the target endpoint that is, either
      maliciously or accidentally, reporting false specified in guidance.  The evaluator queries and
   retrieves the appropriate guidance from the repository as well as
   queries and retrieves the posture information
      to required for the server.  However, other solutions
   assessment from the repository.  If the required posture information
   is not available in the repository, the evaluator may be able to use request the
   posture information from the posture collection engine, which will
   result in the collection of additional posture information collected using from the capabilities described in
      this profile to catch an endpoint
   target endpoint.  This information is subsequently stored in a lie.  For example, a sensor
      may be able to compare the posture information
   repository where it has collected on
      an endpoint's activity on the network to what the endpoint
      reported is made available to the server evaluator and flag discrepancies.  However, these
      particular capabilities other
   components.  The results of the assessment are not described stored in this profile.

   o  Publish/subscribe repository interface: Future versions of the
      Endpoint Compliance Profile may specify
   repository where they are available to tools and administrators for
   follow-up actions, further evaluation, and historical purposes.

5.5.  Orchestrator

   The orchestrator provides a publish/subscribe interface for the repository,
   repository so that infrastructure endpoint endpoints can subscribe to and
   receive published posture assessment results from the repository
   regarding endpoint configuration posture changes.  However,
      the

   The Endpoint Compliance Profile 1.0 includes no such requirements.

4.2.4.  Profile Requirements

   Here are the requirements that does not currently define an
   orchestrator component nor does it specify a standardized publish/
   subscribe interface for this purpose.  Future revisions of the
   Endpoint Compliance Profile
   protocol must meet in order may specify such an interface.

6.  ECP Transactions

6.1.  Provisioning

   An endpoint is provisioned with one or more attributes that will
   serve as its unique identifier on the network as well as the
   components necessary to successfully fit in interact with the SACM
   architecture.

   o  Meets posture manager.  The
   endpoint is deployed on the network.

   NOTE: TO BE EXPANDED

6.2.  Discovery and Validation

   If necessary, the target endpoint finds and validates the posture
   manager.  The posture collection engine on the target endpoint and
   posture collection manager on the posture manager complete a TLS
   handshake, during which endpoint identity information is exchanged.

6.3.  Event Driven Collection

   The posture assessment is initiated when a posture collector on the
   target endpoint notices that relevant posture information on the
   endpoint has changed.  The posture collector notified the posture
   collection engine, which initiates a posture assessment information
   exchange with the posture collection manager.

6.4.  Querying

   The posture assessment is initiated by the needs of posture validator.  This
   can occur because:

   1.  policy states that a previous assessment has aged out or become
       invalid, or

   2.  the SACM architecture: The Endpoint Compliance
      Profile must support posture validator is alerted by a sensor or an administrator
       (via the use cases described in [RFC7632] as they
      apply to endpoint self-reporting and endpoint posture assessment.

   o  Efficient: To minimize manager's user frustration, it interface) that an assessment
       must be completed

6.5.  Data Storage

   Once posture information is essential to
      minimize delays received by making endpoint the posture information collection,
      transmission, and assessment as brief and efficient as possible.

   o  Extensible: The Endpoint Compliance Profile needs to expand over
      time as new features are added manager, it is
   forwarded to the SACM architecture. repository.  The
      solution must allow new features to repository could be added easily, providing for
      a smooth transition and allowing newer and older architectural
      components to continue to work together.  Further, co-located with
   the Endpoint
      Compliance Profile posture manager, or there could be direct or brokered
   communication between the posture manager and the specifications referenced here must
      define safe extensibility mechanisms that enable innovation
      without breaking interoperability.

   o  Easy to implement: repository.  The Endpoint Compliance Profile should be easy
      for vendors to implement in their products, and should result
   posture information is stored 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.

   o  Easy to use: The Endpoint Compliance Profile should describe a
      simple, integrated user interface that administrators can use to
      perform repository along with past
   posture information collected about the target endpoint.

6.6.  Data Sharing

   Because the activities listed target endpoint posture information was sent in
   standards-based data models over secure, standardized protocols, and
   then stored in a centralized repository linked to unique endpoint
   identifiers, authorized parties are able to access the profile's use cases.  The
      Endpoint Compliance Profile should posture
   information.  Such authorized parties may include, but are not constrain innovation by
      specifying details of
   limited to, administrators or endpoint owners (via the user interface but rather functional
      requirements.

   o  Platform-independent: Since network environments may contain many
      different types of endpoints, server's
   administrative interface), evaluators that access the solution should operate
      independently of repository
   directly, and orchestrators that rely on publish/subscribe
   communications with the endpoint platform.

   o  Scalable: The repository.

                                Posture Manager          Endpoint Compliance Profile must be designed to
      scale to very large numbers of endpoints.

4.2.5.  Assumptions

   Here are
               Orchestrator     +---------------+        +---------------+
                +--------+      |               |        |               |
                |        |      | +-----------+ |        | +-----------+ |
                |        |<---->| | Posture   | |        | | Posture   | |
                |        | pub/ | | Validator | |        | | Collector | |
                |        | sub  | +-----------+ |        | +-----------+ |
                +--------+      |      |        |        |      |        |
                                |      |        |        |      |        |
Evaluator       Repository      |      |        |        |      |        |
+------+        +--------+      | +-----------+ |<-------| +-----------+ |
|      |        |        |      | | Posture   | | report | | Posture   | |
|      |        |        |      | | Collection| |        | | Collection| |
|      |<-----> |        |<-----| | Manager   | | query  | | Engine    | |
|      |request/|        | store| +-----------+ |------->| +-----------+ |
|      |respond |        |      |               |        |               |
|      |        |        |      |               |        |               |
+------+        +--------+      +---------------+        +---------------+

               +--------------------------------+
               | Administrative Interface       |
               | and API                        |
               +--------------------------------+

                  Figure 2: Exposing Data to the assumptions Network

   It should be noted that the neither the Endpoint Compliance Profile makes
   about other components in
   nor the SACM architecture.

   o  Existence of a server protocols, interfaces, and repository: The Endpoint Compliance
      Profile assumes data models that a server it references
   provide solutions to the repository, evaluator, and repository exist.

   o  Endpoint SWID installation: The Endpoint Compliance Profile
      assumes that an endpoint has been pre-provisioned with Software
      Identification Tags for its applications, orchestrator
   components and that capabilities listed above.  However, these SWID tags
   capabilities are formatted useful and stored solutions for them should be pursued in conformance with [SWID].

   o  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, future.

7.  ECP Implementations

   The following sections describe implementations of the Endpoint
   Compliance Profile makes the following
   assumptions about the SACM ecosystem:

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

   o  All endpoints on the network must be uniquely identified: Many
      administrators struggle to identify what endpoints leveraging the IETF NEA and IETF NETMOD
   architectures.

7.1.  IETF NEA ECP Implementation

   These requirements are connected
      at any given time.  By requiring written with a standardized method of endpoint
      identity, view to performing a posture
   assessment on an endpoint; as the Endpoint Compliance Profile grows
   and evolves, these requirements will enable
      administrators be expanded to answer address issues
   that arise.  Note that these requirements refer to defined components
   of the basic question, "What is on my
      network?"  Unique endpoint identification also enables NEA architecture.  As with the
      comparison NEA architecture, vendors have
   discretion as to how these NEA components map to separate pieces of current and past
   software or endpoints.

7.1.1.  Endpoint Pre-Provisioning

   An endpoint posture assessments, by
      allowing administrators is provisioned with a machine certificate that will serve
   as its unique identifier on the network as well as the components
   necessary to correlate assessments from interact with the same
      endpoint. posture manager.  This makes it easier includes a
   posture collection engine to flag suspicious changes in
      endpoint manage requests from the posture for manual or automatic review, manager
   and helps to
      swiftly identify malicious changes the posture collectors necessary to endpoint applications.

   o  Posture assessments must occur over secure, standardized
      protocols: Endpoint identity and application collect the posture
   information is very
      valuable, both to administrators and to attackers.  Therefore, it
      must be kept confidential, using secure protocols of importance to transport it
      from the enterprise.  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
   deployed on standardized protocols the network.

   The target endpoint SHOULD authenticate to provide this security enables
      greater interoperability and compatibility between endpoints, and
      allows for the development posture manager using
   a machine certificate during the establishment of compliance testing the outer tunnel
   achieved with the posture transport protocol defined in [RFC6876].
   [IF-IMV] specifies how to ensure that
      each pull an endpoint operates securely and identifier out of a
   machine certificate.  An endpoint identifier SHOULD be created in
   conformance with
      appropriate specifications.  A standards body provides [IF-IMV] from a process
      for experts machine certificate sent via
   [RFC6876].

   In the future, the identity could be a hardware certificate compliant
   with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated
   with the identity of a hardware cryptographic module, in protocols 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 cryptography on the posture manager; and provision
   the endpoints and the posture manager with machine certificates.  The
   target endpoint MAY authenticate to evaluate the
      soundness posture manager using a
   combination of protocols the machine account and security management procedures; password; however, this is
   less secure and not recommended.

7.1.2.  Endpoint

   The endpoint MUST conform to [RFC5793], which levies a set number of security standards allows an enterprise
   requirements against the endpoint.  An endpoint that complies with
   these requirements will be able to:

   1.  attempt to make initiate a session with the most
      effective use of their investment in posture manager if the
       posture makes a security management
      infrastructure.

   o  Posture assessment results must request to send an update to posture manager;

   2.  notify the posture collector if no PT-TLS session with the
       posture manager can be formatted using standardized
      schema: Well-known, standard schema allow for created;

   3.  notify the posture collector when a universal language
      for generating compliance reports.  With each endpoint speaking PT-TLS session is
       established; and

   4.  receive information from the same language, posture collectors, forward this
       information to the server via the posture collection engine.

7.1.2.1.  Posture Collector

   Any posture collector used in an Endpoint Compliance Profile enables
      information sharing between user endpoints and infrastructure
      endpoints, and between infrastructure endpoints that perform
      different security tasks.

   o  Posture information must solution
   MUST be stored by conformant with [IF-IMC]; an Internet-Draft, under
   development, that is a subset of the repository TCG TNC Integrity Measurement
   Collector interface [IF-IMC] and must will be
      exposed to an interface at submitted in the server: A standard schema enables
      standard queries from an interface exposed to an administrator at near
   future.

7.1.2.2.  Posture Collection Engine

   In the server console.  A repository must retain any current posture
      information retrieved from original IETF NEA ECP implementation, the endpoint contained
   posture collector(s), a posture broker client, and store it indexed by posture transport
   client(s).  However, in this draft, the unique identifier for functionality of the endpoint.  Any PV specified by this
      profile must be able to ascertain from its corresponding PC
      whether posture
   broker client and posture transport client(s) have been combined into
   what is now called the posture information collection engine.  This was done
   because there is up to date.  An currently no standard interface on
      the server must support a request to handle the PV
   communication between the posture broker client and posture transport
   client(s) meaning vendors will need to obtain up-to-date
      information when an define proprietary interfaces
   that will not be interoperable.

   The endpoint is connected.  This interface must
      also MUST conform to [IF-IMC] to enable communications
   between the posture collection engine and the posture collectors on
   the endpoint.

   The posture collection engine MUST implement PT-TLS.

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

   The posture collection engine MUST be able to locate an authorized
   posture manager, and switch to make a standard set of queries about
      the new posture information stored manager when required by
   the repository.  In network, in conformance with [Server-Discovery].

7.1.3.  Posture Manager

   The posture manager MUST conform to all requirements in the future,
      some forms of
   [RFC5793].

7.1.3.1.  Posture Validator

   Any posture information might validator used in an Endpoint Compliance Profile solution
   MUST be retained at conformant with [IF-IMV]; an Internet-Draft, under
   development, that is a subset of the
      endpoint.  The TCG TNC Integrity Measurement
   Verifier interface on [IF-IMV] and will be submitted in the server must accommodate near future.

7.1.3.2.  Posture Collection Manager

   In the
      ability to make a request through original IETF NEA ECP implementation, the PV posture manager
   contained posture validators(s), a posture broker server, and posture
   transport servers(s).  Similar to the corresponding PC
      about the posture of approach take on the endpoint.  Standard schema and protocols
      also enable endpoint,
   in this draft, the security functionality of posture assessment results.  By
      storing these results indexed under the endpoint's unique
      identification, secure storage itself enables endpoint posture
      information correlation, broker server and ensures that
   posture transport servers(s) have been combined into what is now
   called the enterprise's
      Repositories always offer posture collection manager.  This was done because there
   is currently no standard interface to handle the freshest, most up-to-date view of communication
   between the enterprise's endpoint posture information possible.

   o  Posture information can broker server and posture transport servers(s)
   meaning vendors will need to define proprietary interfaces that will
   not be shared: By exposing interoperable.

   The posture manager MUST conform to [IF-IMV].  Conformance to
   [IF-IMV] enables the posture manager to obtain endpoint identity
   information
      using a standard interface and API, other security and operational
      components have a high level of insight into from the enterprise's
      endpoints posture collection manager, and the software installed pass this
   information to any posture validators on them.  This will the posture manager.

   The posture collection manager MUST implement PT-TLS.

   The posture collection manager MUST support
      innovation in the areas use of asset management, vulnerability
      scanning, and administrative interfaces, as any authorized
      infrastructure machine
   certificates for TLS at each endpoint can interact consistent with the posture information.

   o  Owners
   requirements stipulated in [RFC6876] and administrators must have complete control of [Server-Discovery].

7.1.4.  Repository

   ECP 1.0 requires a simple administrative interface for the
   repository.  Posture validators on the posture
      information, policy, and manager receive the
   target endpoint mitigation: Enterprise asset posture information belongs to via PA-TNC [RFC5792] messages
   sent from corresponding posture collectors on the enterprise.  Standardized
      schema, protocols target endpoint and interfaces help to ensure that
   store this posture information is not locked in proprietary databases, but the repository linked to the identity of
   the target endpoint where the posture collectors are located.

7.1.5.  Administrative Interface and API

   An interface is made
      available necessary to its owners.  This enables allow administrators to develop
      as nuanced a policy as necessary to keep their networks secure.

5. manage the
   endpoints and software used in the Endpoint Compliance Requirements

   These requirements are written with Profile.  This
   interface SHOULD be accessible either on or through (as in the case
   of a view remotely hosted interface) the posture manager.  Using this
   interface, an authorized user or administrator SHOULD be able to:

   o  Query the repository

   o  Send commands to performing a the posture
   assessment validators, requesting information
      from the associated posture collectors residing on an endpoint; as network
      endpoints

   o  Update the Endpoint Compliance Profile grows policy that resides on the posture manager

   An API is necessary to allow infrastructure endpoints and evolves, these requirements will be expanded software
   access to address issues
   that arise.  Note that these requirements refer the information stored in the repository.  Using this API,
   an authorized endpoint SHOULD be able to:

   o  Query the repository

7.1.6.  IETF SACM SWAM Extension to defined components
   of the IETF NEA architecture.  As ECP Implementation

   This section defines the requirements associated with the NEA architecture, implementers
   have discretion as software
   asset management extension [I-D.ietf-sacm-nea-swima-patnc] to how these the
   IETF NEA components map to separate pieces
   of software or endpoints.

5.1. ECP implementation.

7.1.6.1.  Endpoint Pre-Provisioning

   This section defines the requirements associated with implementing
   SWIMA.

   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.

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

   o  the software installer; or
   o  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
   [SWID].  These tags, and the directory in which they are stored, MUST
   be updated as software is added, removed, or updated.

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.

7.1.6.3.  SWID Posture Collectors and Posture Validators

5.2.1.1.

7.1.6.3.1.  The SWID Posture Collector

   For the Endpoint Compliance Profile, the SWID Posture Collector posture collector MUST
   be conformant with [I-D.ietf-sacm-nea-swid-patnc], [I-D.ietf-sacm-nea-swima-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 posture manager 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
       posture manager

   5.  Responding to a request for SWID tags from the SWID Posture
       Validator on the server posture manager

   6.  Responding to a query from the SWID Posture Validator posture validator as to
       whether all updates have been sent

   The SWID Posture Collector 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.

7.1.6.3.2.  The SWID Posture Validator

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

   1.  Send messages to the SWID Posture Collector posture collector (at the behest of the
       administrator at the server posture manager console) requesting updates
       for SWID tags located on endpoint

   2.  Ask the SWID Posture Collector posture collector whether all updates to the SWID
       directory located at the server posture manager have been sent

   3.  Compare an endpoint's SWID posture information to policy, and
       make a recommendation to the NEAS NEA server about the endpoint

   In addition to these requirements, a SWID Posture Validator 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:

   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 [IF-IMC] to enable communications with
   the SWID Posture Collector.

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.

7.1.6.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 an endpoint

   3.  Query tags based on characteristics, such as vendor, publisher,
       etc.

   In characteristics, such as vendor, publisher,
       etc.

7.2.  IETF NETMOD ECP Implementation

   NOTE: TO BE WRITTEN

8.  ECP Use Cases

   The following sections describe the different use cases supported by
   the Endpoint Compliance Profile.

8.1.  Hardware Asset Management

   Using the administrative interface on the future, if SACM decides to develop posture manager, an interface
   authorized user can learn:

   o  what endpoints are connected 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 network at any given time; and

   o  what SWID tags were reported for the repository

   3. endpoints.

   The types of interactions that must be supported between
       publishers and subscribers ability to answer these questions offers a repository

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

   The PT-TLS protocol provides standards-based
   approach to asset management, which is a transport service vital part of enterprise
   processes such as compliance report generation for carrying the PB-
   TNC protocol messages between the endpoint Federal
   Information Security Modernization Act (FISMA), Payment Card Industry
   Data Security Standard (PCI DSS), Health Insurance Portability and the server.
   Accountability Act (HIPAA), etc.

8.2.  Software Asset Management

   The PTC administrative interface on the posture manager provides the
   ability for authorized users and PTS MUST implement PT-TLS, since a connection infrastructure to know which
   software is needed
   that: installed on which endpoints on the enterprise's network.
   This allows the enterprise to answer questions about what software is
   installed to determine if it is licensed or prohibited.  This
   information can also drive other use cases such as:

   o  Can handle large volumes of data,  vulnerability management: knowing what software is installed
      supports the ability to determine which might require multiple
      roundtrips, endpoints contain
      vulnerable software and need to be sent while the endpoint is connected patched.

   o  Allows either  configuration management: knowing which security controls need to
      be applied to harden installed software and better protect
      endpoints.

8.3.  Vulnerability Searches

   The administrative interface also provides the NEAC ability for authorized
   users or NEAS infrastructure to initiate a connection

   o  Supports secure transport based on machine certificates at both
      ends locate endpoints running software for
   which vulnerabilities have been announced.  Because of

   1.  the connection

   The PTC unique IDs assigned to each endpoint; and PTS MUST support

   2.  the use 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 machine certificates for TLS
   at each endpoint consistent with being vulnerable can
   be addressed by the requirements stipulated in
   [RFC6876] administrator or flagged for further scrutiny.

8.4.  Threat Detection and [Server-Discovery]. Analysis

   The PTC MUST be able repository's standardized API allows authorized infrastructure
   endpoints and software to locate search endpoint posture assessment
   information for evidence that an authorized server, endpoint's software inventory has
   changed, and switch can make endpoint software inventory data available to
   other endpoints.  This automates security data sharing in a
   new server when required by way that
   expedites the network, in conformance with
   [Server-Discovery].

7.  Administrative Interface correlation of relevant network data, allowing
   administrators and API

   An interface is necessary infrastructure endpoints to allow administrators identify odd endpoint
   behavior and configuration using secure, standards-based data models
   and protocols.

9.  Non-supported Use Cases

   Several use cases, including but not limited to manage these, are not
   covered by the
   endpoints and software used Endpoint Compliance Profile 1.0:

   o  Gathering non-standardized types of posture information: The
      Endpoint Compliance Profile does not prevent administrators from
      collecting posture information in proprietary formats from the
      endpoint; however it does not set requirements for doing so.

   o  Solving the lying endpoint problem: The Endpoint Compliance
      Profile does not address the lying endpoint problem; the Endpoint Compliance Profile.  This
   interface SHOULD be accessible Profile
      makes no assertions that it can catch an endpoint that is, either on
      maliciously or through (as in accidentally, reporting false posture information
      to the case
   of a remotely hosted interface) posture manager.  However, other solutions may be able to
      use the server.  Using posture information collected using the capabilities
      described in this interface, profile to catch an
   authorized user or administrator SHOULD endpoint in a lie.  For
      example, a sensor may be able to:

   o  Query the repository
   o  Send commands to compare the PVs, requesting posture information from the
      associated PCs residing
      it has collected on network endpoints

   o  Update the policy that resides an endpoint's activity on the server

   An API is necessary network to allow infrastructure endpoints and software
   access what
      the endpoint reported to the information stored server and flag discrepancies.
      However, these capabilities are not described in the repository.  Using this API,
   an authorized endpoint SHOULD be able to:

   o  Query the repository

8. profile.

10.  Endpoint Compliance Profile Examples

8.1.

10.1.  Continuous Posture Assessment of an Endpoint

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

          Figure 4: 3: Continuous Posture Assessment of an Endpoint

8.1.1.

10.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 posture
   collector to the SWID Posture Validator. posture validator.  The message is sent down
   the NEA stack, encapsulated by NEA protocols until it is sent by the
   PTC
   posture transport client to the PTS. posture transport server.  The PTS
   posture transport server then forwards it up through the stack, where
   the layers of encapsulation are removed until the SWID Message
   arrives at the SWID Posture Validator. posture validator.

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

                Figure 5: 4: Compliance Protocol Encapsulation

   The SWID Posture Validator 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
   +---------------+        +---------------+                  Posture Manager
              +----------------+        +----------------+
              |                |        |                |
              | +-----------+ +------------+ |        | +-----------+ +------------+ |
              | | SWID       | |        | | SWID       |-|-+
              | | Posture    | |        | | Posture    | | |
              | | Collector  | |        | | Validator  | | |
              | +-----------+ +------------+ |        | +-----------+ +------------+ | |
              |      |         |        |      |         | |     Repository
              |      | IF-IMC  |        |      | IF-IMV  | |     +--------+
              |      |         |        |      |         | |     |        |
              | +-----------+ +------------+ |        | +-----------+ +------------+ | |     |        |
              | | PB Client Posture    | |        | | PB Server Posture    | | +---->|        |
              | +-----------+ |        | +-----------+ |       |        |
   |      |        |        |      |        |       +--------+
   |      | | Collection | |        | | Collection | |       |        |
              | | +-----------+ | Engine     | +-----------+ |<------>| | Manager    | | PT Client       | |<------>|        | PT Server
              | +------------+ |        | +-----------+ +------------+ | PT-TLS       | +-----------+        |
              |                |        |                |
   +---------------+        +---------------+       +--------+
              +----------------+        +----------------+

                 Figure 6: 5: 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 posture manager'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                  Posture Manager    |  / \
   +---------------+        +---------------+
              +----------------+        +----------------+ |
              |                |        |                | |
              | +-----------+ +------------+ |        | +-----------+ +------------+ | |
              | | SWID       | |        | | SWID       |-|-+
              | | Posture    | |        | | Posture    | |
              | | Collector  | |        | | Validator  | |
              | +-----------+ +------------+ |        | +-----------+ +------------+ |
              |      |         |        |      |         |       Repository
              |      | IF-IMC  |        |      | IF-IMV  |       +--------+
              |      |         |        |      |         |       |        |
              | +-----------+ +------------+ |        | +-----------+ +------------+ |       |        |
              | | Posture    | |        | | Posture    | |       |        |
              | | Collection | |        | | Collection | | PB Client       |        |
              | | PB Engine     | |<------>| | Manager    | |       +--------+
              | +------------+ |        | +------------+ |
              |                |        |                |
              +----------------+        +----------------+

                   Figure 6: Server Alerts Network Admin

10.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                  Posture Manager    |  / \
            +----------------+        +----------------+ |
            |                |        | +-----------+                | | +-----------+
            | +------------+ |        | +------------+ | |
            | | SWID       | |        | | SWID       |-|-+
            | | Posture    | |        | | Posture    | |
            | | Collector  | |        | | Validator  | |
            | +------------+ |        | +------------+ |
            |      |         |        |      |         |       Repository
            |      | IF-IMC  |        |      | IF-IMV  |       +--------+
            |      |         |        |      |         |       |        |
            | +------------+ |        | +------------+ |       | +-----------+        |
            | +-----------+ | Posture    | |        | | Posture    | |------>|        |
            | | PT Client Collection | |        | | Collection | |       |        |
            | | Engine     | |<------>| | PT Server Manager    | |       | +-----------+        | PT-TLS
            | +-----------+ +------------+ |        | +------------+ |       +--------+
            |                |
   +---------------+        +---------------+        |                |
            +----------------+        +----------------+

             Figure 7: Server Alerts Network Admin

8.2.  Administrator Searches for Vulnerable Endpoints

   An announcement is made that for Vulnerable Endpoints

   The repository returns a particular version list of a piece 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.

11.  Profile Requirements

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

   o  Meets the needs of
   software has SACM use cases: The Endpoint Compliance Profile
      must support the use cases described in [RFC7632] as they apply to
      endpoint self-reporting and endpoint posture assessment.

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

   o  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 vulnerability. 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.

   o  Easy to implement: The administrator uses 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.

   o  Easy to use: The Endpoint Compliance Profile should describe a
      simple, integrated user interface that administrators can use to
      perform the
   Administrative Interface on activities listed in the server to search profile's use cases.  The
      Endpoint Compliance Profile should not constrain innovation by
      specifying details of the repository for
   endpoints that reported user interface but rather functional
      requirements.

   o  Platform-independent: Since network environments may contain many
      different types of endpoints, the SWID tag for solution should operate
      independently of the vulnerable software.

                                                 (")
                                                __|__
                                              +-->| endpoint platform.

   o  Scalable: The 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 Compliance Profile must be designed to
      scale to very large numbers of endpoints.

12.  Future Work

   This section captures ideas for Vulnerable Endpoints

   The repository returns a list future work related to ECP that might
   be of entries interest to the IETF SACM WG.  These ideas are listed in no
   particular order.

   o  Integratate the matching IETF NETMOD Yang Push architecture.

   o  Add support endpoint types beyond workstations, servers, and
      network infrastructure devices.

   o  Examine the
   administrator's search.  The administrator can then address integration of [I-D.ietf-mile-xmpp-grid].

   o  Define a standard interface and API for interacting with the
   vulnerable endpoints by taking some follow-up action such
      repository.  Requirements to consider include: creating a secure
      channel between a publisher and the repository, creating a secure
      channel between a subscriber and the repository, and the types of
      interactions that must be supported between publishers and
      subscribers to a repository.

   o  Define a standard interface for communications between the posture
      broker client and posture transport client(s) as well as removing
   it from the network, quarantining it, or updating
      posture broker server and posture transport server(s).

   o  Retention of posture information on the vulnerable
   software.

9. target endpoint.

   o  Define an orchestrator component as well as publish/subscribe
      interface for it.

   o  Define an evaluator component as well as an interface for it.

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

   +-----------------------+-------------------------------------------+
   | 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   | Juniper Networks                          |
   | Co-Chair)             |                                           |
   |                       |                                           |
   | Cliff Kahn            | Juniper Networks                          |
   |                       |                                           |
   | Lisa Lorenzin         | Juniper Networks                          |
   |                       |                                           |
   | Atul Shah (TNC-WG Co- | Microsoft                                 |
   | Chair)                |                                           |
   |                       |                                           |
   | 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-   | U.S. Government                           |
   | McKay                 |                                           |
   |                       |                                           |
   | Mary Lessels          | U.S. Government                           |
   |                       |                                           |
   | Chris Salter          | U.S. Government                           |
   +-----------------------+-------------------------------------------+

      Table 1: Members of the TNC Work Group that Contributed to the
                                 Document

10.

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

15.  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, whitelisting, 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), 15.1), the
   attacks that may be mounted against systems that implement the
   Endpoint Compliance Profile (Section 11.2), 15.2), and the countermeasures
   that may be used to prevent or mitigate these attacks (Section 11.3). 15.3).
   Overall, a substantial reduction in cyber risk can be achieved.

11.1.

15.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 data models 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 NEA client 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 NEA client and have
   it be compatible with the NEAS NEA server 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:

   o  it has proven secure properties,

   o  it can be implemented on most types of endpoints,

   o  it allows the gathering of large amounts of information when a
      endpoint is connected, and

   o  it enables use of a mechanism to ensure that the client is
      authenticated (authorized) - a client certificate - which also
      provides a consistent identifier.

   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.

15.2.  Threat Model

   This section lists the attacks that can be mounted on an Endpoint
   Compliance Profile environment.  The following section (Section 11.3) 15.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],
   [I-D.ietf-sacm-nea-swima-patnc], [IF-IMC], [RFC5793],
   [Server-Discovery], [RFC6876], [IF-IMV].

11.2.1.

15.2.1.  Endpoint Attacks

   While the Endpoint Compliance Profile provides substantial
   improvements in endpoint security as described in Section 11.1, 15.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.

   o  Compromise of endpoint: A compromised endpoint may report false
      information to confuse or even provide maliciously crafted
      information with a goal of infecting others.

   o  Putting bad information in SWID directory: Even if an endpoint is
      not completely compromised, some of the software running on it may
      be unreliable or even malicious.  This software, potentially
      including the SWID generation or discovery tool, or malicious
      software pretending to be a SWID generation or discovery tool, can
      place incorrect or maliciously crafted information into the SWID
      directory.  Endpoint users may even place such information in the
      directory, whether motivated by curiosity or confusion or a desire
      to bypass restrictions on their use of the endpoint.

   o  Identity spoofing (impersonation): A compromised endpoint may
      attempt to impersonate another endpoint to gain its privileges or
      to besmirch the reputation of that other endpoint.

11.2.2.

15.2.2.  Network Attacks

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

   o  Eavesdropping, modification, injection, replay, deletion

   o  Traffic analysis

   o  Denial of service and blocking traffic

11.2.3.  Server

15.2.3.  Posture Manager Attacks

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

   o  Compromised trusted server: manager: A compromised server posture manager or a
      malicious party that is able to impersonate a server posture manager can
      incorrectly grant or deny access to endpoints, place incorrect
      information into the repository, or send malicious messages to endpoints
      endpoints.

   o  Misconfiguration of trusted server: posture manager: Accidental or purposeful
      misconfiguration of a trusted server posture manager can cause effects
      that are similar to those listed for compromised trusted server. posture
      manager.

   o  Malicious untrusted server: posture manager: An untrusted server posture manager
      cannot mount any significant attacks because all properly
      implemented endpoints will refuse to engage in any meaningful
      dialog with such a server.

11.2.4. posture manager.

15.2.4.  Repository Attacks

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

   o  Putting bad information into trusted repository: An authorized
      repository client such as a server may be able to put incorrect
      information into a trusted repository or delete or modify
      historical information, causing incorrect decisions about endpoint
      security.  Placing maliciously crafted data in the repository
      could even lead to compromise of repository clients, if they fail
      to carefully check such data.

   o  Compromised trusted repository: A compromised trusted repository
      or a malicious untrusted repository that is able to impersonate a
      trusted repository can lead to effects similar to those listed for
      "Putting bad information into trusted repository".  Further, a
      compromised trusted repository can report different results to
      different repository clients or deny access to the repository for
      selected repository clients.

   o  Misconfiguration of trusted repository: Accidental or purposeful
      misconfiguration of a trusted repository can deny access to the
      repository or result in loss of historical data.

   o  Malicious untrusted repository: An untrusted repository cannot
      mount any significant attacks because all properly implemented
      repository clients will refuse to engage in any meaningful dialog
      with such a repository.

11.3.

15.3.  Countermeasures

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

11.3.1.

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

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

15.3.3.  Countermeasures for Server Posture Manager Attacks

   Because of the serious consequences of server posture manager compromise, servers
   posture managers 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 posture manager and SHOULD
   utilize a [IEEE-802-1ar] compliant [IEEE-802-1ar]compliant hardware cryptographic module for
   identity and/or integrity measurements of the server. posture manager.  They
   should be well managed to minimize vulnerabilities in the underlying
   platform and in systems upon which the server posture manager depends.
   Network security measures such as firewalls or intrusion detection
   systems may be used to monitor and limit traffic to and from the server.
   posture manager.  Personnel with administrative access to the
   server posture
   manager should be carefully screened and monitored to detect problems
   as soon as possible.  Server  Posture manager administrators should not use password-
   based
   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. posture managers.

   To ease detection of server posture manager compromise should it occur, server
   posture manager 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 posture manager behavior is detected.
   To aid forensic investigation, permanent read-only audit logs of
   security-relevant information pertaining to servers posture manager
   (especially administrative actions) should be maintained.  If server posture
   manager compromise is detected, the server's posture manager'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, posture managers, using the mechanisms
   described in [Server-Discovery].

11.3.4.

15.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.
   posture manager.  In this circumstance, all messages between the server
   posture manager 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 posture manager 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.

16.  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 NEA client 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.

17.  Change Log

13.1.

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

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

17.3.  -02 to -00

   Edited Absrtact through Figure 2

   Draft adopted by IETF SACM WG.

17.4.  -00 to remove references -01

   Significant edits to SWIMA, and
   uplevel up-level the draft to describe SACM collection
   over multiple different
   protocols protocols.

   Replaced references to SANS with CIS.

   Made a few other minor editorial changes.

14.

18.  References

14.1.

18.1.  Informative References

   [CIS]      http://www.cisecurity.org/controls/, "CIS Critical
              Security Controls".

   [DSD]      http://www.dsd.gov.au/publications/csocprotect/
              top_4_mitigations.htm, "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,
              <https://www.rfc-editor.org/info/rfc5209>.

   [TNC]      Trusted Computing Group, "TCG Trusted Network Connect TNC
              Architecture for Interoperability, Version 1.5", February
              2012.

14.2.

18.2.  Normative References

   [I-D.ietf-sacm-nea-swid-patnc]

   [I-D.ietf-mile-xmpp-grid]
              Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre,
              "Using XMPP for Security Information Exchange", draft-
              ietf-mile-xmpp-grid-04 (work in progress), October 2017.

   [I-D.ietf-netconf-yang-push]
              Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-
              Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore
              Subscription", draft-ietf-netconf-yang-push-12 (work in
              progress), December 2017.

   [I-D.ietf-sacm-nea-swima-patnc]
              Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and
              J. Fitzgerald-
              McKay, Fitzgerald-McKay, "Software Inventory Message and
              Attributes (SWIMA) for PA-TNC", draft-ietf-sacm-nea-swid-patnc-00 draft-ietf-sacm-nea-swima-
              patnc-01 (work in progress), January September 2017.

   [I-D.ietf-sacm-terminology]
              Waltermire, D., Montville, A., Harrington, D., and N. Cam-
              Winget, "Terminology for Security Assessment", draft-ietf-
              sacm-terminology-05 (work in progress), 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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc5792>.

   [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, <https://www.rfc-editor.org/info/rfc5793>.

   [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,
              <https://www.rfc-editor.org/info/rfc6876>.

   [RFC7632]  Waltermire, D. and D. Harrington, "Endpoint Security
              Posture Assessment: Enterprise Use Cases", RFC 7632,
              DOI 10.17487/RFC7632, September 2015,
              <https://www.rfc-editor.org/info/rfc7632>.

   [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: dhaynes@mitre.org

   Jessica Fitzgerald-McKay
   Department of Defense
   9800 Savage Road
   Ft. Meade, Maryland
   USA

   Email: jmfitz2@nsa.gov
   Lisa Lorenzin
   Pulse Secure
   2700 Zanker Rd., Suite 200
   San Jose, CA  95134
   US

   Email: llorenzin@pulsesecure.net