| SACM | D. Haynes |
| Internet-Draft | The MITRE Corporation |
| Intended status: Best Current Practice | J. Fitzgerald-McKay |
| Expires: May 7, 2020 | Department of Defense |
| November 4, 2019 |
Endpoint Posture Collection Profile
draft-ietf-sacm-epcp-00
This document specifies the Endpoint Posture Collection Profile, which describes the best practices for the application of IETF, TNC, and ISO/IEC data models, protocols, and interfaces to support the on-going collection and communication of endpoint posture to a centralized server where it can be stored and made available to other tools.
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 May 7, 2020.
Copyright (c) 2019 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.
The Endpoint Posture Collection Profile (EPCP) describes the best practices for the collection and communication of posture information from network-connected endpoints to a centralized server leveraging prior work from the IETF NEA WG, the IETF NETCONF WG, IETF NETMOD WG, the Trusted Computing Group (TCG) Trusted Network Communications [TNC] Work Group, and the International Organization for Standardization/International Electrotechnical Commission Joint Technical Committee (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC 1, SC7, WG21).
This document focuses on reducing the security exposure of a network by enabling:
Thus, eliminating the need for multiple collection tools on an endpoint collecting the same data for different purposes. Future revisions of this document may include support for the collection of posture information from other endpoint types as well as a standardized interface for storing and querying data in repositories among other capabilities. Additional information about this future work can be found in Section 5 of this document.
To support the collection of posture information from new endpoint types, this document is organized such that it first provides a high-level overview of EPCP as well as the abstract components and transactions that will be realized by implementations (Section 2). This is followed by individual sections that discuss the best practices for specific implementations of the EPCP for a given endpoint type (e.g., traditional workstations and servers, network devices, mobile devices, etc.) along with any extensions for supported use cases (software asset management, vulnerability management, etc.). Over time, the best practices may be expanded to address issues that arise, support new capabilities, or support new implementations beyond IETF NEA and IETF NETCONF.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.
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.
This document uses terms as defined in [I-D.ietf-sacm-terminology] unless otherwise specified.
The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols, and interfaces can be used to support the posture assessment of endpoints on a network. This profile does not generate new data models, protocols, or interfaces; rather, it offers best practices for a full end-to-end solution for posture assessment, as well as a fresh perspective on how existing standards can be leveraged against vulnerabilities. Rationale for the EPCP solution as well as the supported and non-supported use cases is available in Appendix A and Appendix B respectively.
The EPCP defines the following best practices for posture assessments against network-connected endpoints.
Furthermore, the EPCP aims to support data storage and data sharing capabilities to make the collected posture information available to authorized parties and components in support of other post-processes (analytic, access control, remediation, reporting, etc.).
To support posture assessment, data storage, and data sharing capabilities, the EPCP defines several components. Some of these components reside on the target endpoint. Others reside on the posture manager that manages communications with the target endpoint and stores the target endpoint's posture information in a repository.
The primary focus of this document is on the communication between the posture manager and endpoints through the posture collection manager and posture collection engine components. While the orchestrator, evaluator, repository, and API will be discussed in the context of the EPCP, these components are for illustrative purposes only and are not strictly defined nor are best practices provided for them. As a result, vendors are free to implement these components and interfaces in a way that makes the most sense for their products.
Orchestrator
+--------+
| |
| |
| |<---+
| | |
| | | ************Posture Collection Profile*************
| | | * *
+--------+ | * Posture Manager Endpoint *
| * +----------------+ +----------------+ *
publish/ | * | | | | *
subscribe | * | | | | *
+---->| | | | *
Repository * | | report/ | | *
+--------+ * | +------------+ | publish | +------------+ | *
| | store * | | | |<----------| | | | *
| |<-------->| | Posture | | | | Posture | | *
| | * | | Collection | | | | Collection | | *
| | * | | Manager | | query/ | | Engine | | *
| |<---+ * | | | | subscribe | | | | *
| | | * | | | |---------->| | | | *
+--------+ | * | +------------+ | | +------------+ | *
| * | | | | *
request/ | * | | | | *
response | * | | | | *
| * | | | | *
Evaluator | * +----------------+ +----------------+ *
+--------+ | * ^ ^ *
| | | ********|****|*************************************
| | | | +-------------+
| |<---+ | |
| | | +-------------------------+
| | | | Application Programming |
| | | | Interface (API) |
+--------+ | +-------------------------+
^ |
| query/response |
+---------------------+
Figure 1: EPCP Components
An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is monitored by the enterprise and is the target of posture assessments. To support these posture assessments, posture information is collected via a posture collection engine.
The posture collection engine is located on the target endpoint and can either push data to the posture collection manager (see Section 2.2.3) or receive queries for data from the posture collection manager (see Section 2.2.4). The posture collection engine sends collected posture information to the posture manager where it can be sanity checked and stored in the repository. The posture collection engine also contains a capability that sets up exchanges between the target endpoint and posture manager. This capability makes the posture collection engine responsible for performing the client-side portion of encryption handshakes, and for locating authorized posture managers with which to communicate.
The posture manager is an endpoint that collects and validates posture information received about a target endpoint. It also stores the posture information it receives in the repository where it can be retrieved and used in evaluations. The posture manager does not evaluate the posture information.
The posture collection manager is a lightweight and extensible component that facilitates the coordination and execution of posture collection requests using collection mechanisms deployed across the enterprise. The posture collection manager may query and retrieve guidance from the repository to guide the collection of posture information from the target endpoint.
The posture collection manager also contains a capability that sets up exchanges between the target endpoint and the posture manager, and manages data sent to and from the posture collection engine. It is also responsible for performing the server-side portion of encryption handshakes.
If the posture manager wants to register for the continuous collection of endpoint posture changes with the endpoint, then it must do so in a secure and scalable way. Specifically, it will need to create subscriptions with endpoints in a way which allows the posture data to be pushed. Effectively, this means that the target endpoint must be able to establish secure transport connectivity to the posture collection manager as needed, and the posture collection manager must be able to periodically collect the current state of the endpoint and assess its posture.
The repository hosts guidance, endpoint identification information, and posture information reported by target endpoints where it is made available to authorized components and persisted over a period of time set by the administrator. Information stored in the repository will be accessible to authorized parties via a standardized API. The repository may be a standalone component or may be located on the posture manager. Furthermore, an implementation is not restricted to a single repository and may leverage several repositories to provide this functionality.
The evaluator assesses the posture status of a target endpoint by comparing collected posture information against the desired state of the target endpoint specified in guidance. The evaluator queries and retrieves the appropriate guidance from the repository as well as queries and retrieves the posture information required for the assessment from the repository. If the required posture information is not available in the repository, the evaluator may request the posture information from the posture collection manager, which will result in the collection of additional posture information from the target endpoint. This information is subsequently stored in the repository where it is made available to the evaluator and other components. The results of the assessment are stored in the repository where they are available to tools and administrators for post-processes including follow-up actions, further evaluation, and historical purposes. The evaluator may also be triggered by events on an endpoint or the network.
The orchestrator provides a publish/subscribe interface for the repository so that infrastructure endpoints can subscribe to and receive published posture assessment results from the repository regarding endpoint posture changes.
The API allows authorized users, infrastructure endpoints, and software to query the repository as well as manage endpoints and other components used in EPCP via the posture manager.
The following sections describe the transactions associated with EPCP components and may be provided in an implementation. The transactions span the deployment of an endpoint, integration into the EPCP, data collection, and the storage and dissemination of that information for different use cases.
An endpoint is provisioned with one or more attributes that will serve as its unique identifier on the network as well as the components (e.g., posture collection engine, etc.) and data models (e.g., SWID) necessary to interact with the posture manager. Examples of such attributes include serial numbers, hardware certificates compliant with [IEEE-802-1ar], and the identities of hardware cryptographic modules among others. An endpoint should also have a MAC address which should change over time. Once provisioning is complete, the endpoint is deployed on the network. Over time, components and data models may need to be added to the endpoint or updated to support the collection needs of an enterprise.
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 an encryption handshake, during which endpoint identity information is exchanged.
The posture assessment is initiated when the posture collector engine on the target endpoint notices that relevant posture information on the endpoint has changed. Then, the posture collection engine initiates a posture assessment information exchange with the posture collection manager.
The posture assessment is initiated by the posture collection manager. This can occur because:
Once posture information is received by the posture manager, it is forwarded to the repository. The repository could be co-located with the posture manager, or standalone where the repository and posture manager directly communicate with each other or the communication is brokered through the orchestrator. The posture information is stored in the repository along with past posture information collected about the target endpoint.
Because the 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 posture information. Such authorized parties may include, but are not limited to, administrators or endpoint owners (via the posture manager's API), evaluators that access the repository directly, and orchestrators that rely on publish/subscribe communications with the repository.
When EPCP is used, posture collectors running on the target endpoint gather posture information as changes occur on the endpoint. The posture information is aggregated by the posture broker client and forwarded to a posture manager, over a secure channel, via the posture transport client. Once received by the posture transport server on the posture manager, the posture information is directed by the posture broker server to the appropriate posture validators where it can be processed and stored in a repository. There the posture information can be used to carry out assessments or other post-processing tasks. Posture collectors can also be queried by posture validators to refresh posture information about the target endpoint or to ask a specific question about posture information. This is shown in Figure 2.
Posture Posture
Collection Collection
Manager Engine
+---------------+ +---------------+
| | | |
| +-----------+ | PA-TNC | +-----------+ |
| | Posture | |--------| | Posture | |
| | Validator | | | | Collector | |
| +-----------+ | | +-----------+ |
| | | | | |
| | IF-IMV | | | IF-IMC |
| | | | | |
| +-----------+ | PB-TNC | +-----------+ |
| | PB Server | |--------| | PB Client | |
| +-----------+ | | +-----------+ |
| | | | | |
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Server | |<------>| | PT Client | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 2: NEA Components
These requirements are written with a view to performing a posture assessment on an endpoint and refer to defined components of the NEA architecture [RFC5209] as well as the IF-IMV and IF-IMC interfaces defined in the Trusted Computing Group's TNC Work Group. As with the NEA architecture, vendors have discretion as to how these NEA components map to separate pieces of software or endpoints.
It should be noted that the posture broker client and posture transport client components of the posture collection engine and the posture broker server and posture transport server components of the posture collection manager would likely need to be implemented by a single vendor because there are no standardized interfaces between the respective components and would not be interoperable.
Examples of the EPCP as implemented using the components from the NEA architecture are provided in Appendix C.
An endpoint SHOULD be provisioned with a machine certificate that will serve as its unique identifier on the network as well as the components necessary to interact with the posture manager. This includes a posture collection engine to manage requests from the posture manager and the posture collectors necessary to collect the posture information of importance to the enterprise. The endpoint is deployed on the network.
The target endpoint SHOULD authenticate to the posture manager using a machine certificate during the establishment of the outer tunnel achieved with the posture transport protocol defined in [RFC6876]. [IF-IMV] specifies how to pull an endpoint identifier out of a machine certificate. An endpoint identifier SHOULD be created in conformance with [IF-IMV] from a machine certificate sent via [RFC6876].
Other authenticators are possible. The target endpoint MAY authenticate to the posture manager using a combination of the machine account and password; however, this is less secure and not recommended. A more secure approach would leverage a hardware certificate compliant with [IEEE-802-1ar]; this identifier 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 establish a certificate root authority; install its root certificate on endpoints and on the posture manager; and provision the endpoints and the posture manager with machine certificates.
The endpoint MUST conform to [RFC5793], which levies several requirements against the endpoint. An endpoint that complies with these requirements will be able to:
Any posture collector used in an EPCP solution MUST be conformant with the TCG TNC Integrity Measurement Collector interface [IF-IMC].
The posture broker client MUST conform to [IF-IMC] to enable communications between the posture broker client and the posture collectors on the endpoint.
The posture transport client MUST implement PT-TLS.
The posture transport client MUST support the use of machine certificates for TLS at each endpoint consistent with the requirements stipulated in [RFC6876] and [Server-Discovery].
The posture transport client MUST be able to locate an authorized posture manager, and switch to a new posture manager when required by the network, in conformance with [Server-Discovery].
The posture manager MUST conform to all requirements in [RFC5793].
Any posture validator used in an EPCP solution MUST be conformant with the TCG TNC Integrity Measurement Verifier interface [IF-IMV].
The posture broker server MUST conform to [IF-IMV]. Conformance to [IF-IMV] enables the posture broker server to obtain endpoint identity information from the posture transport server, and pass this information to any posture validators on the posture manager.
The posture transport server MUST implement PT-TLS.
The posture transport server MUST support the use of machine certificates for TLS at each endpoint consistent with the requirements stipulated in [RFC6876] and [Server-Discovery].
EPCP requires a simple interface for the repository. Posture validators on the posture manager receive the target endpoint posture information via PA-TNC [RFC5792] messages sent from corresponding posture collectors on the target endpoint. The posture validators store this information in the repository linked to the identity of the target endpoint where the posture collectors are located.
This section defines the requirements associated with the Software Inventory Message and Attributes (SWIMA) extension for PA-TNC [RFC8412] in support of the software asset management use case with the IETF NEA EPCP implementation.
The following requirements assume that the platform or OS vendor supports the use of [SWID] and/or [I-D.ietf-sacm-coswid] tags and the standard directory locations for the SWID and CoSWID tags as specified by the [SWID] specification.
The primary content for the EPCP is the information conveyed in the elements of a SWID or CoSWID tag. The SWID specification defines an XML-based software identification tag and the CoSWID specification defines a Concise Binary Object Representation (CBOR) that is compatible with the SWID specification. CoSWID tags require significantly less memory and bandwidth to store and transmit as compared to the traditional XML-based SWID tags.
For readability, since CoSWID is a concise representation of SWID, only SWID is used throughout the remainder of this document although CoSWID may be used in addition to, or in place of, SWID.
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:
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.
The following sections outline the requirements for SWID Posture Collectors and Posture Validators.
For the EPCP, the SWID posture collector MUST be conformant with [RFC8412], which includes requirements for:
The SWID posture collector is not responsible for detecting that the SWID directory was not updated when an application was either installed or uninstalled.
Conformance to [RFC8412] enables the SWID posture validator to:
In addition to these requirements, a SWID posture validator used in conformance with this profile MUST be capable of passing this SWID posture information as well as the associated endpoint identity to the repository for storage.
The interface SHOULD enable an administrator to:
When EPCP is used, a NETCONF client that implements the posture collection manager sends a query to target network device endpoint requesting posture information over a secure channel. Once the NETCONF server on the endpoint receives the request, it queries one or more datastores for the posture information. The NETCONF server then reports the information back to the NETCONF client where it can be stored in a repository for use by other tools. This is shown in Figure 3.
Posture Posture
Collection Collection
Manager Engine
+---------------+ +---------------+
| | | |
| | | +-----------+ |
| | | | Data | |
| | | | Store(s) | |
| | | +-----------+ |
| | | | |
| | | | |
| +-----------+ | | +-----------+ |
| | NETCONF | | | | NETCONF | |
| | Client | |<------->| | Server | |
| +-----------+ | NETCONF | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 3: NETCONF Components
These requirements are written with a view to performing a posture assessment on network device endpoints (routers, switches, etc.) and refer to defined components of the NETCONF architecture and map back to EPCP. As with the NETCONF architecture, vendors have discretion as to how these NETCONF components map to separate pieces of software or endpoints.
For the posture manager to be able to query the datastores on the endpoint, the endpoint MUST be configured to grant the posture manager access to its datastores as described in [RFC6241]. The posture manager is identified by its NETCONF username. The endpoint is deployed on the network.
For the posture manager to be able to query the datastores on the endpoint, the posture manager MUST be provisioned with a NETCONF username that will be used to authenticate the posture manager to the endpoint as described in [RFC6241]. The username generated will be determined by the selected transport protocol. The posture manager is deployed on the network.
An endpoint MUST conform to the requirements outlined for servers in the NETCONF protocol as defined in [RFC6241]. This requires the implementation of NETCONF over SSH [RFC6242]. An endpoint MAY support the NETCONF protocol over other transports such as TLS [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040].
A NETCONF datastore on an endpoint MUST support the operations outlined in [RFC6241], but, the actual implementation of the datastore is left to the endpoint vendor.
Datastores MUST support the YANG data modeling language [RFC7950] for expressing endpoint posture information in a structured format. In addition, datastores MAY support other data models such as XML (via YIN) for representing posture information.
Datastores MUST support the compliance posture information specified in [RFC7317]. Datastores MAY support other models standardized or proprietary as deemed appropriate by the endpoint vendor.
A posture manager MUST conform to the requirements specified for clients in the NETCONF protocol as defined in [RFC6241]. This requires the implementation of NETCONF over SSH [RFC6242]. A posture manager MAY also support the NETCONF protocol over other transports such as TLS [RFC7589]. In addition, a posture manager MAY support the RESTCONF protocol as defined in [RFC8040].
EPCP requires a simple interface for the repository. The posture collection manager on the posture manager receives the target endpoint posture information via NETCONF [RFC6241] messages sent from posture collection engine on the target endpoint. The posture collection manager stores this information in the repository linked to the identity of the target endpoint from which it was collected.
This section captures ideas for future work related to EPCP that might be of interest to the IETF SACM WG. These ideas are listed in no particular order.
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.
The authors also wish to give a special thanks to Henk Birkholz, Dan Ehrlich, Ira McDonald, Kathleen Moriarty, David Oliva, and Eric Voit for their thoughtful comments and edits to this document.
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.
This Security Considerations section includes an analysis of the attacks that may be mounted against systems that implement the EPCP (Section 8.1) and the countermeasures that may be used to prevent or mitigate these attacks (Section 8.2). Overall, a substantial reduction in cyber risk can be achieved.
This section lists the attacks that can be mounted on a NEA implementation of an EPCP environment. The following section (Section 8.2) describes countermeasures.
Because the EPCP describes a specific use case for NEA components, many security considerations for these components are addressed in more detail in the technical specifications: [RFC8412], [IF-IMC], [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV].
While the EPCP provides substantial improvements in endpoint security, endpoints can still be 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.
Generally, the network cannot be trusted. A variety of attacks can be mounted using the network, including:
The posture manager is a critical security element and therefore merits considerable scrutiny. A variety of attacks can be leveraged against the Posture Manager.
The repository is also an important security element and therefore merits careful scrutiny.
This section lists the countermeasures that can be used in a NEA implementation of an EPCP environment.
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.
For secure device identification and to correlate device identifiers if the MAC address is randomized, MAC addresses should be collected along with other, more secure endpoint identifiers. 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 EPCP 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 by hashing or recording indicators of compromise.
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 EPCP (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.
Because of the serious consequences of posture manager compromise, 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 posture manager and SHOULD utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for identity and/or integrity measurements of the posture manager. They should be well managed to minimize vulnerabilities in the underlying platform and in systems upon which the 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 posture manager. Personnel with administrative access to the posture manager should be carefully screened and monitored to detect problems as soon as possible. Posture manager administrators should not use password-based authentication but should instead use non-reusable credentials and multi-factor authentication (where available). Physical security measures should be employed to prevent physical attacks on posture managers.
To ease detection of posture manager compromise, should it occur, 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 posture manager behavior is detected. To aid forensic investigation, permanent read-only audit logs of security-relevant information pertaining to posture manager (especially administrative actions) should be maintained. If posture manager compromise is detected, the 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 posture managers, using the mechanisms described in [Server-Discovery].
If the host for the repository is located on its own endpoint, it should be protected with the same measures taken to protect the posture manager. In this circumstance, all messages between the 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:
The EPCP specifically addresses the collection of posture data from enterprise endpoints by an enterprise network. As such, privacy is a fundamental concern for those deploying this EPCP solution, given EU GDPR, California CCPA, and many other privacy regulations. The enterprise SHOULD implement and enforce their duty of care.
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 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.
An enterprise network SHOULD limit access to endpoint posture and identification information to authorized users and SHOULD enforce policies that prevent the export of endpoint posture metadata to unauthorized third parties.
| [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. |
| [ECP] | Trusted Computing Group, "TCG Trusted Network Connect Endpoint Compliance Profile, Version 1.10", December 2014. |
| [IEEE-802-1ar] | Institute of Electrical and Electronics Engineers, "IEEE 802.1ar", December 2009. |
| [RFC5209] | Sangster, P., Khosravi, H., Mani, M., Narayan, K. and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008. |
| [TNC] | Trusted Computing Group, "TCG Trusted Network Connect TNC Architecture for Interoperability, Version 1.5", February 2012. |
The value of continuous endpoint posture assessment is well established. Security experts have identified asset management and vulnerability remediation as a critical step for preventing intrusions. Application 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 Controls 1, 2, and 3, respectively, of the CIS Controls [CIS]. While there are commercially available solutions that attempt to address these security controls, these solutions do not:
As is true of most solutions offered today, the solution found in the EPCP does not attempt to solve the lying endpoint problem, or detect infected endpoints; rather, it focuses on ensuring that healthy endpoints remain healthy by keeping software up-to-date and patched.
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.
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 EPCP will enable administrators to answer the basic question, "What is on my network?" In [I-D.ietf-sacm-terminology], SACM defines this set of endpoints on the network as the SACM domain. Unique endpoint identification also enables the comparison of current and past endpoint posture assessments, by allowing administrators to correlate assessments from the same endpoint. This makes it easier to flag suspicious changes in endpoint posture for manual or automatic review, and helps to swiftly identify malicious changes to endpoint applications.
Meeting EPCP best practices requires the use of standardized 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.
Posture information must be sent over standardized protocols to ensure the confidentiality and authenticity of this data while in transit. Implementations of the EPCP include [RFC6876] and [RFC6241] for communication between the target endpoint and the posture manager. These protocols allow networks that implement this solution to collect large amounts of posture information from an endpoint to make decisions about that endpoint's compliance with some policy. The EPCP 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 with some policy.
Posture information must be stored by the repository and must be exposed to an interface at the posture manager. Standardized data models enable standardized queries from an interface exposed to an administrator at the posture manager. 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 collection manager specified by this profile must be able to ascertain from its corresponding posture collection engine whether the posture information is up to date. An interface on the posture manager must support a request 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 posture manager must accommodate the ability to make a request to the corresponding posture collection engine about the posture of the target endpoint. Standardized 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 posture information correlation, and ensures that the enterprise's repositories always offer the freshest, most up-to-date view of the enterprise's endpoint posture information possible.
By exposing posture information using a standardized 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 interfaces, as any authorized infrastructure endpoint can interact with the posture information.
Owners and administrators must have complete control of posture information, policy, and endpoint mitigation. 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. Of course, there may be exceptions to this such as the case with privacy-related information (e.g., personally identifiable information).
The following sections describe the different use cases supported by the EPCP.
Using the API on the posture manager, an authorized user can learn:
The ability to answer these questions offers a standards-based approach to asset management, which is a vital part of enterprise processes such as compliance report generation for the Federal Information Security Modernization Act (FISMA), Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), etc.
The API on the posture manager provides the ability for authorized users and infrastructure to know which software is 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:
The API also provides the ability for authorized users or infrastructure to locate endpoints running software for which vulnerabilities have been announced. Because of
the repository can be queried to find all endpoints running a vulnerable application. Endpoints suspected of being vulnerable can be addressed by the administrator or flagged for further scrutiny.
The repository's standardized API allows authorized infrastructure endpoints and software to search endpoint posture assessment information for evidence that an endpoint's software inventory has changed, and can make endpoint software inventory data available to other endpoints. This automates security data sharing in a way that expedites the correlation of relevant network data, allowing administrators and infrastructure endpoints to identify odd endpoint behavior and configuration using secure, standardized data models and protocols.
Several use cases, including but not limited to these, are not covered by the EPCP:
The following subsections provide examples of the EPCP as implemented using components from the NEA architecture.
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID | |
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | |
| | IF-IMC | | | IF-IMV |
| | | | | |
| +-----------+ | | +-----------+ |
| | PB Client | | | | PB Server | |
| +-----------+ | | +-----------+ |
| | | | | |
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 4: Continuous Posture Assessment of an Endpoint
A new application is installed on the endpoint, and the SWID directory is updated. This triggers an update from the SWID posture collector to the SWID posture validator. The message is sent down the NEA stack, encapsulated by NEA protocols until it is sent by the posture transport client to the posture transport server. The 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.
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID | |
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | SWID Message | | |
| | IF-IMC | for PA-TNC | | IF-IMV |
| | | | | |
| +-----------+ | | +-----------+ |
| | PB Client | | | | PB Server | |
| +-----------+ | | +-----------+ |
| | | | | |
| | | PB-TNC {SWID | | |
| | | Message for | | |
| | | PA-TNC} | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<-------------->| | PT Server | |
| +-----------+ | PT-TLS {PB-TNC | +-----------+ |
| | {SWID Message | |
+---------------+ for PA-TNC}} +---------------+
Figure 5: Compliance Protocol Encapsulation
The SWID posture validator stores the new tag information in the repository. If the tag indicates that the endpoint is compliant with 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 event on the endpoint triggers a posture assessment).
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | | |
| | Collector | | | | Validator | | |
| +-----------+ | | +-----------+ | |
| | | | | | | Repository
| | IF-IMC | | | IF-IMV | | +--------+
| | | | | | | | |
| +-----------+ | | +-----------+ | | | |
| | PB Client | | | | PB Server | | +---->| |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 6: Storing SWIDs in the Repository
If the endpoint has fallen out of compliance with a policy, the posture manager can alert the administrator via the posture manager's API. 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 Posture Manager | / \
+---------------+ +---------------+ |
| | | | |
| +-----------+ | | +-----------+ | |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+
| | | | | | | |
| +-----------+ | | +-----------+ | | |
| | PB Client | | | | PB Server | | | |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 7: Server Alerts Network Admin
An announcement is made that a particular version of a piece of software has a vulnerability. The administrator uses the API on the posture manager 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 | +--------+
| | | | | | | |
| +-----------+ | | +-----------+ | | |
| | PB Client | | | | PB Server | |------>| |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 8: Admin Searches for Vulnerable Endpoints
The repository returns a list of entries 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.
Changed the title of the draft to draft-ietf-sacm-epcp.
Updated the diagram so the Endpoint and Posture Manager are the primary focus of EPCP.
Added a reference to CoSWID in the Software Asset Management extension of the IETF NEA EPCP implementation.
Further clarified the use of MAC addresses in EPCP.
Included a requirement in the Privacy Considerations that the enterprise should exercise due diligence with respect to the privacy of certain data given privacy regulations.
Added a requirement around an endpoint being provisioned with a machine certificate.
Clarified that other protocols and interfaces may be supported beyond IETF NEA and NETCONF.
Made various typographical and editorial changes.
Updated the diagram so the Evaluator and Repository are "current work".
Clarified how the Posture Collection Engine can push data, respond to queries, and establish secure transport connectivity for fulfilling subscriptions.
Expanded on the future work around leveraging NETCONF, RESTCONF, and YANG Push for network devices.
Documented the need to reassess MAC addresses as a device identifier.
Made various typographical and editorial changes.
Addressed various comments from the SACM WG.
Refactored the document to better focus it on the communications between endpoints and the posture manager and the best practices for EPCP implementations.
Made other editorial changes and improved consistency throughout the document.
Addressed various comments from the SACM WG.
Added a reference to TCG ECP 1.0.
Removed text in the "SWID Posture Validator" section that states it performs evaluation. This was removed because it contradicts the posture manager not performing any evaluations.
Expanded the "Provisioning" section of the "EPCP Transactions" section to include examples of endpoint identifiers and the need to provision endpoints with components and data models.
Combined text for the capabilities of the Administrative Interface and API.
Removed superfluous and introductory text from the "Security Considerations" section.
Renamed section "Vulnerability Searches" to Vulnerability Management".
Changed I-D category to BCP.
Changed references to the NETMOD architecture to the NETCONF architecture because NETCONF represents the management protocol whereas NETMOD is focused on the definition of data models.
Addressed various editorial suggestions.
Addressed various comments from the SACM WG.
Added a section for the collection of posture information from network devices using standards from the NETMOD WG.
Updated EPCP component diagrams so they were not specific to a NEA-based implementation.
Updated EPCP NEA example diagrams to reflect all the components in the NEA architecture.
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.
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.
Draft adopted by IETF SACM WG.
Significant edits to up-level the draft to describe SACM collection over multiple different protocols.
Replaced references to SANS with CIS.
Made other minor editorial changes.