draft-ietf-sacm-ecp-00.txt   draft-ietf-sacm-ecp-01.txt 
SACM D. Haynes SACM D. Haynes
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Standards Track J. Fitzgerald-McKay Intended status: Standards Track J. Fitzgerald-McKay
Expires: March 12, 2018 Department of Defense Expires: August 3, 2018 Department of Defense
L. Lorenzin L. Lorenzin
Pulse Secure Pulse Secure
September 8, 2017 January 30, 2018
Endpoint Compliance Profile Endpoint Compliance Profile
draft-ietf-sacm-ecp-00 draft-ietf-sacm-ecp-01
Abstract Abstract
This document specifies the Endpoint Compliance Profile, a high-level This document specifies the Endpoint Compliance Profile, a high-level
specification that describes a specific combination and application specification that describes a specific combination and application
of IETF and TNC protocols and interfaces specifically designed to of IETF and TNC protocols and interfaces specifically designed to
support ongoing assessment of endpoint posture and the controlled support ongoing assessment of endpoint posture and the controlled
exposure of collected posture information to appropriate security exposure of collected posture information to appropriate security
applications. This document is a subset of the Trusted Computing applications. This document is an extension of the Trusted Computing
Group's Endpoint Compliance Profile Version 1.0 specification. Group's Endpoint Compliance Profile Version 1.0 specification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2018. This Internet-Draft will expire on August 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Preventative Posture Assessments . . . . . . . . . . . . 4 1.1. Preventative Posture Assessments . . . . . . . . . . . . 4
1.2. Standardized Schema . . . . . . . . . . . . . . . . . . . 4 1.2. All Network-Connected Endpoints are Endpoints . . . . . . 5
1.3. Secure Standardized Protocols . . . . . . . . . . . . . . 5 1.3. All Endpoints on the Network Must be Uniquely Identified 5
1.4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Standardized Data Models . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Secure Standardized Protocols . . . . . . . . . . . . . . 6
3. Endpoint Compliance Profile . . . . . . . . . . . . . . . . . 6 1.6. Posture Information Must Be Stored . . . . . . . . . . . 6
3.1. Posture Assessments . . . . . . . . . . . . . . . . . . . 7 1.7. Posture Information Can Be Shared . . . . . . . . . . . . 7
3.2. Data Storage . . . . . . . . . . . . . . . . . . . . . . 7 1.8. Enterprise Asset Posture Information Belongs to the
3.3. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 7 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 7
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.9. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Purpose of the Endpoint Compliance Profile . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Connected and Compliant . . . . . . . . . . . . . . . 8 4. Endpoint Compliance Profile . . . . . . . . . . . . . . . . . 10
4.2.2. Exposing Data to the Network . . . . . . . . . . . . 9 4.1. Posture Assessments . . . . . . . . . . . . . . . . . . . 10
4.2.2.1. Asset Management . . . . . . . . . . . . . . . . 11 4.2. Data Storage . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2.2. Vulnerability Searches . . . . . . . . . . . . . 12 4.3. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2.3. Threat Detection and Analysis . . . . . . . . . . 12 5. ECP Components . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Non-supported Use Cases . . . . . . . . . . . . . . . 12 5.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4. Profile Requirements . . . . . . . . . . . . . . . . 13 5.1.1. Posture Collector . . . . . . . . . . . . . . . . . . 12
4.2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. Posture Collection Engine . . . . . . . . . . . . . . 13
5. Endpoint Compliance Requirements . . . . . . . . . . . . . . 16 5.2. Posture Manager . . . . . . . . . . . . . . . . . . . . . 13
5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . . . 16 5.2.1. Posture Validator . . . . . . . . . . . . . . . . . . 13
5.1.1. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2. Posture Collection Manager . . . . . . . . . . . . . 13
5.1.2. Endpoint Identity and Machine Certificate . . . . . . 17 5.3. Repository . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Posture Validators and Posture Collectors . . . . . . . . 17 5.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1. SWID Posture Collectors and Posture Validators . . . 18 5.5. Orchestrator . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1.1. The SWID Posture Collector . . . . . . . . . . . 18 6. ECP Transactions . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1.2. The SWID Posture Validator . . . . . . . . . . . 18 6.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 15
5.3. NEA Client (NEAC) and NEA Server (NEAS) . . . . . . . . . 19 6.2. Discovery and Validation . . . . . . . . . . . . . . . . 15
5.3.1. NEAC . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Event Driven Collection . . . . . . . . . . . . . . . . . 15
5.3.2. NEAS . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Querying . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 19 6.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . 15
6. Posture Transport Client (PTC) and Posture Transport Server 6.6. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 16
(PTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. ECP Implementations . . . . . . . . . . . . . . . . . . . . . 17
7. Administrative Interface and API . . . . . . . . . . . . . . 20 7.1. IETF NEA ECP Implementation . . . . . . . . . . . . . . . 17
8. Endpoint Compliance Profile Examples . . . . . . . . . . . . 21 7.1.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 17
8.1. Continuous Posture Assessment of an Endpoint . . . . . . 21 7.1.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 18
8.1.1. Change on Endpoint Triggers Posture Assessment . . . 21 7.1.2.1. Posture Collector . . . . . . . . . . . . . . . . 18
8.2. Administrator Searches for Vulnerable Endpoints . . . . . 24 7.1.2.2. Posture Collection Engine . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7.1.3. Posture Manager . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7.1.3.1. Posture Validator . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7.1.3.2. Posture Collection Manager . . . . . . . . . . . 19
11.1. Security Benefits of Endpoint Compliance Profile . . . . 27 7.1.4. Repository . . . . . . . . . . . . . . . . . . . . . 19
11.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 29 7.1.5. Administrative Interface and API . . . . . . . . . . 20
11.2.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 30 7.1.6. IETF SACM SWAM Extension to the IETF NEA ECP
11.2.2. Network Attacks . . . . . . . . . . . . . . . . . . 30 Implementation . . . . . . . . . . . . . . . . . . . 20
11.2.3. Server Attacks . . . . . . . . . . . . . . . . . . . 30 7.1.6.1. Endpoint Pre-Provisioning . . . . . . . . . . . . 20
11.2.4. Repository Attacks . . . . . . . . . . . . . . . . . 31 7.1.6.2. SWID Tags . . . . . . . . . . . . . . . . . . . . 20
11.3. Countermeasures . . . . . . . . . . . . . . . . . . . . 31 7.1.6.3. SWID Posture Collectors and Posture Validators . 21
11.3.1. Countermeasures for Endpoint Attacks . . . . . . . . 31 7.1.6.4. Repository . . . . . . . . . . . . . . . . . . . 22
11.3.2. Countermeasures for Network Attacks . . . . . . . . 32 7.2. IETF NETMOD ECP Implementation . . . . . . . . . . . . . 22
11.3.3. Countermeasures for Server Attacks . . . . . . . . . 32 8. ECP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 22
11.3.4. Countermeasures for Repository Attacks . . . . . . . 33 8.1. Hardware Asset Management . . . . . . . . . . . . . . . . 22
12. Privacy-Considerations . . . . . . . . . . . . . . . . . . . 34 8.2. Software Asset Management . . . . . . . . . . . . . . . . 23
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.3. Vulnerability Searches . . . . . . . . . . . . . . . . . 23
13.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 34 8.4. Threat Detection and Analysis . . . . . . . . . . . . . . 23
13.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 34 9. Non-supported Use Cases . . . . . . . . . . . . . . . . . . . 24
13.3. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 34 10. Endpoint Compliance Profile Examples . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Continuous Posture Assessment of an Endpoint . . . . . . 24
14.1. Informative References . . . . . . . . . . . . . . . . . 35 10.1.1. Change on Endpoint Triggers Posture Assessment . . . 25
14.2. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Administrator Searches for Vulnerable Endpoints . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 11. Profile Requirements . . . . . . . . . . . . . . . . . . . . 28
12. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 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 1. Introduction
The Endpoint Compliance Profile (ECP) builds on prior work from the The Endpoint Compliance Profile (ECP) builds on prior work from the
IETF NEA WG, the Netmod WG, and the Trusted Network Communications IETF NEA WG, the IETF NETMOD WG, and the Trusted Computing Group
(TNC) WG of the Trusted Computing Group [TNC], to standardize the [TNC]Trusted Network Communications (TNC) WG to standardize the
collection, storage and sharing of posture information from network- collection, storage and sharing of posture information from network-
connected endpointgs, including user endpoints, servers, and connected endpoints, including user endpoints, servers, and
infrastructure. The first generation of this specification focuses infrastructure. The first generation of this specification focuses
on reducing the security exposure of a network by enabling event- on reducing the security exposure of a network by enabling event-
driven posture collection, as well as standardized querying for driven posture collection, as well as standardized querying for
additional endpoint data as needed. Standadrid collection improves additional endpoint data as needed. Standardized collection improves
network security by confirming that endpoints are known and network security by confirming that endpoints are known and
authrosized, and are compliant with network policy. authorized, and are compliant with network policy.
When ECP is used, posture information is gathered by collectors When ECP is used, posture collectors running on the target endpoint
running on the endpoint and is forwarded to a posture server, which gather posture information as changes occur on the endpoint, and
stores it in a repository. This information is gathered while the forward this information to a posture manager, which stores it in a
endpoint is already connected to the network. Administrators will repository. This information is gathered while the target endpoint
query the repository to determine the posture status of an endpoint. is already connected to the network. Administrators will query the
For example, if a vulnerability is discovered in a product, an repository to determine the posture status of an endpoint.
administrator may query the repository to determine which endpoints
have the vulnerable software installed and thus require some follow-
up action.
The ECP then describes how to expose information--such as endpoint Building and maintaining a continuously updated repository of
information using the ECP enables network owners and administrators
to perform the asset, vulnerability, and configuration management
tasks that are the basis for robust network security.
The ECP also describes how to expose information--such as endpoint
purpose, the software that is supposed to be running on an endpoint, purpose, the software that is supposed to be running on an endpoint,
and the activities an endpoint is supposed to be performing--to and the activities an endpoint is supposed to be performing--to
sensors that are looking for indicators of attacks and malicious sensors that are looking for indicators of attacks and malicious
activity on the network. 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 1.1. Preventative Posture Assessments
The value of continuous endpoint posture assessment is well The value of continuous endpoint posture assessment is well
established. Security experts have for years identified software established. Security experts have for years identified asset
updating and patching as a critical step for preventing intrusions. management and vulnerability remediation as a critical step for
Application white listing, patching applications and operating preventing intrusions. Application whitelisting, patching
systems, and using the latest versions of applications top the applications and operating systems, and using the latest versions of
Defense Signals Directorate's "Top 4 Mitigations to Protect Your ICT applications top the Defense Signals Directorate's "Top 4 Mitigations
System". [DSD] "Inventory of Authorized and Unauthorized Endpoints", to Protect Your ICT System". [DSD] "Inventory of Authorized and
"Inventory of Authorized and Unauthorized Software", and "Continuous Unauthorized Endpoints", "Inventory of Authorized and Unauthorized
Vulnerability Assessment and Remediation" are Critical Controls 1, 2, Software", and "Continuous Vulnerability Assessment and Remediation"
and 4, respectively, of the CIS "20 Critical Security Controls". are Critical Controls 1, 2, and 4, respectively, of the CIS "20
[CIS] While there are commercially available solutions that attempt Critical Security Controls". [CIS] While there are commercially
to address these security controls, these solutions do not run on all available solutions that attempt to address these security controls,
types of endpoints; consistently interoperate with other tools that these solutions do not run on all types of endpoints; consistently
could make use of the data collected; collect posture information interoperate with other tools that could make use of the data
from all types of endpoints in a consistent, standardized schema; or collected; collect posture information from all types of endpoints in
require vetted, standardized protocols that have been evaluated by a consistent, standardized schema; or require vetted, standardized
the international community for cryptographic soundness. 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 As is true of most solutions offered today, the solution found in the
ECP does not attempt to solve the lying endpoint problem. An ECP does not attempt to solve the lying endpoint problem. An
endpoint that has already been infected with malicious software can endpoint that has already been infected with malicious software can
provide false information about its identity and the software it is provide false information about its identity and the software it is
running. The primary purpose of the ECP is not to detect infected running. The primary purpose of the ECP is not to detect infected
endpoints; rather, it focuses on ensuring that healthy endpoints endpoints; rather, it focuses on ensuring that healthy endpoints
remain healthy by keeping software up-to-date and patched. The first 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 goal of the ECP is to help an administrator easily determine which
determine which endpoints require some follow-up action. By sharing endpoints require some follow-up action. By sharing posture
posture informatino with sensors on the network, ECP aids in the information with sensors on the network, ECP aids in the detection of
detection of attacks on endpoints and drives follow-up actions. attacks on endpoints and drives follow-up actions.
1.2. Standardized Schema 1.2. All Network-Connected Endpoints are Endpoints
The ECP requires the use of standardized schema for the exchange of As defined by [I-D.ietf-sacm-terminology], an endpoint is any
posture information. This helps to ensure that the posture 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 helps to swiftly identify malicious changes to
endpoint applications.
1.4. Standardized Data Models
The ECP 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 information sent from endpoints to the repository can be easily
stored, due to their known format, and shared with authorized stored, due to their known format, and shared with authorized
endpoints and users. Standardized schema also enable collection from endpoints and users. Standardized data models also enable collection
myriad types of endpoints. Such standardization saves implementers from myriad types of endpoints. Such standardization saves vendors
time and money--time that does not have to be spent integrating new time and money--time that does not have to be spent integrating new
schema into the enterprise's reporting mechanisms, and money that data models into the enterprise's reporting mechanisms, and money
does not have to be spent on developing tools to parse information that does not have to be spent on developing tools to parse
from each type of endpoint connected to the network. Standardized information from each type of endpoint connected to the network.
schema also enable the development of standardized client software. Standardized data models also enable the development of standardized
This allows endpoint vendors to include their own client software client software. This allows endpoint vendors to include their own
that can interoperate with posture assessment infrastructure and thus client software that can interoperate with posture assessment
not have to introduce third party code in their products. infrastructure and thus not have to introduce third party code in
their products.
1.3. Secure Standardized Protocols 1.5. Secure Standardized Protocols
Posture information must be sent over mature, standardized protocols Posture information must be sent over mature, standardized protocols
to ensure the confidentiality and authenticity of this data while in to ensure the confidentiality and authenticity of this data while in
transit. Conformant implementations of the ECP include [RFC6876] for transit. Conformant implementations of the ECP include [RFC6876] and
communication between the endpoint and the server. This protocol [I-D.ietf-netconf-yang-push] for communication between the target
allows networks that implement this solution to collect large amounts endpoint and the posture manager. These protocols allow networks
of posture information from an endpoint in order to make decisions that implement this solution to collect large amounts of posture
about that endpoint's compliance to some policy. This Profile offers information from an endpoint to make decisions about that endpoint's
a solution for all endpoints already connected to the network. compliance with some policy. The ECP offers a solution for all
Periodic assessments and automated reporting of changes to endpoint endpoints already connected to the network. Periodic assessments and
posture allow for instantaneous identification of connected endpoints automated reporting of changes to endpoint posture allow for
that are no longer compliant to some policy. instantaneous identification of connected endpoints that are no
longer compliant to some policy.
The IETF NEA WG has designed an architecture to support endpoint 1.6. Posture Information Must Be Stored
posture assessment. Figure 1 illustrates the architectural
components used in the Endpoint Compliance Profile:
Endpoint Server 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 target endpoint and store it
| | Posture | | | | Posture | | indexed by the unique identifier for the endpoint. Any posture
| | Collector | | | | Validator | | 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
| | | | | | Repository 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
| | Posture | | | | Posture | | | | information stored by the repository. In the future, some forms of
| | Client | | | | Server | |---->| | 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
| | Comms | | | | Comms | | identification, secure storage itself enables endpoint posture
| | Client | |<------>| | Server | | 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.
+---------------+ +---------------+
Figure 1: The Endpoint Compliance Architecture 1.7. Posture Information Can Be Shared
1.4. Keywords By exposing posture information using a standard interface and API,
other security and operational components have a high level of
insight into the enterprise's endpoints and the software installed on
them. This will support innovation in the areas of asset management,
vulnerability scanning, and administrative interfaces, as any
authorized infrastructure endpoint can interact with the posture
information.
1.8. Enterprise Asset Posture 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. This document are to be interpreted as described in [RFC2119]. This
specification does not distinguish blocks of informative comments and specification does not distinguish blocks of informative comments and
normative requirements. Therefore, for the sake of clarity, note normative requirements. Therefore, for the sake of clarity, note
that lower case instances of must, should, etc. do not indicate that lower case instances of must, should, etc. do not indicate
normative requirements. normative requirements.
2. Terminology 2. Terminology
This document uses terms as defined in [I-D.ietf-sacm-terminology] This document uses terms as defined in [I-D.ietf-sacm-terminology]
unless otherwise specified. unless otherwise specified.
3. Endpoint Compliance Profile 3. Assumptions
The Endpoint Compliance Profile describes how IETF and TNC data Here are the assumptions that the Endpoint Compliance Profile makes
models and protocols can be used to support the posture assessment of about other components in the SACM architecture.
endpoints on a network. This profile does not generate new schema or
o Existence of a posture manager and repository: The Endpoint
Compliance Profile assumes that a posture manager and repository
exist.
o Endpoint posture information availability: The Endpoint Compliance
Profile assumes that an endpoint has posture information in
standardized data model that can be communicated to the posture
manager.
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, 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 are connected
at any given time. By requiring a standardized method of endpoint
identity, the Endpoint Compliance Profile will enable
administrators to answer the basic question, "What is on my
network?" Unique endpoint identification also enables the
comparison of current and past endpoint posture assessments, by
allowing administrators to correlate assessments from the same
endpoint. This makes it easier to flag suspicious changes in
endpoint posture for manual or automatic review, and helps to
swiftly identify malicious changes to endpoint applications.
o Posture assessments must occur over secure, standardized
protocols: Endpoint identity and application information is very
valuable, both to administrators and to attackers. Therefore, it
must be kept confidential, using secure protocols to transport it
from the endpoint to the posture manager. Additionally, it is
critical that only authorized parties be capable of requesting
information, receiving information, or taking action to change an
endpoint's connectivity status. Relying on standardized protocols
to provide this security enables greater interoperability and
compatibility between endpoints, and allows for the development of
compliance testing to ensure that each endpoint operates securely
and in conformance with appropriate specifications. A standards
body provides a process for experts in protocols and cryptography
to evaluate the soundness of protocols and security management
procedures; a set of security standards allows an enterprise to
make the most effective use of their investment in a security
management infrastructure.
o Posture 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 Compliance
Profile enables information sharing between user endpoints and
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
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 posture manager must
accommodate the ability to make a 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 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.
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 can interact with the posture information.
o Owners and administrators must have complete control of posture
information, policy, and endpoint mitigation: Enterprise asset
posture information belongs to the enterprise. 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.
4. Endpoint Compliance Profile
The Endpoint Compliance Profile describes how IETF data models and
protocols can be used to support the posture assessment 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 protocols; rather, it offers a full end-to-end solution for posture
assessment, as well as a fresh perspective on how existing standards assessment, as well as a fresh perspective on how existing standards
can be leveraged against vulnerabilities. can be leveraged against vulnerabilities.
3.1. Posture Assessments 4.1. Posture Assessments
The Endpoint Compliance Profile 1.0 describes how IETF and TNC data The Endpoint Compliance Profile 1.0 describes how IETF and TNC data
modles and protocols make it possible to perform posture assessments models and protocols make it possible to perform posture assessments
against all network-connected endpoints by: against all network-connected endpoints by:
1. uniquely identifying the endpoint; 1. uniquely identifying the endpoint;
2. collecting and assessing posture based on data from the endpoint; 2. collecting and assessing posture based on data from the endpoint;
3. creating a secure, authenticated, confidential channel between 3. creating a secure, authenticated, confidential channel between
the endpoint and the server; the endpoint and the posture manager;
4. enabling the endpoint to notify the server about changes to its 4. enabling the endpoint to notify the posture manager about changes
configuration; to its configuration;
5. enabling the posture server to request information about the 5. enabling the posture manager to request information about the
configuration of the endpoint; and configuration of the endpoint; and
6. storing the posture information in a repository linked to the 6. storing the posture information in a repository linked to the
identifier for the endpoint. identifier for the endpoint.
3.2. Data Storage 4.2. Data Storage
The Endpoint Compliance Profile 1.0 focuses on being able to collect The Endpoint Compliance Profile 1.0 focuses on being able to collect
posture information from an endpoint and store it in a repository. posture information from an endpoint and store it in a repository.
This makes posture information from a network's endpoints available This makes posture information from a network's endpoints available
to authorized parties. Uses of this data are innumerable-- to authorized parties. Uses of this data are innumerable -
vulnerability management, asset management, software asset vulnerability management, asset management, software asset
management, and configuration management solutions, analytics tools, management, and configuration management solutions, analytics tools,
endpoints that need to make connectivity decisions, and metrics endpoints that need to make connectivity decisions, and metrics
reporting scripts, among others, are all able to reference the data reporting scripts, among others, are all able to reference the data
stored in the repository to achieve their purposes. stored in the repository to achieve their purposes. Currently, the
Endpoint Compliance Profile 1.0 does not specify a protocol or
interfaces to access stored posture information. 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 free to implement a repository and the protocols and
interfaces used to interact with it in a way that makes the most
sense for them.
3.3. Data Sharing 4.3. Data Sharing
TBD 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 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 IETF MILE WG may be a potential candidate for
sharing information between components.
4. Background 5. ECP Components
4.1. Purpose of the Endpoint Compliance Profile To perform posture assessment, data storage, and data sharing, ECP
defines a number of components. Some of these components reside on
the target endpoint. Others reside on a posture manager that manages
communications with the target endpoint and stores the target
endpoint's posture information in a repository.
The Endpoint Compliance Profile describes a standard way to collect Posture Manager Endpoint
endpoint posture information s and to make it available to other Orchestrator +---------------+ +---------------+
authorized parties. +--------+ | | | |
| | | +-----------+ | | +-----------+ |
| |<---->| | Posture | | | | Posture | |
| | pub/ | | Validator | | | | Collector | |
| | sub | +-----------+ | | +-----------+ |
+--------+ | | | | | |
| | | | | |
Evaluator Repository | | | | | |
+------+ +--------+ | +-----------+ |<-------| +-----------+ |
| | | | | | Posture | | report | | Posture | |
| | | | | | Collection| | | | Collection| |
| |<-----> | |<---->| | Manager | | query | | Engine | |
| |request/| | store| +-----------+ |------->| +-----------+ |
| |respond | | | | | |
| | | | | | | |
+------+ +--------+ +---------------+ +---------------+
4.2. Supported Use Cases Figure 1: ECP Components
The Endpoint Compliance Profile focuses on the posture assessment of 5.1. Endpoint
enterprise endpoints on enterprise networks. Use cases supported by
the Endpoint Compliance Profile 1.0 are as follows:
4.2.1. Connected and Compliant An endpoint is defined in [RFC6876]. In the Endpoint Compliance
Profile, the endpoint is monitored by the enterprise and is the
target of posture assessments. To support these posture assessments,
posture information is collected via posture collectors.
A network-connected endpoint sends posture information using standard 5.1.1. Posture Collector
schemas an protocols.
Endpoint Server A posture collector is responsible for monitoring and gathering
+-------------------+ +---------------+ posture information from the target endpoint. This component reports
| | | | changes to posture information as they occur. This event-driven
| +---------+ | | | collection provides network administrators up-to-date insight into
| | Endpoint| | | | the state of the network as the network state changes, which enables
| | Posture | | | +-----------+ | continuous monitoring of the network. Posture collectors can also be
| | Data | | | | | | queried supporting ad-hoc collection, addressed below as "querying"
| +---------+ | | | Validator | | which can be used to refresh information about the target endpoint,
| | | | | | | or to ask a specific question about posture information.
| | | | +-----------+ | Furthermore, a posture collector may process posture information
| | +-----------+ | | | | before it is communicated to the posture manager. An endpoint may
| +->| | | | | | have one or more posture collectors depending on the type of endpoint
| | Collector | | | | | and what posture information is being monitored and collected.
| | | | | | |
| +-----------+ | | | |
| | | | | |
| | | | | | Repository
| | | | | | +--------+
| +-----------+ | | +-----------+ | | |
| | Posture | | | | Posture | | |
| | Client | | | | Server | |---->| |
| +-----------+ | | +-----------+ | | |
| | | | | | | |
| +----------+ | | | | | +--------+
| | Endpoint | | | | | |
| | ID | | | | | |
| +----------+ | | | | |
| | | | | | |
| | +-----------+ | | +-----------+ |
| +->| Comms | | | | Comms | |
| | Client | |<------>| | Server | |
| +-----------+ | | +-----------+ |
| | | |
+-------------------+ +---------------+
Figure 2: Connected and Compliant Use Case 5.1.2. Posture Collection Engine
1. If necessary, the endpoint finds and validates the server in The posture collection engine is located on the target endpoint. It
compliance with [Server-Discovery]. receives queries from a posture collection manager and directs them
to the 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 distributed to
the appropriate posture validator 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.
2. The Posture Transport Client (PTC) on the endpoint and Posture 5.2. Posture Manager
Transport Server (PTS) on the server complete a TLS handshake,
during which endpoint identity information is exchanged.
3. Either the NEA Server (NEAS) on the server or the NEA Client The posture manager is an endpoint that collects, validates, and
(NEAC) on the endpoint initiates a posture assessment. Checks enriches posture information received about a target endpoint. It
may be triggered for multiple reasons, including: also stores the posture information it receives in the repository.
The posture manager does not evaluate the posture information.
(a) policy states that a previous assessment has aged out and 5.2.1. Posture Validator
become invalid;
(b) the NEAC notices that the relevant posture information on A posture validator receives data from a posture collector, performs
the endpoint has changed, (for example, due to application basic sanity checking, and stores that data in the repository. It
updates, deletions or additions); or can also send queries to a posture collector. There is a posture
validator for every posture collector.
(c) the NEAS is alerted by a sensor or an administrator (via the 5.2.2. Posture Collection Manager
server's user interface) that an assessment must be
completed.
All information exchanges between the PCs and PVs are subject to A posture collection manager is a lightweight and extensible
the enterprise's policy, which may limit the content or size of component that facilitates the coordination and execution of posture
information sent between the endpoint and the server. 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.
4. The SWID Posture Collector on the endpoint collects from the SWID The posture collection manager also contains a capability that sets
tag directory on the endpoint. This data is sent via the NEAC up exchanges between the target endpoint and the posture manager, and
and PTC to the server. manages data sent to and from posture validators. It is also
responsible for performing the server-side portion of encryption
handshakes. It is also responsible for performing the server-side
portion of encryption handshakes.
5. Once the posture information is received by the PTS, it is 5.3. Repository
forwarded to the SWID Posture Validator via the NEAS. The SWID
Posture Validator also forwards the posture information to the
repository. The posture information is stored along with past
posture information collected about the endpoint.
4.2.2. Exposing Data to the Network 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 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.
Because the endpoint posture information was sent in a standards- Currently, the Endpoint Compliance Profile does not provide a
based schema (ISO/IEC 19770-2:2009) over secure, standardized standardized interface or API for accessing the information contained
protocols, and the SWID tags are stored in a centralized repository within the repository. A future revision of the Endpoint Compliance
linked to unique endpoint identifiers, authorized parties are able to Profile may specify a standardized interface and API for components
access the posture information. Such authorized parties may include, to interact with the repository.
but are not limited to, administrators or endpoint owners (via the
server's administrative interface), and other pieces of
infrastructure that can make use of this data (via the server's API).
The server will provide:
o a standard administrative interface that allows data sharing with 5.4. Evaluator
authorized parties;
o a standard API that allows data sharing with authorized The evaluator assesses the posture status of a target endpoint by
infrastructure and software; 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 engine, 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
follow-up actions, further evaluation, and historical purposes.
o a persistent account of endpoints that have connected to the 5.5. Orchestrator
network over a period of time set by the administrator;
o the identities provided by those endpoints; and 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.
o what SWIDs were reported by the endpoint. The Endpoint Compliance Profile 1.0 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 may specify such an interface.
The endpoint will publish updates as its local SWID directory 6. ECP Transactions
changes, as well as each time it disconnects and reconnects to the
network.
Endpoint Server 6.1. Provisioning
+--------------------+ +---------------+
| | | |
| +-------+ | | +-----------+ |
| | SWIDs | | | | SWID | |
| +-------+ | | | Posture | |
| | | | | Validator | |
| | | | +-----------+ |
| | +-----------+ | | | |
| +->| SWID | | | | |
| | Posture | | | | |
| | Collector | | | | |
| +-----------+ | | | |
| | | | | |
| | IF-IMC | | | IF-IMV | Repository
| | | | | | +--------+
| +-----------+ | | +-----------+ | | |
| | PB Client | | | | PB Server | |---->| |
| +-----------+ | | +-----------+ | | |
| | | | | | | |
| +----------+ | | | | | +--------+
| | Endpoint | | | | | |
| | ID | | | | | |
| +----------+ | | | | |
| | | | | | |
| | +-----------+ | | +-----------+ |
| +->| PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+--------------------+ +---------------+
+----------------------------------+
| Administrative Interface and API |
+----------------------------------+
Figure 3: Exposing Data to the Network 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 interact with the 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 posture validator. This
can occur because:
1. policy states that a previous assessment has aged out or become
invalid, or
2. the posture validator is alerted by a sensor or an administrator
(via the posture manager's user interface) that an assessment
must be completed
6.5. Data Storage
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 there could be direct or brokered
communication between the posture manager and the repository. The
posture information is stored in the repository along with past
posture information collected about the target endpoint.
6.6. Data Sharing
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 server's
administrative interface), evaluators that access the repository
directly, and orchestrators that rely on publish/subscribe
communications with the repository.
Posture Manager Endpoint
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 Network
It should be noted that the neither the Endpoint Compliance Profile It should be noted that the neither the Endpoint Compliance Profile
nor the protocols, interfaces, and data models that it references nor the protocols, interfaces, and data models that it references
provide solutions to the server capabilities listed above. However, provide solutions to the repository, evaluator, and orchestrator
these capabilities are useful and solutions for them should be components and capabilities listed above. However, these
pursued in the future. capabilities are useful and solutions for them should be pursued in
the future.
4.2.2.1. Asset Management 7. ECP Implementations
Using the administrative interface on the server, an authorized user The following sections describe implementations of the Endpoint
can learn: Compliance Profile leveraging the IETF NEA and IETF NETMOD
architectures.
o what endpoints are connected to the network at any given time; and 7.1. IETF NEA ECP Implementation
o what SWID tags were reported for the endpoints.
The ability to answer these questions offers a standards-based These requirements are written with a view to performing a posture
approach to asset management, which is a vital part of enterprise assessment on an endpoint; as the Endpoint Compliance Profile grows
processes such as compliance report generation for the Federal and evolves, these requirements will be expanded to address issues
Information Security Modernization Act (FISMA), Payment Card Industry that arise. Note that these requirements refer to defined components
Data Security Standard (PCI DSS), Health Insurance Portability and of the NEA architecture. As with the NEA architecture, vendors have
Accountability Act (HIPAA), etc. discretion as to how these NEA components map to separate pieces of
software or endpoints.
4.2.2.2. Vulnerability Searches 7.1.1. Endpoint Pre-Provisioning
The administrative interface also provides the ability for authorized An endpoint is provisioned with a machine certificate that will serve
users or infrastructure to locate endpoints running software for as its unique identifier on the network as well as the components
which vulnerabilities have been announced. Because of 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.
1. the unique IDs assigned to each endpoint; and 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].
2. the rich application data provided in the endpoints' posture In the future, the identity could be a hardware certificate compliant
information, with [IEEE-802-1ar]; ideally, 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 stand up 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
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.
the repository can be queried to find all endpoints running a 7.1.2. Endpoint
vulnerable application. Endpoints suspected of being vulnerable can
be addressed by the administrator or flagged for further scrutiny.
4.2.2.3. Threat Detection and Analysis The endpoint MUST conform to [RFC5793], which levies a number of
requirements against the endpoint. An endpoint that complies with
these requirements will be able to:
The repository's standardized API allows authorized infrastructure 1. attempt to initiate a session with the posture manager if the
endpoints and software to search endpoint posture assessment posture makes a request to send an update to posture manager;
information for evidence that an endpoint's software inventory has
changed, and can make endpoint software inventory data available to
other endpoints. This automates security data sharing in a way that
expedites the correlation of relevant network data, allowing
administrators and infrastructure endpoints to identify odd endpoint
behavior and configuration using secure, standards-based schema and
protocols.
4.2.3. Non-supported Use Cases 2. notify the posture collector if no PT-TLS session with the
posture manager can be created;
Several use cases, including but not limited to these, are not 3. notify the posture collector when a PT-TLS session is
covered by the Endpoint Compliance Profile 1.0: established; and
o Gathering other types of posture information: The Endpoint 4. receive information from the posture collectors, forward this
Compliance Profile does not prevent administrators from collecting information to the server via the posture collection engine.
other types of posture information other than SWIDs from the
endpoint; however it does not set requirements for doing so.
o Solving the lying endpoint problem: The Endpoint Compliance 7.1.2.1. Posture Collector
Profile does not address the lying endpoint problem; the Profile
makes no assertions that it can catch an endpoint that is, either
maliciously or accidentally, reporting false posture information
to the server. However, other solutions may be able to use the
posture information collected using the capabilities described in
this profile to catch an endpoint in a lie. For example, a sensor
may be able to compare the posture information it has collected on
an endpoint's activity on the network to what the endpoint
reported to the server and flag discrepancies. However, these
particular capabilities are not described in this profile.
o Publish/subscribe repository interface: Future versions of the Any posture collector used in an Endpoint Compliance Profile solution
Endpoint Compliance Profile may specify a publish/subscribe MUST be conformant with [IF-IMC]; an Internet-Draft, under
interface for the repository, so infrastructure endpoint can development, that is a subset of the TCG TNC Integrity Measurement
subscribe to and receive published posture assessment results from Collector interface [IF-IMC] and will be submitted in the near
the repository regarding endpoint configuration changes. However, future.
the Endpoint Compliance Profile 1.0 includes no such requirements.
4.2.4. Profile Requirements 7.1.2.2. Posture Collection Engine
Here are the requirements that the Endpoint Compliance Profile In the original IETF NEA ECP implementation, the endpoint contained
protocol must meet in order to successfully fit in the SACM posture collector(s), a posture broker client, and posture transport
architecture. client(s). However, in this draft, the functionality of the posture
broker client and posture transport client(s) have been combined into
what is now called the posture collection engine. This was done
because there is currently no standard interface to handle the
communication between the posture broker client and posture transport
client(s) meaning vendors will need to define proprietary interfaces
that will not be interoperable.
o Meets the needs of the SACM architecture: The Endpoint Compliance The endpoint MUST conform to [IF-IMC] to enable communications
Profile must support the use cases described in [RFC7632] as they between the posture collection engine and the posture collectors on
apply to endpoint self-reporting and endpoint posture assessment. the endpoint.
o Efficient: To minimize user frustration, it is essential to The posture collection engine MUST implement PT-TLS.
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 The posture collection engine MUST support the use of machine
time as new features are added to the SACM architecture. The certificates for TLS at each endpoint consistent with the
solution must allow new features to be added easily, providing for requirements stipulated in [RFC6876] and [Server-Discovery].
a smooth transition and allowing newer and older architectural
components to continue to work together. Further, the Endpoint
Compliance Profile and the specifications referenced here must
define safe extensibility mechanisms that enable innovation
without breaking interoperability.
o Easy to implement: The Endpoint Compliance Profile should be easy The posture collection engine MUST be able to locate an authorized
for vendors to implement in their products, and should result in posture manager, and switch to a new posture manager when required by
products that are easy for administrators to implement on their the network, in conformance with [Server-Discovery].
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 7.1.3. Posture Manager
simple, integrated user interface that administrators can use to
perform the activities listed in the profile's use cases. The
Endpoint Compliance Profile should not constrain innovation by
specifying details of the user interface but rather functional
requirements.
o Platform-independent: Since network environments may contain many The posture manager MUST conform to all requirements in the
different types of endpoints, the solution should operate [RFC5793].
independently of the endpoint platform.
o Scalable: The Endpoint Compliance Profile must be designed to 7.1.3.1. Posture Validator
scale to very large numbers of endpoints.
4.2.5. Assumptions Any posture validator used in an Endpoint Compliance Profile solution
MUST be conformant with [IF-IMV]; an Internet-Draft, under
development, that is a subset of the TCG TNC Integrity Measurement
Verifier interface [IF-IMV] and will be submitted in the near future.
Here are the assumptions that the Endpoint Compliance Profile makes 7.1.3.2. Posture Collection Manager
about other components in the SACM architecture.
o Existence of a server and repository: The Endpoint Compliance In the original IETF NEA ECP implementation, the posture manager
Profile assumes that a server and repository exist. contained posture validators(s), a posture broker server, and posture
transport servers(s). Similar to the approach take on the endpoint,
in this draft, the functionality of the posture broker server and
posture transport servers(s) have been combined into what is now
called the posture collection manager. This was done because there
is currently no standard interface to handle the communication
between the posture broker server and posture transport servers(s)
meaning vendors will need to define proprietary interfaces that will
not be interoperable.
o Endpoint SWID installation: The Endpoint Compliance Profile The posture manager MUST conform to [IF-IMV]. Conformance to
assumes that an endpoint has been pre-provisioned with Software [IF-IMV] enables the posture manager to obtain endpoint identity
Identification Tags for its applications, and that these SWID tags information from the posture collection manager, and pass this
are formatted and stored in conformance with [SWID]. information to any posture validators on the posture manager.
o Certificate provisioning: In order to implement the most secure The posture collection manager MUST implement PT-TLS.
endpoint identification option, the Endpoint Compliance Profile
assumes that the enterprise has set up a certificate root
authority, and has provisioned each endpoint with an endpoint
identification certificate. This is not required if an enterprise
chooses to use other endpoint authentication methods.
In addition, the Endpoint Compliance Profile makes the following The posture collection manager MUST support the use of machine
assumptions about the SACM ecosystem: certificates for TLS at each endpoint consistent with the
requirements stipulated in [RFC6876] and [Server-Discovery].
o All network-connected endpoints are endpoints: As defined by 7.1.4. Repository
[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 ECP 1.0 requires a simple administrative interface for the
administrators struggle to identify what endpoints are connected repository. Posture validators on the posture manager receive the
at any given time. By requiring a standardized method of endpoint target endpoint posture information via PA-TNC [RFC5792] messages
identity, the Endpoint Compliance Profile will enable sent from corresponding posture collectors on the target endpoint and
administrators to answer the basic question, "What is on my store this information in the repository linked to the identity of
network?" Unique endpoint identification also enables the the target endpoint where the posture collectors are located.
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.
o Posture assessments must occur over secure, standardized 7.1.5. Administrative Interface and API
protocols: Endpoint identity and application information is very
valuable, both to administrators and to attackers. Therefore, it
must be kept confidential, using secure protocols to transport it
from the endpoint to network infrastructure endpoints.
Additionally, it is critical that only authorized parties be
capable of requesting information, receiving information, or
taking action to change an endpoint's connectivity status.
Relying on standardized protocols to provide this security enables
greater interoperability and compatibility between endpoints, and
allows for the development of compliance testing to ensure that
each endpoint operates securely and in conformance with
appropriate specifications. A standards body provides a process
for experts in protocols and cryptography to evaluate the
soundness of protocols and security management procedures; a set
of security standards allows an enterprise to make the most
effective use of their investment in a security management
infrastructure.
o Posture assessment results must be formatted using standardized An interface is necessary to allow administrators to manage the
schema: Well-known, standard schema allow for a universal language endpoints and software used in the Endpoint Compliance Profile. This
for generating compliance reports. With each endpoint speaking interface SHOULD be accessible either on or through (as in the case
the same language, the Endpoint Compliance Profile enables of a remotely hosted interface) the posture manager. Using this
information sharing between user endpoints and infrastructure interface, an authorized user or administrator SHOULD be able to:
endpoints, and between infrastructure endpoints that perform
different security tasks.
o Posture information must be stored by the repository and must be o Query the repository
exposed to an interface at the server: A standard schema enables
standard queries from an interface exposed to an administrator at
the server console. A repository must retain any current posture
information retrieved from the endpoint and store it indexed by
the unique identifier for the endpoint. Any PV specified by this
profile must be able to ascertain from its corresponding PC
whether the posture information is up to date. An interface on
the server must support a request to the PV to obtain up-to-date
information when an endpoint is connected. This interface must
also support the ability to make a standard set of queries about
the posture information stored by the repository. In the future,
some forms of posture information might be retained at the
endpoint. The interface on the server must accommodate the
ability to make a request through the PV to the corresponding PC
about the posture of the endpoint. Standard schema and protocols
also enable the security of posture assessment results. By
storing these results indexed under the endpoint's unique
identification, secure storage itself enables endpoint posture
information correlation, and ensures that the enterprise's
Repositories always offer the freshest, most up-to-date view of
the enterprise's endpoint posture information possible.
o Posture information can be shared: By exposing posture information o Send commands to the posture validators, requesting information
using a standard interface and API, other security and operational from the associated posture collectors residing on network
components have a high level of insight into the enterprise's endpoints
endpoints and the software installed on them. This will support
innovation in the areas of asset management, vulnerability
scanning, and administrative interfaces, as any authorized
infrastructure endpoint can interact with the posture information.
o Owners and administrators must have complete control of posture o Update the policy that resides on the posture manager
information, policy, and endpoint mitigation: Enterprise asset
posture information belongs to the enterprise. Standardized
schema, protocols and interfaces help to ensure that this posture
information is not locked in proprietary databases, but is made
available to its owners. This enables administrators to develop
as nuanced a policy as necessary to keep their networks secure.
5. Endpoint Compliance Requirements An API is necessary to allow infrastructure endpoints and software
access to the information stored in the repository. Using this API,
an authorized endpoint SHOULD be able to:
These requirements are written with a view to performing a posture o Query the repository
assessment on an endpoint; as the Endpoint Compliance Profile grows
and evolves, these requirements will be expanded to address issues
that arise. Note that these requirements refer to defined components
of the NEA architecture. As with the NEA architecture, implementers
have discretion as to how these NEA components map to separate pieces
of software or endpoints.
5.1. Endpoint Pre-Provisioning 7.1.6. IETF SACM SWAM Extension to the IETF NEA ECP Implementation
This section defines the requirements associated with the software
asset management extension [I-D.ietf-sacm-nea-swima-patnc] to the
IETF NEA 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 The following requirements assume that the platform or OS vendor
supports the use of SWID tags and has identified a standard directory supports the use of SWID tags and has identified a standard directory
location for the SWID tags to be located as specified by [SWID]. location for the SWID tags to be located as specified by [SWID].
5.1.1. SWID Tags 7.1.6.2. SWID Tags
The primary content for the Endpoint Compliance Profile 1.0 is the The primary content for the Endpoint Compliance Profile 1.0 is the
information conveyed in the elements of a SWID tag. information conveyed in the elements of a SWID tag.
The endpoint MUST have SWID tags stored in a directory specified in The endpoint MUST have SWID tags stored in a directory specified in
[SWID]. The tags SHOULD be provided by the software vendor; they MAY [SWID]. The tags SHOULD be provided by the software vendor; they MAY
also be generated by: also be generated by:
o the software installer; or o the software installer; or
o third-party software that creates tags based on the applications o third-party software that creates tags based on the applications
it sees installed on the endpoint. it sees installed on the endpoint.
The elements in the SWID tag MUST be populated as specified in The elements in the SWID tag MUST be populated as specified in
[SWID]. These tags, and the directory in which they are stored, MUST [SWID]. These tags, and the directory in which they are stored, MUST
be updated as software is added, removed, or updated. be updated as software is added, removed, or updated.
5.1.2. Endpoint Identity and Machine Certificate 7.1.6.3. SWID Posture Collectors and Posture Validators
The endpoint SHOULD authenticate to the server using a machine
certificate during the establishment of the outer tunnel achieved
with PT. [IF-IMV] specifies how to pull an endpoint ID out of a
machine certificate. An endpoint ID SHOULD be created in conformance
with [IF-IMV] from a machine certificate sent via [RFC6876].
In the future, the identity could be a hardware certificate compliant
with [IEEE-802-1ar]; ideally, this ID SHOULD be associated with the
identity of a hardware cryptographic module, in accordance with
[IEEE-802-1ar], if present on the endpoint. The enterprise SHOULD
stand up a certificate root authority; install its root certificate
on endpoints and on the server; and provision the endpoints and the
server with machine certificates. The endpoint MAY authenticate to
the server using a combination of the machine account and password;
however, this is less secure and not recommended.
5.2. Posture Validators and Posture Collectors
Any PC used in an Endpoint Compliance Profile solution MUST be
conformant with [IF-IMC]; an Internet-Draft, under development, that
is a subset of the TCG TNC Integrity Measurement Collector interface
[IF-IMC] and will be submitted in the near future. Any Posture
Validator used in an Endpoint Compliance Profile solution MUST be
conformant with [IF-IMV].
5.2.1. SWID Posture Collectors and Posture Validators
5.2.1.1. The SWID Posture Collector 7.1.6.3.1. The SWID Posture Collector
For the Endpoint Compliance Profile, the SWID Posture Collector MUST For the Endpoint Compliance Profile, the SWID posture collector MUST
be conformant with [I-D.ietf-sacm-nea-swid-patnc], which includes be conformant with [I-D.ietf-sacm-nea-swima-patnc], which includes
requirements for: requirements for:
1. Collecting SWID tags from the SWID directory 1. Collecting SWID tags from the SWID directory
2. Monitoring the SWID directory for changes 2. Monitoring the SWID directory for changes
3. Initiating a session with the server to report changes to the 3. Initiating a session with the posture manager to report changes
directory to the directory
4. Maintaining a list of changes to the SWID directory when updates 4. Maintaining a list of changes to the SWID directory when updates
take place and no PT-TLS connection can be created with the 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 5. Responding to a request for SWID tags from the SWID Posture
Validator on the server Validator on the posture manager
6. Responding to a query from the SWID Posture Validator as to 6. Responding to a query from the SWID posture validator as to
whether all updates have been sent whether all updates have been sent
The SWID Posture Collector is not responsible for detecting that the The SWID posture collector is not responsible for detecting that the
SWID directory was not updated when an application was either SWID directory was not updated when an application was either
installed or uninstalled. installed or uninstalled.
5.2.1.2. The SWID Posture Validator 7.1.6.3.2. The SWID Posture Validator
Conformance to [I-D.ietf-sacm-nea-swid-patnc] enables the SWID Conformance to [I-D.ietf-sacm-nea-swima-patnc] enables the SWID
Posture Validator to: posture validator to:
1. Send messages to the SWID Posture Collector (at the behest of the 1. Send messages to the SWID posture collector (at the behest of the
administrator at the server console) requesting updates for SWID administrator at the posture manager console) requesting updates
tags located on endpoint for SWID tags located on endpoint
2. Ask the SWID Posture Collector whether all updates to the SWID 2. Ask the SWID posture collector whether all updates to the SWID
directory located at the server have been sent directory located at the posture manager have been sent
3. Compare an endpoint's SWID posture information to policy, and 3. Compare an endpoint's SWID posture information to policy, and
make a recommendation to the NEAS about the endpoint make a recommendation to the NEA server about the endpoint
In addition to these requirements, a SWID Posture Validator used in In addition to these requirements, a SWID posture validator used in
conformance with this profile MUST be capable of passing information conformance with this profile MUST be capable of passing information
from the posture assessment results and the endpoint identity from the posture assessment results and the endpoint identity
associated with those results to the repository for storage. associated with those results to the repository for storage.
5.3. NEA Client (NEAC) and NEA Server (NEAS) 7.1.6.4. Repository
[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 The administrative interface SHOULD enable an administrator to:
established; and
4. receive information from the PCs, forward this information to the 1. Query which endpoints have reported SWID tags for a particular
server via the PTC. application
The NEAC MUST also conform to [IF-IMC] to enable communications with 2. Query which SWID tags are installed on an endpoint
the SWID Posture Collector.
5.3.2. NEAS 3. Query tags based on characteristics, such as vendor, publisher,
etc.
The NEAS MUST conform to all requirements in the [RFC5793] and 7.2. IETF NETMOD ECP Implementation
[IF-IMV] specifications. Conformance to [IF-IMV] enables the NEAS to
obtain endpoint identity information from the PTS, and pass this
information to any IMVs on the server.
5.4. Repository NOTE: TO BE WRITTEN
ECP 1.0 requires a simple administrative interface for the 8. ECP Use Cases
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: The following sections describe the different use cases supported by
the Endpoint Compliance Profile.
1. Query which endpoints have reported SWID tags for a particular 8.1. Hardware Asset Management
application
2. Query which SWID tags are installed on a particular endpoint Using the administrative interface on the posture manager, an
3. Query tags based on characteristics, such as vendor, publisher, authorized user can learn:
etc.
In the future, if SACM decides to develop an interface to the o what endpoints are connected to the network at any given time; and
repository server, it should consider requirements for:
1. Creating a secure channel between a publisher and the repository o what SWID tags were reported for the endpoints.
2. Creating a secure channel between a subscriber and the repository 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.
3. The types of interactions that must be supported between 8.2. Software Asset Management
publishers and subscribers to a repository
6. Posture Transport Client (PTC) and Posture Transport Server (PTS) The administrative interface 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 PT-TLS protocol provides a transport service for carrying the PB- o vulnerability management: knowing what software is installed
TNC protocol messages between the endpoint and the server. supports the ability to determine which endpoints contain
vulnerable software and need to be patched.
The PTC and PTS MUST implement PT-TLS, since a connection is needed o configuration management: knowing which security controls need to
that: be applied to harden installed software and better protect
endpoints.
o Can handle large volumes of data, which might require multiple 8.3. Vulnerability Searches
roundtrips, to be sent while the endpoint is connected
o Allows either the NEAC or NEAS to initiate a connection The administrative interface also provides the ability for authorized
users or infrastructure to locate endpoints running software for
which vulnerabilities have been announced. Because of
o Supports secure transport based on machine certificates at both 1. the unique IDs assigned to each endpoint; and
ends of the connection
The PTC and PTS MUST support the use of machine certificates for TLS 2. the rich application data provided in the endpoints' posture
at each endpoint consistent with the requirements stipulated in information,
[RFC6876] and [Server-Discovery].
The PTC MUST be able to locate an authorized server, and switch to a the repository can be queried to find all endpoints running a
new server when required by the network, in conformance with vulnerable application. Endpoints suspected of being vulnerable can
[Server-Discovery]. be addressed by the administrator or flagged for further scrutiny.
7. Administrative Interface and API 8.4. Threat Detection and Analysis
An interface is necessary to allow administrators to manage the The repository's standardized API allows authorized infrastructure
endpoints and software used in the Endpoint Compliance Profile. This endpoints and software to search endpoint posture assessment
interface SHOULD be accessible either on or through (as in the case information for evidence that an endpoint's software inventory has
of a remotely hosted interface) the server. Using this interface, an changed, and can make endpoint software inventory data available to
authorized user or administrator SHOULD be able to: other endpoints. This automates security data sharing in a way that
expedites the correlation of relevant network data, allowing
administrators and infrastructure endpoints to identify odd endpoint
behavior and configuration using secure, standards-based data models
and protocols.
o Query the repository 9. Non-supported Use Cases
o Send commands to the PVs, requesting information from the
associated PCs residing on network endpoints
o Update the policy that resides on the server Several use cases, including but not limited to these, are not
covered by the Endpoint Compliance Profile 1.0:
An API is necessary to allow infrastructure endpoints and software o Gathering non-standardized types of posture information: The
access to the information stored in the repository. Using this API, Endpoint Compliance Profile does not prevent administrators from
an authorized endpoint SHOULD be able to: collecting posture information in proprietary formats from the
endpoint; however it does not set requirements for doing so.
o Query the repository o Solving the lying endpoint problem: The Endpoint Compliance
Profile does not address the lying endpoint problem; the Profile
makes no assertions that it can catch an endpoint that is, either
maliciously or accidentally, reporting false posture information
to the posture manager. However, other solutions may be able to
use the posture information collected using the capabilities
described in this profile to catch an endpoint in a lie. For
example, a sensor may be able to compare the posture information
it has collected on an endpoint's activity on the network to what
the endpoint reported to the server and flag discrepancies.
However, these capabilities are not described in this profile.
8. Endpoint Compliance Profile Examples 10. Endpoint Compliance Profile Examples
8.1. Continuous Posture Assessment of an Endpoint 10.1. Continuous Posture Assessment of an Endpoint
Endpoint Server Endpoint Posture Manager
+---------------+ +---------------+ +----------------+ +----------------+
| | | | | | | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | SWID | | | | SWID | | | | SWID | | | | SWID | |
| | Posture | | | | Posture | | | | Posture | | | | Posture | |
| | Collector | | | | Validator | | | | Collector | | | | Validator | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | | | | | | | | | | |
| | IF-IMC | | | IF-IMV | | | IF-IMC | | | IF-IMV |
| | | | | | | | | | | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | PB Client | | | | PB Server | | | | Posture | | | | Posture | |
| +-----------+ | | +-----------+ | | | Collection | | | | Collection | |
| | | | | | | | Engine | |<------>| | Manager | |
| | | | | | | +------------+ | PT-TLS | +------------+ |
| | | | | | | | | |
| +-----------+ | | +-----------+ | +----------------+ +----------------+
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 4: Continuous Posture Assessment of an Endpoint Figure 3: Continuous Posture Assessment of an Endpoint
8.1.1. Change on Endpoint Triggers Posture Assessment 10.1.1. Change on Endpoint Triggers Posture Assessment
A new application is installed on the endpoint, and the SWID A new application is installed on the endpoint, and the SWID
directory is updated. This triggers an update from the SWID Posture directory is updated. This triggers an update from the SWID posture
Collector to the SWID Posture Validator. The message is sent down collector to the SWID posture validator. The message is sent down
the NEA stack, encapsulated by NEA protocols until it is sent by the the NEA stack, encapsulated by NEA protocols until it is sent by the
PTC to the PTS. The PTS then forwards it up through the stack, where 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 the layers of encapsulation are removed until the SWID Message
arrives at the SWID Posture Validator. arrives at the SWID posture validator.
Endpoint Server Endpoint Posture Manager
+---------------+ +---------------+ +----------------+ +----------------+
| | | | | | | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | SWID | | | | SWID | | | | SWID | | | | SWID | |
| | Posture | | | | Posture | | | | Posture | | | | Posture | |
| | Collector | | | | Validator | | | | Collector | | | | Validator | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | | SWID Message | | | | | | SWIMA for | | |
| | IF-IMC | for PA-TNC | | IF-IMV | | | IF-IMC | PA-TNC | | IF-IMV |
| | | | | | | | | | | |
| +-----------+ | | +-----------+ | | +------------+ | PB-TNC {SWIMA | +------------+ |
| | PB Client | | | | PB Server | | | | Posture | | for PA-TNC} | | Posture | |
| +-----------+ | | +-----------+ | | | Collection | |<--------------->| | Collection | |
| | | | | | | | Engine | | PT-TLS {PB-TNC | | Manager | |
| | | PB-TNC {SWID | | | | +------------+ | {SWIMA for | +------------+ |
| | | Message for | | | | | PA-TNC}} | |
| | | PA-TNC} | | | +----------------+ +----------------+
| +-----------+ | | +-----------+ |
| | PT Client | |<-------------->| | PT Server | |
| +-----------+ | PT-TLS {PB-TNC | +-----------+ |
| | {SWID Message | |
+---------------+ for PA-TNC}} +---------------+
Figure 5: Compliance Protocol Encapsulation Figure 4: Compliance Protocol Encapsulation
The SWID Posture Validator stores the new tag information in the The SWID posture validator stores the new tag information in the
repository. If the tag indicates that the endpoint is compliant to repository. If the tag indicates that the endpoint is compliant to
the policy, then the process is complete until the next time an the policy, then the process is complete until the next time an
update is needed (either because policy states that the endpoint must update is needed (either because policy states that the endpoint must
submit posture assessment results periodically or because an submit posture assessment results periodically or because an
install/uninstall/update on the endpoint triggers a posture install/uninstall/update on the endpoint triggers a posture
assessment). assessment).
Endpoint Server Endpoint Posture Manager
+---------------+ +---------------+ +----------------+ +----------------+
| | | | | | | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | SWID | | | | SWID |-|-+ | | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | | | | | Posture | | | | Posture | | |
| | Collector | | | | Validator | | | | | Collector | | | | Validator | | |
| +-----------+ | | +-----------+ | | | +------------+ | | +------------+ | |
| | | | | | | Repository | | | | | | | Repository
| | IF-IMC | | | IF-IMV | | +--------+ | | IF-IMC | | | IF-IMV | | +--------+
| | | | | | | | | | | | | | | | | |
| +-----------+ | | +-----------+ | | | | | +------------+ | | +------------+ | | | |
| | PB Client | | | | PB Server | | +---->| | | | Posture | | | | Posture | | +---->| |
| +-----------+ | | +-----------+ | | | | | Collection | | | | Collection | | | |
| | | | | | +--------+ | | Engine | |<------>| | Manager | | | |
| | | | | | | +------------+ | | +------------+ | | |
| | | | | | | | | | +--------+
| +-----------+ | | +-----------+ | +----------------+ +----------------+
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 6: Storing SWIDs in the Repository Figure 5: Storing SWIDs in the Repository
If the endpoint has fallen out of compliance with a policy, the If the endpoint has fallen out of compliance with a policy, the
server can alert the administrator via the server's administrative server can alert the administrator via the posture manager's
interface. The administrator can then take steps to address the administrative interface. The administrator can then take steps to
problem. If the administrator has already established a policy for address the problem. If the administrator has already established a
automatically addressing this problem, that policy will be followed. policy for automatically addressing this problem, that policy will be
followed.
(") (")
__|__ __|__
+-->| +-->|
Endpoint Server | / \ Endpoint Posture Manager | / \
+---------------+ +---------------+ | +----------------+ +----------------+ |
| | | | | | | | | |
| +-----------+ | | +-----------+ | | | +------------+ | | +------------+ | |
| | SWID | | | | SWID |-|-+ | | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | | | | Posture | | | | Posture | |
| | Collector | | | | Validator | | | | Collector | | | | Validator | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | | | | | Repository | | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+ | | IF-IMC | | | IF-IMV | +--------+
| | | | | | | | | | | | | | | |
| +-----------+ | | +-----------+ | | | | +------------+ | | +------------+ | | |
| | PB Client | | | | PB Server | | | | | | Posture | | | | Posture | | | |
| +-----------+ | | +-----------+ | | | | | Collection | | | | Collection | | | |
| | | | | | +--------+ | | Engine | |<------>| | Manager | | +--------+
| | | | | | | +------------+ | | +------------+ |
| | | | | | | | | |
| +-----------+ | | +-----------+ | +----------------+ +----------------+
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 7: Server Alerts Network Admin Figure 6: Server Alerts Network Admin
8.2. Administrator Searches for Vulnerable Endpoints 10.2. Administrator Searches for Vulnerable Endpoints
An announcement is made that a particular version of a piece of An announcement is made that a particular version of a piece of
software has a vulnerability. The administrator uses the software has a vulnerability. The administrator uses the
Administrative Interface on the server to search the repository for Administrative Interface on the server to search the repository for
endpoints that reported the SWID tag for the vulnerable software. endpoints that reported the SWID tag for the vulnerable software.
(") (")
__|__ __|__
+-->| +-->|
Endpoint Server | / \ Endpoint Posture Manager | / \
+---------------+ +---------------+ | +----------------+ +----------------+ |
| | | | | | | | | |
| +-----------+ | | +-----------+ | | | +------------+ | | +------------+ | |
| | SWID | | | | SWID |-|-+ | | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | | | | Posture | | | | Posture | |
| | Collector | | | | Validator | | | | Collector | | | | Validator | |
| +-----------+ | | +-----------+ | | +------------+ | | +------------+ |
| | | | | | Repository | | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+ | | IF-IMC | | | IF-IMV | +--------+
| | | | | | | | | | | | | | | |
| +-----------+ | | +-----------+ | | | | +------------+ | | +------------+ | | |
| | PB Client | | | | PB Server | |------>| | | | Posture | | | | Posture | |------>| |
| +-----------+ | | +-----------+ | | | | | Collection | | | | Collection | | | |
| | | | | | +--------+ | | Engine | |<------>| | Manager | | | |
| | | | | | | +------------+ | | +------------+ | +--------+
| | | | | | | | | |
| +-----------+ | | +-----------+ | +----------------+ +----------------+
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 8: Admin Searches for Vulnerable Endpoints Figure 7: Admin Searches for Vulnerable Endpoints
The repository returns a list of entries in the matching the The repository returns a list of entries in the matching the
administrator's search. The administrator can then address the administrator's search. The administrator can then address the
vulnerable endpoints by taking some follow-up action such as removing vulnerable endpoints by taking some follow-up action such as removing
it from the network, quarantining it, or updating the vulnerable it from the network, quarantining it, or updating the vulnerable
software. software.
9. Acknowledgements 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 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 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 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 activities listed in the profile's use cases. The
Endpoint Compliance Profile should not constrain innovation by
specifying details of the user interface but rather functional
requirements.
o Platform-independent: Since network environments may contain many
different types of endpoints, the solution should operate
independently of the endpoint platform.
o Scalable: The Endpoint Compliance Profile must be designed to
scale to very large numbers of endpoints.
12. Future Work
This section captures ideas for future work related to ECP that might
be of interest to the IETF SACM WG. These ideas are listed in no
particular order.
o Integratate the IETF NETMOD Yang Push architecture.
o Add support endpoint types beyond workstations, servers, and
network infrastructure devices.
o Examine the integration of [I-D.ietf-mile-xmpp-grid].
o Define a standard interface and API for interacting with the
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 the
posture broker server and posture transport server(s).
o Retention of posture information on the 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 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 contributed to development of the TNC ECP specification upon which
this document is based. this document is based.
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Member | Organization | | Member | Organization |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Padma Krishnaswamy | Battelle Memorial Institute | | Padma Krishnaswamy | Battelle Memorial Institute |
| | | | | |
skipping to change at page 27, line 14 skipping to change at page 31, line 39
| McKay | | | McKay | |
| | | | | |
| Mary Lessels | U.S. Government | | Mary Lessels | U.S. Government |
| | | | | |
| Chris Salter | U.S. Government | | Chris Salter | U.S. Government |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 1: Members of the TNC Work Group that Contributed to the Table 1: Members of the TNC Work Group that Contributed to the
Document Document
10. IANA Considerations 14. IANA Considerations
This document does not define any new IANA registries. However, this This document does not define any new IANA registries. However, this
document does reference other documents that do define IANA document does reference other documents that do define IANA
registries. As a result, the IANA Considerations section of the registries. As a result, the IANA Considerations section of the
referenced documents should be consulted. referenced documents should be consulted.
11. Security Considerations 15. Security Considerations
The Endpoint Compliance Profile offers substantial improvements in The Endpoint Compliance Profile offers substantial improvements in
endpoint security, as evidenced by the Australian Defense Signals endpoint security, as evidenced by the Australian Defense Signals
Directorate's analysis that 85% of targeted cyber intrusions can be Directorate's analysis that 85% of targeted cyber intrusions can be
prevented through application white listing, patching applications prevented through application whitelisting, patching applications and
and operating systems, and using the latest versions of applications. operating systems, and using the latest versions of applications.
[DSD] Despite these gains, some security risks continue to exist and [DSD] Despite these gains, some security risks continue to exist and
must be considered. must be considered.
To ensure that these benefits and risks are properly understood, this To ensure that these benefits and risks are properly understood, this
Security Considerations section includes an analysis of the benefits Security Considerations section includes an analysis of the benefits
provided by the Endpoint Compliance Profile (Section 11.1), the provided by the Endpoint Compliance Profile (Section 15.1), the
attacks that may be mounted against systems that implement the attacks that may be mounted against systems that implement the
Endpoint Compliance Profile (Section 11.2), and the countermeasures Endpoint Compliance Profile (Section 15.2), and the countermeasures
that may be used to prevent or mitigate these attacks (Section 11.3). that may be used to prevent or mitigate these attacks (Section 15.3).
Overall, a substantial reduction in cyber risk can be achieved. Overall, a substantial reduction in cyber risk can be achieved.
11.1. Security Benefits of Endpoint Compliance Profile 15.1. Security Benefits of Endpoint Compliance Profile
Security weaknesses of the components for this profile should be Security weaknesses of the components for this profile should be
considered in light of the practical considerations that must be considered in light of the practical considerations that must be
addressed to have a viable solution. addressed to have a viable solution.
Posture assessment has two parts: assessment and follow-up actions. Posture assessment has two parts: assessment and follow-up actions.
The point of posture assessment is to ensure that authorized users The point of posture assessment is to ensure that authorized users
are using authorized software configured to be as resilient as are using authorized software configured to be as resilient as
possible against an attack. possible against an attack.
skipping to change at page 28, line 32 skipping to change at page 33, line 9
is needed that can report from every type of endpoint. All software is needed that can report from every type of endpoint. All software
on the endpoint has to be discovered. Information about the software on the endpoint has to be discovered. Information about the software
has to be up to date and accurate. The information that is has to be up to date and accurate. The information that is
discovered has to be reported in a consistent format, so discovered has to be reported in a consistent format, so
administrators do not have to squander time deciphering proprietary administrators do not have to squander time deciphering proprietary
systems and the information can be made readily useful for other systems and the information can be made readily useful for other
security automation purposes. security automation purposes.
ECP is based on a model of a standards-based schema, a standards- ECP is based on a model of a standards-based schema, a standards-
based set of protocols and interfaces, and the existence of an based set of protocols and interfaces, and the existence of an
oversight group, the IETF, that can update the schemas and protocols oversight group, the IETF, that can update the data models and
to meet new use cases and security issues that may be discovered. 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 The data elements in the schema determine what work can be done
consistently for every endpoint and every piece of software. How the consistently for every endpoint and every piece of software. How the
data gets populated is an important consideration. ECP leverages the data gets populated is an important consideration. ECP leverages the
SWID tags from ISO 19770-2 because the tag originates with a single SWID tags from ISO 19770-2 because the tag originates with a single
authoritative source, the application vendor itself. Moreover, there authoritative source, the application vendor itself. Moreover, there
is a natural incentive for the vendor to create this content, since is a natural incentive for the vendor to create this content, since
it makes it easier for enterprises and vendors to track whether it makes it easier for enterprises and vendors to track whether
software is licensed. Practical considerations are security software is licensed. Practical considerations are security
considerations. A sustainable business model for obtaining all the considerations. A sustainable business model for obtaining all the
necessary content is a fundamental requirement. necessary content is a fundamental requirement.
The NEA model is based on having a NEAC run on an endpoint that The NEA model is based on having a NEA client run on an endpoint that
publishes posture information to a server. The advantages are easy publishes posture information to a server. The advantages are easy
to list. A platform vendor can implement its own NEAC and have it be to list. A platform vendor can implement its own NEA client and have
compatible with the NEAS from a different vendor. The interfaces are it be compatible with the NEA server from a different vendor. The
layered on top of mature protocols such as TLS. TLS is the protocol interfaces are layered on top of mature protocols such as TLS. TLS
of choice for ECP, since: is the protocol of choice for ECP, since:
o it has proven secure properties, o it has proven secure properties,
o it can be implemented on most types of endpoints, o it can be implemented on most types of endpoints,
o it allows the gathering of large amounts of information when a o it allows the gathering of large amounts of information when a
endpoint is connected, and endpoint is connected, and
o it enables use of a mechanism to ensure that the client is o it enables use of a mechanism to ensure that the client is
authenticated (authorized) - a client certificate - which also authenticated (authorized) - a client certificate - which also
skipping to change at page 29, line 39 skipping to change at page 34, line 18
endpoints, we will also want to ensure that this information is only endpoints, we will also want to ensure that this information is only
released to authorized applications and parties. For the next stage released to authorized applications and parties. For the next stage
of ECP, SACM may want to define an interface on the repository that of ECP, SACM may want to define an interface on the repository that
can be queried by other security automation applications to make it can be queried by other security automation applications to make it
easier to detect attacks and for other security automation easier to detect attacks and for other security automation
applications. This interface has to be standards-based for applications. This interface has to be standards-based for
enterprises to reap the benefits of innovation that can be achieved enterprises to reap the benefits of innovation that can be achieved
by making the enterprise's data available to other tools and by making the enterprise's data available to other tools and
services. services.
11.2. Threat Model 15.2. Threat Model
This section lists the attacks that can be mounted on an Endpoint This section lists the attacks that can be mounted on an Endpoint
Compliance Profile environment. The following section (Section 11.3) Compliance Profile environment. The following section (Section 15.3)
describes countermeasures. describes countermeasures.
Because the Endpoint Compliance Profile describes a specific use case Because the Endpoint Compliance Profile describes a specific use case
for NEA components, many security considerations for these components for NEA components, many security considerations for these components
are addressed in more detail in the technical specifications: are addressed in more detail in the technical specifications:
[I-D.ietf-sacm-nea-swid-patnc], [IF-IMC], [RFC5793], [I-D.ietf-sacm-nea-swima-patnc], [IF-IMC], [RFC5793],
[Server-Discovery], [RFC6876], [IF-IMV]. [Server-Discovery], [RFC6876], [IF-IMV].
11.2.1. Endpoint Attacks 15.2.1. Endpoint Attacks
While the Endpoint Compliance Profile provides substantial While the Endpoint Compliance Profile provides substantial
improvements in endpoint security as described in Section 11.1, a improvements in endpoint security as described in Section 15.1, a
certain percentage of endpoints will always get compromised. For certain percentage of endpoints will always get compromised. For
this reason, all parties must regard data coming from endpoints as this reason, all parties must regard data coming from endpoints as
potentially unreliable or even malicious. An analogy can be drawn potentially unreliable or even malicious. An analogy can be drawn
with human testimony in an investigation or trial. Human testimony with human testimony in an investigation or trial. Human testimony
is essential but must be regarded with suspicion. is essential but must be regarded with suspicion.
o Compromise of endpoint: A compromised endpoint may report false o Compromise of endpoint: A compromised endpoint may report false
information to confuse or even provide maliciously crafted information to confuse or even provide maliciously crafted
information with a goal of infecting others. information with a goal of infecting others.
skipping to change at page 30, line 33 skipping to change at page 35, line 11
software pretending to be a SWID generation or discovery tool, can software pretending to be a SWID generation or discovery tool, can
place incorrect or maliciously crafted information into the SWID place incorrect or maliciously crafted information into the SWID
directory. Endpoint users may even place such information in the directory. Endpoint users may even place such information in the
directory, whether motivated by curiosity or confusion or a desire directory, whether motivated by curiosity or confusion or a desire
to bypass restrictions on their use of the endpoint. to bypass restrictions on their use of the endpoint.
o Identity spoofing (impersonation): A compromised endpoint may o Identity spoofing (impersonation): A compromised endpoint may
attempt to impersonate another endpoint to gain its privileges or attempt to impersonate another endpoint to gain its privileges or
to besmirch the reputation of that other endpoint. to besmirch the reputation of that other endpoint.
11.2.2. Network Attacks 15.2.2. Network Attacks
A variety of attacks can be mounted using the network. Generally, A variety of attacks can be mounted using the network. Generally,
the network cannot be trusted. the network cannot be trusted.
o Eavesdropping, modification, injection, replay, deletion o Eavesdropping, modification, injection, replay, deletion
o Traffic analysis o Traffic analysis
o Denial of service and blocking traffic o Denial of service and blocking traffic
11.2.3. Server Attacks 15.2.3. Posture Manager Attacks
The server is a critical security element and therefore merits The posture manager is a critical security element and therefore
considerable scrutiny. merits considerable scrutiny.
o Compromised trusted server: A compromised server or a malicious o Compromised trusted manager: A compromised posture manager or a
party that is able to impersonate a server can incorrectly grant malicious party that is able to impersonate a posture manager can
or deny access to endpoints, place incorrect information into the incorrectly grant or deny access to endpoints, place incorrect
repository, or send malicious messages to endpoints information into the repository, or send malicious messages to
endpoints.
o Misconfiguration of trusted server: Accidental or purposeful o Misconfiguration of posture manager: Accidental or purposeful
misconfiguration of a trusted server can cause effects that are misconfiguration of a trusted posture manager can cause effects
similar to those listed for compromised trusted server. that are similar to those listed for compromised trusted posture
manager.
o Malicious untrusted server: An untrusted server cannot mount any o Malicious untrusted posture manager: An untrusted posture manager
significant attacks because all properly implemented endpoints cannot mount any significant attacks because all properly
will refuse to engage in any meaningful dialog with such a server. implemented endpoints will refuse to engage in any meaningful
dialog with such a posture manager.
11.2.4. Repository Attacks 15.2.4. Repository Attacks
The repository is also an important security element and therefore The repository is also an important security element and therefore
merits careful scrutiny. merits careful scrutiny.
o Putting bad information into trusted repository: An authorized o Putting bad information into trusted repository: An authorized
repository client such as a server may be able to put incorrect repository client such as a server may be able to put incorrect
information into a trusted repository or delete or modify information into a trusted repository or delete or modify
historical information, causing incorrect decisions about endpoint historical information, causing incorrect decisions about endpoint
security. Placing maliciously crafted data in the repository security. Placing maliciously crafted data in the repository
could even lead to compromise of repository clients, if they fail could even lead to compromise of repository clients, if they fail
skipping to change at page 31, line 43 skipping to change at page 36, line 25
o Misconfiguration of trusted repository: Accidental or purposeful o Misconfiguration of trusted repository: Accidental or purposeful
misconfiguration of a trusted repository can deny access to the misconfiguration of a trusted repository can deny access to the
repository or result in loss of historical data. repository or result in loss of historical data.
o Malicious untrusted repository: An untrusted repository cannot o Malicious untrusted repository: An untrusted repository cannot
mount any significant attacks because all properly implemented mount any significant attacks because all properly implemented
repository clients will refuse to engage in any meaningful dialog repository clients will refuse to engage in any meaningful dialog
with such a repository. with such a repository.
11.3. Countermeasures 15.3. Countermeasures
This section lists the countermeasures that can be used in an This section lists the countermeasures that can be used in an
Endpoint Compliance Profile environment. Endpoint Compliance Profile environment.
11.3.1. Countermeasures for Endpoint Attacks 15.3.1. Countermeasures for Endpoint Attacks
This profile is in and of itself a countermeasure for a compromised 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 endpoint. A primary defense for an endpoint is to run up to date
software configured to be run as safely as possible. software configured to be run as safely as possible.
Ensuring that anti-virus signatures are up to date and that a Ensuring that anti-virus signatures are up to date and that a
firewall is configured are also protections for an endpoint that are firewall is configured are also protections for an endpoint that are
supported by the current NEA specifications. supported by the current NEA specifications.
Endpoints that have hardware cryptographic modules that are Endpoints that have hardware cryptographic modules that are
provisioned by the enterprise, in accordance with [IEEE-802-1ar], can provisioned by the enterprise, in accordance with [IEEE-802-1ar], can
protect the private keys used for authentication and help prevent protect the private keys used for authentication and help prevent
adversaries from stealing credentials that can be used for adversaries from stealing credentials that can be used for
impersonation. Future versions of the Endpoint Compliance Profile impersonation. Future versions of the Endpoint Compliance Profile
may want to discuss in greater detail how to use a hardware may want to discuss in greater detail how to use a hardware
cryptographic module, in accordance with [IEEE-802-1ar], to protect cryptographic module, in accordance with [IEEE-802-1ar], to protect
credentials and to protect the integrity of the code that executes credentials and to protect the integrity of the code that executes
during the bootstrap process. during the bootstrap process.
11.3.2. Countermeasures for Network Attacks 15.3.2. Countermeasures for Network Attacks
To address network attacks, [RFC6876] includes required encryption, To address network attacks, [RFC6876] includes required encryption,
authentication, integrity protection, and replay protection. authentication, integrity protection, and replay protection.
[Server-Discovery] also includes authorization checks to ensure that [Server-Discovery] also includes authorization checks to ensure that
only authorized servers are trusted by endpoints. Any unspecified or only authorized servers are trusted by endpoints. Any unspecified or
not yet specified network protocols employed in the Endpoint not yet specified network protocols employed in the Endpoint
Compliance Profile (e.g. the protocol used to interface with the Compliance Profile (e.g. the protocol used to interface with the
repository) should include similar protections. repository) should include similar protections.
These protections reduce the scope of the network threat to traffic These protections reduce the scope of the network threat to traffic
analysis and denial of service. Countermeasures for traffic analysis analysis and denial of service. Countermeasures for traffic analysis
(e.g. masking) are usually impractical but may be employed. (e.g. masking) are usually impractical but may be employed.
Countermeasures for denial of service (e.g. detecting and blocking Countermeasures for denial of service (e.g. detecting and blocking
particular sources) SHOULD be used when appropriate to detect and particular sources) SHOULD be used when appropriate to detect and
block denial of service attacks. These are routine practices in block denial of service attacks. These are routine practices in
network security. network security.
11.3.3. Countermeasures for Server Attacks 15.3.3. Countermeasures for Posture Manager Attacks
Because of the serious consequences of server compromise, servers Because of the serious consequences of posture manager compromise,
SHOULD be especially well hardened against attack and minimized to posture managers SHOULD be especially well hardened against attack
reduce their attack surface. They SHOULD be monitored using the NEA and minimized to reduce their attack surface. They SHOULD be
protocols to ensure the integrity of the behavior and analysis data monitored using the NEA protocols to ensure the integrity of the
stored on the server and SHOULD utilize a [IEEE-802-1ar] compliant behavior and analysis data stored on the posture manager and SHOULD
hardware cryptographic module for identity and/or integrity utilize a [IEEE-802-1ar]compliant hardware cryptographic module for
measurements of the server. They should be well managed to minimize identity and/or integrity measurements of the posture manager. They
vulnerabilities in the underlying platform and in systems upon which should be well managed to minimize vulnerabilities in the underlying
the server depends. Network security measures such as firewalls or platform and in systems upon which the posture manager depends.
intrusion detection systems may be used to monitor and limit traffic Network security measures such as firewalls or intrusion detection
to and from the server. Personnel with administrative access to the systems may be used to monitor and limit traffic to and from the
server should be carefully screened and monitored to detect problems posture manager. Personnel with administrative access to the posture
as soon as possible. Server administrators should not use password- manager should be carefully screened and monitored to detect problems
based authentication but should instead use non-reusable credentials as soon as possible. Posture manager administrators should not use
and multi-factor authentication (where available). Physical security password-based authentication but should instead use non-reusable
measures should be employed to prevent physical attacks on servers. credentials and multi-factor authentication (where available).
Physical security measures should be employed to prevent physical
attacks on posture managers.
To ease detection of server compromise should it occur, server To ease detection of posture manager compromise should it occur,
behavior should be monitored to detect unusual behavior (such as a posture manager behavior should be monitored to detect unusual
server reboot, unusual traffic patterns, or other odd behavior). behavior (such as a server reboot, unusual traffic patterns, or other
Endpoints should log and/or notify users and/or administrators when odd behavior). Endpoints should log and/or notify users and/or
peculiar server behavior is detected. To aid forensic investigation, administrators when peculiar posture manager behavior is detected.
permanent read-only audit logs of security-relevant information To aid forensic investigation, permanent read-only audit logs of
pertaining to servers (especially administrative actions) should be security-relevant information pertaining to posture manager
maintained. If server compromise is detected, the server's (especially administrative actions) should be maintained. If posture
certificate should be revoked and careful analysis should be manager compromise is detected, the posture manager's certificate
performed of the source and impact of this compromise. Any reusable should be revoked and careful analysis should be performed of the
credentials that may have been compromised should be reissued. 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 Endpoints can reduce the threat of server compromise by minimizing
the number of trusted servers, using the mechanisms described in the number of trusted posture managers, using the mechanisms
[Server-Discovery]. described in [Server-Discovery].
11.3.4. Countermeasures for Repository Attacks 15.3.4. Countermeasures for Repository Attacks
If the host for the repository is located on its own endpoint, it If the host for the repository is located on its own endpoint, it
should be protected with the same measures taken to protect the should be protected with the same measures taken to protect the
server. In this circumstance, all messages between the server and posture manager. In this circumstance, all messages between the
repository should be protected with a mature security protocol such posture manager and repository should be protected with a mature
as TLS or IPsec. security protocol such as TLS or IPsec.
The repository can aid in the detection of compromised endpoints if The repository can aid in the detection of compromised endpoints if
an adversary cannot tamper with its contents. For instance, if an an adversary cannot tamper with its contents. For instance, if an
endpoint reports that it does not have an application with a known endpoint reports that it does not have an application with a known
vulnerability installed, an administrator can check whether the vulnerability installed, an administrator can check whether the
endpoint might be lying by querying the repository for the history of endpoint might be lying by querying the repository for the history of
what applications were installed on the endpoint. what applications were installed on the endpoint.
To help prevent tampering with the information in the repository: To help prevent tampering with the information in the repository:
1. Only authorized parties should have privilege to run code on the 1. Only authorized parties should have privilege to run code on the
endpoint and to change the repository. endpoint and to change the repository.
2. If a separate endpoint hosts the repository, then the 2. If a separate endpoint hosts the repository, then the
functionality of that endpoint should be limited to hosting the functionality of that endpoint should be limited to hosting the
repository. The firewall on the repository should only allow repository. The firewall on the repository should only allow
access to the server and to any endpoint authorized for access to the posture manager and to any endpoint authorized for
administration. administration.
3. The repository should ideally use "write once" media to archive 3. The repository should ideally use "write once" media to archive
the history of what was placed in the repository, to include a the history of what was placed in the repository, to include a
snapshot of the current status of applications on endpoints. snapshot of the current status of applications on endpoints.
12. Privacy-Considerations 16. Privacy-Considerations
The Endpoint Compliance Profile specifically addresses the collection The Endpoint Compliance Profile specifically addresses the collection
of posture data from enterprise endpoints by an enterprise network. of posture data from enterprise endpoints by an enterprise network.
As such, privacy is not going to often arise as a concern for those As such, privacy is not going to often arise as a concern for those
deploying this solution. deploying this solution.
A possible exception may be the concerns a user may have when A possible exception may be the concerns a user may have when
attempting to connect a personal endpoint (such as a phone or mobile attempting to connect a personal endpoint (such as a phone or mobile
endpoint) to an enterprise network. The user may not want to share endpoint) to an enterprise network. The user may not want to share
certain details, such as an endpoint identifier or SWID tags, with certain details, such as an endpoint identifier or SWID tags, with
the enterprise. The user can configure their NEAC to reject requests the enterprise. The user can configure their NEA client to reject
for this information; however, it is possible that the enterprise requests for this information; however, it is possible that the
policy will not allow the user's endpoint to connect to the network enterprise policy will not allow the user's endpoint to connect to
without providing the requested data. the network without providing the requested data.
13. Change Log 17. Change Log
13.1. -00 to -01 17.1. -00 to -01
There are no textual changes associated with this revision. This There are no textual changes associated with this revision. This
revision simply reflects a resubmission of the document so that it revision simply reflects a resubmission of the document so that it
remains in active status. remains in active status.
13.2. -01 to -02 17.2. -01 to -02
Added references to the Software Inventory Message and Attributes Added references to the Software Inventory Message and Attributes
(SWIMA) for PA-TNC I-D. (SWIMA) for PA-TNC I-D.
Replaced references to PC-TNC with IF-IMC. Replaced references to PC-TNC with IF-IMC.
Removed erroneous hyphens from a couple of section titles. Removed erroneous hyphens from a couple of section titles.
Made a few minor editorial changes. Made a few minor editorial changes.
13.3. -02 to -00 17.3. -02 to -00
Edited Absrtact through Figure 2 to remove references to SWIMA, and Draft adopted by IETF SACM WG.
uplevel draft to describe SACM collection over multiple different
protocols 17.4. -00 to -01
Significant edits to up-level the draft to describe SACM collection
over multiple different protocols.
Replaced references to SANS with CIS. Replaced references to SANS with CIS.
Made a few minor editorial changes. Made other minor editorial changes.
14. References 18. References
14.1. Informative References 18.1. Informative References
[CIS] http://www.cisecurity.org/controls/, "CIS Critical [CIS] http://www.cisecurity.org/controls/, "CIS Critical
Security Controls". Security Controls".
[DSD] http://www.dsd.gov.au/publications/csocprotect/ [DSD] http://www.dsd.gov.au/publications/csocprotect/
top_4_mitigations.htm, "Top 4 Mitigation Strategies to top_4_mitigations.htm, "Top 4 Mitigation Strategies to
Protect Your ICT System", November 2012. Protect Your ICT System", November 2012.
[IEEE-802-1ar] [IEEE-802-1ar]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
skipping to change at page 35, line 29 skipping to change at page 40, line 18
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>. <https://www.rfc-editor.org/info/rfc5209>.
[TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC [TNC] Trusted Computing Group, "TCG Trusted Network Connect TNC
Architecture for Interoperability, Version 1.5", February Architecture for Interoperability, Version 1.5", February
2012. 2012.
14.2. Normative References 18.2. Normative References
[I-D.ietf-sacm-nea-swid-patnc] [I-D.ietf-mile-xmpp-grid]
Schmidt, C., Haynes, D., Coffin, C., and J. Fitzgerald- Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre,
McKay, "Software Inventory Message and Attributes (SWIMA) "Using XMPP for Security Information Exchange", draft-
for PA-TNC", draft-ietf-sacm-nea-swid-patnc-00 (work in ietf-mile-xmpp-grid-04 (work in progress), October 2017.
progress), January 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, "Software Inventory Message and
Attributes (SWIMA) for PA-TNC", draft-ietf-sacm-nea-swima-
patnc-01 (work in progress), September 2017.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., and N. Cam- Waltermire, D., Montville, A., Harrington, D., and N. Cam-
Winget, "Terminology for Security Assessment", draft-ietf- Winget, "Terminology for Security Assessment", draft-ietf-
sacm-terminology-05 (work in progress), August 2014. sacm-terminology-05 (work in progress), August 2014.
[IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC
IF-IMC, Version 1.3", February 2013. IF-IMC, Version 1.3", February 2013.
[IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC
 End of changes. 218 change blocks. 
855 lines changed or deleted 1117 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/