draft-ietf-sacm-ecp-02.txt   draft-ietf-sacm-ecp-03.txt 
SACM D. Haynes SACM D. Haynes
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Standards Track J. Fitzgerald-McKay Intended status: Best Current Practice J. Fitzgerald-McKay
Expires: January 3, 2019 Department of Defense Expires: March 11, 2019 Department of Defense
L. Lorenzin L. Lorenzin
Pulse Secure Pulse Secure
July 2, 2018 September 7, 2018
Endpoint Posture Collection Profile Endpoint Posture Collection Profile
draft-ietf-sacm-ecp-02 draft-ietf-sacm-ecp-03
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 and
TNC protocols and interfaces to support the on-going collection, TNC protocols and interfaces to support the on-going collection,
communication, and assessment of endpoint posture, as well as the communication, and assessment of endpoint posture, as well as the
controlled exposure of endpoint posture to other tools. This controlled exposure of endpoint posture to other tools. This
document is an extension of the Trusted Computing Group's Endpoint document is an extension of the Trusted Computing Group's Endpoint
Compliance Profile Version 1.0 specification. 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 January 3, 2019. This Internet-Draft will expire on March 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.1.1. Posture Collection Engine . . . . . . . . . . . . . . 9 4.1.1. Posture Collection Engine . . . . . . . . . . . . . . 9
4.2. Posture Manager . . . . . . . . . . . . . . . . . . . . . 9 4.2. Posture Manager . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Posture Collection Manager . . . . . . . . . . . . . 10 4.2.1. Posture Collection Manager . . . . . . . . . . . . . 10
4.3. Repository . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Repository . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Orchestrator . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Orchestrator . . . . . . . . . . . . . . . . . . . . . . 11
5. EPCP Transactions . . . . . . . . . . . . . . . . . . . . . . 11 5. EPCP Transactions . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Discovery and Validation . . . . . . . . . . . . . . . . 11 5.2. Discovery and Validation . . . . . . . . . . . . . . . . 11
5.3. Event Driven Collection . . . . . . . . . . . . . . . . . 11 5.3. Event Driven Collection . . . . . . . . . . . . . . . . . 11
5.4. Querying . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Querying . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 12 5.6. Data Sharing . . . . . . . . . . . . . . . . . . . . . . 12
6. EPCP Implementations . . . . . . . . . . . . . . . . . . . . 13 6. EPCP Implementations . . . . . . . . . . . . . . . . . . . . 13
6.1. IETF NEA EPCP Implementation for Traditional Endpoints . 13 6.1. IETF NEA EPCP Implementation for Traditional Endpoints . 13
6.1.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 14 6.1.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 14
6.1.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 15
6.1.2.1. Posture Collector . . . . . . . . . . . . . . . . 15 6.1.2.1. Posture Collector . . . . . . . . . . . . . . . . 15
6.1.2.2. Posture Broker Client . . . . . . . . . . . . . . 16 6.1.2.2. Posture Broker Client . . . . . . . . . . . . . . 16
6.1.2.3. Posture Transport Client . . . . . . . . . . . . 16 6.1.2.3. Posture Transport Client . . . . . . . . . . . . 16
6.1.3. Posture Manager . . . . . . . . . . . . . . . . . . . 16 6.1.3. Posture Manager . . . . . . . . . . . . . . . . . . . 16
6.1.3.1. Posture Validator . . . . . . . . . . . . . . . . 16 6.1.3.1. Posture Validator . . . . . . . . . . . . . . . . 16
6.1.3.2. Posture Broker Server . . . . . . . . . . . . . . 16 6.1.3.2. Posture Broker Server . . . . . . . . . . . . . . 16
6.1.3.3. Posture Transport Server . . . . . . . . . . . . 16 6.1.3.3. Posture Transport Server . . . . . . . . . . . . 16
6.1.4. Repository . . . . . . . . . . . . . . . . . . . . . 17 6.1.4. Repository . . . . . . . . . . . . . . . . . . . . . 16
6.1.5. IETF SACM SWAM Extension to the IETF NEA EPCP 6.1.5. IETF SACM SWAM Extension to the IETF NEA EPCP
Implementation . . . . . . . . . . . . . . . . . . . 17 Implementation . . . . . . . . . . . . . . . . . . . 17
6.1.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . 17 6.1.5.1. Endpoint Pre-Provisioning . . . . . . . . . . . . 17
6.1.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . 17 6.1.5.2. SWID Tags . . . . . . . . . . . . . . . . . . . . 17
6.1.5.3. SWID Posture Collectors and Posture Validators . 17 6.1.5.3. SWID Posture Collectors and Posture Validators . 17
6.1.5.4. Repository . . . . . . . . . . . . . . . . . . . 19 6.1.5.4. Repository . . . . . . . . . . . . . . . . . . . 18
6.2. IETF NETMOD EPCP Implementation for Network Device 6.2. IETF NETCONF EPCP Implementation for Network Device
Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 19 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 20 6.2.1. Endpoint Pre-Provisioning . . . . . . . . . . . . . . 19
6.2.2. Posture Manager Pre-Provisioning . . . . . . . . . . 20 6.2.2. Posture Manager Pre-Provisioning . . . . . . . . . . 20
6.2.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 20 6.2.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 20
6.2.3.1. Datastore . . . . . . . . . . . . . . . . . . . . 20 6.2.3.1. Datastore . . . . . . . . . . . . . . . . . . . . 20
6.2.4. Posture Manager . . . . . . . . . . . . . . . . . . . 20 6.2.4. Posture Manager . . . . . . . . . . . . . . . . . . . 20
6.2.5. Repository . . . . . . . . . . . . . . . . . . . . . 21 6.2.5. Repository . . . . . . . . . . . . . . . . . . . . . 21
6.3. Administrative Interface and API . . . . . . . . . . . . 21 6.3. Administrative Interface and API . . . . . . . . . . . . 21
7. EPCP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 22 7. EPCP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Hardware Asset Management . . . . . . . . . . . . . . . . 22 7.1. Hardware Asset Management . . . . . . . . . . . . . . . . 21
7.2. Software Asset Management . . . . . . . . . . . . . . . . 22 7.2. Software Asset Management . . . . . . . . . . . . . . . . 22
7.3. Vulnerability Searches . . . . . . . . . . . . . . . . . 22 7.3. Vulnerability Management . . . . . . . . . . . . . . . . 22
7.4. Threat Detection and Analysis . . . . . . . . . . . . . . 23 7.4. Threat Detection and Analysis . . . . . . . . . . . . . . 22
8. Non-supported Use Cases . . . . . . . . . . . . . . . . . . . 23 8. Non-supported Use Cases . . . . . . . . . . . . . . . . . . . 23
9. Endpoint Posture Collection Profile Examples . . . . . . . . 23 9. Endpoint Posture Collection Profile Examples . . . . . . . . 23
9.1. Continuous Posture Assessment of an Endpoint . . . . . . 23 9.1. Continuous Posture Assessment of an Endpoint . . . . . . 23
9.1.1. Change on Endpoint Triggers Posture Assessment . . . 24 9.1.1. Change on Endpoint Triggers Posture Assessment . . . 24
9.2. Administrator Searches for Vulnerable Endpoints . . . . . 27 9.2. Administrator Searches for Vulnerable Endpoints . . . . . 27
10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
13.1. Security Benefits of Endpoint Posture Collection Profile 31 13.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 31
13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 33 13.1.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 31
13.2.1. Endpoint Attacks . . . . . . . . . . . . . . . . . . 33 13.1.2. Network Attacks . . . . . . . . . . . . . . . . . . 32
13.2.2. Network Attacks . . . . . . . . . . . . . . . . . . 34 13.1.3. Posture Manager Attacks . . . . . . . . . . . . . . 32
13.2.3. Posture Manager Attacks . . . . . . . . . . . . . . 34 13.1.4. Repository Attacks . . . . . . . . . . . . . . . . . 32
13.2.4. Repository Attacks . . . . . . . . . . . . . . . . . 34 13.2. Countermeasures . . . . . . . . . . . . . . . . . . . . 33
13.3. Countermeasures . . . . . . . . . . . . . . . . . . . . 35 13.2.1. Countermeasures for Endpoint Attacks . . . . . . . . 33
13.3.1. Countermeasures for Endpoint Attacks . . . . . . . . 35 13.2.2. Countermeasures for Network Attacks . . . . . . . . 33
13.3.2. Countermeasures for Network Attacks . . . . . . . . 36 13.2.3. Countermeasures for Posture Manager Attacks . . . . 34
13.3.3. Countermeasures for Posture Manager Attacks . . . . 36 13.2.4. Countermeasures for Repository Attacks . . . . . . . 35
13.3.4. Countermeasures for Repository Attacks . . . . . . . 37 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 36
15.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 38 15.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 36
15.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 38 15.3. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 37
15.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 38 15.4. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 37
15.4. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 38 15.5. -02 to -00 . . . . . . . . . . . . . . . . . . . . . . . 37
15.5. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 38 15.6. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Informative References . . . . . . . . . . . . . . . . . 39 16.1. Informative References . . . . . . . . . . . . . . . . . 37
16.2. Normative References . . . . . . . . . . . . . . . . . . 39 16.2. Normative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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 NETMOD WG, and the Trusted Computing from the IETF NEA WG, the IETF NETCONF WG, and the Trusted Computing
Group [TNC] Trusted Network Communications (TNC) WG to describe the Group [TNC] Trusted Network Communications (TNC) WG to describe the
best practices for the collection, communication, and sharing of best practices for the collection, communication, and sharing of
posture information from network-connected endpoints. The first posture information from network-connected endpoints. The first
generation of this document focuses on reducing the security exposure generation of this document focuses on reducing the security exposure
of a network by enabling event-driven posture collection, of a network by enabling event-driven posture collection,
standardized querying of additional endpoint data as needed, and the standardized querying of additional endpoint data as needed, and the
communication of that data to a posture manager. communication of that data to a posture manager.
Future revisions of this document may include support for the Future revisions of this document may include support for the
collection of endpoint posture from other endpoint types and a collection of endpoint posture from other endpoint types and a
skipping to change at page 4, line 39 skipping to change at page 4, line 39
The value of continuous endpoint posture assessment is well The value of continuous endpoint posture assessment is well
established. Security experts have identified asset management and established. Security experts have identified asset management and
vulnerability remediation as a critical step for preventing vulnerability remediation as a critical step for preventing
intrusions. Application whitelisting, patching applications and intrusions. Application whitelisting, patching applications and
operating systems, and using the latest versions of applications top operating systems, and using the latest versions of applications top
the Defense Signals Directorate's "Top 4 Mitigations to Protect Your the Defense Signals Directorate's "Top 4 Mitigations to Protect Your
ICT System". [DSD] "Inventory of Authorized and Unauthorized ICT System". [DSD] "Inventory of Authorized and Unauthorized
Endpoints", "Inventory of Authorized and Unauthorized Software", and Endpoints", "Inventory of Authorized and Unauthorized Software", and
"Continuous Vulnerability Assessment and Remediation" are Controls 1, "Continuous Vulnerability Assessment and Remediation" are Controls 1,
2, and 4, respectively, of the CIS Controls. [CIS] While there are 2, and 3, respectively, of the CIS Controls [CIS]. While there are
commercially available solutions that attempt to address these commercially available solutions that attempt to address these
security controls, these solutions do not run on all types of security controls, these solutions do not run on all types of
endpoints; consistently interoperate with other tools that could make endpoints; consistently interoperate with other tools that could make
use of the data collected; collect posture information from all types use of the data collected; collect posture information from all types
of endpoints in a consistent, standardized schema; or require vetted, of endpoints in a consistent, standardized schema; or require vetted,
standardized protocols that have been evaluated by the international standardized protocols that have been evaluated by the international
community for cryptographic soundness. community for cryptographic soundness.
As is true of most solutions offered today, the solution found in the As is true of most solutions offered today, the solution found in the
EPCP does not attempt to solve the lying endpoint problem, or detect EPCP does not attempt to solve the lying endpoint problem, or detect
skipping to change at page 8, line 29 skipping to change at page 8, line 29
management, and configuration management use cases as well as support management, and configuration management use cases as well as support
analytic, access control, remediation, and reporting processes. analytic, access control, remediation, and reporting processes.
However, the EPCP does not currently specify a protocol for However, the EPCP does not currently specify a protocol for
communicating this information between components to support these communicating this information between components to support these
use cases and processes. This needs to be addressed in a future use cases and processes. This needs to be addressed in a future
revision. revision.
4. EPCP Components 4. EPCP Components
To perform posture assessment, data storage, and data sharing, EPCP To perform posture assessment, data storage, and data sharing, EPCP
defines a number of components. Some of these components reside on defines several components. Some of these components reside on the
the target endpoint. Others reside on a posture manager that manages 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 Posture Manager Endpoint
Orchestrator +----------------+ +----------------+ Orchestrator +----------------+ +----------------+
+--------+ | | | | +--------+ | | | |
| | | | | | | | | | | |
| |<---->| | | | | |<---->| | | |
| | pub/ | | | | | | pub/ | | | |
| | sub | +------------+ | | +------------+ | | | sub | +------------+ | | +------------+ |
skipping to change at page 11, line 26 skipping to change at page 11, line 26
The EPCP does not currently define an orchestrator component nor does The EPCP does not currently define an orchestrator component nor does
it specify a standardized publish/subscribe interface for this it specify a standardized publish/subscribe interface for this
purpose. Future revisions of the EPCP may specify such an interface. purpose. Future revisions of the EPCP may specify such an interface.
5. EPCP Transactions 5. EPCP Transactions
5.1. Provisioning 5.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 necessary to interact with the posture manager. The components and data models necessary to interact with the posture
endpoint is deployed on the network. manager. Examples of such identifiers include MAC addresses, serial
numbers, hardware certificates compliant with [IEEE-802-1ar], and the
NOTE: TO BE EXPANDED identities of hardware cryptographic modules among others. Once
provisioning is complete, the endpoint is deployed on the network.
Over time, components and data models may need to be added to the
endpoint or updated to support the collection needs of an enterprise.
5.2. Discovery and Validation 5.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 5.3. Event Driven Collection
skipping to change at page 13, line 36 skipping to change at page 13, line 36
+--------------------------------+ +--------------------------------+
| Administrative Interface | | Administrative Interface |
| and API | | and API |
+--------------------------------+ +--------------------------------+
Figure 2: Exposing Data to the Network Figure 2: Exposing Data to the Network
6. EPCP Implementations 6. EPCP Implementations
The following sections describe implementations of the EPCP The following sections describe implementations of the EPCP
leveraging the IETF NEA and IETF NETMOD architectures. leveraging the IETF NEA and IETF NETCONF architectures.
6.1. IETF NEA EPCP Implementation for Traditional Endpoints 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
skipping to change at page 15, line 28 skipping to change at page 15, line 28
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 6.1.2. Endpoint
The endpoint MUST conform to [RFC5793], which levies a number of 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 6.1.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 [IF-IMC]; an Internet-Draft, under development, that is a subset with the TCG TNC Integrity Measurement Collector interface [IF-IMC].
of the TCG TNC Integrity Measurement Collector interface [IF-IMC] and
will be submitted in the near future.
6.1.2.2. Posture Broker Client 6.1.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 6.1.2.3. Posture Transport Client
The posture transport client MUST implement PT-TLS. The posture transport client MUST implement PT-TLS.
skipping to change at page 16, line 31 skipping to change at page 16, line 31
the network, in conformance with [Server-Discovery]. the network, in conformance with [Server-Discovery].
6.1.3. Posture Manager 6.1.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 6.1.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 [IF-IMV]; an Internet-Draft, under development, that is a subset with the TCG TNC Integrity Measurement Verifier interface [IF-IMV].
of the TCG TNC Integrity Measurement Verifier interface [IF-IMV] and
will be submitted in the near future.
6.1.3.2. Posture Broker Server 6.1.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 6.1.3.3. Posture Transport Server
skipping to change at page 17, line 18 skipping to change at page 17, line 12
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 6.1.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 [I-D.ietf-sacm-nea-swima-patnc] to the asset management extension [RFC8412] to the IETF NEA EPCP
IETF NEA EPCP implementation. implementation.
6.1.5.1. Endpoint Pre-Provisioning 6.1.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].
skipping to change at page 18, line 4 skipping to change at page 17, line 43
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 6.1.5.3. SWID Posture Collectors and Posture Validators
6.1.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
[I-D.ietf-sacm-nea-swima-patnc], 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 32 skipping to change at page 18, line 23
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 6.1.5.3.2. The SWID Posture Validator
Conformance to [I-D.ietf-sacm-nea-swima-patnc] enables the SWID Conformance to [RFC8412] enables the SWID posture validator to:
posture validator to:
1. Send messages to the SWID posture collector (at the behest of the 1. Send messages to the SWID posture collector (at the behest of the
administrator at the 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. Compare an endpoint's SWID posture information to policy, and 3. Perform any validation and processing on the collected SWID
make a recommendation to the posture manager about the endpoint 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 information conformance with this profile MUST be capable of passing this SWID
from the posture assessment results and the endpoint identity posture information as well as the associated endpoint identity to
associated with those results to the repository for storage. the repository for storage.
6.1.5.4. Repository 6.1.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 NETMOD EPCP Implementation for Network Device Endpoints 6.2. 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 4.
skipping to change at page 19, line 46 skipping to change at page 19, line 34
| | | +-----------+ | | | | +-----------+ |
| | | | | | | | | |
| | | | | | | | | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | NETCONF | | | | NETCONF | | | | NETCONF | | | | NETCONF | |
| | Client | |<------->| | Server | | | | Client | |<------->| | Server | |
| +-----------+ | NETCONF | +-----------+ | | +-----------+ | NETCONF | +-----------+ |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 4: NETMOD Components Figure 4: 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
NETMOD architecture and map back to EPCP. As with the NETMOD NETCONF architecture and map back to EPCP. As with the NETCONF
architecture, vendors have discretion as to how these NETMOD 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 6.2.1. Endpoint Pre-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.
6.2.2. Posture Manager Pre-Provisioning 6.2.2. Posture Manager Pre-Provisioning
skipping to change at page 21, line 31 skipping to change at page 21, line 19
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.3. Administrative Interface and API
An interface is necessary to allow administrators to manage the An interface is necessary to allow administrators to query the
endpoints and software used in the EPCP. This interface SHOULD be repository and manage the endpoints and software used in the EPCP via
accessible either on or through (as in the case of a remotely hosted the posture manager. Similarly, an API is necessary to allow
interface) the posture manager. Using this interface, an authorized infrastructure endpoints and software access to the information
user or administrator SHOULD be able to: 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 Query the repository
o Send commands to the posture collection managers, requesting o Send commands to the posture collection managers, requesting
information from the associated posture collection engines information from the associated posture collection engines
residing on endpoints residing on endpoints
o Update the policy that resides on the posture manager o Establish and update the policy that resides on the posture
manager
An API is necessary to allow infrastructure endpoints and software
access to the information stored in the repository. Using this API,
an authorized endpoint SHOULD be able to:
o Query the repository
7. EPCP Use Cases 7. EPCP Use Cases
The following sections describe the different use cases supported by The following sections describe the different use cases supported by
the EPCP. the EPCP.
7.1. Hardware Asset Management 7.1. Hardware Asset Management
Using the administrative interface on the posture manager, an Using the administrative interface on the posture manager, an
authorized user can learn: authorized user can learn:
skipping to change at page 22, line 43 skipping to change at page 22, line 29
information can also drive other use cases such as: information can also drive other use cases such as:
o vulnerability management: knowing what software is installed o vulnerability management: knowing what software is installed
supports the ability to determine which endpoints contain supports the ability to determine which endpoints contain
vulnerable software and need to be patched. vulnerable software and need to be patched.
o configuration management: knowing which security controls need to o configuration management: knowing which security controls need to
be applied to harden installed software and better protect be applied to harden installed software and better protect
endpoints. endpoints.
7.3. Vulnerability Searches 7.3. Vulnerability Management
The administrative interface also provides the ability for authorized The administrative interface also provides the ability for authorized
users or infrastructure to locate endpoints running software for users or infrastructure to locate endpoints running software for
which vulnerabilities have been announced. Because of which vulnerabilities have been announced. Because of
1. the unique IDs assigned to each endpoint; and 1. the unique IDs assigned to each endpoint; and
2. the rich application data provided in the endpoints' posture 2. the rich application data provided in the endpoints' posture
information, information,
skipping to change at page 28, line 45 skipping to change at page 28, line 45
vulnerable endpoints by taking some follow-up action such as removing vulnerable endpoints by taking some follow-up action such as removing
it from the network, quarantining it, or updating the vulnerable it from the network, quarantining it, or updating the vulnerable
software. software.
10. Future Work 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 NETMOD 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.
o Examine the integration of [I-D.ietf-mile-xmpp-grid]. o Examine the integration of [I-D.ietf-mile-xmpp-grid].
o Define a standard interface and API for interacting with the o Define a standard interface and API for interacting with the
repository. Requirements to consider include: creating a secure repository. Requirements to consider include: creating a secure
channel between a publisher and the repository, creating a secure channel between a publisher and the repository, creating a secure
channel between a subscriber and the repository, and the types of channel between a subscriber and the repository, and the types of
skipping to change at page 31, line 7 skipping to change at page 31, line 7
12. IANA Considerations 12. 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 13. Security Considerations
The EPCP offers substantial improvements in endpoint security, as This Security Considerations section includes an analysis of the
evidenced by the Australian Defense Signals Directorate's analysis attacks that may be mounted against systems that implement the EPCP
that 85% of targeted cyber intrusions can be prevented through (Section 13.1) and the countermeasures that may be used to prevent or
application whitelisting, patching applications and operating mitigate these attacks (Section 13.2). Overall, a substantial
systems, and using the latest versions of applications. [DSD] reduction in cyber risk can be achieved.
Despite these gains, some security risks continue to exist and must
be considered.
To ensure that these benefits and risks are properly understood, this
Security Considerations section includes an analysis of the benefits
provided by the EPCP (Section 13.1), the attacks that may be mounted
against systems that implement the EPCP (Section 13.2), and the
countermeasures that may be used to prevent or mitigate these attacks
(Section 13.3). Overall, a substantial reduction in cyber risk can
be achieved.
13.1. Security Benefits of Endpoint Posture Collection Profile
Security weaknesses of the components for this profile should be
considered in light of the practical considerations that must be
addressed to have a viable solution.
Posture assessment has two parts: assessment and follow-up actions.
The point of posture assessment is to ensure that authorized users
are using authorized software configured to be as resilient as
possible against an attack.
Posture assessment answers the question whether the endpoint is
healthy. Our goal for posture assessment is to make it harder for an
adversary to execute code on one of our endpoints. This profile
represents an important first step in reaching that goal. If we keep
our endpoints healthier, we are able to prevent more attacks on our
endpoints and thus on our information systems.
The goal of EPCP is to address posture assessment in stages. Stage 1
is the ability to ascertain whether all endpoints are authorized and
whether all applications are authorized and up to date. Stage 2 will
attempt to address the harder problem of whether all software is
configured safely. Eventually, the goal is to also address
remediation which is currently out-of-scope for the SACM WG; that
presents a far greater security challenge than reporting, since
remediation implies the ability of a remote party to modify software
or its settings on endpoints.
A second security consideration is how to gain visibility over every
type of endpoint and every piece of software installed on the
endpoint. This is a problem of scaling and observation. A solution
is needed that can report from every type of endpoint. All software
on the endpoint has to be discovered. Information about the software
has to be up to date and accurate. The information that is
discovered has to be reported in a consistent format, so
administrators do not have to squander time deciphering proprietary
systems and the information can be made readily useful for other
security automation purposes.
EPCP is based on a model of a standards-based schema, a standards-
based set of protocols and interfaces, and the existence of an
oversight group, the IETF, that can update the data models and
protocols to meet new use cases and security issues that may be
discovered.
The data elements in the schema determine what work can be done
consistently for every endpoint and every piece of software. How the
data gets populated is an important consideration. EPCP leverages
the SWID tags from ISO 19770-2 because the tag originates with a
single authoritative source, the application vendor itself.
Moreover, there is a natural incentive for the vendor to create this
content, since it makes it easier for enterprises and vendors to
track whether software is licensed. Practical considerations are
security considerations. A sustainable business model for obtaining
all the necessary content is a fundamental requirement.
The NEA implementation of EPCP is based on having a NEA client run on
an endpoint that publishes posture information to a server. The
advantages are easy to list. A platform vendor can implement its own
NEA client and have it be compatible with the NEA server from a
different vendor. The interfaces are layered on top of mature
protocols such as TLS. TLS is the protocol of choice for EPCP,
since:
o it has proven secure properties,
o it can be implemented on most types of endpoints,
o it allows the gathering of large amounts of information when a
endpoint is connected, and
o it enables use of a mechanism to ensure that the client is
authenticated (authorized) - a client certificate - which also
provides a consistent identifier.
Mature protocols that can be implemented on most types of endpoints
and a standards-based schema with a sustainable business model are
both critical security considerations for compliance.
Additionally, it is important to consider the future stages for EPCP
such as a posture assessment being followed up by some action (e.g.
remediation, alert, etc.). Ensuring that clients are taking
instructions only from authorized parties will be critical. Inasmuch
as it is practical, enterprises will want to use the same
infrastructure and investment in PKI to send those instructions to a
client.
Likewise, as more information with more value is gathered from
endpoints, we will also want to ensure that this information is only
released to authorized applications and parties. For the next stage
of EPCP, SACM may want to define an interface on the repository that
can be queried by other security automation applications to make it
easier to detect attacks and for other security automation
applications. This interface has to be standards-based for
enterprises to reap the benefits of innovation that can be achieved
by making the enterprise's data available to other tools and
services.
13.2. Threat Model 13.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.3) describes countermeasures. (Section 13.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: more detail in the technical specifications: [RFC8412], [IF-IMC],
[I-D.ietf-sacm-nea-swima-patnc], [IF-IMC], [RFC5793], [RFC5793], [Server-Discovery], [RFC6876], [IF-IMV].
[Server-Discovery], [RFC6876], [IF-IMV].
13.2.1. Endpoint Attacks 13.1.1. Endpoint Attacks
While the EPCP provides substantial improvements in endpoint security While the EPCP provides substantial improvements in endpoint
as described in Section 13.1, a certain percentage of endpoints will security, endpoints can still be compromised. For this reason, all
always get compromised. For this reason, all parties must regard parties must regard data coming from endpoints as potentially
data coming from endpoints as potentially unreliable or even unreliable or even malicious. An analogy can be drawn with human
malicious. An analogy can be drawn with human testimony in an testimony in an investigation or trial. Human testimony is essential
investigation or trial. Human testimony is essential but must be but must be regarded with suspicion.
regarded with suspicion.
o Compromise of endpoint: A compromised endpoint may report false o Compromise of endpoint: A compromised endpoint may report false
information to confuse or even provide maliciously crafted information to confuse or even provide maliciously crafted
information with a goal of infecting others. information with a goal of infecting others.
o Putting bad information in SWID directory: Even if an endpoint is o Putting bad information in SWID directory: Even if an endpoint is
not completely compromised, some of the software running on it may not completely compromised, some of the software running on it may
be unreliable or even malicious. This software, potentially be unreliable or even malicious. This software, potentially
including the SWID generation or discovery tool, or malicious including the SWID generation or discovery tool, or malicious
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.2.2. Network Attacks 13.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.2.3. Posture Manager Attacks 13.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.2.4. Repository Attacks 13.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 35, line 30 skipping to change at page 33, 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.3. Countermeasures 13.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.3.1. Countermeasures for Endpoint Attacks 13.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.3.2. Countermeasures for Network Attacks 13.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.3.3. Countermeasures for Posture Manager Attacks 13.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 a [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).
Physical security measures should be employed to prevent physical Physical security measures should be employed to prevent physical
attacks on posture managers. attacks on posture managers.
To ease detection of posture manager compromise should it occur, To ease detection of posture manager compromise, should it occur,
posture manager behavior should be monitored to detect unusual posture manager behavior should be monitored to detect unusual
behavior (such as a server reboot, unusual traffic patterns, or other behavior (such as a server reboot, unusual traffic patterns, or other
odd behavior). Endpoints should log and/or notify users and/or odd behavior). Endpoints should log and/or notify users and/or
administrators when peculiar posture manager behavior is detected. administrators when peculiar posture manager behavior is detected.
To aid forensic investigation, permanent read-only audit logs of To aid forensic investigation, permanent read-only audit logs of
security-relevant information pertaining to posture manager security-relevant information pertaining to posture manager
(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.3.4. Countermeasures for Repository Attacks 13.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 38, line 12 skipping to change at page 36, line 7
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 15. Change Log
15.1. -01 to -02 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. Addressed various comments from the SACM WG.
Added a section for the collection of posture information from Added a section for the collection of posture information from
network devices using standards from the NETMOD WG. network devices using standards from the NETMOD WG.
Updated EPCP component diagrams so they were not specific to a NEA- Updated EPCP component diagrams so they were not specific to a NEA-
based implementation. based implementation.
Updated EPCP NEA example diagrams to reflect all the components in Updated EPCP NEA example diagrams to reflect all the components in
the NEA architecture. the NEA architecture.
15.2. -00 to -01 15.3. -00 to -01
There are no textual changes associated with this revision. This There are no textual changes associated with this revision. This
revision simply reflects a resubmission of the document so that it revision simply reflects a resubmission of the document so that it
remains in active status. remains in active status.
15.3. -01 to -02 15.4. -01 to -02
Added references to the Software Inventory Message and Attributes Added references to the Software Inventory Message and Attributes
(SWIMA) for PA-TNC I-D. (SWIMA) for PA-TNC I-D.
Replaced references to PC-TNC with IF-IMC. Replaced references to PC-TNC with IF-IMC.
Removed erroneous hyphens from a couple of section titles. Removed erroneous hyphens from a couple of section titles.
Made a few minor editorial changes. Made a few minor editorial changes.
15.4. -02 to -00 15.5. -02 to -00
Draft adopted by IETF SACM WG. Draft adopted by IETF SACM WG.
15.5. -00 to -01 15.6. -00 to -01
Significant edits to up-level the draft to describe SACM collection Significant edits to up-level the draft to describe SACM collection
over multiple different protocols. over multiple different protocols.
Replaced references to SANS with CIS. Replaced references to SANS with CIS.
Made other minor editorial changes. Made other minor editorial changes.
16. References 16. References
16.1. Informative References 16.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
Endpoint Compliance Profile, Version 1.10", December 2014.
[IEEE-802-1ar] [IEEE-802-1ar]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
802.1ar", December 2009. 802.1ar", December 2009.
[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
skipping to change at page 40, line 5 skipping to change at page 38, line 33
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-
notifications-13 (work in progress), June 2018. notifications-13 (work in progress), June 2018.
[I-D.ietf-netconf-yang-push] [I-D.ietf-netconf-yang-push]
Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-
Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore
Subscription", draft-ietf-netconf-yang-push-12 (work in Subscription", draft-ietf-netconf-yang-push-12 (work in
progress), December 2017. progress), December 2017.
[I-D.ietf-sacm-nea-swima-patnc]
Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and
J. Fitzgerald-McKay, "Software Inventory Message and
Attributes (SWIMA) for PA-TNC", draft-ietf-sacm-nea-swima-
patnc-01 (work in progress), September 2017.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., and N. Cam- Waltermire, D., Montville, A., Harrington, D., and N. Cam-
Winget, "Terminology for Security Assessment", draft-ietf- Winget, "Terminology for Security Assessment", draft-ietf-
sacm-terminology-05 (work in progress), August 2014. sacm-terminology-05 (work in progress), August 2014.
[IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC
IF-IMC, Version 1.3", February 2013. IF-IMC, Version 1.3", February 2013.
[IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC
IF-IMV, Version 1.4", December 2014. IF-IMV, Version 1.4", December 2014.
skipping to change at page 41, line 28 skipping to change at page 39, line 47
<https://www.rfc-editor.org/info/rfc7632>. <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
J. Fitzgerald-McKay, "Software Inventory Message and
Attributes (SWIMA) for PA-TNC", RFC 8412,
DOI 10.17487/RFC8412, July 2018,
<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.
Authors' Addresses Authors' Addresses
 End of changes. 57 change blocks. 
228 lines changed or deleted 149 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/