Today’s enterprise is a highly dynamic, and hyper connected environment where IT plays a critical role in connecting the users, devices, resources and corporate IT systems. Today’s employees are also highly mobile in nature and do not necessarily have a single workspace assignment. The IT departments are constantly being challenged by the organization’s Line of Business owners to keep up with the pace of rolling out new services to address market needs, while keeping up with user expectations.

At the same time, IT departments also are responsible for ensuring business continuity and an uninterrupted service. However, the toughest challenge that any IT organization faces is implementing a security architecture which not only satisfies the compliance and industry regulatory requirements, but also provides a sufficient amount of protection against unauthorized access, data breaches, etc.

The traditional way to implement a security architecture in this kind of an environment is by implementing security rules in Firewall for traffic traversing the network’s extranet/intranet or data-center perimeters. For implementing security policies within an organizations network, Identity-Based Networking using IEEE 802.1X is generally used.

In spite of Firewalls and Network Access Control systems being quite mature technologies both from a standards and products perspective, implementing security architectures using these constructs has been a challenge for IT organizations. While it is true that these systems allow for a secure environment enabling organizations to cater to requirements like secure BYOD access, secure mobility and remote access, they are complex to administer and maintain.

This results in a security architecture which is cumbersome and expensive to maintain, does not lend itself to ability to roll out new services rapidly, and susceptible to breaches arising from administration errors since the rules are so complex.

Here, I’d like to delve a little deeper into the question of – when we talk about security policies, why do we inherently consider them to be complex in nature? There are a couple of reasons for this:

  1. The security policies are coupled to the network architecture and the network design defined using VLANs and IP Subnets, which are then mapped to IP-address based Access Control Lists (ACLs) – an approach which does not scale very well as the size of the network and its services offerings grows.
  2. IP Addresses/MAC addresses are simply numeric values which lack any kind of inherent business context when it comes to their usage in security permissions. This makes maintaining large lists of IP-based ACLs extremely complex to maintain.

As an example, one of the largest global Oil and Gas company that we have worked with has about 1400 partners. For each of their partners, they have an ACL which is about 600 lines long. Do the math and you see that for an organization of this size and scale, their IT security teams are spending most of their time maintaining the ACL configurations on their firewalls, routers and switches. It is no surprise then that we often see organizations which have dedicated IT staff with the sole responsibility of ACL management.

At Cisco, we believe in fundamentally defining network architectures and solutions which:

  • provide you with an intuitive and business relevant way to run your network
  • reduce network complexity
  • are able to scale
  • and most importantly, are flexible to cater to a wide range of use-cases for our customers

Cisco TrustSec is an architecture for network access control and network segmentation which addresses all of these. The way we do that is through:

1. Security Policy abstractions based on User-Role and Business Functions
The biggest architectural element of Cisco TrustSec is definition of security policies in terms of a security grouping abstraction of the User/Resource into a “Security Group Tag”. The management of security policies can thereby be performed exclusively based of this security grouping abstraction and the relationship between the various group e.g. whether traffic between two groups should be permitted or denied. Since these security groupings can be expressed in terms of business function e.g. “production servers” versus “development servers” or “Employee on Corporate Device” vs “Employee on Personal Device”, they are much easier to manage since user/resources/assets do not have to be individually managed.

2. Decoupling of security policies from the network design
In the Cisco TrustSec architecture, the security grouping abstraction of user/network resources can be completely decoupled from the underlying IP addressing infrastructure and network design based on VLAN, Subnets, VRFs, etc. Network design is simplified as the security policies can be defined as an overlay over any network architecture and design with complete flexibility. Besides, this security policy definition is in terms of Business functions described above, making it much easier to manage and maintain.

3. Centralization of security policies and its dynamic enforcement in the network
The Cisco TrustSec architecture permits you to design, deploy and change your security policies without having to access your network device. All policies can be defined and managed in a centralized policy engine, Cisco Identity Services Engine (ISE), and changes to the security policies can be rolled out to the entire network irrespective of number of devices in the network with a single click of a button.

The benefits of Cisco TrustSec can be quite obvious to anyone who has experienced the pains of dealing with security architectures based on VLANs and ACLs. However, the key really is about the range of use-cases that this opens up for organizations – whether it is about providing limited access to BYOD Devices, segmentation of traffic for compliance and regulatory requirements, automation of rolling out new services in Data Centers, segmentation of users and resources, infrastructure consolidation and network virtualization, creating secure multi-tenant environments, and many more.

In the upcoming posts, I will discuss about the Cisco TrustSec architecture and use-cases in further detail.


Vaibhav Katkade

Product Manager

Cisco's Enterprise Networking Group