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]