SlideShare a Scribd company logo
1 of 15
Download to read offline
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
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 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
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.
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
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
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
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
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
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.

More Related Content

What's hot

SOC-2 Compliance Status Report sample v10.0
SOC-2 Compliance Status Report   sample v10.0SOC-2 Compliance Status Report   sample v10.0
SOC-2 Compliance Status Report sample v10.0Mark S. Mahre
 
Selenium metabolism and its clinical significance
Selenium metabolism and its clinical significanceSelenium metabolism and its clinical significance
Selenium metabolism and its clinical significancerohini sane
 
VITAMIN D-METABOLISM
VITAMIN D-METABOLISMVITAMIN D-METABOLISM
VITAMIN D-METABOLISMYESANNA
 
Mineral metabolism, dental bioch212 1
Mineral metabolism, dental bioch212 1Mineral metabolism, dental bioch212 1
Mineral metabolism, dental bioch212 1IAU Dent
 
Foundations of cloud security monitoring
Foundations of cloud security monitoringFoundations of cloud security monitoring
Foundations of cloud security monitoringMoshe Ferber
 

What's hot (10)

Vitamin D in health and disease
Vitamin D in health and diseaseVitamin D in health and disease
Vitamin D in health and disease
 
SOC-2 Compliance Status Report sample v10.0
SOC-2 Compliance Status Report   sample v10.0SOC-2 Compliance Status Report   sample v10.0
SOC-2 Compliance Status Report sample v10.0
 
Selenium metabolism and its clinical significance
Selenium metabolism and its clinical significanceSelenium metabolism and its clinical significance
Selenium metabolism and its clinical significance
 
VITAMIN D-METABOLISM
VITAMIN D-METABOLISMVITAMIN D-METABOLISM
VITAMIN D-METABOLISM
 
Mineral metabolism, dental bioch212 1
Mineral metabolism, dental bioch212 1Mineral metabolism, dental bioch212 1
Mineral metabolism, dental bioch212 1
 
Foundations of cloud security monitoring
Foundations of cloud security monitoringFoundations of cloud security monitoring
Foundations of cloud security monitoring
 
vitamin D deficiency
vitamin D deficiency vitamin D deficiency
vitamin D deficiency
 
CSIRT_16_Jun
CSIRT_16_JunCSIRT_16_Jun
CSIRT_16_Jun
 
NIST SP 800 30 Flow Chart
NIST SP 800 30 Flow ChartNIST SP 800 30 Flow Chart
NIST SP 800 30 Flow Chart
 
Rickets
RicketsRickets
Rickets
 

Viewers also liked

Integrated Network Security Strategies
Integrated Network Security StrategiesIntegrated Network Security Strategies
Integrated Network Security StrategiesCisco Security
 
Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!
Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!
Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!Cisco Russia
 
Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...
Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...
Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...Lancope, Inc.
 
Demografi profil gampong kulu 1
Demografi profil gampong kulu 1Demografi profil gampong kulu 1
Demografi profil gampong kulu 1Arya Ningrat
 
Batey Portfolio
Batey PortfolioBatey Portfolio
Batey Portfoliofrbatey
 
503 reading quiz
503 reading quiz503 reading quiz
503 reading quizamybass
 
Presentación institucional - Urbanización San Pedro
Presentación institucional - Urbanización San PedroPresentación institucional - Urbanización San Pedro
Presentación institucional - Urbanización San Pedrowww.tumarketing.co
 
Interni urbani: tra scarti e nuove circolarità
Interni urbani: tra scarti e nuove circolaritàInterni urbani: tra scarti e nuove circolarità
Interni urbani: tra scarti e nuove circolaritàSaverio Massaro
 
Demografi profil gampong kulu
Demografi profil gampong kuluDemografi profil gampong kulu
Demografi profil gampong kuluArya Ningrat
 
Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...
Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...
Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...MobileCreation
 
Ian Christie, “Towards a personalised ethnography of mobile communications: m...
Ian Christie, “Towards a personalised ethnography of mobile communications: m...Ian Christie, “Towards a personalised ethnography of mobile communications: m...
Ian Christie, “Towards a personalised ethnography of mobile communications: m...MobileCreation
 
Kasus neurobehaviour ke
Kasus neurobehaviour keKasus neurobehaviour ke
Kasus neurobehaviour keArya Ningrat
 

Viewers also liked (20)

Integrated Network Security Strategies
Integrated Network Security StrategiesIntegrated Network Security Strategies
Integrated Network Security Strategies
 
Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!
Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!
Программируемая сеть, думающая за вас: ночной кошмар или светлое будущее?!
 
Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...
Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...
Intelligent Segmentation: Protecting the Enterprise with StealthWatch, Cisco ...
 
Demografi profil gampong kulu 1
Demografi profil gampong kulu 1Demografi profil gampong kulu 1
Demografi profil gampong kulu 1
 
Hasil percobaan
Hasil percobaanHasil percobaan
Hasil percobaan
 
Batey Portfolio
Batey PortfolioBatey Portfolio
Batey Portfolio
 
Plasma e2 24-01-53
Plasma e2 24-01-53Plasma e2 24-01-53
Plasma e2 24-01-53
 
Dapodik ltj 1
Dapodik  ltj 1Dapodik  ltj 1
Dapodik ltj 1
 
503 reading quiz
503 reading quiz503 reading quiz
503 reading quiz
 
Bunga lanka
Bunga lankaBunga lanka
Bunga lanka
 
Presentación institucional - Urbanización San Pedro
Presentación institucional - Urbanización San PedroPresentación institucional - Urbanización San Pedro
Presentación institucional - Urbanización San Pedro
 
Interni urbani: tra scarti e nuove circolarità
Interni urbani: tra scarti e nuove circolaritàInterni urbani: tra scarti e nuove circolarità
Interni urbani: tra scarti e nuove circolarità
 
Demografi profil gampong kulu
Demografi profil gampong kuluDemografi profil gampong kulu
Demografi profil gampong kulu
 
Lks cut lah
Lks cut lahLks cut lah
Lks cut lah
 
Bab
BabBab
Bab
 
Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...
Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...
Mar Camacho, Universitat Rovira i Virgili Faculty (Spain), Visiting scholar a...
 
Jawaban 1
Jawaban  1Jawaban  1
Jawaban 1
 
Ian Christie, “Towards a personalised ethnography of mobile communications: m...
Ian Christie, “Towards a personalised ethnography of mobile communications: m...Ian Christie, “Towards a personalised ethnography of mobile communications: m...
Ian Christie, “Towards a personalised ethnography of mobile communications: m...
 
Kasus neurobehaviour ke
Kasus neurobehaviour keKasus neurobehaviour ke
Kasus neurobehaviour ke
 
Dapodik ltj
Dapodik  ltjDapodik  ltj
Dapodik ltj
 

Similar to Gartner Newsletter: Cisco TrustSec Deployed Across Enterprise Campus, Branch and Data Center Networks

Secure Data Center for Enterprise
Secure Data Center for EnterpriseSecure Data Center for Enterprise
Secure Data Center for EnterpriseCisco Russia
 
TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)
TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)
TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)Robb Boyd
 
Cisco Secure Enclaves Architecture
Cisco Secure Enclaves ArchitectureCisco Secure Enclaves Architecture
Cisco Secure Enclaves ArchitectureCisco Russia
 
Cisco Cyber Threat Defense for the Data Center Solution: Cisco Validated Design
Cisco Cyber Threat Defense for the Data Center Solution: Cisco Validated DesignCisco Cyber Threat Defense for the Data Center Solution: Cisco Validated Design
Cisco Cyber Threat Defense for the Data Center Solution: Cisco Validated DesignCisco Russia
 
OmniNet MDS HIPPA Compliance Info
OmniNet MDS HIPPA Compliance InfoOmniNet MDS HIPPA Compliance Info
OmniNet MDS HIPPA Compliance InfoJonathan Eubanks
 
azure-security-overview-slideshare-180419183626.pdf
azure-security-overview-slideshare-180419183626.pdfazure-security-overview-slideshare-180419183626.pdf
azure-security-overview-slideshare-180419183626.pdfBenAissaTaher1
 
Experiences evaluating cloud services and products
Experiences evaluating cloud services and productsExperiences evaluating cloud services and products
Experiences evaluating cloud services and productsJavier Tallón
 
From Cisco ACS to ISE
From Cisco ACS to ISE From Cisco ACS to ISE
From Cisco ACS to ISE Mahzad Zahedi
 
System Approach for Single Keyword Search for Encrypted Data Files Guarantees...
System Approach for Single Keyword Search for Encrypted Data Files Guarantees...System Approach for Single Keyword Search for Encrypted Data Files Guarantees...
System Approach for Single Keyword Search for Encrypted Data Files Guarantees...IRJET Journal
 
Azure Security Overview
Azure Security OverviewAzure Security Overview
Azure Security OverviewAllen Brokken
 
Cisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design GuideCisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design GuideCisco Service Provider
 
Cisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design GuideCisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design GuideCisco Service Provider
 
2017 02-17 rsac 2017 tech-f02
2017 02-17 rsac 2017 tech-f022017 02-17 rsac 2017 tech-f02
2017 02-17 rsac 2017 tech-f02Shawn Wells
 
VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...
VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...
VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...VMworld
 
What you should pay attention to cisco aironet access point while purchasing
What you should pay attention to cisco aironet access point while purchasingWhat you should pay attention to cisco aironet access point while purchasing
What you should pay attention to cisco aironet access point while purchasingIT Tech
 
Microservices: A Step Towards Modernizing Healthcare Applications
Microservices: A Step Towards Modernizing Healthcare ApplicationsMicroservices: A Step Towards Modernizing Healthcare Applications
Microservices: A Step Towards Modernizing Healthcare ApplicationsCitiusTech
 
Breaking silos between DevOps and SecOps with Elastic
Breaking silos between DevOps and SecOps with ElasticBreaking silos between DevOps and SecOps with Elastic
Breaking silos between DevOps and SecOps with ElasticElasticsearch
 
IoT Security Assessment - IEEE PAR Proposal
IoT Security Assessment - IEEE PAR ProposalIoT Security Assessment - IEEE PAR Proposal
IoT Security Assessment - IEEE PAR ProposalSyam Madanapalli
 
Latest Developments in Cloud Security Standards and Privacy
Latest Developments in Cloud Security Standards and PrivacyLatest Developments in Cloud Security Standards and Privacy
Latest Developments in Cloud Security Standards and PrivacyCloud Standards Customer Council
 

Similar to Gartner Newsletter: Cisco TrustSec Deployed Across Enterprise Campus, Branch and Data Center Networks (20)

Secure Data Center for Enterprise
Secure Data Center for EnterpriseSecure Data Center for Enterprise
Secure Data Center for Enterprise
 
TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)
TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)
TechWiseTV Workshop: Cisco ISE 2.1 (Identity Services Engine)
 
Cloud Security Solution Overview
Cloud Security Solution OverviewCloud Security Solution Overview
Cloud Security Solution Overview
 
Cisco Secure Enclaves Architecture
Cisco Secure Enclaves ArchitectureCisco Secure Enclaves Architecture
Cisco Secure Enclaves Architecture
 
Cisco Cyber Threat Defense for the Data Center Solution: Cisco Validated Design
Cisco Cyber Threat Defense for the Data Center Solution: Cisco Validated DesignCisco Cyber Threat Defense for the Data Center Solution: Cisco Validated Design
Cisco Cyber Threat Defense for the Data Center Solution: Cisco Validated Design
 
OmniNet MDS HIPPA Compliance Info
OmniNet MDS HIPPA Compliance InfoOmniNet MDS HIPPA Compliance Info
OmniNet MDS HIPPA Compliance Info
 
azure-security-overview-slideshare-180419183626.pdf
azure-security-overview-slideshare-180419183626.pdfazure-security-overview-slideshare-180419183626.pdf
azure-security-overview-slideshare-180419183626.pdf
 
Experiences evaluating cloud services and products
Experiences evaluating cloud services and productsExperiences evaluating cloud services and products
Experiences evaluating cloud services and products
 
From Cisco ACS to ISE
From Cisco ACS to ISE From Cisco ACS to ISE
From Cisco ACS to ISE
 
System Approach for Single Keyword Search for Encrypted Data Files Guarantees...
System Approach for Single Keyword Search for Encrypted Data Files Guarantees...System Approach for Single Keyword Search for Encrypted Data Files Guarantees...
System Approach for Single Keyword Search for Encrypted Data Files Guarantees...
 
Azure Security Overview
Azure Security OverviewAzure Security Overview
Azure Security Overview
 
Cisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design GuideCisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design Guide
 
Cisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design GuideCisco VMDC Cloud Security 1.0 Design Guide
Cisco VMDC Cloud Security 1.0 Design Guide
 
2017 02-17 rsac 2017 tech-f02
2017 02-17 rsac 2017 tech-f022017 02-17 rsac 2017 tech-f02
2017 02-17 rsac 2017 tech-f02
 
VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...
VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...
VMworld 2013: Get on with Business - VMware Reference Architectures Help Stre...
 
What you should pay attention to cisco aironet access point while purchasing
What you should pay attention to cisco aironet access point while purchasingWhat you should pay attention to cisco aironet access point while purchasing
What you should pay attention to cisco aironet access point while purchasing
 
Microservices: A Step Towards Modernizing Healthcare Applications
Microservices: A Step Towards Modernizing Healthcare ApplicationsMicroservices: A Step Towards Modernizing Healthcare Applications
Microservices: A Step Towards Modernizing Healthcare Applications
 
Breaking silos between DevOps and SecOps with Elastic
Breaking silos between DevOps and SecOps with ElasticBreaking silos between DevOps and SecOps with Elastic
Breaking silos between DevOps and SecOps with Elastic
 
IoT Security Assessment - IEEE PAR Proposal
IoT Security Assessment - IEEE PAR ProposalIoT Security Assessment - IEEE PAR Proposal
IoT Security Assessment - IEEE PAR Proposal
 
Latest Developments in Cloud Security Standards and Privacy
Latest Developments in Cloud Security Standards and PrivacyLatest Developments in Cloud Security Standards and Privacy
Latest Developments in Cloud Security Standards and Privacy
 

More from Cisco Security

Incident Response Services Template - Cisco Security
Incident Response Services Template - Cisco SecurityIncident Response Services Template - Cisco Security
Incident Response Services Template - Cisco SecurityCisco Security
 
Infographic: Security for Mobile Service Providers
Infographic: Security for Mobile Service ProvidersInfographic: Security for Mobile Service Providers
Infographic: Security for Mobile Service ProvidersCisco Security
 
Cisco ISE Reduces the Attack Surface by Controlling Access
Cisco ISE Reduces the Attack Surface by Controlling AccessCisco ISE Reduces the Attack Surface by Controlling Access
Cisco ISE Reduces the Attack Surface by Controlling AccessCisco Security
 
Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...
Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...
Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...Cisco Security
 
Pervasive Security Across Your Extended Network
Pervasive Security Across Your Extended NetworkPervasive Security Across Your Extended Network
Pervasive Security Across Your Extended NetworkCisco Security
 
Cisco Web and Email Security Overview
Cisco Web and Email Security OverviewCisco Web and Email Security Overview
Cisco Web and Email Security OverviewCisco Security
 
Cisco 2015 Midyear Security Report Slide Deck
Cisco 2015 Midyear Security Report Slide DeckCisco 2015 Midyear Security Report Slide Deck
Cisco 2015 Midyear Security Report Slide DeckCisco Security
 
3 Tips for Choosing a Next Generation Firewall
3 Tips for Choosing a Next Generation Firewall3 Tips for Choosing a Next Generation Firewall
3 Tips for Choosing a Next Generation FirewallCisco Security
 
AMP Helps Cisco IT Catch 50% More Malware threats
AMP Helps Cisco IT Catch 50% More Malware threatsAMP Helps Cisco IT Catch 50% More Malware threats
AMP Helps Cisco IT Catch 50% More Malware threatsCisco Security
 
A Reality Check on the State of Cybersecurity
A Reality Check on the State of CybersecurityA Reality Check on the State of Cybersecurity
A Reality Check on the State of CybersecurityCisco Security
 
Balance Data Center Security and Performance
Balance Data Center Security and PerformanceBalance Data Center Security and Performance
Balance Data Center Security and PerformanceCisco Security
 
The Cost of Inactivity: Malware Infographic
The Cost of Inactivity: Malware InfographicThe Cost of Inactivity: Malware Infographic
The Cost of Inactivity: Malware InfographicCisco Security
 
Data Center Security Challenges
Data Center Security ChallengesData Center Security Challenges
Data Center Security ChallengesCisco Security
 
Enterprise Strategy Group: Security Survey
Enterprise Strategy Group: Security SurveyEnterprise Strategy Group: Security Survey
Enterprise Strategy Group: Security SurveyCisco Security
 
Malware and the Cost of Inactivity
Malware and the Cost of InactivityMalware and the Cost of Inactivity
Malware and the Cost of InactivityCisco Security
 
Midsize Business Solutions: Cybersecurity
Midsize Business Solutions: CybersecurityMidsize Business Solutions: Cybersecurity
Midsize Business Solutions: CybersecurityCisco Security
 
Cisco Addresses the Full Attack Continuum
Cisco Addresses the Full Attack ContinuumCisco Addresses the Full Attack Continuum
Cisco Addresses the Full Attack ContinuumCisco Security
 
Infonetics Network and Content Security Vendor Scorecard
Infonetics Network and Content Security Vendor ScorecardInfonetics Network and Content Security Vendor Scorecard
Infonetics Network and Content Security Vendor ScorecardCisco Security
 
The Evolution of and Need for Secure Network Access
The Evolution of and Need for Secure Network AccessThe Evolution of and Need for Secure Network Access
The Evolution of and Need for Secure Network AccessCisco Security
 
Cisco 2014 Midyear Security Report
Cisco 2014 Midyear Security ReportCisco 2014 Midyear Security Report
Cisco 2014 Midyear Security ReportCisco Security
 

More from Cisco Security (20)

Incident Response Services Template - Cisco Security
Incident Response Services Template - Cisco SecurityIncident Response Services Template - Cisco Security
Incident Response Services Template - Cisco Security
 
Infographic: Security for Mobile Service Providers
Infographic: Security for Mobile Service ProvidersInfographic: Security for Mobile Service Providers
Infographic: Security for Mobile Service Providers
 
Cisco ISE Reduces the Attack Surface by Controlling Access
Cisco ISE Reduces the Attack Surface by Controlling AccessCisco ISE Reduces the Attack Surface by Controlling Access
Cisco ISE Reduces the Attack Surface by Controlling Access
 
Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...
Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...
Identify Zero-Day Breaches with Cognitive Threat Analytics on Cisco Web Secur...
 
Pervasive Security Across Your Extended Network
Pervasive Security Across Your Extended NetworkPervasive Security Across Your Extended Network
Pervasive Security Across Your Extended Network
 
Cisco Web and Email Security Overview
Cisco Web and Email Security OverviewCisco Web and Email Security Overview
Cisco Web and Email Security Overview
 
Cisco 2015 Midyear Security Report Slide Deck
Cisco 2015 Midyear Security Report Slide DeckCisco 2015 Midyear Security Report Slide Deck
Cisco 2015 Midyear Security Report Slide Deck
 
3 Tips for Choosing a Next Generation Firewall
3 Tips for Choosing a Next Generation Firewall3 Tips for Choosing a Next Generation Firewall
3 Tips for Choosing a Next Generation Firewall
 
AMP Helps Cisco IT Catch 50% More Malware threats
AMP Helps Cisco IT Catch 50% More Malware threatsAMP Helps Cisco IT Catch 50% More Malware threats
AMP Helps Cisco IT Catch 50% More Malware threats
 
A Reality Check on the State of Cybersecurity
A Reality Check on the State of CybersecurityA Reality Check on the State of Cybersecurity
A Reality Check on the State of Cybersecurity
 
Balance Data Center Security and Performance
Balance Data Center Security and PerformanceBalance Data Center Security and Performance
Balance Data Center Security and Performance
 
The Cost of Inactivity: Malware Infographic
The Cost of Inactivity: Malware InfographicThe Cost of Inactivity: Malware Infographic
The Cost of Inactivity: Malware Infographic
 
Data Center Security Challenges
Data Center Security ChallengesData Center Security Challenges
Data Center Security Challenges
 
Enterprise Strategy Group: Security Survey
Enterprise Strategy Group: Security SurveyEnterprise Strategy Group: Security Survey
Enterprise Strategy Group: Security Survey
 
Malware and the Cost of Inactivity
Malware and the Cost of InactivityMalware and the Cost of Inactivity
Malware and the Cost of Inactivity
 
Midsize Business Solutions: Cybersecurity
Midsize Business Solutions: CybersecurityMidsize Business Solutions: Cybersecurity
Midsize Business Solutions: Cybersecurity
 
Cisco Addresses the Full Attack Continuum
Cisco Addresses the Full Attack ContinuumCisco Addresses the Full Attack Continuum
Cisco Addresses the Full Attack Continuum
 
Infonetics Network and Content Security Vendor Scorecard
Infonetics Network and Content Security Vendor ScorecardInfonetics Network and Content Security Vendor Scorecard
Infonetics Network and Content Security Vendor Scorecard
 
The Evolution of and Need for Secure Network Access
The Evolution of and Need for Secure Network AccessThe Evolution of and Need for Secure Network Access
The Evolution of and Need for Secure Network Access
 
Cisco 2014 Midyear Security Report
Cisco 2014 Midyear Security ReportCisco 2014 Midyear Security Report
Cisco 2014 Midyear Security Report
 

Recently uploaded

UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarPrecisely
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 

Recently uploaded (20)

UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity Webinar
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 

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

  • 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.