Cisco TrustSec Deployed Across Enterprise Campus, Branch and Data Center Networks

Featuring research from

Software-defined segmentation with Cisco TrustSec

Introduction

Research From Gartner: Maturing Support for Cisco’s TrustSec Framework

TrustSec Summary

Recent Developments

Customer Case Study

Cisco Validated Designs

Issue 12

3

14

15 15 15

2

Introduction

Recent security breaches have drawn attention to the importance of minimizing the attack surface and have highlighted the significance of segmentation to restrict access to sensitive resources.

Many customers seeking to reduce exposure are turning to Cisco TrustSec to provide software-defined segmentation in campus and DC environments but also enable granular access controls for business partners, contractors, guests and employees.

We are delighted to be sharing a report on Cisco’s TrustSec Framework produced by Gartner in February 2013, followed by updates on how the solution has developed since then, including:

- Submissions to the IETF to open up the solution to other vendors

- Validation by VerizonBusiness, a PCI Qualified Security Assessor, of how Cisco TrustSec can be used to reduce the scope of PCI compliance

Links to the latest updates and case studies follow at the end of this document highlighting the extended TrustSec capabilities and platform support, now including:

- TrustSec capabilities released across Nexus 7000, 6000, 5600, 5500, 2000 and 1000v switches, in addition to Catalyst 6500, 4500, 3000 and 2960S/X switches, ISRG2 Routers, ASR1000 Routers, WLAN Controllers and ASA Next-Generation Firewalls

- Remote access VPN TrustSec capabilities are now available, allowing the solution to provide common policy entitlements for wired access, WLAN access and remote access.

These new capabilities are now being used by customers to provide:

• Data Center segmentation

• Campus and branch segmentation

• Much-simplified firewall rule administration

• BYOD access control

• Reduced scope of PCI compliance

• Effective controls to contain the ‘lateral movement’ of threats

Source: Cisco

3

Maturing Support for Cisco’s TrustSec Framework

Research From Gartner

Cisco’s Trusted Security framework is maturing with growing support across Cisco’s product lines. This document assesses the technical components, interoperability considerations, Cisco’s progress in implementing support across its product lines, and customer deployment experiences.

Gartner Foundational

This research is reviewed periodically for accuracy. It was last reviewed on 1 October 2014.

Summary of Findings

Bottom Line: Some organizations are now taking advantage of enhanced network security functions rolled out by Cisco over 2011 and 2012. Although the technology has matured and is more broadly supported across Cisco’s product lines, it still involves the use of some proprietary protocols that create challenges for enterprise customers with mixed vendor networks.

Context: There is a growing business requirement for guests, vendors, partners and employee-owned devices to have limited access to internal networks and specific IT systems that are hosted in virtualized internal data centers or with cloud providers. However, current zoning and access control mechanisms are based on the physical network’s topology and do not have the flexibility required.

Take-Aways:

• Cisco’s Trusted Security (TrustSec) framework is maturing and is now integrated in more Cisco product lines either with embedded hardware or through software support for compatibility protocols.

• Cisco’s Identity Services Engine (ISE) is a much-needed replacement for its Secure Access Control Server (ACS) and a key component of TrustSec. ISE provides critical authentication and policy services to support access control based on security group tags (SGTs), trusted security domains with device authentication, dynamic profiling of devices for 802.1X bypass, and dynamic access decisions that leverage security context and attributes.

• Access control lists (ACLs) that authorize users and devices to access data center resources

based on logical source and destination security groups are more flexible, are easier to maintain and reduce runtime overhead in the network’s switching fabric.

• A trusted network security domain leverages the Institute of Electrical and Electronics Engineers’ (IEEE’s) Media Access Control security (MACsec) standard and a Cisco-proprietary key exchange protocol to mutually authenticate network devices and optionally encrypt traffic between devices at each hop.

• Customer deployments start with 802.1X authentication at the access layer; the next steps focus on tactical deployments for special use cases, such as securing inter-data-center traffic.

• Enterprise customers often need assistance with their major 802.1X and TrustSec deployment projects, typically directly involving Cisco or a certified Cisco partner.

• Cisco’s vision for how Layer 2 networks and virtualized data centers will be secured is one of great potential operational and security benefit. But Cisco also needs to listen to its customers who want an open market, interoperability based on industry standards and a network security framework that adapts to include solutions from any network or network security vendor.

• Enterprise networks that include a mix of Cisco and non-Cisco devices need to proceed cautiously due to limited interoperability and Cisco’s strict control over partner access to its proprietary protocols.

Conclusion: Cisco is making clear progress on its Trusted Security framework and related product offerings, especially in its improved support for 802.1X-based identity, dynamic device profiling, diagnostic tools, training programs and an enhanced ISE. For mixed vendor networks, enterprise customers should avoid or confine use of proprietary SGTs and related controls to tactical use cases until Cisco makes progress toward standardization.

Analysis

Over much of the past decade, Cisco has tried a variety of strategies for expanding the role of

4

the network infrastructure in enforcing security controls based on user and device identity and endpoint system health scans, with mixed results. These strategies included:

• Cisco’s network access control (NAC) framework (2003-04)

• Identity-aware networking

• NAC Appliance (Clean Access) and NAC Profiler

• Trusted Security (TrustSec) 1.0 framework and Secure Access Control Server (ACS) 5.x (2008-10)

• TrustSec 2.0 and Identity Services Engine (ISE) as part of the Borderless Networks strategy and SecureX architecture:

• TrustSec 2.1 (July 2012 release)

• Cisco’s Unified Access Solution (October 2012)

• TrustSec 3.0 (late 2012 through 2013)

What’s Different This Time?Cisco’s earlier initiatives were well-intentioned but substantially underestimated the complexity of implementing protocol changes that touched almost every device in the network and required complementary changes across most Cisco product lines, as well as solutions from other network and security vendors. In particular, the requirement to establish device and user identity required organizations to implement 802.1X mechanisms on both wireless controllers and the wired network’s access layer switches. Even for large companies with teams of network and security experts, rolling out 802.1X, managing the exceptions and diagnosing problems proved to be difficult because few tools were available from Cisco, or elsewhere, to make those tasks easier.

Back in 2008, as described in “Cisco’s Strategy for Identity and Policy in the Network,” neither Cisco nor its customers were ready for TrustSec. Only the Nexus 7000 series of data center switches had the hardware support required, and the enhancements needed in Cisco’s Secure ACS authentication and policy server were spread over multiple product releases. It’s taken longer than predicted, but many of the missing pieces are now in place.

Cisco’s Commitment to TrustSec

With the many TrustSec-related announcements over 2011 and 2012 — including support in the

Catalyst 6500 series switches, the launch of and enhancements to Cisco’s ISE, initial phases of support in Cisco’s Adaptive Security Appliance (ASA) platform, and Cisco’s Unified Access solution strategy (October 2012) — it’s becoming much clearer that Cisco is committed to broadly supporting TrustSec’s architecture across all of its products, in one form or another.

A Broader Scope for TrustSec 2.x and 3.x

In its latest incarnations, TrustSec has a much broader scope than in its 1.0 origins. It’s not just about its innovative and proprietary model of logical network access control based on security group tags (SGTs); TrustSec as a framework incorporates extensive support for Institute of Electrical and Electronics Engineers (IEEE) standards-based 802.1X and MACsec, a Remote Authentication Dial-In User Service (RADIUS)-based identity and policy server, a system health policy evaluation and enforcement mechanism, dynamic profiling of devices that may not be 802.1X-capable, a mechanism for registering and provisioning guest access, related enhancements to Cisco’s Internetwork Operating System (IOS), a management and reporting interface, and a variety of diagnostic tools. In this document, references to TrustSec refer to the aggregated set of capabilities and generally not to any specific feature or tool. However, in discussions that relate to interoperability or standards, the use of the term TrustSec is restricted to Cisco’s use of proprietary mechanisms associated with its access control model based on security groups and other extensions to 802.1X that are not in synch with the latest release of this industry standard.

Cisco’s customers could choose to take advantage of only those capabilities of TrustSec that are both standards-based and interoperable with products supplied by other vendors. It’s also feasible to tactically leverage TrustSec to address specific security requirements in a portion of the network and to not embrace it as an architectural approach that has to span the entire enterprise network.

Cisco’s Unified Access Solution

Announced in early October 2012, Cisco’s Unified Access Solution provides a single management platform, Cisco Prime Infrastructure (r1.2), and a single policy system, Cisco ISE (r1.1.x), to unify access policy administration and enforcement across wired, wireless and VPN infrastructure. This announcement also extended TrustSec support to many of Cisco’s wireless access point and wireless controller products, as well as its Catalyst 3560-X and 3750-X switches. Support for Catalyst 4500E switches is planned for mid-2013.

5

Better Support for Customer Deployment Projects

From 2008 to 2012, Cisco worked closely with customers to better understand the obstacles and challenges they faced when deploying 802.1X and in early TrustSec projects. Based on these lessons, Cisco made improvements to its IOS software to support problematic situations, such as reimaging a new machine over the network (preboot execution environment [PXE] boot) or Wake-on-LAN (WOL) during maintenance. Cisco also developed better diagnostic tools for the customer and its own support teams and invested in developing training materials and a certification program for its channel partners and their support staffs.

Maturity and Completeness of the Solution

Until May 2011, the only switch product you could buy from Cisco that incorporated the hardware needed to tag Ethernet frames with SGTs was the Nexus 7000 series of data center switches. Since then, Cisco has announced the Catalyst 6500 E-series with its Supervisor Engine 2T feature, Nexus 5000 series support, and some models of the Catalyst 3000 series (3560-X and 3750-X) with the necessary hardware support for SGTs.

Several other Cisco products can leverage software to associate a role and an SGT with an Internet Protocol (IP) address, but they must use the TCP-based SGT eXchange Protocol (SXP) to communicate this IP-to-SGT binding information to a Cisco device that has hardware support for TrustSec. Shipping Cisco products that support SXP include:

• Aggregation Services Router (ASR) 1000 and Integrated Services Router (ISR) G2 series routers

• Catalyst 2960-S, 3x00, 37xx(E), 4500 (Sup6L-E or Sup6-E), 49xx and 6500E (Sup32, Sup720 and Sup720 VSS) series switches

• Nexus 2000, 5000 and 7000 series

• Wireless LAN controllers (2500 and 5500 series) and the Wireless Services Module 2 (WiSM2)

Cisco’s ASA 9.0 platform firewall appliances are now able to filter traffic based on context and security groups and support SXP. Cisco’s Nexus 1000V (v2.1) has some built-in support for SXP in the advanced edition, but more work is planned for 2013. The October 2012 release of Cisco’s IOS (v15.1SY) contained a number of improvements

to its support for SXP and other functions of TrustSec and ISE.

In the meantime, until your favorite Cisco product has explicit support either for TrustSec in the hardware or for SXP, you can relay SGT information from access layer switches and wireless controllers that already have support for SXP over other Cisco and third-party network devices en route to Cisco devices that have TrustSec support in their hardware.

Cisco’s Identity Services Engine Gaining Momentum

As described in “Revisiting 802.1X-Based LAN Access Controls,” Cisco shipped its new ISE in May 2011 as its next-generation network security policy system, effectively replacing Secure ACS for most functions with the exception of legacy support for the Terminal Access Controller Access-Control System Plus (TACACS+) protocol. While later versions of Secure ACS included support for SGTs as part of Cisco’s TrustSec framework, ISE is the preferred policy system for TrustSec going forward.

In addition to its support for role-based access decisions based on SGTs, ISE includes support for system health policy evaluation and for policies that use location, time of day and other session context information. In support for 802.1X deployment on wired networks, ISE includes dynamic device profiling, thus replacing the need for Cisco’s former NAC Profiler product (an OEM from Great Bay Software). In effect, ISE replaces the need for a stand-alone Cisco NAC appliance for most use cases. ISE is also a critical component in Cisco’s strategy for supporting client bring your own device (BYOD) programs and related mobile device management requirements.

An operational dashboard tool complements ISE and integrates with Cisco’s Prime Network Control System (NCS). Early customer experience with ISE shows it to be stable and effective in combining identity controls with system health controls. ISE R1.1.1 shipped in July 2012 with R1.1.2 following in late October 2012. Cisco claims that ISE is now in use by more than 2,500 client organizations and forecasts large-scale migration activity over the 2013 to 2014 time frame.

Cisco’s Strategy for TrustSecFrom a market strategy perspective, Cisco considers TrustSec to be a competitive differentiator and a way to expand its business with existing enterprise customers. There are some clear advantages to the architecture that target existing pain points for customers

6

seeking to segregate IT assets, increase network operational assurance and strictly control access based on device, user identity and system health of the device that is requesting access.

Access control in the network may satisfy compliance audits that require sensitive payment card, health, personal, financial and other special classes of information to be exposed only to authorized users, although it may be too early for auditors to have a position on whether separation based on SGTs is adequate. It’s also a way to segregate which IT systems that partially trusted users, such as vendors, partners and employee-owned devices, will be able to access.

The Importance of Security Context

When Cisco and other network and network security vendors discuss extended access control strategies, their market messaging is around gathering information in real time from multiple sources to provide context for the security decision. Device identity (MAC address or machine certificate) and user identity (established by explicit login to a VPN or Web portal or communicated from the endpoint by an 802.1X client supplicant) are the most critical attributes. Devices that are unable to host a client supplicant are identified by matching the device against known device profiles and by registering authorized devices in an exception database used in MAC-auth-bypass processing.

Other security context attributes include the security posture or system health status of the device, which is typically determined by agent software running on the device or by an external appliance based on a series of probes. Location of the device, inside or outside the firewall or a geolocation based on IP address and, potentially, GPS coordinates (for a mobile device), is also becoming an important element for making a risk-based access decision. For TrustSec, the decision to permit a device to connect as part of a known security group leverages context information. Once approved as an authorized member of the security group, the user and device accrue all of the entitlements granted to the source security group to access sets of protected resources (clustered into destination security groups).

Replacing the Use of Device-Specific ACLs

A mainstay for network security control is the ACLs that network switches and network firewalls use to permit or deny traffic based on IP address and TCP port number. Enterprise networks became more complex as compliance

requirements, use by partially trusted partners, and consolidation and use of server virtualization increased. The ACLs used to segregate resources into zones and to limit traffic to and from specific zones became large and, in some cases, consisted of thousands of rules that impacted network performance and manageability. ACLs often reference specific IP addresses and need to be updated frequently. Cisco positions TrustSec’s security group as an alternative that is more scalable and doesn’t need to change as new users and resources are added to the network or when devices move or change their IP addresses.

Scalable Alternative to Use of Virtual LANs

Virtual LANs (VLANs) have also been heavily utilized to segment traffic, and support for dynamic VLAN assignment is growing. The virtualized data center created a whole new set of use cases for VLANs associated with the virtual switch infrastructure. Managing ACLs for each VLAN, static routes for inter-VLAN traffic, and VLAN identifiers is complex and prone to configuration error. Here again, TrustSec’s security group provides an alternative logical mechanism for segregating traffic that can coexist with VLANs but that is intended to reduce the need to use VLANs for most use cases. The capability to associate a security group to a VLAN is one strategy for supporting edge devices that are not able to natively support TrustSec’s SGTs or SXP protocol.

Independent of Physical Network Topology

For a short tutorial-style introduction to SGTs, see the Tagging Packets section of this document. By associating the resource-hosting systems with a destination security group, the physical location of the server/system is irrelevant to the access control enforcement mechanism. Enterprise customers who found it difficult to physically relocate resource-hosting systems to a sub-net for enforcing strict access controls (often for compliance reasons) can now solve this problem with a logical abstraction layer. Only devices and users associated with a source security group that is authorized to access the destination security group’s resources will be permitted to do so. The ACLs that specify the set of granular permit and deny rules for each source group to access each destination group do not have to change when new users and resources are added or moved. More recently, the emergence of the software-defined network (SDN) provides a different form of independence from the physical network’s topology.

7

Creating a Trusted Network

The concepts of a trusted network and security domain, along with its associated authentication processes, are outlined in the Trusted Security Domains section. Only network devices that authenticate to a TrustSec authentication server — such as ISE, which is based on 802.1X and includes support for Cisco’s proprietary key exchange protocol — are considered to be part of a TrustSec security domain. Layer 2 (L2) devices mutually authenticate and optionally encrypt (based on 802.1AE or MACsec) traffic flows between themselves. Industry support for MACsec is still early with few products arriving in advance of clear market demand. However, MACsec and the proprietary extensions to the 802.1X-2004 and 802.1X-2010 standard protocols that Cisco utilizes are essential elements of its TrustSec architecture and borderless network strategy.

Use Cases

There are many scenarios and possible use cases for leveraging the enhanced capabilities that TrustSec brings to the Cisco toolkit for enterprise network and security architects. Typical examples are profiled in this section. Note that TrustSec-aware Cisco equipment is required and therefore cited in these examples.

Inter-Data-Center and Data-Center-to-Cloud Connectivity

With rapid consolidation of data centers comes a growing requirement for high-performance and secure connections between mirrored data centers or between primary and backup data center sites. A traditional Layer 3 (L3) site-to-site VPN may not be able to provide the performance required. In this use case, Cisco suggests L2 encryption between Nexus switches at both data centers. Ethernet traffic between the data centers can be encapsulated and tunneled over a Multiprotocol Label Switching (MPLS) connection and a pair of ASRs, or the traffic can be more directly linked by using fiber and repeaters. This kind of secure inter-data-center connection may also be utilized as enterprise data centers secure the network traffic associated with projected strong growth in the use of cloud computing resources that are hosted at an external provider’s data center(s).

Campus and Branch LAN to Data Center

Devices on the campus or branch LAN authenticate to either a local catalyst switch or the EtherSwitch module in an ISR branch router. This authentication process uses 802.1X, a Web portal login or MAC-auth-bypass (leveraging

a database of exceptions). The access layer switch function associates the IP address to a security group number and communicates this information using the SXP protocol (over TCP) to the data center’s Nexus 7000 switch. The Nexus 7000 enforces the access policy based on source and destination security groups, as specified in the security group ACL (SG-ACL) matrix.

Intra-Data-Center Scenario

Devices within the data center may be associated with a security group based on an authentication process. Servers may be assigned to a VLAN, where policy needs to be enforced at the distribution layer switch. Access rules can be enforced dynamically at the Nexus 7000 switch, whether both devices are in the same VLAN or in different community VLANs. For access layer switches, SXP is used to communicate the IP-address-to-SGT binding information to the distribution layer switch.

Customer Deployments

Cisco has encouraged its customers to initially focus on rolling out support for user and device authentication based on a mix of 802.1X authentication for wireless and wired port access, device profiling and a database of exceptions (MAC-auth-bypass), and use of a Web portal’s login. Many organizations are far along in their use of 802.1X in a mix of wired and wireless network use cases.

Deployment and field experience with access control based on SGTs, aside from proof-of-concept and limited pilots, is at a much less mature level. However, Cisco was able to share a few profiles of early adopters and their use cases:

• A healthcare organization is using SGTs and a pair of Nexus 7000 switches to restrict access to servers containing Payment Card Industry (PCI) data. This organization has a policy that access to PCI data will only be permitted for devices on their wired network. All of their access layer switches in the campus LAN and in branch LANs are implementing 802.1X and mapping users to a role and associated SGT. Other early healthcare deployments leverage TrustSec to segregate multiple business units on a shared campus network, to isolate medical devices in healthcare facilities and to limit access from healthcare practitioner BYODs.

• A large financial services organization has a requirement for segregating IT assets associated with each line of business within its data centers. In this solution, each line of business is represented in a set of servers

8

and a distinct security zone behind its own firewall. Only users associating with the role and SGT for the line of business are permitted to access the security zone. Traffic between servers within a security zone is filtered and enforced based on SGTs. Traffic between zones is controlled based on SGTs leveraging recently upgraded ASA firewall appliances.

• A very large enterprise classifies its wireless users (assigns a source SGT) on ingress and applies access policies that differentiate between employees and contractors.

• A midsize organization needs a mechanism to enable specific users to access restricted resources. Initial deployments are putting 802.1X in place and plan to employ SGTs with a default policy of permitting access to allow for monitoring of access prior to enabling enforcement.

Although SGTs provide a powerful mechanism for enforcing security decisions deep within the network, it does represent a major shift in how networks are secured, and it impacts network operations. Dynamic policy changes can directly affect perceived availability of some network applications, and extra diligence is needed. For many customers, the plan for rolling out TrustSec is a multiyear effort that requires rigorous due diligence at each stage.

StrengthsThere is much to like about Cisco’s ambitious and innovative initiative to provide a framework for logical network-enforced controls based on identity and security context.

Flexibility to Segregate Resources Without Physical Segmentation or Managing VLANs

Many organizations are unable to physically isolate all resources subject to a specific compliance provision because of the number of physical systems involved and the cost and difficulty of relocating existing systems. The use of VLANs is a less effective mechanism and is also somewhat complex, difficult to manage, and hard to scale. Cisco’s TrustSec avoids dependencies on the network’s physical topology while enabling resources to be logically associated to a security group and to share a common set of access policies.

Greater Network Operational Security as L2 Devices Mutually Authenticate

Cisco has implemented a Network Device Admission Control (NDAC) capability that is similar to 802.11i in the wireless network and

that leverages both 802.11AE (MACsec) and a proprietary Security Association Protocol (SAP) to establish a more secure operational network. Each L2 network device mutually authenticates with peer devices and optionally encrypts and decrypts traffic at each transit point (or hop). The combined effect of these mechanisms is to define areas of the network that can be trusted and precludes the introduction of rogue switches and wireless access points within these trusted domains.

Reduction in ACL Maintenance, Complexity and Overhead

The use of TrustSec source and destination security groups is a form of simplified role-based access control (RBAC) and shares the general benefits of RBAC systems. Because access rules do not have to be created and managed for each specific requesting user or device and for each target server or destination IP address, there are fewer, potentially a couple of orders of magnitude fewer, ACLs required. As new users are added to existing source groups and as new servers are added to existing destination groups, no new rules have to be created and no current rule sets have to be changed. During ACL enforcement, there is also less processing overhead because fewer rule sets have to be handled and evaluated.

Potential for Traffic Inspection in L2 Network Devices

Cisco’s NDAC implements MACsec and a precursor to enhancements now contained within the 2010 revision to 802.1X. Unlike L3 protocols such as IPsec, traffic between devices in a trusted security domain is encrypted while in transit but decrypted and available for inspection, filtering and content-based controls at each network device in the path. Use of L2 encryption also has an advantage where traffic volume is high and latency must be minimized, such as when data centers are mirrored.

WeaknessesAs with any substantive innovation driven by a single vendor, even one as important to the enterprise customer as Cisco, there are obstacles to adoption and other weaknesses to consider.

Lack of Interoperability With Products From Other Vendors

There are aspects of Cisco’s TrustSec architecture that can improve network access security controls in heterogeneous networks, such as its use of 802.1X to authenticate users and devices, its next generation policy system and RADIUS server, and its growing support for IEEE 802.1AE (MACsec).

9

However, non-Cisco products cannot generate SGTs or use SXP to communicate an IP-address-to-SGT binding table for use by Cisco switches with TrustSec hardware (for example, Nexus). Cisco also has not yet migrated from its prestandard version of a protocol to create secure associations between L2 devices that are now part of 802.1X-2010. Cisco can relay SGT-to-IP binding information across third-party network devices and has a VLAN mapping mechanism to compensate for non-Cisco gear in the access layer, but this is not a substitute for interoperable industry standards as a long-term market solution.

In the short term, it’s likely that Cisco will selectively license use of its proprietary protocols to partners who complement rather than directly compete with Cisco’s own products. Until Cisco goes through the industry standards process for these protocols, interoperability between Cisco products and non-Cisco network infrastructure and security products will continue to be a problem for the industry, Cisco and Cisco’s customers.

Enforcement of Access Control Based on SGTs Relies on Hardware

Cisco is in the process of integrating support for TrustSec’s SGTs in all of its enterprise-class switches and security products. Changes to IOS that support the use of the SXP protocol enables a migration path where some existing hardware can continue to be used. However, only switches that include Cisco’s application-specific integrated circuit (ASIC) will be able to manipulate the SGT information in the Ethernet frame. The switches in the data center that enforce access control to destination servers based on SG-ACLs will need to be equipped with the ASIC, which means that a Nexus switch or the Sup2T version of the Catalyst 6500 will need to be deployed. Cisco has recently (second half of 2012) added this hardware support to newer versions of its Catalyst 3K (3750-X and 3560-X) and 4K switches, but has no plans to add this hardware to its low-end Catalyst 2K switches. However, support for the SXP protocol is pervasive across Cisco’s switch and router product lines.

Compliance and Audit Uncertainty

SGT-based security is not yet generally accepted to satisfy compliance requirements dealing with network access control and segregation. Due to its newness and low market penetration, many auditors will be unfamiliar with the technology and its security properties. For the foreseeable future, customers should check with their

auditors before planning on using TrustSec as a compliance control.

Complexity Trade-Offs and Potential for Errors Due to Lack of Familiarity

Cisco, its channel partners and its customers are still in the early stages of a learning curve on what it takes to deploy TrustSec with this new approach to securing the L2 network. The first challenge is identifying the user and devices through some combination of 802.1X, MAC-auth-bypass or captive Web portal login. The next is migrating from an existing RADIUS server (perhaps Secure ACS) to the new ISE policy system. There is then the complexity of configurations and use cases that involve a mix of Cisco products that rely on software and SXP or the TrustSec ASIC hardware. Cisco has invested in troubleshooting tools, but any substantial deployment of TrustSec will be a major project with a great deal of complexity, both in designing the architecture and configuring each of the impacted network devices. Even a well-trained channel partner is likely to experience difficulties in assisting early customers with deployment projects.

Recommendations

It’s tempting for many enterprise customers to simply follow wherever Cisco leads, trusting that the strategic relationship will be sufficient to ensure that investments will be preserved and major infrastructure upgrade projects will not be allowed to fail. However, based on Cisco’s track record with its NAC framework and the lack of standards-based interoperability with other network and network security products, Gartner recommends a more cautious approach.

Implement 802.1X-Based Controls FirstCisco’s TrustSec relies on establishing user and device identity at the point where devices connect to the network’s access layer switches, wireless controllers and VPN gateways. Many organizations are already requiring 802.1 X-based authentication when devices access the internal wireless network infrastructure, and there is a growing trend for implementing port-based controls when devices connect to the wired network’s switches. Enterprise customers can also choose to defer the decision to commit to TrustSec security domains and the use of SGTs and instead continue to rely on standard industry support for 802.1X and RADIUS. When TrustSec matures and Cisco opens its proprietary protocols for general industry use, the investment in network identity can be more broadly leveraged across both Cisco and non-Cisco network and network security infrastructure.

10

Upgrade Existing Network Identity and Policy SystemsOrganizations with an older RADIUS server should consider upgrading to a more current product that supports dynamic authorization enhancements (Request for Comments [RFC] 5176 replaces RFC 3576), which enables transparent reauthorization of a session after additional policy checks have been performed. Many Cisco customers who didn’t require new features supported in Secure ACS 5.x releases continue to run older 4.x and 3.x versions of Secure ACS. TrustSec requires the new Cisco ISE, which first shipped in May 2011, and functionally replaces the Secure ACS 5.x product. ISE does not yet support the legacy TACACS+ protocol, but this is likely to be added in a 2013 release. ISE includes device-profiling features that can be used to identify those devices that cannot natively support 802.1X and have to be handled as exceptions. Even if no immediate plan exists to move to an access control approach based on logical security groups, the profiling and security posture policy capabilities of ISE are worth considering as an upgrade.

Whether you choose to move to ISE or some other vendor’s RADIUS-based identity and policy system, this critical infrastructure must be reliable, well-performing and capable of enforcing the authorization policies required by the 802.1X deployment project.

Consider TrustSec When Planning Network Infrastructure UpgradesMajor network infrastructure upgrade projects typically occur every three to five years and represent a major multiyear IT investment in upgrading, replacing and extending the current network and network security infrastructure to meet new requirements and deliver reliable and well-performing network services and connectivity. In order to preserve the option to implement network security controls based on MACsec, 802.1X-2010, and some Cisco or hopefully a future industry standard variation of SGTs, the vendor’s current capabilities and committed road maps need to be considered when comparing alternatives. Any network infrastructure vendor can supply or will work with a RADIUS-based identity and policy system obtained from a third party. Cisco isn’t the only vendor to recognize the need for context-based network authorization decisions.

If the enterprise customer currently only uses switches from Cisco, and there is a strong requirement for TrustSec, then the infrastructure upgrade will need to incorporate a mix of Cisco

products with TrustSec hardware support and other Cisco products that have only software support and must communicate security group binding information using SXP. Non-Cisco equipment or Cisco equipment that is not TrustSec-aware can be traversed using Layer 3 forwarding and encapsulation techniques, but cannot be part of a TrustSec security domain. Use of VLAN mapping will enable some non-TrustSec-aware edge devices to associate traffic to SGTs.

For enterprise customers who prefer to work with multiple suppliers and a competitive market for network and network security infrastructure, any use of SGTs or prestandard key exchange protocols should be avoided entirely or restricted to specific tactical situations where it solves an important problem or use case, such as securing inter-data-center traffic at Layer 2.

Consider Alternatives While TrustSec Matures and StandardizesCustomers will get TrustSec in the box with most new Cisco purchases but should not pay a premium for a proprietary security system. It still makes sense to purchase basic switches from multiple vendors, leverage broadly supported industry standards, and rely on multiple competitive sources of supply to keep costs down. Cisco may consider TrustSec to be a short-term competitive advantage, but it also needs to listen to its customers who want an open market, interoperability based on industry standards and a network security framework that adapts to include solutions from any network or network security vendor.

While TrustSec matures and gains support across Cisco’s various businesses and product lines, organizations should focus on the major pain points and alternative strategies that improve both network operations and network security. For example, a variety of mechanisms exist for monitoring and segregating access within the virtualized data center. Operational tools can help optimize and manage ACLs. Some alternative solutions for modern identity and policy infrastructure are profiled in “Revisiting 802.1X-Based LAN Access Controls.”

Reduce TrustSec Project RisksFor those organizations that choose to embark on tactical or larger-scale TrustSec projects, keep in mind that this technology is new and complex and involves a significant learning curve. Cisco provides a training and certification program for its channel partners. Some of these partners have already worked with organizations on early deployments of ISE and TrustSec and are well-

11

positioned to bring the benefits of their early experience with TrustSec hardware and associated software protocols to customer TrustSec projects. Although each organization deploying TrustSec will need to experience its own learning curve, some project risks can be reduced by leveraging Cisco and Cisco channel personnel who are already far along the learning path.

Recommendation to CiscoIn many respects, Cisco is a trailblazer for its bold vision for how future networks and virtualized data centers will be secured. Cisco has made great strides in integrating support for the TrustSec framework across its product lines and has established an aggressive road map for even more progress over the next 18 months. Though still early in terms of large-scale customer deployments, Cisco has had over four years to refine the protocols and address early operational issues. For TrustSec to become a major force in the industry and a part of strategic investments by customers in a next-generation network security architecture, Cisco has to openly license its proprietary protocols and start down the path of full industry standardization. This is absolutely the right strategy for Cisco’s business and for its enterprise customers. Cisco has already achieved first-mover status, and its substantial investment in TrustSec will be paid back as its customers upgrade and replace aging network infrastructure over the next several years. The private and public networks that are essential to the information economy would not have been possible without the interoperability and open market conditions that industry standards enable. Cisco’s position as a leader in the network equipment market was built on a foundation of industry standards, and now is the time for Cisco to honor its heritage and do the right thing.

ConclusionsCisco is making clear progress on its Trusted Security framework and related product offerings, especially in its improved support for 802.1X-based identity, dynamic device profiling, diagnostic tools, training programs and enhanced ISE. For mixed vendor networks, enterprise customers should avoid or confine use of proprietary SGTs and related controls to limited scope use cases until Cisco makes progress toward standardization.

The Details

A growing body of documentation and training materials on TrustSec is available from Cisco, including detailed configuration guides. The following sections provide a basic outline of the

capabilities and features that are important for understanding how Cisco products implement this enhanced but somewhat proprietary network security framework.

Trusted Security DomainsAs network devices and endpoints authenticate to a TrustSec authentication server, they are assigned to a security group and become members of a security domain of similarly trusted devices.

Identifying Network Devices

Key aspects of the TrustSec architecture are that all devices in a trusted security domain must be authenticated and that mutual trust must be established through an authentication server that implements TrustSec protocols.

Authenticating the Device

Cisco’s Network Device Admission Control (NDAC) process leverages 802.1X to authenticate devices seeking to connect to the network. Credential information is exchanged between the device’s supplicant and an authenticator switch by using Cisco’s preferred form of the standard Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST). EAP-FAST is also used to secure the communication between the authenticator and the authentication server in a RADIUS protocol exchange. The authentication server establishes the identities of both the supplicant device and the authenticator switch and determines whether either or both have the capability to understand TrustSec protocols and the use of SGTs. A shared key is used to secure all subsequent communications between supplicant and authenticator devices and the authentication server and is required by Cisco’s proprietary Security Association Protocol.

Security Association Protocol

Cisco’s NDAC and SAP are proprietary mechanisms that are based on standards, such as 802.11i, but are now duplicate functions built into the latest version of 802.1X-2010. SAP is primarily a key exchange mechanism, comparable to the MACsec Key Agreement (MKA) that was one of the enhancements included in 802.1X-2010. At this point, Cisco is not supporting 802.1X-2010, and no committed date has been made for adding this support.

Unique Logical Device Identifier

Every network device is assigned a unique TrustSec device identifier, either manually or

12

by the authentication server — typically Cisco’s ISE. These identifiers are used when determining peer trust relationships between devices within the domain. Because authorization policies are no longer based on IP addresses, devices can be moved without impacting their established permissions.

Tagging PacketsIn order to implement TrustSec’s logical security architecture that authorizes access to protected resources based on the role or security group associated with authenticated users and endpoint devices, it is essential that all traffic associated with a source device be assigned a tag or label.

Assigning a Security Group

SGTs are unique 16-bit numbers assigned by Cisco’s ISE (that is, authentication and policy server) during the process of identifying the network device or endpoint device to the TrustSec security domain. The SGT type, value, version and length fields are part of a Cisco-specific Ethernet type field in each L2 Ethernet frame.

A security group number is assigned by Cisco ISE during authentication or can be manually configured through Identity Port Mapping (IPM) on the device. It’s also possible to configure an explicit mapping of an IP address of the source device to its applicable security group.

Using Security Group Exchange Protocol

Because tagging of Ethernet frames with security group information requires TrustSec hardware, Cisco provides a software-based mechanism and TCP (port 64999) protocol, SXP, for relaying IP-source-address-to-security-group mapping information between some Cisco devices and others that have the required TrustSec hardware. Although SXP incorporates a Message-Digest Algorithm 5 (MD5) hash for integrity, it does not encrypt the payload, which exposes its tags and IP address binding information to network sniffers and potential packet injection attacks. Cisco is planning to add support for Secure Sockets Layer/Transport Layer Security (SSL/TLS) to further address this vulnerability.

Security Group Access for Server Segmentation

Security Group Access (SGA) enables server segmentation without physical topology or VLAN segmentation by associating SGTs to servers and controlling which connections and traffic flows are allowed through an SG-ACL. By applying this mechanism, servers associated with one business

system or business unit can belong to a logical security subzone with access controlled by the network switching fabric and supported by Cisco ISE.

Applying Policies and Filtering PacketsAuthorization policy enforcement is performed by the TrustSec-capable device closest to the destination device. A permissions matrix consists of a SG-ACL for each source and destination security group pair. SG-ACLs are enforced on both routed and switched IP traffic, including traffic within VLANs (if explicitly enabled).

Security Group ACLs

Each SG-ACL consists of an ordered list of permit or deny statements that are to be applied to traffic that originates from a specific source security group and is directed to a device that is a member of a specific destination security group. These ACLs do not change as new users and devices are added to existing source groups or as servers and other resources are associated with destination groups.

Strategies for Untrusted Networks and DevicesLarge networks will contain a variety of devices, including routers, wireless controllers and switches, that are not capable of authenticating to a TrustSec security domain or of associating SGTs with either themselves or the endpoint devices that connect to them. These network devices could consist of legacy Cisco products that are running older versions of IOS or products from Cisco that do not yet support TrustSec’s protocols. Likely, some network devices from vendors other than Cisco will not be licensed to use TrustSec’s proprietary protocols. Cisco has a number of strategies for how to coexist with devices that are not TrustSec-aware.

L3 Encapsulation

When a TrustSec-aware device is forwarding packets to another TrustSec-aware device that must traverse portions of a network that are not TrustSec-aware, the forwarding device encapsulates the packets. An Encapsulating Security Payload (ESP) header is created that includes the SGT information. When the encapsulated packets arrive at a TrustSec-aware device, the receiving device removes the encapsulating headers. Because no encryption is applied to the payload, IPsec or an alternate mechanism must be used to establish confidentiality during transit. Devices that provide a gateway service between TrustSec domains must have access to a database of

13

eligible target subnets as well as subnets that are not part of a TrustSec domain. Typically, this information is obtained from the TrustSec authentication server, ISE.

Untrusted Destination Devices

The last TrustSec-aware device to handle a packet that is en route to a network device that is not part of a TrustSec security domain is responsible for stripping headers and any SGT information from the packet. Applicable SG-ACL policies are enforced on exit from the TrustSec security domain.

Untrusted Source Devices and VLAN Mapping

Cisco devices that do not support NDAC to authenticate to the TrustSec security domain may still communicate with ISE to determine the security group to associate with incoming packets and relay this information using SXP to a Cisco device with the required TrustSec hardware to tag the packets.

ACL access control list

ACS Access Control Server

ASA Adaptive Security Appliance

ASIC application-specific integrated circuit

ASR Aggregation Services Routers

BYOD bring your own device

EAP-FAST Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling

ESP Encapsulating Security Payload

IEEE Institute of Electrical and Electronics Engineers

IOS Internetwork Operating System

IP Internet Protocol

IPM Identity Port Mapping

ISE Identity Services Engine

ISR Integrated Services Router

L2 Layer 2

L3 Layer 3

MACsec Media Access Control security

MD5 Message-Digest Algorithm 5

MKA MACsec Key Agreement

MPLS Multiprotocol Label Switching

NAC network access control

NCS Network Control System

NDAC Network Device Admission Control

PCI Payment Card Industry

PXE preboot execution environment

The first TrustSec-aware device that processes a packet originating from a non-TrustSec-aware device can determine an IP-to-security-group binding. Cisco is supporting what it calls a “reflector” feature in the TrustSec-capable supervisor engine of its latest Catalyst 6500 switch. Traffic from a device that is not TrustSec-aware is reflected using Cisco’s Switched Port Analyzer (SPAN), a form of port mirroring. For example, this reflector feature would enable the assignment of a security group to VLAN traffic that originates from non-Cisco wireless controllers.

Mapping VLANs and/or subnets to security groups is becoming a common strategy for integrating with network edge devices that don’t natively support SGTs or SXP. This mapping may be done dynamically by ISE or manually through an administrative interface. ISE publishes its IP-to-SGT map/table to TrustSec-aware network devices.

Acronym Key and Glossary Terms

(continued)

14

RADIUS Remote Authentication Dial-In User Service

RBAC role-based access control

RFC Request for Comments

SAP Security Association Protocol

SDN software-defined network

SGA Security Group Access

SG-ACL security group ACL

SGT security group tag

SPAN Switched Port Analyzer

SSL/TLS Secure Sockets Layer/Transport Layer Security

SXP SGT eXchange Protocol

TACACS+ Terminal Access Controller Access-Control System Plus

TrustSec Trusted Security

VLAN virtual LAN

WiSM2 Wireless Services Module 2

WOL Wake-on-LAN

Acronym Key and Glossary Terms (continued)

Source: Gartner Research, G00245544, Phil Schacter, 12 February 2013

TrustSec Summary

Cisco TrustSec simplifies the provisioning and management of secure access to network services and applications.

Unlike segmentation mechanisms that are based on network topology, Cisco TrustSec policies use logical groupings, so access is consistently maintained even as resources are moved.

Decoupling access entitlements from IP addresses and VLANs simplifies security policy maintenance tasks, lowers operational costs and allows access policies to be consistently applied to wired, wireless and remote access VPN users and business partner connections.

In our experience, defining access controls and segmentation functions using logical policy groups, instead of IP addresses and subnets, removes much operational complexity for customers.

An overview of the technology with a summary of all of the ISR and ASR routers, Catalyst switches, Nexus switches, Wireless LAN Controllers, Firewalls and VPN appliances that now have TrustSec capabilities is available here.

15

Recent Developments

Opening TrustSec to other vendors

With much encouragement from customers, Cisco has submitted the protocol which shares TrustSec information between network devices to the IETF.

The Source-group eXchange Protocol (SXP) has been published to enable other vendors to have interoperability with TrustSec functions in widely deployed Cisco products, for details please click here.

Reducing the scope of PCI Compliance with TrustSec

VerizonBusiness were engaged to assess the effectiveness of TrustSec controls to reduce the scope of PCI compliance. Their assessment, based upon their analysis and penetration testing is available at: ‘Using Cisco TrustSec for PCI Scope Reduction--Verizon Assessment and Validation’

Customer Case Study

To understand how TrustSec technology is being used by customers please refer to a case study on Erickson Living who have found that with TrustSec capabilities in their network, that “Instead of managing VLANS and SSIDs, we can use policies to segment our networks. It’s much easier.”

Cisco Validated Designs

There are many different use-cases for TrustSec, some examples of how it can be used are given in Cisco validated designs, including:

TrustSec use in the Cisco’s BYOD validated design.

TrustSec use in the Cisco Secure Data Center for Enterprise Design Guide

To find out more about Cisco TrustSec, see how it can be used to simplify how security policies are enforced in networks and reduce operational effort please go to www.cisco.com/go/trustsec

Source: Cisco

Cisco TrustSec Deployed Across Enterprise Campus, Branch and Data Center Networks is published by Cisco. Editorial content supplied by Cisco is independent of Gartner analysis. All Gartner research is used with Gartner’s permission, and was originally published as part of Gartner’s syndicated research service available to all entitled Gartner clients. © 2014 Gartner, Inc. and/or its affiliates. All rights reserved. The use of Gartner research in this publication does not indicate Gartner’s endorsement of Cisco’s products and/or strategies. Reproduction or distribution of this publication in any form without Gartner’s prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see “Guiding Principles on Independence and Objectivity” on its website, http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp.