draft-ietf-sacm-ecp-03.txt   draft-ietf-sacm-ecp-04.txt 
SACM D. Haynes SACM D. Haynes
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Best Current Practice J. Fitzgerald-McKay Intended status: Best Current Practice J. Fitzgerald-McKay
Expires: March 11, 2019 Department of Defense Expires: August 19, 2019 Department of Defense
L. Lorenzin L. Lorenzin
Pulse Secure Pulse Secure
September 7, 2018 February 15, 2019
Endpoint Posture Collection Profile Endpoint Posture Collection Profile
draft-ietf-sacm-ecp-03 draft-ietf-sacm-ecp-04
Abstract Abstract
This document specifies the Endpoint Posture Collection Profile, This document specifies the Endpoint Posture Collection Profile,
which describes the best practices for the application of IETF and which describes the best practices for the application of IETF, TNC,
TNC protocols and interfaces to support the on-going collection, and ISO/IEC data models, protocols, and interfaces to support the on-
communication, and assessment of endpoint posture, as well as the going collection and communication of endpoint posture to a
controlled exposure of endpoint posture to other tools. This centralized server where it can be stored and made available to other
document is an extension of the Trusted Computing Group's Endpoint tools. This document is an extension of the Trusted Computing
Compliance Profile Version 1.0 specification [ECP]. Group's Endpoint Compliance Profile Version 1.0 specification [ECP].
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 11, 2019. This Internet-Draft will expire on August 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Preventative Posture Assessments . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. All Network-Connected Endpoints are Endpoints . . . . . . 5 3. Endpoint Posture Collection Profile . . . . . . . . . . . . . 5
1.3. All Endpoints on the Network Must be Uniquely Identified 5 3.1. Components . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Standardized Data Models . . . . . . . . . . . . . . . . 5 3.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Posture Information Must Be Stored . . . . . . . . . . . 6 3.1.1.1. Posture Collection Engine . . . . . . . . . . . . 7
1.6. Posture Information Can Be Shared . . . . . . . . . . . . 6 3.1.2. Posture Manager . . . . . . . . . . . . . . . . . . . 7
1.7. Enterprise Asset Posture Information Belongs to the 3.1.2.1. Posture Collection Manager . . . . . . . . . . . 7
Enterprise . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Repository . . . . . . . . . . . . . . . . . . . . . 7
1.8. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . 8
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.5. Orchestrator . . . . . . . . . . . . . . . . . . . . 8
3. Endpoint Posture Collection Profile . . . . . . . . . . . . . 7 3.1.6. Administrative Interface and API . . . . . . . . . . 8
3.1. Posture Assessments . . . . . . . . . . . . . . . . . . . 7 3.2. Transactions . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Data Storage . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . 9
3.3. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Discovery and Validation . . . . . . . . . . . . . . 9
4. EPCP Components . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Event Driven Collection . . . . . . . . . . . . . . . 9
4.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. Querying . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Posture Collection Engine . . . . . . . . . . . . . . 9 3.2.5. Data Storage . . . . . . . . . . . . . . . . . . . . 10
4.2. Posture Manager . . . . . . . . . . . . . . . . . . . . . 9 3.2.6. Data Sharing . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Posture Collection Manager . . . . . . . . . . . . . 10 4. IETF NEA EPCP Implementation for Traditional Endpoints . . . 10
4.3. Repository . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 12
4.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Orchestrator . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Posture Collector . . . . . . . . . . . . . . . . . . 13
5. EPCP Transactions . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. Posture Broker Client . . . . . . . . . . . . . . . . 13
5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11 4.2.3. Posture Transport Client . . . . . . . . . . . . . . 13
5.2. Discovery and Validation . . . . . . . . . . . . . . . . 11 4.3. Posture Manager . . . . . . . . . . . . . . . . . . . . . 13
5.3. Event Driven Collection . . . . . . . . . . . . . . . . . 11 4.3.1. Posture Validator . . . . . . . . . . . . . . . . . . 13
5.4. Querying . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. Posture Broker Server . . . . . . . . . . . . . . . . 13
5.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . 12 4.3.3. Posture Transport Server . . . . . . . . . . . . . . 13
5.6. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Repository . . . . . . . . . . . . . . . . . . . . . . . 14
6. EPCP Implementations . . . . . . . . . . . . . . . . . . . . 13 4.5. IETF SACM SWAM Extension to the IETF NEA EPCP
6.1. IETF NEA EPCP Implementation for Traditional Endpoints . 13 Implementation . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 14 4.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 14
6.1.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 15 4.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . . . 14
6.1.2.1. Posture Collector . . . . . . . . . . . . . . . . 15 4.5.3. SWID Posture Collectors and Posture Validators . . . 14
6.1.2.2. Posture Broker Client . . . . . . . . . . . . . . 16 4.5.3.1. The SWID Posture Collector . . . . . . . . . . . 15
6.1.2.3. Posture Transport Client . . . . . . . . . . . . 16 4.5.3.2. The SWID Posture Validator . . . . . . . . . . . 15
6.1.3. Posture Manager . . . . . . . . . . . . . . . . . . . 16 4.5.4. Repository . . . . . . . . . . . . . . . . . . . . . 16
6.1.3.1. Posture Validator . . . . . . . . . . . . . . . . 16 5. IETF NETCONF EPCP Implementation for Network Device Endpoints 16
6.1.3.2. Posture Broker Server . . . . . . . . . . . . . . 16 5.1. Endpoint Provisioning . . . . . . . . . . . . . . . . . . 17
6.1.3.3. Posture Transport Server . . . . . . . . . . . . 16 5.2. Posture Manager Provisioning . . . . . . . . . . . . . . 17
6.1.4. Repository . . . . . . . . . . . . . . . . . . . . . 16 5.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.5. IETF SACM SWAM Extension to the IETF NEA EPCP 5.3.1. Datastore . . . . . . . . . . . . . . . . . . . . . . 17
Implementation . . . . . . . . . . . . . . . . . . . 17 5.4. Posture Manager . . . . . . . . . . . . . . . . . . . . . 18
6.1.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . 17 5.5. Repository . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . 17 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.5.3. SWID Posture Collectors and Posture Validators . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
6.1.5.4. Repository . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.2. IETF NETCONF EPCP Implementation for Network Device 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 19 9.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 21
6.2.2. Posture Manager Pre-Provisioning . . . . . . . . . . 20 9.1.2. Network Attacks . . . . . . . . . . . . . . . . . . . 22
6.2.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 20 9.1.3. Posture Manager Attacks . . . . . . . . . . . . . . . 22
6.2.3.1. Datastore . . . . . . . . . . . . . . . . . . . . 20 9.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 22
6.2.4. Posture Manager . . . . . . . . . . . . . . . . . . . 20 9.2. Countermeasures . . . . . . . . . . . . . . . . . . . . . 23
6.2.5. Repository . . . . . . . . . . . . . . . . . . . . . 21 9.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 23
6.3. Administrative Interface and API . . . . . . . . . . . . 21 9.2.2. Countermeasures for Network Attacks . . . . . . . . . 23
7. EPCP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 21 9.2.3. Countermeasures for Posture Manager Attacks . . . . . 24
7.1. Hardware Asset Management . . . . . . . . . . . . . . . . 21 9.2.4. Countermeasures for Repository Attacks . . . . . . . 25
7.2. Software Asset Management . . . . . . . . . . . . . . . . 22 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
7.3. Vulnerability Management . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.4. Threat Detection and Analysis . . . . . . . . . . . . . . 22 11.1. Informative References . . . . . . . . . . . . . . . . . 26
8. Non-supported Use Cases . . . . . . . . . . . . . . . . . . . 23 11.2. Normative References . . . . . . . . . . . . . . . . . . 26
9. Endpoint Posture Collection Profile Examples . . . . . . . . 23 Appendix A. Rationale for an EPCP Solution . . . . . . . . . . . 28
9.1. Continuous Posture Assessment of an Endpoint . . . . . . 23 A.1. Preventative Posture Assessments . . . . . . . . . . . . 28
9.1.1. Change on Endpoint Triggers Posture Assessment . . . 24 A.2. All Network-Connected Endpoints are Endpoints . . . . . . 29
9.2. Administrator Searches for Vulnerable Endpoints . . . . . 27 A.3. All Endpoints on the Network Must be Uniquely Identified 29
10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.4. Standardized Data Models . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 A.5. Posture Information Must Be Stored . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 A.6. Posture Information Can Be Shared . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 A.7. Enterprise Asset Posture Information Belongs to the
13.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 31 Enterprise . . . . . . . . . . . . . . . . . . . . . . . 30
13.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 31 Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases 31
13.1.2. Network Attacks . . . . . . . . . . . . . . . . . . 32 B.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 31
13.1.3. Posture Manager Attacks . . . . . . . . . . . . . . 32 B.1.1. Hardware Asset Management . . . . . . . . . . . . . . 31
13.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 32 B.1.2. Software Asset Management . . . . . . . . . . . . . . 31
13.2. Countermeasures . . . . . . . . . . . . . . . . . . . . 33 B.1.3. Vulnerability Management . . . . . . . . . . . . . . 32
13.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 33 B.1.4. Threat Detection and Analysis . . . . . . . . . . . . 32
13.2.2. Countermeasures for Network Attacks . . . . . . . . 33 B.2. Non-Supported Use Cases . . . . . . . . . . . . . . . . . 32
13.2.3. Countermeasures for Posture Manager Attacks . . . . 34 Appendix C. Endpoint Posture Collection Profile Examples . . . . 33
13.2.4. Countermeasures for Repository Attacks . . . . . . . 35 C.1. Continuous Posture Assessment of an Endpoint . . . . . . 33
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 C.1.1. Change on Endpoint Triggers Posture Assessment . . . 33
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36 C.2. Administrator Searches for Vulnerable Endpoints . . . . . 36
15.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 37
15.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 36 D.1. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 37
15.3. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 37 D.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 38
15.4. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 37 D.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 38
15.5. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 37 D.4. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39
15.6. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 37 D.5. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 D.6. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Informative References . . . . . . . . . . . . . . . . . 37 D.7. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 39
16.2. Normative References . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
The Endpoint Posture Collection Profile (EPCP) builds on prior work The Endpoint Posture Collection Profile (EPCP) builds on prior work
from the IETF NEA WG, the IETF NETCONF WG, and the Trusted Computing from the IETF NEA WG, the IETF NETCONF WG, IETF NETMOD WG, the
Group [TNC] Trusted Network Communications (TNC) WG to describe the Trusted Computing Group (TCG) Trusted Network Communications [TNC]
best practices for the collection, communication, and sharing of WG, and the International Organization for Standardization/
posture information from network-connected endpoints. The first International Electrotechnical Commission Joint Technical Committee
generation of this document focuses on reducing the security exposure (JTC) 1, Subcommittee (SC) 7, WG 21 (ISO/IEC JTC 1, SC7, WG21) to
of a network by enabling event-driven posture collection, describe the best practices for the collection and communication of
standardized querying of additional endpoint data as needed, and the posture information from network-connected endpoints to a centralized
communication of that data to a posture manager. server.
Future revisions of this document may include support for the
collection of endpoint posture from other endpoint types and a
standardized interface for repositories among other capabilities.
Additional information about this future work can be found in
Section 10 of this document.
1.1. Preventative Posture Assessments
The value of continuous endpoint posture assessment is well
established. Security experts have identified asset management and
vulnerability remediation as a critical step for preventing
intrusions. Application whitelisting, patching applications and
operating systems, and using the latest versions of applications top
the Defense Signals Directorate's "Top 4 Mitigations to Protect Your
ICT System". [DSD] "Inventory of Authorized and Unauthorized
Endpoints", "Inventory of Authorized and Unauthorized Software", and
"Continuous Vulnerability Assessment and Remediation" are Controls 1,
2, and 3, respectively, of the CIS Controls [CIS]. While there are
commercially available solutions that attempt to address these
security controls, these solutions do not run on all types of
endpoints; consistently interoperate with other tools that could make
use of the data collected; collect posture information from all types
of endpoints in a consistent, standardized schema; or require vetted,
standardized protocols that have been evaluated by the international
community for cryptographic soundness.
As is true of most solutions offered today, the solution found in the
EPCP does not attempt to solve the lying endpoint problem, or detect
infected endpoints; rather, it focuses on ensuring that healthy
endpoints remain healthy by keeping software up-to-date and patched.
1.2. All Network-Connected Endpoints are Endpoints
As defined by [I-D.ietf-sacm-terminology], an endpoint is any
physical or virtual computing endpoint that can be connected to a
network. Posture assessment against policy is equally, if not more,
important for continuously connected endpoints, such as enterprise
workstations and infrastructure endpoints, as it is for sporadically
connected endpoints. Continuously connected endpoints are just as
likely to fall out of compliance with policy, and a standardized
posture assessment method is necessary to ensure they can be properly
handled.
1.3. All Endpoints on the Network Must be Uniquely Identified
Many administrators struggle to identify what endpoints are connected
to the network at any given time. By requiring a standardized method
of endpoint identity, the EPCP will enable administrators to answer
the basic question, "What is on my network?" In
[I-D.ietf-sacm-terminology], SACM defines this set of endpoints on
the network as the SACM domain. Unique endpoint identification also
enables the comparison of current and past endpoint posture
assessments, by allowing administrators to correlate assessments from
the same endpoint. This makes it easier to flag suspicious changes
in endpoint posture for manual or automatic review, and helps to
swiftly identify malicious changes to endpoint applications.
1.4. Standardized Data Models
Meeting EPCP best practices requires the use of standardized data
models for the exchange of posture information. This helps to ensure
that the posture information sent from endpoints to the repository
can be easily stored, due to their known format, and shared with
authorized endpoints and users.
Posture information must be sent over standardized protocols to
ensure the confidentiality and authenticity of this data while in
transit. Implementations of the EPCP include [RFC6876] and [RFC6241]
for communication between the target endpoint and the posture
manager. These protocols allow networks that implement this solution
to collect large amounts of posture information from an endpoint to
make decisions about that endpoint's compliance with some policy.
The EPCP offers a solution for all endpoints already connected to the
network. Periodic assessments and automated reporting of changes to
endpoint posture allow for instantaneous identification of connected
endpoints that are no longer compliant to some policy.
1.5. Posture Information Must Be Stored
Posture information must be stored by the repository and must be
exposed to an interface at the posture manager. Standard data models
enable standard queries from an interface exposed to an administrator
at the posture manager console. A repository must retain any current
posture information retrieved from the target endpoint and store it
indexed by the unique identifier for the endpoint. Any posture
collection manager specified by this profile must be able to
ascertain from its corresponding posture collection engine whether
the posture information is up to date. An interface on the posture
manager must support a request to obtain up-to-date information when
an endpoint is connected. This interface must also support the
ability to make a standard set of queries about the posture
information stored by the repository. In the future, some forms of
posture information might be retained at the endpoint. The interface
on the posture manager must accommodate the ability to make a request
to the corresponding posture collection engine about the posture of
the target endpoint. Standard data models and protocols also enable
the security of posture assessment results. By storing these results
indexed under the endpoint's unique identification, secure storage
itself enables endpoint posture 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.
1.6. 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.
1.7. Enterprise Asset Posture Information Belongs to the Enterprise This document focuses on reducing the security exposure of a network
by enabling event-driven posture collection, standardized querying of
additional posture information as needed, and the communication of
that data to a centralized server where it can made available to
other components. Thus, eliminating the need for redundant
collection and agents on endpoints. Future revisions of this
document may include support for the collection of posture
information from other endpoint types as well as a standardized
interface for storing and querying data in repositories among other
capabilities. Additional information about this future work can be
found in Section 6 of this document.
Owners and administrators must have complete control of posture To support the collection of posture information from new endpoint
information, policy, and endpoint mitigation. Standardized data types, this document is organized such that it first provides a high-
models, protocols and interfaces help to ensure that this posture level overview of EPCP as well as its abstract architectural
information is not locked in proprietary databases, but is made components and transactions that will be realized by implementations
available to its owners. This enables administrators to develop as (Section 3). This is followed by individual sections that discuss
nuanced a policy as necessary to keep their networks secure. the best practices for specific implementations of the EPCP for a
given endpoint type (e.g., traditional, network device, etc.) along
with any extensions for supported use cases (software asset
management, vulnerability management, etc.).
1.8. Keywords 2. Terminology
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 Furthermore, this document uses terms as defined in
[I-D.ietf-sacm-terminology] unless otherwise specified.
This document uses terms as defined in [I-D.ietf-sacm-terminology]
unless otherwise specified.
3. Endpoint Posture Collection Profile 3. Endpoint Posture Collection Profile
The EPCP describes how IETF data models and protocols can be used to The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols,
support the posture assessment of endpoints on a network. This and interfaces can be used to support the posture assessment of
profile does not generate new data models or protocols; rather, it endpoints on a network. This profile does not generate new data
offers best practices for a full end-to-end solution for posture models, protocols, or interfaces; rather, it offers best practices
assessment, as well as a fresh perspective on how existing standards for a full end-to-end solution for posture assessment, as well as a
can be leveraged against vulnerabilities. fresh perspective on how existing standards can be leveraged against
vulnerabilities. Rationale for the EPCP solution as well as the
3.1. Posture Assessments supported and non-supported use cases is available in Appendix A and
Appendix B respectively.
The EPCP describes how IETF and TNC data models and protocols make it The EPCP makes it possible to perform posture assessments against all
possible to perform posture assessments against all network-connected network-connected endpoints by:
endpoints by:
1. uniquely identifying the endpoint; 1. uniquely identifying the endpoint;
2. collecting and evaluating posture based on data from the 2. collecting and evaluating posture based on data from the endpoint
endpoint; (asset management, software asset management, vulnerability
management, and configuration management);
3. creating a secure, authenticated, confidential channel between 3. creating a secure, authenticated, confidential channel between
the endpoint and the posture manager; the endpoint and the posture manager;
4. enabling the endpoint to notify the posture manager about changes 4. enabling the endpoint to notify the posture manager about changes
to its configuration; to its configuration;
5. enabling the posture manager 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 Furthermore, the EPCP aims to support data storage and data sharing
capabilities to make the collected posture information available to
The EPCP focuses on being able to collect posture information from an authorized parties and components insupport of other processes
endpoint, store it, and make it available to authorized parties. (analytic, access control, remediation, reporting, etc.).
Currently, the EPCP does not specify a protocol or interfaces to
access stored posture information. This needs to be addressed in a
future revision. 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
The EPCP 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 EPCP 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.
4. EPCP Components 3.1. Components
To perform posture assessment, data storage, and data sharing, EPCP To perform posture assessment, data storage, and data sharing, the
defines several components. Some of these components reside on the EPCP defines several components. Some of these components reside on
target endpoint. Others reside on a posture manager that manages the target endpoint. Others reside on a posture manager that manages
communications with the target endpoint and stores the target communications with the target endpoint and stores the target
endpoint's posture information in a repository. endpoint's posture information in a repository.
Posture Manager Endpoint It should be noted that the primary focus of this document is on the
Orchestrator +----------------+ +----------------+ communication between the posture manager and endpoints. While the
+--------+ | | | | orchestrator, evaluator, repository, and administrative interface and
| | | | | | API will be discussed in the context of the broader EPCP
| |<---->| | | | architecture, these components are not strictly defined nor are best
| | pub/ | | | | practices provided for them at this time. As a result, vendors are
| | sub | +------------+ | | +------------+ | free to implement these components and interfaces in a way that makes
+--------+ | | | | | | | | the most sense for their products.
| | Posture | | | | Posture | |
Evaluator Repository | | Collection | | | | Collection | | ************FUTURE WORK*************
+------+ +--------+ | | Manager | |<-------| | Engine | | * *
| | | | | | | | report | | | | * *
| | | | | +------------+ | | +------------+ | * * Posture Manager Endpoint
| |<-----> | |<---->| | query | | * Orchestrator * +----------------+ +----------------+
| |request/| | store| |------->| | * +--------+ * | | | |
| |respond | | | | | | * | |<------*->| | | |
| | | | | | | | * | | pub/ * | | | |
+------+ +--------+ +----------------+ +----------------+ * | | sub * | | | |
| ^ * | | * | +------------+ | | +------------+ |
| query | * +--------+ * | | | | | | | |
+-------------------------------------+ * * | | Posture | | | | Posture | |
* Evaluator Repository * | | Collection | | | | Collection | |
* +------+ +--------+ * | | Manager | |<-------| | Engine | |
* | | | | * | | | | report | | | |
* | | | | * | +------------+ | | +------------+ |
* | |<-----> | |<------*->| | query | |
* | |request/| | store * | |------->| |
* | |respond | | * | | | |
* | | | | * | | | |
* +------+ +--------+ * +----------------+ +----------------+
* | * ^
* | query * |
* +-----------------------------*----------+
* *
* ****************************
* *
* +--------------------------------+ *
* | Administrative Interface | *
* | and API | *
* +--------------------------------+ *
* *
************FUTURE WORK****************************************
Figure 1: EPCP Components Figure 1: EPCP Components
4.1. Endpoint 3.1.1. Endpoint
An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is An endpoint is defined in [RFC6876]. In the EPCP, the endpoint is
monitored by the enterprise and is the target of posture assessments. monitored by the enterprise and is the target of posture assessments.
To support these posture assessments, posture information is To support these posture assessments, posture information is
collected via a posture collection engine. collected via a posture collection engine.
4.1.1. Posture Collection Engine 3.1.1.1. Posture Collection Engine
The posture collection engine is located on the target endpoint and The posture collection engine is located on the target endpoint and
receives queries from a posture collection manager. It also sends receives queries from a posture collection manager. It also sends
collected posture information to the posture manager where it can be collected posture information to the posture manager where it can be
sanity checked and stored in the repository. The posture collection sanity checked and stored in the repository. The posture collection
engine also contains a capability that sets up exchanges between the engine also contains a capability that sets up exchanges between the
target endpoint and posture manager. This capability makes the target endpoint and posture manager. This capability makes the
posture collection engine responsible for performing the client-side posture collection engine responsible for performing the client-side
portion of encryption handshakes, and for locating authorized posture portion of encryption handshakes, and for locating authorized posture
managers with which to communicate. managers with which to communicate.
4.2. Posture Manager 3.1.2. Posture Manager
The posture manager is an endpoint that collects, validates, and The posture manager is an endpoint that collects, validates, and
enriches posture information received about a target endpoint. It enriches posture information received about a target endpoint. It
also stores the posture information it receives in the repository. also stores the posture information it receives in the repository
The posture manager does not evaluate the posture information. where it can be evaluated. The posture manager does not evaluate the
posture information.
4.2.1. Posture Collection Manager 3.1.2.1. Posture Collection Manager
A posture collection manager is a lightweight and extensible A posture collection manager is a lightweight and extensible
component that facilitates the coordination and execution of posture component that facilitates the coordination and execution of posture
collection requests using collection mechanisms deployed across the collection requests using collection mechanisms deployed across the
enterprise. The posture collection manager may query and retrieve enterprise. The posture collection manager may query and retrieve
guidance from the repository to guide the collection of posture guidance from the repository to guide the collection of posture
information from the target endpoint. information from the target endpoint.
The posture collection manager also contains a capability that sets The posture collection manager also contains a capability that sets
up exchanges between the target endpoint and the posture manager, and up exchanges between the target endpoint and the posture manager, and
manages data sent to and from posture collection engine. It is also manages data sent to and from posture collection engine. It is also
responsible for performing the server-side portion of encryption responsible for performing the server-side portion of encryption
handshakes. handshakes.
4.3. Repository 3.1.3. Repository
The repository hosts guidance, endpoint identification information, The repository hosts guidance, endpoint identification information,
and posture information reported by target endpoints where it is made and posture information reported by target endpoints where it is made
available to authorized components and persisted over a period of available to authorized components and persisted over a period of
time set by the administrator. Information stored in the repository time set by the administrator. Information stored in the repository
will be accessible to authorized parties via a standard will be accessible to authorized parties via a standard
administrative interface as well as through a standardized API. The administrative interface as well as through a standardized API. The
repository may be a standalone component or may be located on the repository may be a standalone component or may be located on the
posture manager. Furthermore, an implementation is not restricted to posture manager. Furthermore, an implementation is not restricted to
a single repository and may leverage several repositories to provide a single repository and may leverage several repositories to provide
this functionality. this functionality.
Currently, the EPCP does not provide a standardized interface or API 3.1.4. Evaluator
for accessing the information contained within the repository. A
future revision of the EPCP may specify a standardized interface and
API for components to interact with the repository.
4.4. Evaluator
The evaluator assesses the posture status of a target endpoint by The evaluator assesses the posture status of a target endpoint by
comparing collected posture information against the desired state of comparing collected posture information against the desired state of
the target endpoint specified in guidance. The evaluator queries and the target endpoint specified in guidance. The evaluator queries and
retrieves the appropriate guidance from the repository as well as retrieves the appropriate guidance from the repository as well as
queries and retrieves the posture information required for the queries and retrieves the posture information required for the
assessment from the repository. If the required posture information assessment from the repository. If the required posture information
is not available in the repository, the evaluator may request the is not available in the repository, the evaluator may request the
posture information from the posture collection manager, which will posture information from the posture collection manager, which will
result in the collection of additional posture information from the result in the collection of additional posture information from the
target endpoint. This information is subsequently stored in the target endpoint. This information is subsequently stored in the
repository where it is made available to the evaluator and other repository where it is made available to the evaluator and other
components. The results of the assessment are stored in the components. The results of the assessment are stored in the
repository where they are available to tools and administrators for repository where they are available to tools and administrators for
follow-up actions, further evaluation, and historical purposes. follow-up actions, further evaluation, and historical purposes.
4.5. Orchestrator 3.1.5. Orchestrator
The orchestrator provides a publish/subscribe interface for the The orchestrator provides a publish/subscribe interface for the
repository so that infrastructure endpoints can subscribe to and repository so that infrastructure endpoints can subscribe to and
receive published posture assessment results from the repository receive published posture assessment results from the repository
regarding endpoint posture changes. regarding endpoint posture changes.
The EPCP does not currently define an orchestrator component nor does 3.1.6. Administrative Interface and API
it specify a standardized publish/subscribe interface for this
purpose. Future revisions of the EPCP may specify such an interface.
5. EPCP Transactions The administrative interface allows administrators to query the
repository and manage the endpoints and software used in the EPCP via
the posture manager. Similarly, an API is necessary to allow
infrastructure endpoints and software access to the information
stored in the repository and to manage the endpoints and software
used in the EPCP. The administrative interface and API provide
authorized users, infrastructure endpoints, and software with the
ability to query the repository for data, send commands to the
posture collection managers requesting information from the
associated posture collection engines residing on endpoints, and
establish and update the policy that resides on the posture manager
5.1. Provisioning 3.2. Transactions
The following sections describe the transactions associated with the
components of the EPCP architecture and may be provided in an
implementation.
3.2.1. Provisioning
An endpoint is provisioned with one or more attributes that will An endpoint is provisioned with one or more attributes that will
serve as its unique identifier on the network as well as the serve as its unique identifier on the network as well as the
components and data models necessary to interact with the posture components and data models necessary to interact with the posture
manager. Examples of such identifiers include MAC addresses, serial manager. Examples of such identifiers include MAC addresses, serial
numbers, hardware certificates compliant with [IEEE-802-1ar], and the numbers, hardware certificates compliant with [IEEE-802-1ar], and the
identities of hardware cryptographic modules among others. Once identities of hardware cryptographic modules among others. Once
provisioning is complete, the endpoint is deployed on the network. provisioning is complete, the endpoint is deployed on the network.
Over time, components and data models may need to be added to the Over time, components and data models may need to be added to the
endpoint or updated to support the collection needs of an enterprise. endpoint or updated to support the collection needs of an enterprise.
5.2. Discovery and Validation 3.2.2. Discovery and Validation
If necessary, the target endpoint finds and validates the posture If necessary, the target endpoint finds and validates the posture
manager. The posture collection engine on the target endpoint and manager. The posture collection engine on the target endpoint and
posture collection manager on the posture manager complete an posture collection manager on the posture manager complete an
encryption handshake, during which endpoint identity information is encryption handshake, during which endpoint identity information is
exchanged. exchanged.
5.3. Event Driven Collection 3.2.3. Event Driven Collection
The posture assessment is initiated when the posture collector engine The posture assessment is initiated when the posture collector engine
on the target endpoint notices that relevant posture information on on the target endpoint notices that relevant posture information on
the endpoint has changed. Then, the posture collection engine the endpoint has changed. Then, the posture collection engine
initiates a posture assessment information exchange with the posture initiates a posture assessment information exchange with the posture
collection manager. collection manager.
5.4. Querying 3.2.4. Querying
The posture assessment is initiated by the posture collection The posture assessment is initiated by the posture collection
manager. This can occur because: manager. This can occur because:
1. policy states that a previous assessment has aged out or become 1. policy states that a previous assessment has aged out or become
invalid, or invalid, or
2. the posture collection manager is alerted by a sensor or an 2. the posture collection manager is alerted by a sensor or an
administrator (via the posture manager's administrative administrator (via the posture manager's administrative
interface) that an assessment must be completed interface) that an assessment must be completed
5.5. Data Storage 3.2.5. Data Storage
Once posture information is received by the posture manager, it is Once posture information is received by the posture manager, it is
forwarded to the repository. The repository could be co-located with forwarded to the repository. The repository could be co-located with
the posture manager, or there could be direct or brokered the posture manager, or there could be direct or brokered
communication between the posture manager and the repository. The communication between the posture manager and the repository. The
posture information is stored in the repository along with past posture information is stored in the repository along with past
posture information collected about the target endpoint. posture information collected about the target endpoint.
5.6. Data Sharing 3.2.6. Data Sharing
Because the target endpoint posture information was sent in Because the target endpoint posture information was sent in
standards-based data models over secure, standardized protocols, and standards-based data models over secure, standardized protocols, and
then stored in a centralized repository linked to unique endpoint then stored in a centralized repository linked to unique endpoint
identifiers, authorized parties are able to access the posture identifiers, authorized parties are able to access the posture
information. Such authorized parties may include, but are not information. Such authorized parties may include, but are not
limited to, administrators or endpoint owners (via the posture limited to, administrators or endpoint owners (via the posture
manager's administrative interface), evaluators that access the manager's administrative interface), evaluators that access the
repository directly, and orchestrators that rely on publish/subscribe repository directly, and orchestrators that rely on publish/subscribe
communications with the repository. communications with the repository.
Posture Manager Endpoint 4. IETF NEA EPCP Implementation for Traditional Endpoints
Orchestrator +----------------+ +----------------+
+--------+ | | | |
| | | | | |
| |<---->| | | |
| | pub/ | | | |
| | sub | +------------+ | | +------------+ |
+--------+ | | | | | | | |
| | Posture | | | | Posture | |
Evaluator Repository | | Collection | | | | Collection | |
+------+ +--------+ | | Manager | |<-------| | Engine | |
| | | | | | | | report | | | |
| | | | | +------------+ | | +------------+ |
| |<-----> | |<---->| | query | |
| |request/| | store| |------->| |
| |respond | | | | | |
| | | | | | | |
+------+ +--------+ +----------------+ +----------------+
| ^
| query |
+-------------------------------------+
+--------------------------------+
| Administrative Interface |
| and API |
+--------------------------------+
Figure 2: Exposing Data to the Network
6. EPCP Implementations
The following sections describe implementations of the EPCP
leveraging the IETF NEA and IETF NETCONF architectures.
6.1. IETF NEA EPCP Implementation for Traditional Endpoints
When EPCP is used, posture collectors running on the target endpoint When EPCP is used, posture collectors running on the target endpoint
gather posture information as changes occur on the endpoint. The gather posture information as changes occur on the endpoint. The
data is aggregated by the posture broker client and forwarded to a data is aggregated by the posture broker client and forwarded to a
posture manager, over a secure channel, via the posture transport posture manager, over a secure channel, via the posture transport
client. Once received by the posture transport server on the posture client. Once received by the posture transport server on the posture
manager, the posture information is directed by the posture broker manager, the posture information is directed by the posture broker
server to the appropriate posture validators where it can be server to the appropriate posture validators where it can be
processed and stored in a repository. There the posture information processed and stored in a repository. There the posture information
can be used by other tools to carry out assessment tasks. Posture can be used by other tools to carry out assessment tasks. Posture
collectors can also be queried by posture validators to refresh collectors can also be queried by posture validators to refresh
posture information about the target endpoint or to ask a specific posture information about the target endpoint or to ask a specific
question about posture information. This is shown in Figure 3. question about posture information. This is shown in Figure 2.
Posture Posture Posture Posture
Collection Collection Collection Collection
Manager Engine Manager Engine
+---------------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| +-----------+ | PA-TNC | +-----------+ | | +-----------+ | PA-TNC | +-----------+ |
| | Posture | |--------| | Posture | | | | Posture | |--------| | Posture | |
| | Validator | | | | Collector | | | | Validator | | | | Collector | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
skipping to change at page 14, line 29 skipping to change at page 11, line 29
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | PT Server | |<------>| | PT Client | | | | PT Server | |<------>| | PT Client | |
| +-----------+ | PT-TLS | +-----------+ | | +-----------+ | PT-TLS | +-----------+ |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 3: NEA Components Figure 2: NEA Components
These requirements are written with a view to performing a posture These requirements are written with a view to performing a posture
assessment on an endpoint; as the EPCP grows and evolves, these assessment on an endpoint; as the EPCP grows and evolves, these
requirements will be expanded to address issues that arise. Note requirements will be expanded to address issues that arise. Note
that these requirements refer to defined components of the NEA that these requirements refer to defined components of the NEA
architecture. As with the NEA architecture, vendors have discretion architecture [RFC5209]. As with the NEA architecture, vendors have
as to how these NEA components map to separate pieces of software or discretion as to how these NEA components map to separate pieces of
endpoints. software or endpoints.
It should be noted that the posture broker client and posture Furthermore, it should be noted that the posture broker client and
transport client components of the posture collection engine and the posture transport client components of the posture collection engine
posture broker server and posture transport server components of the and the posture broker server and posture transport server components
posture collection manager would likely need to be implemented by a of the posture collection manager would likely need to be implemented
single vendor because there are no standardized interfaces between by a single vendor because there are no standardized interfaces
the respective components and would not be interoperable. between the respective components and would not be interoperable.
6.1.1. Endpoint Pre-Provisioning Examples of the EPCP as implemented using the components from the NEA
architecture are provided in Appendix C.
4.1. Endpoint Provisioning
An endpoint is provisioned with a machine certificate that will serve An endpoint is provisioned with a machine certificate that will serve
as its unique identifier on the network as well as the components as its unique identifier on the network as well as the components
necessary to interact with the posture manager. This includes a necessary to interact with the posture manager. This includes a
posture collection engine to manage requests from the posture manager posture collection engine to manage requests from the posture manager
and the posture collectors necessary to collect the posture and the posture collectors necessary to collect the posture
information of importance to the enterprise. The endpoint is information of importance to the enterprise. The endpoint is
deployed on the network. deployed on the network.
The target endpoint SHOULD authenticate to the posture manager using The target endpoint SHOULD authenticate to the posture manager using
skipping to change at page 15, line 26 skipping to change at page 12, line 34
with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated
with the identity of a hardware cryptographic module, in accordance with the identity of a hardware cryptographic module, in accordance
with [IEEE-802-1ar], if present on the endpoint. The enterprise with [IEEE-802-1ar], if present on the endpoint. The enterprise
SHOULD stand up a certificate root authority; install its root SHOULD stand up a certificate root authority; install its root
certificate on endpoints and on the posture manager; and provision certificate on endpoints and on the posture manager; and provision
the endpoints and the posture manager with machine certificates. The the endpoints and the posture manager with machine certificates. The
target endpoint MAY authenticate to the posture manager using a target endpoint MAY authenticate to the posture manager using a
combination of the machine account and password; however, this is combination of the machine account and password; however, this is
less secure and not recommended. less secure and not recommended.
6.1.2. Endpoint 4.2. Endpoint
The endpoint MUST conform to [RFC5793], which levies several The endpoint MUST conform to [RFC5793], which levies several
requirements against the endpoint. An endpoint that complies with requirements against the endpoint. An endpoint that complies with
these requirements will be able to: these requirements will be able to:
1. attempt to initiate a session with the posture manager if the 1. attempt to initiate a session with the posture manager if the
posture makes a request to send an update to posture manager; posture makes a request to send an update to posture manager;
2. notify the posture collector if no PT-TLS session with the 2. notify the posture collector if no PT-TLS session with the
posture manager can be created; posture manager can be created;
3. notify the posture collector when a PT-TLS session is 3. notify the posture collector when a PT-TLS session is
established; and established; and
4. receive information from the posture collectors, forward this 4. receive information from the posture collectors, forward this
information to the posture manager via the posture collection information to the posture manager via the posture collection
engine. engine.
6.1.2.1. Posture Collector 4.2.1. Posture Collector
Any posture collector used in an EPCP solution MUST be conformant Any posture collector used in an EPCP solution MUST be conformant
with the TCG TNC Integrity Measurement Collector interface [IF-IMC]. with the TCG TNC Integrity Measurement Collector interface [IF-IMC].
6.1.2.2. Posture Broker Client 4.2.2. Posture Broker Client
The posture broker client MUST conform to [IF-IMC] to enable The posture broker client MUST conform to [IF-IMC] to enable
communications between the posture broker client and the posture communications between the posture broker client and the posture
collectors on the endpoint. collectors on the endpoint.
6.1.2.3. Posture Transport Client 4.2.3. Posture Transport Client
The posture transport client MUST implement PT-TLS. The posture transport client MUST implement PT-TLS.
The posture transport client MUST support the use of machine The posture transport client MUST support the use of machine
certificates for TLS at each endpoint consistent with the certificates for TLS at each endpoint consistent with the
requirements stipulated in [RFC6876] and [Server-Discovery]. requirements stipulated in [RFC6876] and [Server-Discovery].
The posture transport client MUST be able to locate an authorized The posture transport client MUST be able to locate an authorized
posture manager, and switch to a new posture manager when required by posture manager, and switch to a new posture manager when required by
the network, in conformance with [Server-Discovery]. the network, in conformance with [Server-Discovery].
6.1.3. Posture Manager 4.3. Posture Manager
The posture manager MUST conform to all requirements in the The posture manager MUST conform to all requirements in the
[RFC5793]. [RFC5793].
6.1.3.1. Posture Validator 4.3.1. Posture Validator
Any posture validator used in an EPCP solution MUST be conformant Any posture validator used in an EPCP solution MUST be conformant
with the TCG TNC Integrity Measurement Verifier interface [IF-IMV]. with the TCG TNC Integrity Measurement Verifier interface [IF-IMV].
6.1.3.2. Posture Broker Server 4.3.2. Posture Broker Server
The posture broker server MUST conform to [IF-IMV]. Conformance to The posture broker server MUST conform to [IF-IMV]. Conformance to
[IF-IMV] enables the posture broker server to obtain endpoint [IF-IMV] enables the posture broker server to obtain endpoint
identity information from the posture transport server, and pass this identity information from the posture transport server, and pass this
information to any posture validators on the posture manager. information to any posture validators on the posture manager.
6.1.3.3. Posture Transport Server 4.3.3. Posture Transport Server
The posture transport server MUST implement PT-TLS. The posture transport server MUST implement PT-TLS.
The posture transport server MUST support the use of machine The posture transport server MUST support the use of machine
certificates for TLS at each endpoint consistent with the certificates for TLS at each endpoint consistent with the
requirements stipulated in [RFC6876] and [Server-Discovery]. requirements stipulated in [RFC6876] and [Server-Discovery].
6.1.4. Repository 4.4. Repository
EPCP requires a simple administrative interface for the repository. EPCP requires a simple administrative interface for the repository.
Posture validators on the posture manager receive the target endpoint Posture validators on the posture manager receive the target endpoint
posture information via PA-TNC [RFC5792] messages sent from posture information via PA-TNC [RFC5792] messages sent from
corresponding posture collectors on the target endpoint. The posture corresponding posture collectors on the target endpoint. The posture
validators store this information in the repository linked to the validators store this information in the repository linked to the
identity of the target endpoint where the posture collectors are identity of the target endpoint where the posture collectors are
located. located.
6.1.5. IETF SACM SWAM Extension to the IETF NEA EPCP Implementation 4.5. IETF SACM SWAM Extension to the IETF NEA EPCP Implementation
This section defines the requirements associated with the software This section defines the requirements associated with the software
asset management extension [RFC8412] to the IETF NEA EPCP asset management extension [RFC8412] to the IETF NEA EPCP
implementation. implementation.
6.1.5.1. Endpoint Pre-Provisioning 4.5.1. Endpoint Pre-Provisioning
This section defines the requirements associated with implementing This section defines the requirements associated with implementing
SWIMA. 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].
6.1.5.2. SWID Tags 4.5.2. SWID Tags
The primary content for the EPCP is the information conveyed in the The primary content for the EPCP is the information conveyed in the
elements of a SWID tag. 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.
6.1.5.3. SWID Posture Collectors and Posture Validators 4.5.3. SWID Posture Collectors and Posture Validators
4.5.3.1. The SWID Posture Collector
6.1.5.3.1. The SWID Posture Collector
For the EPCP, the SWID posture collector MUST be conformant with For the EPCP, the SWID posture collector MUST be conformant with
[RFC8412], which includes requirements for: [RFC8412], which includes 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 posture manager to report changes 3. Initiating a session with the posture manager to report changes
to the 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
posture manager 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 posture manager Validator on the posture manager
skipping to change at page 18, line 21 skipping to change at page 15, line 30
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 posture manager 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.
6.1.5.3.2. The SWID Posture Validator 4.5.3.2. The SWID Posture Validator
Conformance to [RFC8412] enables the SWID posture validator to: Conformance to [RFC8412] enables the SWID 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 posture manager console) requesting updates administrator at the posture manager console) requesting updates
for SWID 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 posture manager have been sent directory located at the posture manager have been sent
3. Perform any validation and processing on the collected SWID 3. Perform any validation and processing on the collected SWID
posture information prior to storage posture information prior to storage
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 this SWID conformance with this profile MUST be capable of passing this SWID
posture information as well as the associated endpoint identity to posture information as well as the associated endpoint identity to
the repository for storage. the repository for storage.
6.1.5.4. Repository 4.5.4. Repository
The administrative interface SHOULD enable an administrator to: The administrative interface SHOULD enable an administrator to:
1. Query which endpoints have reported SWID tags for a particular 1. Query which endpoints have reported SWID tags for a particular
application application
2. Query which SWID tags are installed on an endpoint 2. Query which SWID tags are installed on an endpoint
3. Query tags based on characteristics, such as vendor, publisher, 3. Query tags based on characteristics, such as vendor, publisher,
etc. etc.
6.2. IETF NETCONF EPCP Implementation for Network Device Endpoints 5. IETF NETCONF EPCP Implementation for Network Device Endpoints
When EPCP is used, a NETCONF client that implements the posture When EPCP is used, a NETCONF client that implements the posture
collection manager sends a query to target network device endpoint collection manager sends a query to target network device endpoint
requesting posture information over a secure channel. Once the requesting posture information over a secure channel. Once the
NETCONF server on the endpoint receives the request, it queries one NETCONF server on the endpoint receives the request, it queries one
or more datastores for the posture information. The NETCONF server or more datastores for the posture information. The NETCONF server
then reports the information back to the NETCONF client where it can then reports the information back to the NETCONF client where it can
be stored in a repository for use by other tools. This is shown in be stored in a repository for use by other tools. This is shown in
Figure 4. Figure 3.
Posture Posture Posture Posture
Collection Collection Collection Collection
Manager Engine Manager Engine
+---------------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| | | +-----------+ | | | | +-----------+ |
| | | | Data | | | | | | Data | |
| | | | Store(s) | | | | | | Store(s) | |
| | | +-----------+ | | | | +-----------+ |
| | | | | | | | | |
| | | | | | | | | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | NETCONF | | | | NETCONF | | | | NETCONF | | | | NETCONF | |
| | Client | |<------->| | Server | | | | Client | |<------->| | Server | |
| +-----------+ | NETCONF | +-----------+ | | +-----------+ | NETCONF | +-----------+ |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 4: NETCONF Components Figure 3: NETCONF Components
These requirements are written with a view to performing a posture These requirements are written with a view to performing a posture
assessment on network device endpoints (routers, switches, etc.); as assessment on network device endpoints (routers, switches, etc.); as
the EPCP grows and evolves, these requirements will be expanded to the EPCP grows and evolves, these requirements will be expanded to
address issues that arise. address issues that arise.
Note that these requirements refer to defined components of the Note that these requirements refer to defined components of the
NETCONF architecture and map back to EPCP. As with the NETCONF NETCONF architecture and map back to EPCP. As with the NETCONF
architecture, vendors have discretion as to how these NETCONF architecture, vendors have discretion as to how these NETCONF
components map to separate pieces of software or endpoints. components map to separate pieces of software or endpoints.
6.2.1. Endpoint Pre-Provisioning 5.1. Endpoint Provisioning
For the posture manager to be able to query the datastores on the For the posture manager to be able to query the datastores on the
endpoint, the endpoint MUST be configured to grant the posture endpoint, the endpoint MUST be configured to grant the posture
manager access to its datastores as described in [RFC6241]. The manager access to its datastores as described in [RFC6241]. The
posture manager is identified by its NETCONF username. posture manager is identified by its NETCONF username. The endpoint
is deployed on the network.
6.2.2. Posture Manager Pre-Provisioning 5.2. Posture Manager Provisioning
For the posture manager to be able to query the datastores on the For the posture manager to be able to query the datastores on the
endpoint, the posture manager MUST be provisioned with a NETCONF endpoint, the posture manager MUST be provisioned with a NETCONF
username that will be used to authenticate the posture manager to the username that will be used to authenticate the posture manager to the
endpoint as described in [RFC6241]. The username generated will be endpoint as described in [RFC6241]. The username generated will be
determined by the selected transport protocol. determined by the selected transport protocol. The posture manager
is deployed on the network.
6.2.3. Endpoint 5.3. Endpoint
An endpoint MUST conform to the requirements outlined for servers in An endpoint MUST conform to the requirements outlined for servers in
the NETCONF protocol as defined in [RFC6241]. This requires the the NETCONF protocol as defined in [RFC6241]. This requires the
implementation of NETCONF over SSH [RFC6242]. An endpoint MAY implementation of NETCONF over SSH [RFC6242]. An endpoint MAY
support the NETCONF protocol over other transports such as TLS support the NETCONF protocol over other transports such as TLS
[RFC7589] as well as the RESTCONF protocol as defined in [RFC8040]. [RFC7589] as well as the RESTCONF protocol as defined in [RFC8040].
6.2.3.1. Datastore 5.3.1. Datastore
A NETCONF datastore on an endpoint MUST support the operations A NETCONF datastore on an endpoint MUST support the operations
outlined in [RFC6241], but, the actual implementation of the outlined in [RFC6241], but, the actual implementation of the
datastore is left to the endpoint vendor. datastore is left to the endpoint vendor.
Datastores MUST support the YANG data modeling language [RFC7950] for Datastores MUST support the YANG data modeling language [RFC7950] for
expressing endpoint posture information in a structured format. In expressing endpoint posture information in a structured format. In
addition, datastores MAY support other data models such as XML (via addition, datastores MAY support other data models such as XML (via
YIN) for representing posture information. YIN) for representing posture information.
Datastores MUST support the compliance posture information specified Datastores MUST support the compliance posture information specified
in [RFC7317]. Datastores MAY support other models standardized or in [RFC7317]. Datastores MAY support other models standardized or
proprietary as deemed appropriate by the endpoint vendor. proprietary as deemed appropriate by the endpoint vendor.
6.2.4. Posture Manager 5.4. Posture Manager
A posture manager MUST conform to the requirements specified for A posture manager MUST conform to the requirements specified for
clients in the NETCONF protocol as defined in [RFC6241]. This clients in the NETCONF protocol as defined in [RFC6241]. This
requires the implementation of NETCONF over SSH [RFC6242]. A posture requires the implementation of NETCONF over SSH [RFC6242]. A posture
manager MAY also support the NETCONF protocol over other transports manager MAY also support the NETCONF protocol over other transports
such as TLS [RFC7589]. In addition, a posture manager MAY support such as TLS [RFC7589]. In addition, a posture manager MAY support
the RESTCONF protocol as defined in [RFC8040]. the RESTCONF protocol as defined in [RFC8040].
While ad-hoc fetch/polling via NETCONF and RESTCONF is useful for While ad-hoc fetch/polling via NETCONF and RESTCONF is useful for
assessing endpoint compliance, such solutions by themselves are not assessing endpoint compliance, such solutions by themselves are not
able to detect changes as they occur on the endpoint. As a result, a able to detect changes as they occur on the endpoint. As a result, a
future revision of this document will support future revision of this document will support
[I-D.ietf-netconf-yang-push] to receive updates on YANG-modeled [I-D.ietf-netconf-yang-push] to receive updates on YANG-modeled
posture information. Similarly, because not all posture information posture information. Similarly, because not all posture information
is modeled in YANG, a future revision of this document will reference is modeled in YANG, a future revision of this document will reference
[I-D.ietf-netconf-subscribed-notifications] once it is a standard to [I-D.ietf-netconf-subscribed-notifications] once it is a standard to
support continuous streams of unstructured data from the endpoint to support continuous streams of unstructured data from the endpoint to
the posture manager. the posture manager.
6.2.5. Repository 5.5. Repository
EPCP requires a simple administrative interface for the repository. EPCP requires a simple administrative interface for the repository.
The posture collection manager on the posture manager receives the The posture collection manager on the posture manager receives the
target endpoint posture information via NETCONF [RFC6241] messages target endpoint posture information via NETCONF [RFC6241] messages
sent from posture collection engine on the target endpoint. The sent from posture collection engine on the target endpoint. The
posture collection manager stores this information in the repository posture collection manager stores this information in the repository
linked to the identity of the target endpoint from which it was linked to the identity of the target endpoint from which it was
collected. collected.
6.3. Administrative Interface and API 6. Future Work
An interface is necessary to allow administrators to query the
repository and manage the endpoints and software used in the EPCP via
the posture manager. Similarly, an API is necessary to allow
infrastructure endpoints and software access to the information
stored in the repository and to manage the endpoints and software
used in the EPCP.
Using this interface or API, authorized users, infrastructure
endpoints, and software SHOULD be able to:
o Query the repository
o Send commands to the posture collection managers, requesting
information from the associated posture collection engines
residing on endpoints
o Establish and update the policy that resides on the posture
manager
7. EPCP Use Cases
The following sections describe the different use cases supported by
the EPCP.
7.1. Hardware Asset Management
Using the administrative interface on the posture manager, an
authorized user can learn:
o what endpoints are connected to the network at any given time; and
o what SWID tags were reported for the endpoints.
The ability to answer these questions offers a standards-based
approach to asset management, which is a vital part of enterprise
processes such as compliance report generation for the Federal
Information Security Modernization Act (FISMA), Payment Card Industry
Data Security Standard (PCI DSS), Health Insurance Portability and
Accountability Act (HIPAA), etc.
7.2. Software Asset Management
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:
o vulnerability management: knowing what software is installed
supports the ability to determine which endpoints contain
vulnerable software and need to be patched.
o configuration management: knowing which security controls need to
be applied to harden installed software and better protect
endpoints.
7.3. Vulnerability Management
The administrative interface also provides the ability for authorized
users or infrastructure to locate endpoints running software for
which vulnerabilities have been announced. Because of
1. the unique IDs assigned to each endpoint; and
2. the rich application data provided in the endpoints' posture
information,
the repository can be queried to find all endpoints running a
vulnerable application. Endpoints suspected of being vulnerable can
be addressed by the administrator or flagged for further scrutiny.
7.4. Threat Detection and Analysis
The repository's standardized API allows authorized infrastructure
endpoints and software to search endpoint posture assessment
information for evidence that an endpoint's software inventory has
changed, and can make endpoint software inventory data available to
other endpoints. This automates security data sharing in a way that
expedites the correlation of relevant network data, allowing
administrators and infrastructure endpoints to identify odd endpoint
behavior and configuration using secure, standards-based data models
and protocols.
8. Non-supported Use Cases
Several use cases, including but not limited to these, are not
covered by the EPCP:
o Gathering non-standardized types of posture information: The EPCP
does not prevent administrators from collecting posture
information in proprietary formats from the endpoint; however it
does not set requirements for doing so.
o Solving the lying endpoint problem: The EPCP 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.
9. Endpoint Posture Collection Profile Examples
The following subsections provide examples of the EPCP as implemented
using components from the NEA architecture.
9.1. Continuous Posture Assessment of an Endpoint
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID | |
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | |
| | IF-IMC | | | IF-IMV |
| | | | | |
| +-----------+ | | +-----------+ |
| | PB Client | | | | PB Server | |
| +-----------+ | | +-----------+ |
| | | | | |
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 5: Continuous Posture Assessment of an Endpoint
9.1.1. Change on Endpoint Triggers Posture Assessment
A new application is installed on the endpoint, and the SWID
directory is updated. This triggers an update from the SWID posture
collector to the SWID posture validator. The message is sent down
the NEA stack, encapsulated by NEA protocols until it is sent by the
posture transport client to the posture transport server. The
posture transport server then forwards it up through the stack, where
the layers of encapsulation are removed until the SWID Message
arrives at the SWID posture validator.
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID | |
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | SWID Message | | |
| | IF-IMC | for PA-TNC | | IF-IMV |
| | | | | |
| +-----------+ | | +-----------+ |
| | PB Client | | | | PB Server | |
| +-----------+ | | +-----------+ |
| | | | | |
| | | PB-TNC {SWID | | |
| | | Message for | | |
| | | PA-TNC} | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<-------------->| | PT Server | |
| +-----------+ | PT-TLS {PB-TNC | +-----------+ |
| | {SWID Message | |
+---------------+ for PA-TNC}} +---------------+
Figure 6: Compliance Protocol Encapsulation
The SWID posture validator stores the new tag information in the
repository. If the tag indicates that the endpoint is compliant to
the policy, then the process is complete until the next time an
update is needed (either because policy states that the endpoint must
submit posture assessment results periodically or because an
install/uninstall/update on the endpoint triggers a posture
assessment).
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | | |
| | Collector | | | | Validator | | |
| +-----------+ | | +-----------+ | |
| | | | | | | Repository
| | IF-IMC | | | IF-IMV | | +--------+
| | | | | | | | |
| +-----------+ | | +-----------+ | | | |
| | PB Client | | | | PB Server | | +---->| |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 7: Storing SWIDs in the Repository
If the endpoint has fallen out of compliance with a policy, the
posture manager can alert the administrator via the posture manager's
administrative interface. The administrator can then take steps to
address the problem. If the administrator has already established a
policy for automatically addressing this problem, that policy will be
followed.
(")
__|__
+-->|
Endpoint Posture Manager | / \
+---------------+ +---------------+ |
| | | | |
| +-----------+ | | +-----------+ | |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+
| | | | | | | |
| +-----------+ | | +-----------+ | | |
| | PB Client | | | | PB Server | | | |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 8: Server Alerts Network Admin
9.2. Administrator Searches for Vulnerable Endpoints
An announcement is made that a particular version of a piece of
software has a vulnerability. The administrator uses the
administrative interface on the server to search the repository for
endpoints that reported the SWID tag for the vulnerable software.
(")
__|__
+-->|
Endpoint Posture Manager | / \
+---------------+ +---------------+ |
| | | | |
| +-----------+ | | +-----------+ | |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+
| | | | | | | |
| +-----------+ | | +-----------+ | | |
| | PB Client | | | | PB Server | |------>| |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 9: Admin Searches for Vulnerable Endpoints
The repository returns a list of entries in the matching the
administrator's search. The administrator can then address the
vulnerable endpoints by taking some follow-up action such as removing
it from the network, quarantining it, or updating the vulnerable
software.
10. Future Work
This section captures ideas for future work related to EPCP that This section captures ideas for future work related to EPCP that
might be of interest to the IETF SACM WG. These ideas are listed in might be of interest to the IETF SACM WG. These ideas are listed in
no particular order. no particular order.
o Integrate the IETF NETCONF Yang Push architecture. o Integrate the IETF NETCONF Yang Push architecture.
o Add support endpoint types beyond workstations, servers, and o Add support endpoint types beyond workstations, servers, and
network infrastructure devices. network infrastructure devices.
skipping to change at page 29, line 23 skipping to change at page 19, line 18
broker client and posture transport client(s) as well as the broker client and posture transport client(s) as well as the
posture broker server and posture transport server(s). posture broker server and posture transport server(s).
o Retention of posture information on the target endpoint. o Retention of posture information on the target endpoint.
o Define an orchestrator component as well as publish/subscribe o Define an orchestrator component as well as publish/subscribe
interface for it. interface for it.
o Define an evaluator component as well as an interface for it. o Define an evaluator component as well as an interface for it.
11. Acknowledgements 7. 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 30, line 46 skipping to change at page 20, line 42
| 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
12. IANA Considerations 8. 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.
13. Security Considerations 9. Security Considerations
This Security Considerations section includes an analysis of the This Security Considerations section includes an analysis of the
attacks that may be mounted against systems that implement the EPCP attacks that may be mounted against systems that implement the EPCP
(Section 13.1) and the countermeasures that may be used to prevent or (Section 9.1) and the countermeasures that may be used to prevent or
mitigate these attacks (Section 13.2). Overall, a substantial mitigate these attacks (Section 9.2). Overall, a substantial
reduction in cyber risk can be achieved. reduction in cyber risk can be achieved.
13.1. Threat Model 9.1. Threat Model
This section lists the attacks that can be mounted on a NEA This section lists the attacks that can be mounted on a NEA
implementation of an EPCP environment. The following section implementation of an EPCP environment. The following section
(Section 13.2) describes countermeasures. (Section 9.2) describes countermeasures.
Because the EPCP describes a specific use case for NEA components, Because the EPCP describes a specific use case for NEA components,
many security considerations for these components are addressed in many security considerations for these components are addressed in
more detail in the technical specifications: [RFC8412], [IF-IMC], more detail in the technical specifications: [RFC8412], [IF-IMC],
[RFC5793], [Server-Discovery], [RFC6876], [IF-IMV]. [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV].
13.1.1. Endpoint Attacks 9.1.1. Endpoint Attacks
While the EPCP provides substantial improvements in endpoint While the EPCP provides substantial improvements in endpoint
security, endpoints can still be compromised. For this reason, all security, endpoints can still be compromised. For this reason, all
parties must regard data coming from endpoints as potentially parties must regard data coming from endpoints as potentially
unreliable or even malicious. An analogy can be drawn with human unreliable or even malicious. An analogy can be drawn with human
testimony in an investigation or trial. Human testimony is essential testimony in an investigation or trial. Human testimony is essential
but must be regarded with suspicion. 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
skipping to change at page 32, line 5 skipping to change at page 22, line 5
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.
13.1.2. Network Attacks 9.1.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
13.1.3. Posture Manager Attacks 9.1.3. Posture Manager Attacks
The posture manager is a critical security element and therefore The posture manager is a critical security element and therefore
merits considerable scrutiny. merits considerable scrutiny.
o Compromised trusted manager: A compromised posture manager or a o Compromised trusted manager: A compromised posture manager or a
malicious party that is able to impersonate a posture manager can malicious party that is able to impersonate a posture manager can
incorrectly grant or deny access to endpoints, place incorrect incorrectly grant or deny access to endpoints, place incorrect
information into the repository, or send malicious messages to information into the repository, or send malicious messages to
endpoints. endpoints.
o Misconfiguration of posture manager: Accidental or purposeful o Misconfiguration of posture manager: Accidental or purposeful
misconfiguration of a trusted posture manager can cause effects misconfiguration of a trusted posture manager can cause effects
that are similar to those listed for compromised trusted posture that are similar to those listed for compromised trusted posture
manager. manager.
o Malicious untrusted posture manager: An untrusted posture manager o Malicious untrusted posture manager: An untrusted posture manager
cannot mount any significant attacks because all properly cannot mount any significant attacks because all properly
implemented endpoints will refuse to engage in any meaningful implemented endpoints will refuse to engage in any meaningful
dialog with such a posture manager. dialog with such a posture manager.
13.1.4. Repository Attacks 9.1.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 33, line 18 skipping to change at page 23, line 18
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.
13.2. Countermeasures 9.2. Countermeasures
This section lists the countermeasures that can be used in a NEA This section lists the countermeasures that can be used in a NEA
implementation of an EPCP environment. implementation of an EPCP environment.
13.2.1. Countermeasures for Endpoint Attacks 9.2.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 EPCP may want to discuss in impersonation. Future versions of the EPCP may want to discuss in
greater detail how to use a hardware cryptographic module, in greater detail how to use a hardware cryptographic module, in
accordance with [IEEE-802-1ar], to protect credentials and to protect accordance with [IEEE-802-1ar], to protect credentials and to protect
the integrity of the code that executes during the bootstrap process. the integrity of the code that executes during the bootstrap process.
13.2.2. Countermeasures for Network Attacks 9.2.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 EPCP (e.g. the not yet specified network protocols employed in the EPCP (e.g. the
protocol used to interface with the repository) should include protocol used to interface with the repository) should include
similar protections. 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.
13.2.3. Countermeasures for Posture Manager Attacks 9.2.3. Countermeasures for Posture Manager Attacks
Because of the serious consequences of posture manager compromise, Because of the serious consequences of posture manager compromise,
posture managers SHOULD be especially well hardened against attack posture managers SHOULD be especially well hardened against attack
and minimized to reduce their attack surface. They SHOULD be and minimized to reduce their attack surface. They SHOULD be
monitored using the NEA protocols to ensure the integrity of the monitored using the NEA protocols to ensure the integrity of the
behavior and analysis data stored on the posture manager and SHOULD behavior and analysis data stored on the posture manager and SHOULD
utilize a [IEEE-802-1ar]compliant hardware cryptographic module for utilize an [IEEE-802-1ar]-compliant hardware cryptographic module for
identity and/or integrity measurements of the posture manager. They identity and/or integrity measurements of the posture manager. They
should be well managed to minimize vulnerabilities in the underlying should be well managed to minimize vulnerabilities in the underlying
platform and in systems upon which the posture manager depends. platform and in systems upon which the posture manager depends.
Network security measures such as firewalls or intrusion detection Network security measures such as firewalls or intrusion detection
systems may be used to monitor and limit traffic to and from the systems may be used to monitor and limit traffic to and from the
posture manager. Personnel with administrative access to the posture posture manager. Personnel with administrative access to the posture
manager should be carefully screened and monitored to detect problems manager should be carefully screened and monitored to detect problems
as soon as possible. Posture manager administrators should not use as soon as possible. Posture manager administrators should not use
password-based authentication but should instead use non-reusable password-based authentication but should instead use non-reusable
credentials and multi-factor authentication (where available). credentials and multi-factor authentication (where available).
skipping to change at page 35, line 5 skipping to change at page 25, line 5
(especially administrative actions) should be maintained. If posture (especially administrative actions) should be maintained. If posture
manager compromise is detected, the posture manager's certificate manager compromise is detected, the posture manager's certificate
should be revoked and careful analysis should be performed of the should be revoked and careful analysis should be performed of the
source and impact of this compromise. Any reusable credentials that source and impact of this compromise. Any reusable credentials that
may have been compromised should be reissued. 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 posture managers, using the mechanisms the number of trusted posture managers, using the mechanisms
described in [Server-Discovery]. described in [Server-Discovery].
13.2.4. Countermeasures for Repository Attacks 9.2.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
posture manager. In this circumstance, all messages between the posture manager. In this circumstance, all messages between the
posture manager and repository should be protected with a mature posture manager and repository should be protected with a mature
security protocol such 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
skipping to change at page 35, line 35 skipping to change at page 25, line 35
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 posture manager 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.
14. Privacy Considerations 10. Privacy Considerations
The EPCP specifically addresses the collection of posture data from The EPCP specifically addresses the collection of posture data from
enterprise endpoints by an enterprise network. As such, privacy is enterprise endpoints by an enterprise network. As such, privacy is
not going to often arise as a concern for those deploying this not going to often arise as a concern for those deploying this
solution. 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 NEA client to reject the enterprise. The user can configure their NEA client to reject
requests for this information; however, it is possible that the requests for this information; however, it is possible that the
enterprise policy will not allow the user's endpoint to connect to enterprise policy will not allow the user's endpoint to connect to
the network without providing the requested data. the network without providing the requested data.
15. Change Log 11. References
15.1. -02 to -03
Addressed various comments from the SACM WG.
Added a reference to TCG ECP 1.0.
Removed text in the "SWID Posture Validator" section that states it
performs evaluation. This was removed because it contradicts the
posture manager not performing any evaluations.
Expanded the "Provisioning" section of the "EPCP Transactions"
section to include examples of endpoint identifiers and the need to
provision endpoints with components and data models.
Combined text for the capabilities of the Administrative Interface
and API.
Removed superfluous and introductory text from the "Security
Considerations" section.
Renamed section "Vulnerability Searches" to Vulnerability
Management".
Changed I-D category to BCP.
Changed references to the NETMOD architecture to the NETCONF
architecture because NETCONF represents the management protocol
whereas NETMOD is focused on the definition of data models.
Addressed various editorial suggestions.
15.2. -01 to -02
Addressed various comments from the SACM WG.
Added a section for the collection of posture information from
network devices using standards from the NETMOD WG.
Updated EPCP component diagrams so they were not specific to a NEA-
based implementation.
Updated EPCP NEA example diagrams to reflect all the components in
the NEA architecture.
15.3. -00 to -01
There are no textual changes associated with this revision. This
revision simply reflects a resubmission of the document so that it
remains in active status.
15.4. -01 to -02
Added references to the Software Inventory Message and Attributes
(SWIMA) for PA-TNC I-D.
Replaced references to PC-TNC with IF-IMC.
Removed erroneous hyphens from a couple of section titles.
Made a few minor editorial changes.
15.5. -02 to -00
Draft adopted by IETF SACM WG.
15.6. -00 to -01
Significant edits to up-level the draft to describe SACM collection
over multiple different protocols.
Replaced references to SANS with CIS.
Made other minor editorial changes.
16. References
16.1. Informative References 11.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.
[ECP] Trusted Computing Group, "TCG Trusted Network Connect [ECP] Trusted Computing Group, "TCG Trusted Network Connect
Endpoint Compliance Profile, Version 1.10", December 2014. Endpoint Compliance Profile, Version 1.10", December 2014.
skipping to change at page 38, line 14 skipping to change at page 26, line 32
[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.
16.2. Normative References 11.2. Normative References
[I-D.ietf-mile-xmpp-grid] [I-D.ietf-mile-xmpp-grid]
Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre, Cam-Winget, N., Appala, S., Pope, S., and P. Saint-Andre,
"Using XMPP for Security Information Exchange", draft- "Using XMPP for Security Information Exchange", draft-
ietf-mile-xmpp-grid-04 (work in progress), October 2017. ietf-mile-xmpp-grid-04 (work in progress), October 2017.
[I-D.ietf-netconf-subscribed-notifications] [I-D.ietf-netconf-subscribed-notifications]
Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and
A. Tripathy, "Customized Subscriptions to a Publisher's A. Tripathy, "Customized Subscriptions to a Publisher's
Event Streams", draft-ietf-netconf-subscribed- Event Streams", draft-ietf-netconf-subscribed-
skipping to change at page 39, line 34 skipping to change at page 28, line 11
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>. 2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589, Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015, DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>. <https://www.rfc-editor.org/info/rfc7589>.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632,
DOI 10.17487/RFC7632, September 2015,
<https://www.rfc-editor.org/info/rfc7632>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and
J. Fitzgerald-McKay, "Software Inventory Message and J. Fitzgerald-McKay, "Software Inventory Message and
skipping to change at page 40, line 13 skipping to change at page 28, line 33
<https://www.rfc-editor.org/info/rfc8412>. <https://www.rfc-editor.org/info/rfc8412>.
[Server-Discovery] [Server-Discovery]
Trusted Computing Group, "DRAFT: TCG Trusted Network Trusted Computing Group, "DRAFT: TCG Trusted Network
Connect PDP Discovery and Validation, Version 1.0", Connect PDP Discovery and Validation, Version 1.0",
October 2015. October 2015.
[SWID] "Information technology--Software asset management--Part [SWID] "Information technology--Software asset management--Part
2: Software identification tag", ISO/IEC 9899:1999, 2009. 2: Software identification tag", ISO/IEC 9899:1999, 2009.
Appendix A. Rationale for an EPCP Solution
A.1. Preventative Posture Assessments
The value of continuous endpoint posture assessment is well
established. Security experts have identified asset management and
vulnerability remediation as a critical step for preventing
intrusions. Application whitelisting, patching applications and
operating systems, and using the latest versions of applications top
the Defense Signals Directorate's "Top 4 Mitigations to Protect Your
ICT System". [DSD] "Inventory of Authorized and Unauthorized
Endpoints", "Inventory of Authorized and Unauthorized Software", and
"Continuous Vulnerability Assessment and Remediation" are Controls 1,
2, and 3, respectively, of the CIS Controls [CIS]. While there are
commercially available solutions that attempt to address these
security controls, these solutions do not run on all types of
endpoints; consistently interoperate with other tools that could make
use of the data collected; collect posture information from all types
of endpoints in a consistent, standardized schema; or require vetted,
standardized protocols that have been evaluated by the international
community for cryptographic soundness.
As is true of most solutions offered today, the solution found in the
EPCP does not attempt to solve the lying endpoint problem, or detect
infected endpoints; rather, it focuses on ensuring that healthy
endpoints remain healthy by keeping software up-to-date and patched.
A.2. All Network-Connected Endpoints are Endpoints
As defined by [I-D.ietf-sacm-terminology], an endpoint is any
physical or virtual computing endpoint that can be connected to a
network. Posture assessment against policy is equally, if not more,
important for continuously connected endpoints, such as enterprise
workstations and infrastructure endpoints, as it is for sporadically
connected endpoints. Continuously connected endpoints are just as
likely to fall out of compliance with policy, and a standardized
posture assessment method is necessary to ensure they can be properly
handled.
A.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 EPCP will enable administrators to answer
the basic question, "What is on my network?" In
[I-D.ietf-sacm-terminology], SACM defines this set of endpoints on
the network as the SACM domain. Unique endpoint identification also
enables the comparison of current and past endpoint posture
assessments, by allowing administrators to correlate assessments from
the same endpoint. This makes it easier to flag suspicious changes
in endpoint posture for manual or automatic review, and helps to
swiftly identify malicious changes to endpoint applications.
A.4. Standardized Data Models
Meeting EPCP best practices requires the use of standardized data
models for the exchange of posture information. This helps to ensure
that the posture information sent from endpoints to the repository
can be easily stored, due to their known format, and shared with
authorized endpoints and users.
Posture information must be sent over standardized protocols to
ensure the confidentiality and authenticity of this data while in
transit. Implementations of the EPCP include [RFC6876] and [RFC6241]
for communication between the target endpoint and the posture
manager. These protocols allow networks that implement this solution
to collect large amounts of posture information from an endpoint to
make decisions about that endpoint's compliance with some policy.
The EPCP offers a solution for all endpoints already connected to the
network. Periodic assessments and automated reporting of changes to
endpoint posture allow for instantaneous identification of connected
endpoints that are no longer compliant to some policy.
A.5. Posture Information Must Be Stored
Posture information must be stored by the repository and must be
exposed to an interface at the posture manager. Standard data models
enable standard queries from an interface exposed to an administrator
at the posture manager console. A repository must retain any current
posture information retrieved from the target endpoint and store it
indexed by the unique identifier for the endpoint. Any posture
collection manager specified by this profile must be able to
ascertain from its corresponding posture collection engine whether
the posture information is up to date. An interface on the posture
manager must support a request to obtain up-to-date information when
an endpoint is connected. This interface must also support the
ability to make a standard set of queries about the posture
information stored by the repository. In the future, some forms of
posture information might be retained at the endpoint. The interface
on the posture manager must accommodate the ability to make a request
to the corresponding posture collection engine about the posture of
the target endpoint. Standard data models and protocols also enable
the security of posture assessment results. By storing these results
indexed under the endpoint's unique identification, secure storage
itself enables endpoint posture 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.
A.6. 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.
A.7. 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. Of
course, there may be exceptions to this such as the case with
privacy-related information (e.g., personally identifiable
information).
Appendix B. EPCP Supported Use Cases and Non-Supported Use Cases
B.1. Supported Use Cases
The following sections describe the different use cases supported by
the EPCP.
B.1.1. Hardware Asset Management
Using the administrative interface on the posture manager, an
authorized user can learn:
o what endpoints are connected to the network at any given time; and
o what SWID tags were reported for the endpoints.
The ability to answer these questions offers a standards-based
approach to asset management, which is a vital part of enterprise
processes such as compliance report generation for the Federal
Information Security Modernization Act (FISMA), Payment Card Industry
Data Security Standard (PCI DSS), Health Insurance Portability and
Accountability Act (HIPAA), etc.
B.1.2. Software Asset Management
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:
o vulnerability management: knowing what software is installed
supports the ability to determine which endpoints contain
vulnerable software and need to be patched.
o configuration management: knowing which security controls need to
be applied to harden installed software and better protect
endpoints.
B.1.3. Vulnerability Management
The administrative interface also provides the ability for authorized
users or infrastructure to locate endpoints running software for
which vulnerabilities have been announced. Because of
1. the unique IDs assigned to each endpoint; and
2. the rich application data provided in the endpoints' posture
information,
the repository can be queried to find all endpoints running a
vulnerable application. Endpoints suspected of being vulnerable can
be addressed by the administrator or flagged for further scrutiny.
B.1.4. Threat Detection and Analysis
The repository's standardized API allows authorized infrastructure
endpoints and software to search endpoint posture assessment
information for evidence that an endpoint's software inventory has
changed, and can make endpoint software inventory data available to
other endpoints. This automates security data sharing in a way that
expedites the correlation of relevant network data, allowing
administrators and infrastructure endpoints to identify odd endpoint
behavior and configuration using secure, standards-based data models
and protocols.
B.2. Non-Supported Use Cases
Several use cases, including but not limited to these, are not
covered by the EPCP:
o Gathering non-standardized types of posture information: The EPCP
does not prevent administrators from collecting posture
information in proprietary formats from the endpoint; however it
does not set requirements for doing so.
o Solving the lying endpoint problem: The EPCP 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.
Appendix C. Endpoint Posture Collection Profile Examples
The following subsections provide examples of the EPCP as implemented
using components from the NEA architecture.
C.1. Continuous Posture Assessment of an Endpoint
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID | |
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | |
| | IF-IMC | | | IF-IMV |
| | | | | |
| +-----------+ | | +-----------+ |
| | PB Client | | | | PB Server | |
| +-----------+ | | +-----------+ |
| | | | | |
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 4: Continuous Posture Assessment of an Endpoint
C.1.1. Change on Endpoint Triggers Posture Assessment
A new application is installed on the endpoint, and the SWID
directory is updated. This triggers an update from the SWID posture
collector to the SWID posture validator. The message is sent down
the NEA stack, encapsulated by NEA protocols until it is sent by the
posture transport client to the posture transport server. The
posture transport server then forwards it up through the stack, where
the layers of encapsulation are removed until the SWID Message
arrives at the SWID posture validator.
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID | |
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | SWID Message | | |
| | IF-IMC | for PA-TNC | | IF-IMV |
| | | | | |
| +-----------+ | | +-----------+ |
| | PB Client | | | | PB Server | |
| +-----------+ | | +-----------+ |
| | | | | |
| | | PB-TNC {SWID | | |
| | | Message for | | |
| | | PA-TNC} | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<-------------->| | PT Server | |
| +-----------+ | PT-TLS {PB-TNC | +-----------+ |
| | {SWID Message | |
+---------------+ for PA-TNC}} +---------------+
Figure 5: Compliance Protocol Encapsulation
The SWID posture validator stores the new tag information in the
repository. If the tag indicates that the endpoint is compliant to
the policy, then the process is complete until the next time an
update is needed (either because policy states that the endpoint must
submit posture assessment results periodically or because an
install/uninstall/update on the endpoint triggers a posture
assessment).
Endpoint Posture Manager
+---------------+ +---------------+
| | | |
| +-----------+ | | +-----------+ |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | | |
| | Collector | | | | Validator | | |
| +-----------+ | | +-----------+ | |
| | | | | | | Repository
| | IF-IMC | | | IF-IMV | | +--------+
| | | | | | | | |
| +-----------+ | | +-----------+ | | | |
| | PB Client | | | | PB Server | | +---->| |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 6: Storing SWIDs in the Repository
If the endpoint has fallen out of compliance with a policy, the
posture manager can alert the administrator via the posture manager's
administrative interface. The administrator can then take steps to
address the problem. If the administrator has already established a
policy for automatically addressing this problem, that policy will be
followed.
(")
__|__
+-->|
Endpoint Posture Manager | / \
+---------------+ +---------------+ |
| | | | |
| +-----------+ | | +-----------+ | |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+
| | | | | | | |
| +-----------+ | | +-----------+ | | |
| | PB Client | | | | PB Server | | | |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 7: Server Alerts Network Admin
C.2. Administrator Searches for Vulnerable Endpoints
An announcement is made that a particular version of a piece of
software has a vulnerability. The administrator uses the
administrative interface on the server to search the repository for
endpoints that reported the SWID tag for the vulnerable software.
(")
__|__
+-->|
Endpoint Posture Manager | / \
+---------------+ +---------------+ |
| | | | |
| +-----------+ | | +-----------+ | |
| | SWID | | | | SWID |-|-+
| | Posture | | | | Posture | |
| | Collector | | | | Validator | |
| +-----------+ | | +-----------+ |
| | | | | | Repository
| | IF-IMC | | | IF-IMV | +--------+
| | | | | | | |
| +-----------+ | | +-----------+ | | |
| | PB Client | | | | PB Server | |------>| |
| +-----------+ | | +-----------+ | | |
| | | | | | +--------+
| | | | | |
| | | | | |
| +-----------+ | | +-----------+ |
| | PT Client | |<------>| | PT Server | |
| +-----------+ | PT-TLS | +-----------+ |
| | | |
+---------------+ +---------------+
Figure 8: Admin Searches for Vulnerable Endpoints
The repository returns a list of entries in the matching the
administrator's search. The administrator can then address the
vulnerable endpoints by taking some follow-up action such as removing
it from the network, quarantining it, or updating the vulnerable
software.
Appendix D. Change Log
D.1. -03 to -04
Addressed various comments from the SACM WG.
Refactored the document to better focus it on the communications
between endpoints and the posture manager and the best practices for
EPCP implementations.
Made other editorial changes and improved consistency throughout the
document.
D.2. -02 to -03
Addressed various comments from the SACM WG.
Added a reference to TCG ECP 1.0.
Removed text in the "SWID Posture Validator" section that states it
performs evaluation. This was removed because it contradicts the
posture manager not performing any evaluations.
Expanded the "Provisioning" section of the "EPCP Transactions"
section to include examples of endpoint identifiers and the need to
provision endpoints with components and data models.
Combined text for the capabilities of the Administrative Interface
and API.
Removed superfluous and introductory text from the "Security
Considerations" section.
Renamed section "Vulnerability Searches" to Vulnerability
Management".
Changed I-D category to BCP.
Changed references to the NETMOD architecture to the NETCONF
architecture because NETCONF represents the management protocol
whereas NETMOD is focused on the definition of data models.
Addressed various editorial suggestions.
D.3. -01 to -02
Addressed various comments from the SACM WG.
Added a section for the collection of posture information from
network devices using standards from the NETMOD WG.
Updated EPCP component diagrams so they were not specific to a NEA-
based implementation.
Updated EPCP NEA example diagrams to reflect all the components in
the NEA architecture.
D.4. -00 to -01
There are no textual changes associated with this revision. This
revision simply reflects a resubmission of the document so that it
remains in active status.
D.5. -01 to -02
Added references to the Software Inventory Message and Attributes
(SWIMA) for PA-TNC I-D.
Replaced references to PC-TNC with IF-IMC.
Removed erroneous hyphens from a couple of section titles.
Made a few minor editorial changes.
D.6. -02 to -00
Draft adopted by IETF SACM WG.
D.7. -00 to -01
Significant edits to up-level the draft to describe SACM collection
over multiple different protocols.
Replaced references to SANS with CIS.
Made other minor editorial changes.
Authors' Addresses Authors' Addresses
Danny Haynes Danny Haynes
The MITRE Corporation The MITRE Corporation
202 Burlington Road 202 Burlington Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: dhaynes@mitre.org Email: dhaynes@mitre.org
 End of changes. 91 change blocks. 
780 lines changed or deleted 774 lines changed or added

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