1. 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 1
2
3
14
15
15
15

2. 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. 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. 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. 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 TrustSec
From 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. 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. 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. 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.
Strengths
There 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.
Weaknesses
As 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. 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 First
Cisco’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. 10
Upgrade Existing Network Identity and
Policy Systems
Organizations 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 Upgrades
Major 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 Standardizes
Customers 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 Risks
For 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. 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 Cisco
In 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.
Conclusions
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 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 Domains
As 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. 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 Packets
In 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 Packets
Authorization 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
Devices
Large 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. 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. 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. 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.