SACM J. Fitzgerald-McKay, Ed.
Internet-Draft Department of Defense
Intended status: Informational November 16, 2015
Expires: May 19, 2016
Endpoint Compliance Standard
draft-fitzgeraldmckay-sacm-endpointcompliance-01
Abstract
This document describes how published standards can be used to meet
SACM endpoint compliance use cases.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Fitzgerald-McKay Expires May 19, 2016 [Page 1]
Internet-Draft Endpoint Compliance Standard November 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Focus on a Way Forward . . . . . . . . . . . . . . . . . . . 3
3. Existing Protocols and Schema for Internal Data Collection . 3
4. An Architecture for Internal Data Collection . . . . . . . . 3
5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Informative References . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This document proposes leveraging the Network Enterprise Assessment
(NEA) architecture [RFC5209], work from the Trusted Computing Group's
(TCG) Trusted Network Connect (TNC) Work Group, and the ISO Software
Identification (SWID) Tag Standard [ISO.19770-2] as a starting place
for building an endpoint compliance solution.
The SACM Information Model [I-D.ietf-sacm-information-model] defines
an internal collector to gather posture attributes from an endpoint.
These posture attributes must be communicated to a server that can
store the attributes in a data repository. This repository of
endpoint identities and attributes is where work can take place to
validate the attributes.
The NEA architecture was originally designed for access control use
cases. Using the TLS-based Posture Transport Protocol (PT-TLS)
[RFC6876], the same architecture can be reused to collect large
amounts of compliance data. Work from the TCG's TNC work group
expands on this, enabling standardized communication of SWID Tags to
a NEA server. Based on these standards, SACM can define actions that
can be performed on endpoint posture attributes to ensure compliance,
including:
1. ensuring that all network-connected endpoints are known, and
authorized to access network resources;
2. confirming that only authorized applications are running on the
endpoint;
3. knowing that all applications are patched and up-to-date; and,
4. ensuring that applications with known vulnerabilities can be
located and patched.
Fitzgerald-McKay Expires May 19, 2016 [Page 2]
Internet-Draft Endpoint Compliance Standard November 2015
2. Focus on a Way Forward
In light of SACM's new focus and the need for quick wins that get
SACM closer to its goals, we would like to open discussion on
standardizing the collection, communication and evaluation of
endpoint software load reports. This meets a number of SACM use
cases [I-D.ietf-sacm-use-cases]. Many of these standards already
exist and are captured in the TCG's Endpoint Compliance Profile
[Endpoint-Compliance-Profile]. Implementations are also publically
available, such as the strongSwan TNC implementation [strongSwan].
3. Existing Protocols and Schema for Internal Data Collection
The Trusted Computing Group's TNC Work Group has additional standards
that could be incorporated into the NEA architecture to specify how
internal data collection can be used for security automation. The
Integrity Measurement Collector Interface (IF-IMC) [IF-IMC] could be
used to describe a standardized interface between a posture collector
and a NEA client on an endpoint. Likewise, the Integrity Measurement
Verifier Interface (IF-IMV) [IF-IMV] could provide an interface
between a posture validator and a NEA Server. Both of these
standards are critical additions to the NEA architecture that improve
the security and interoperability of the messaging between
components.
The SACM Information Model calls out a number of components that tie
directly to the existing NEA architecture. The Posture Collector
described by NEA [RFC5209] is a SACM Internal Collector, and the
Posture Validator is a SACM evaluator. The PT-TLS protocol
standardized by NEA addresses the SACM Information Model's security
considerations by providing an authenticated, confidential channel
through which posture attribute-value pairs can be communicated, with
assurance that the communicated data has not been modified.
In recent years, TNC has worked to specify SWID Message and
Attributes for IF-M [SWID-Messages]. This standard uses NEA and TCG
architectural elements to collect and validate software identities
using the ISO Software Identification Tag Standard. It also enables
a NEA server to automate the storage of SWID tags for later
evaluation, separating collection and evaluation roles. Server
Discovery and Validation [Server-Discovery] ensures that the endpoint
only communicates with trusted servers.
4. An Architecture for Internal Data Collection
Using these standards, we can begin to build an architecture for
internal data collection that addresses SACM's use cases. An
endpoint is connected to the network, and using the Server Discovery
Fitzgerald-McKay Expires May 19, 2016 [Page 3]
Internet-Draft Endpoint Compliance Standard November 2015
and Validation protocol, locates a trusted server, and connects to it
over PT-TLS. A SWID Collector gathers SWID tags from a directory on
the endpoint, and communicates them over IF-IMC to the Posture Broker
(PB) Client. The Posture Broker Client then communicates this data
to the Posture Transport Server via the Posture Broker Protocol
[RFC5793].
While NEA included validation capabilities on its server, SACM
requires the separation of collection and evaluation. Certain
features of Posture Attribute validators, such as the evaluation of
collected data against network policy or guidance, will be best
performed at the data repository. Other features, such as the
ability to request data from an endpoint, should remain on the
server. SACM will have to decide how to best separate these
function. For now, a SACM Server will work as a place holder for the
PB Server plus any functionality from the NEA Posture Validator that
the group chooses to retain on the server. The SACM Server will also
be responsible for storing collected data in a data repository, where
it will be made available to evaluators.
Endpoint Server
+------------------+ +------------------+
| | | |
| +--------------+ | | | Evaluators
| |SWID Collector| | | | +------------------+
| +--------------+ | | | Data Repository | +------------------+
| | | | | +-----------------+ | | +------------------+
| | IF-IMC | | | | | | | | |
| | | | | | | | | | |
| +--------------+ | | +--------------+ | | | | | | |
| | PB Client | | | | SACM Server +------------+ +------------+ |
| +--------------+ | | +--------------+ | | | | | | |
| | | | | | | | | | | |
| | PB | | | PB | | | +-+-| |
| | | | | | +-----------------+ +------------------+
| +--------------+ | | +--------------+ |
| | PT Client +-----------------+ PT Server | |
| +--------------+ | PT-TLS | +--------------+ |
| | | |
+------------------+ +------------------+
Figure 1
5. Future Work
This collection of standards provides a reasonable basis upon which
we can build a SACM solution that focuses on the applications that
are running on different types of endpoints, and the work that can be
Fitzgerald-McKay Expires May 19, 2016 [Page 4]
Internet-Draft Endpoint Compliance Standard November 2015
performed on this data when it is collected securely by an authorized
server and stored in an data repository. We intend, in the coming
months, to ask the TNC to submit these standards to SACM for
inclusion in our first version solution, as they meet our newly
scoped goals of collecting state information from a subset of
endpoint types.
More work is needed to build out the capabilities in this set of
standards. Agreeing to use them as a starting point will clarify our
work and help scope out future efforts.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
Each of the standards referenced in this internet draft contains its
own security considerations section. This internet draft does not
itself propose any new security considerations.
8. Informative References
[Endpoint-Compliance-Profile]
Trusted Computing Group, "TNC Endpoint Compliance Profile
Specification", December 2014.
[I-D.ietf-sacm-information-model]
Waltermire, D., Watson, K., Kahn, C., and L. Lorenzin,
"SACM Information Model", draft-ietf-sacm-information-
model-02 (work in progress), July 2015.
[I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-10 (work in progress), July 2015.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", draft-narten-iana-
considerations-rfc2434bis-09 (work in progress), March
2008.
[IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC
IF-IMC, Verion 1.3", February 2013.
[IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC
IF-IMV, Version 1.4", December 2014.
Fitzgerald-McKay Expires May 19, 2016 [Page 5]
Internet-Draft Endpoint Compliance Standard November 2015
[ISO.19770-2]
"Information technology -- Software asset management --
Part 2: Software identification tag", ISO/IEC 19770-2,
2009.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, DOI
10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793,
March 2010, <http://www.rfc-editor.org/info/rfc5793>.
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI
10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc6876>.
[Server-Discovery]
Trusted Computing Group, "DRAFT: TCG Trusted Network
Connect PDP Discovery and Validation, Version 1.0", August
2013.
[strongSwan]
strongSwan, "Trusted Network Connect (TNC) HOWTO", April
2015,
<https://wiki.strongswan.org/projects/strongswan/wiki/
TrustedNetworkConnect>.
[SWID-Messages]
Trusted Computing Group, "DRAFT: TCG Trusted Network
Connect SWID Message and Attributes for IF-M, Version
1.0", March 2015.
Author's Address
Fitzgerald-McKay Expires May 19, 2016 [Page 6]
Internet-Draft Endpoint Compliance Standard November 2015
Jessica Fitzgerald-McKay (editor)
Department of Defense
9800 Savage Road
Ft. Meade, Maryland
USA
Email: jmfitz2@nsa.gov
Fitzgerald-McKay Expires May 19, 2016 [Page 7]