Internet DRAFT - draft-shah-sacm-tnc-architecture
draft-shah-sacm-tnc-architecture
Internet Draft A. Shah
Intended status: Informational Microsoft
Expires: October 2014 L. Lorenzin
Juniper Networks
April 21, 2014
SACM Architecture Based on TNC Standards
draft-shah-sacm-tnc-architecture-00.txt
Abstract
The Security Automation and Continuous Monitoring (SACM) Working
Group aims to develop open standards for managing endpoint posture
assessment. This document shows how the Trusted Network Connect
standards can be used to meet this goal.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 21, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Shah, et al. Expires October 21, 2014 [Page 1]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
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.
Table of Contents
1. Introduction...................................................2
1.1. Offering TCG Standards to IETF............................3
1.2. TNC Architecture Benefits for SACM........................3
1.3. Terminology...............................................4
2. TNC Architecture Overview......................................4
2.1. Endpoint Assessment Standards.............................4
2.2. Security Automation Standards.............................5
2.3. TNC Architecture in Detail................................5
2.4. Flexibility of the TNC architecture.......................7
3. SACM Architecture Based on TNC Architecture....................8
4. Use Case Walkthrough...........................................9
5. Security Considerations.......................................11
6. Privacy Considerations........................................11
7. IANA Considerations...........................................11
8. References....................................................11
8.1. Informative References...................................11
9. Acknowledgments...............................................12
1. Introduction
Trusted Network Connect (TNC) is a vendor-neutral open architecture
[10] for network security developed by the Trusted Computing Group
(TCG). TNC standards integrate security components across the
endpoint, network, and servers into an intelligent, responsive,
coordinated defense. The TNC standards have been widely adopted by
vendors, customers, and standards groups such as the IETF.
This document describes the TNC standards and proposes a SACM
architecture that builds on the TNC standards to allow a wide
variety of options for endpoint assessment, extending beyond the
existing TNC standards and permitting many future enhancements.
The TNC technologies based SACM architecture addresses most if not
all of the current SACM use cases that are under consideration.
Shah, et al. Expires October 21, 2014 [Page 2]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
1.1. Offering TCG Standards to IETF
The Trusted Computing Group (TCG) has a long track record of
offering its standards to IETF for standardization with no strings
attached. If the SACM working group decides that some or all of the
TNC standards would be useful, the TCG will almost certainly be
happy to donate them to the IETF without any restrictions (as it has
done in the past with the TNC standards that were adopted by the NEA
working group and adapted into Standards Track RFCs).
1.2. TNC Architecture Benefits for SACM
o TCG TNC standards have a proven track record of delivering
interoperable solutions to address endpoint, network, and server
security. Products based on TNC standards have been shipping
since 2005. There are many open-source implementations as well.
o TNC standards are widely deployed in real production scenarios. A
wide range of customers across many sectors (Government,
Healthcare, Finance, Retail and Education, among others) are
benefitting from interoperable security solutions based on TNC
standards.
o As mentioned before, TCG has a longstanding relationship with
IETF. TNC standards were submitted and accepted into the IETF NEA
standards in the past. This document extends the existing NEA
architecture to include security automation, a core building
block for SACM Use Cases.
o TNC standards are completely vendor-neutral. TNC based solutions
leverage existing network infrastructure in a production
environment which would also be an important consideration for
SACM.
o TNC standards are flexible. They support a broad range of
assessment options (identity, health, behavior, and location;
hardware-based & software-based security; and pre-admission &
post-admission evaluation and monitoring). TNC standards also
accommodate rapid change and can adapt to the evolving security
landscape.
o TNC standards can and do easily integrate with other standards
both existing and emerging, e.g., SCAP and SWID Tags (ISO 19770-
2).
Shah, et al. Expires October 21, 2014 [Page 3]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
1.3. Terminology
For historical reasons, TCG and IETF often have different names for
the same standard (e.g. TCG's IF-M = IETF's PA-TNC). Because the TNC
standards are a superset of the IETF NEA standards, this document
uses the TCG names. If the SACM working group decides to adopt some
of the TNC standards, maybe we can come up with a way to avoid these
duplicate names in the future.
2. TNC Architecture Overview
This section describes the TNC standards and architecture.
2.1. Endpoint Assessment Standards
The TNC endpoint assessment protocols [1] [2] [3] [4] have been
adopted as the IETF NEA RFCs [16] [17] [18] [19]. These protocols
allow an endpoint assessment server to query an endpoint for posture
information and even to send remediation instructions to the
endpoint, all in a standard, vendor-neutral manner.
The NEA standards are highly relevant to the SACM use cases. They
directly address the use cases for Security Automation Data,
Endpoint Identification and Assessment Planning, Endpoint Posture
Collection, Posture Evaluation and Database Mining by providing a
standard way for endpoints to be queried regarding their security
posture and configuration.
TCG has extended the NEA standards using the built-in extension
points to support the conveyance of SCAP content [9] and SWID tags
[8] between the endpoint and the posture server. Further, TCG has
published other documents that supplement the NEA standards by
defining standard methods for an endpoint to discover the endpoint
assessment server and verify that it is trustworthy [13], place TNC
assessment results in SAML assertions for federated operation [14],
use hardware to verify endpoint posture and prevent lying endpoints
[15], etc.
Of course, some endpoints don't support the NEA standards. For those
endpoints, other assessment methods must be used: proprietary
agents, commands sent via SSH or other mechanisms, fingerprinting,
behavior monitoring, and the like. The TNC architecture integrates
these methods with the IF-MAP standards [5] [6], as described in
section 2.2 below.
Shah, et al. Expires October 21, 2014 [Page 4]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
2.2. Security Automation Standards
Traditional information security architectures have separate silos
for endpoint security, network security, server security, physical
security, etc. The TNC architecture enables the integration of all
an enterprise's security systems through a standard known as IF-MAP.
IF-MAP [5] is a standard client-server protocol for publishing
security-relevant information to a database server known as the
Metadata Access Point or MAP. In addition to the standard database
operations (add, delete, update, and query), IF-MAP also supports
publish and subscribe operations. This allows authorized enterprise
security systems to share information rapidly with all interested
parties receiving a notification whenever relevant data is changed.
The data stored in the MAP (known as ''metadata'') is XML documents.
Each piece of metadata is tagged with a metadata type that indicates
the meaning of the metadata and identifies an XML schema for it. Of
course, the set of metadata types is easily extensible. Each MAP
client ignores metadata that it doesn't understand.
The MAP is a graph database, not a relational database. Metadata can
be associated with an identifier (e.g. the email address
''shanna@juniper.net'') or with a link between two identifiers (e.g.
the link between MAC address 00:11:22:33:44:55 and IPv4 address
192.0.2.1). At any point in time, the MAP represents the latest and
best knowledge available about the security state of the network.
The IF-MAP standards are designed to ensure adaptability for
changing networking environments, and the IF-MAP environment is
continually evolving to meet the requirements of new network
security use cases such as integrated physical and logical access
control, Industrial Control Systems (ICS) security, and telemetry
sharing for network threat detection.
2.3. TNC Architecture in Detail
Figure 1 provides a conceptual view of the current TNC Architecture.
Shah, et al. Expires October 21, 2014 [Page 5]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
+----+ +----+ +---+ +------+
|IMC |<--- IF-M ---->|IMV |-+ | |<-IF-MAP->|Admin |
+----+ +----+ | | | +------+
| | | | |
+----+ +----+ | | | +------+
|TNCC|<- IF-TNCCS -->|TNCS|-+ | |<-IF-MAP->|Sensor|
+----+ +----+ | |MAP| +------+
| | |<-IF-MAP->| |
+----+<--- IF-T ---->+----+ | | | +------+
| | | | | | |<-IF-MAP->|Other |
|NAR |+---+ |NAA |-+ | | +------+
| ||PEP|<-IF-PEP->| | | |
+----++---+ +----+ +---+
AR PEP PDP MAP MAP Clients
Figure 1 TNC Architecture
First, we'll review the logical components. The leftmost column is
an endpoint, called an Access Requestor (AR), that supports the
TNC/NEA protocols. The endpoint contains several software modules
known as the Integrity Measurement Collector (IMC), TNC Client
(TNCC), and Network Access Requestor (NAR). The next column is a
Policy Enforcement Point (PEP) such as an 802.1X switch or a
firewall. The third column is a Policy Decision Point (PDP), which
assesses endpoint posture and decides what access should be granted.
The PDP contains several software components known as the Integrity
Measurement Verifier (IMV), TNC Server (TNCS), and Network Access
Authority (NAA). In the fourth column is the Metadata Access Point
(MAP). And the last column is a variety of MAP clients.
As usual with architecture, logical components may be eliminated if
not needed, replicated for scaling, or co-hosted on a single virtual
or physical machine for efficiency.
Now we'll move on to the interfaces. As you can see, the TNC
architecture has many standardized interfaces whose names have the
form IF-*. Every interface in the architecture has a defined
standard. In fact, some of the interfaces between the software
modules on the endpoint and PDP have API standards but those have
been omitted since the IETF is not generally concerned with APIs.
The client-server endpoint assessment protocols standardized by the
NEA working group and mentioned in section 2.1 are IF-M [1], IF-
TNCCS [2], and IF-T [3] [4]. These form a layered stack with IF-T
providing several transport options, IF-TNCCS managing the
Shah, et al. Expires October 21, 2014 [Page 6]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
assessment session, and IF-M defining an extensible set of endpoint
posture messages.
When the PDP wants to send commands to the PEP (e.g. quarantine this
endpoint), it uses IF-PEP (typically RADIUS [7]).
MAP clients such as the PDP, sensors, and administrative clients use
IF-MAP to talk to the MAP. The software components on the PDP can
store information such as endpoint posture assessments or user and
endpoint identity into the MAP database. Administrative clients can
query this information or run reports. Sensors can store information
gathered from the network such as malicious behavior alerts. If the
PDP subscribed to alerts on endpoints it admitted to the network,
the MAP will notify it when such an alert is received and the PDP
can respond by blocking the endpoint or whatever response is needed.
One misconception about the TNC Architecture is that it requires all
endpoints to support the TNC/NEA protocols. That's not true. TCG's
Clientless Endpoint Support Profile [12] describes how to handle
such clients. They can be placed on the network and then scanned or
monitored by a device profiler (a kind of Sensor) to decide what
access they should get.
Another misconception about the TNC architecture is that it's only
for Network Access Control. That's not true either. The PEP can be
omitted from the system. In that case, all endpoints are admitted to
the network. Endpoints can be assessed after they join the network,
as described in the Endpoint Compliance Profile [11]. Assessment
results may simply be stored for later consideration or used to
drive actions such increased scrutiny or mitigation (e.g. blocking
traffic to the endpoint that could exploit a discovered
vulnerability).
2.4. Flexibility of the TNC architecture
The open and extensible interfaces provided by the TNC architecture
permit new components to be plugged in easily without changing the
rest of the system. For example, an anomaly detection system can
notify other components when an endpoint's behavior is abnormal.
As a result, the TNC architecture itself is quite flexible. For
example, the TNC architecture could be extended to include a
Configuration Management Database (CMDB), as described in the
Endpoint Compliance Profile [11]. A CMDB is a store of current and
historical information, such as posture information and
configuration, about endpoints that have previously been assessed.
It can be queried to answer questions about specific endpoints, such
Shah, et al. Expires October 21, 2014 [Page 7]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
as ''Find all endpoints that ever had MyFozz 4.3.29a installed'', or
to generate compliance reports.
3. SACM Architecture Based on TNC Architecture
Clearly, the TNC architecture is highly relevant to the SACM problem
space. Both TNC and SACM include endpoint assessment and add more to
it. But how should the TNC architecture be applied to SACM?
This section proposes a SACM architecture that builds on the TNC
standards to allow a wide variety of options for policy authoring,
endpoint assessment, and security automation. This architecture
extends beyond the existing TNC standards and is flexible enough to
permit many future enhancements.
+----------+ +-----+ +-------+
| Endpoint |--+ | MAP | +--| Admin |
|Assessment| | +-----+ | +-------+
+----------+ | ^ |
| | IF-MAP | +--------+
+----------+ | | +--| Sensor |
| Analysis |--+-------+----------+----------+ +--------+
+----------+ | | | |
| | IF-CMDB | IF-CRDB | +--------+
+----------+ | v v +--| Other |
| Response |--+ +------+ +------+ +--------+
+----------+ | CMDB | | CRDB |
+------+ +------+
Database Clients Databases Database Clients
Figure 2 SACM Architecture Based on TNC
The fundamental basis for this architecture is the TNC concept of
multiple products sharing information, such as historical
information via the CMDB and up-to-the-minute notifications via the
MAP. A Content Repository Database (CRDB) is also added to provide a
location for storing and retrieving other content such as
configuration checklists, with an IF-CRDB protocol to provide a
standard way to access the CRDB.
One of the reasons for having separate interfaces for the CMDB and
CRDB is to allow querying for different types of information on
endpoints. In addition, having a lot of data in one database to sort
through may not be an ideal architectural choice. Using the inherent
flexibility of the TNC architecture, therefore, both the CMDB and
CRDB databases and interfaces are proposed in this architecture.
Shah, et al. Expires October 21, 2014 [Page 8]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
The TNC/NEA Endpoint Assessment protocols are not eliminated. They
can be used by the Endpoint Assessment component to interrogate
devices that support them. However, other Endpoint Assessment
components such as device profiling can be used instead of or in
addition to the TNC/NEA protocols.
The Analysis and Response components in this architecture can be
built into the Endpoint Assessment component for flexibility, but
they can also be separated out, permitting innovation in these
important areas.
4. Use Case Walkthrough
This section looks at each of the current SACM use cases to see how
the proposed SACM architecture based on TNC meets their requirements
at a high level. This section does not dig deeper into specifics of
implementation by use case as yet.
4.1 Define, Publish, Query and Retrieve Security Automation Data
This SACM use case has two distinct types of data -- attribute data
to be collected from endpoints, and guidance data (policy) on what
should be collected from the endpoints. In the proposed
architecture, the CMDB offers the functionality for storing,
publishing, querying, and retrieving attribute data collected from
endpoints. Similarly, the CRDB provides the ability to define,
publish, query, and retrieve policy data (expected configuration of
endpoints). The processing artifacts (reports) are currently not
accounted for in the proposed SACM architecture; however, the
proposed CRDB extension would be utilized for reporting purposes.
Coverage of this use case: With the addition of the CMDB and CRDB
components to the flexible extensible TNC architecture (as detailed
elsewhere in this document), the proposed SACM architecture
completely covers this use case.
4.2 Endpoint Identification and Assessment Planning
TNC interfaces directly apply to this use case: discovery of
endpoints, policy on desired state of the endpoints, and then
identifying what attributes are to be collected to evaluate
endpoints against the desired state. The proposed SACM architecture
allows for various mechanisms to identify endpoints on the network,
for example, sensors, policy decision points, network equipment, and
servers.
Coverage of this use case: complete.
Shah, et al. Expires October 21, 2014 [Page 9]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
4.3 Endpoint Posture Attribute Value Collection
One of the primary applications of the TNC architecture is endpoint
attribute collection - this SACM use case is wholly served by the
proposed SACM architecture based on TNC. Both the initial collection
of endpoint posture information and subsequent collection of
incremental change in posture are accomplished well with the use of
TNC technologies.
As detailed in section 2.3 (TNC Architecture in Detail), the TNC
architecture handles both endpoints that have native NEA/TNC support
and endpoints that do not. TCG's Clientless Endpoint Support Profile
describes how to handle clients that don't support the NEA
standards. They can be placed on the network and then scanned or
monitored by a device profiler (a kind of Sensor) to decide what
access they should get. The MAP and CMDB can then store attributes
about the endpoint posture and provide that information for endpoint
evaluation even though clientless endpoints may not have support for
TNC client/server protocols.
Coverage of this use case: complete.
4.4 Posture Evaluation
There are three building blocks mentioned as part of this use case:
Posture Attribute Value Query, Evaluation Guidance Acquisition and
Posture Attribute Evaluation.
The Posture Attribute Value Query is used to figure out what
endpoint attributes already exist. Then, the guidance for evaluation
of those attributes is used to determine what the policies require.
The final part of this use case details the actual evaluation based
on the above two factors.
The proposed SACM architecture enables all these functions. A policy
server uses the attributes it collects from the CMDB or directly
from the endpoint. The policy server also gathers the policies from
the CRDB. Finally, the policy server does the actual evaluation
based on these two factors.
Coverage of this use case: complete.
4.5 Mining the Database
The proposed SACM architecture, leveraging the MAP component and the
addition of the CMDB component as described in the Endpoint
Compliance profile, enables querying collected and stored endpoint
Shah, et al. Expires October 21, 2014 [Page 10]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
information for the purpose of this use case. The TNC group has been
working on incorporating Software ID (SWID) messages into IF-M [8]
and incorporating ISO 19770-2 with TNC endpoint and server
components to collect, store and query endpoint software
information.
Coverage of this use case: almost complete.
5. Security Considerations
The specification for each TNC interface and profile includes its
own Security Considerations section that analyzes the threats and
countermeasures relevant to that document. The TNC Architecture
includes an overall security analysis.
6. Privacy Considerations
The TNC Architecture and IF-MAP specifications include analyses of
privacy considerations.
7. IANA Considerations
There are no IANA considerations for this document.
8. References
8.1. Informative References
[1] Trusted Computing Group, TNC IF-M, Specification Version 1.0,
April 2014.
[2] Trusted Computing Group, TNC IF-TNCCS: TLV Binding,
Specification Version 2.0, April 2014.
[3] Trusted Computing Group, TNC IF-T: Protocol Bindings for
Tunneled EAP Methods, Specification Version 2.0, April 2014.
[4] Trusted Computing Group, TNC IF-T: Binding to TLS,
Specification Version 2.0, December 2012.
[5] Trusted Computing Group, TNC IF-MAP Binding for SOAP,
Specification Version 2.2, March 2014.
[6] Trusted Computing Group, TNC IF-MAP Metadata for Network
Security, Specification Version 1.1, May 2012.
Shah, et al. Expires October 21, 2014 [Page 11]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
[7] Trusted Computing Group, TNC IF-PEP: Protocol Bindings for
RADIUS, Specification Version 1.1, February 2007.
[8] Trusted Computing Group, SWID Message and Attributes for IF-M,
Specification Version 1.0 Revision 14, August 2013.
[9] Trusted Computing Group, SCAP Messages for IF-M, Specification
Version 1.0 Revision 17, October 2012.
[10] Trusted Computing Group, TNC Architecture, Specification
Version 1.5, May 2012.
[11] Trusted Computing Group, TNC Endpoint Compliance Profile,
Specification Version 1.0 Revision 9, August 2013.
[12] Trusted Computing Group, TNC Clientless Endpoint Support
Profile, Specification Version 1.0, May 2009.
[13] Trusted Computing Group, TNC PDP Discovery and Validation,
Specification Version 1.0 Revision 9, August 2013.
[14] Trusted Computing Group, Federated TNC, Specification Version
1.0, May 2009.
[15] Trusted Computing Group, PTS Protocol: Binding to TNC IF-M,
Specification Version 1.0, August 2011.
[16] Sangster, P. and K. Narayan, PA-TNC: A Posture Attribute
Protocol (PA) Compatible with TNC, IETF RFC 5792, March 2010.
[17] Sahita, R., Hanna, S., Hurst, R., and K. Narayanan, PB-TNC: A
Posture Broker (PB) Protocol Compatible with Trusted Network
Connect (TNC), IETF RFC 5793, March 2010.
[18] Sangster P., Cam-Winget N., Salowey J., PT-TLS: A TCP-based
Posture Transport (PT) Protocol, RFC 6876, February 2013.
[19] Cam-Winget, N. and P. Sangster, PT-EAP: Posture Transport (PT)
Protocol For Extensible Authentication Protocol (EAP) Tunnel
Methods, RFC 7171, April 2014.
9. Acknowledgments
The authors would like to acknowledge the contributions of the
following people: Beth Abramowitz, Henk Birkholz, Nancy Cam-Winget,
Jessica Fitzgerald-McKay, Steve Hanna, Cliff Kahn, Ira McDonald,
Scott Pope, Charles Schmidt, Steve Venema, and Dave Waltermire.
Shah, et al. Expires October 21, 2014 [Page 12]
Internet-Draft SACM Architecture Based on TNC Standards April 2014
Authors' Addresses
Atul Shah
Microsoft Corporation
One Microsoft Way
112/2242
Redmond, WA 98052
Email: atuls@microsoft.com
Lisa Lorenzin
Juniper Networks, Inc.
3614 Laurel Creek Way
Durham, NC 27712 USA
Email: llorenzin@juniper.net
Shah, et al. Expires October 21, 2014 [Page 13]
