Posted: 2014-07-29. Modified: 2015-04-27. Link.
This time round I'm going to finish off Authorization and cover Security Group Tagging, a neat way that completely separates security from my network topology.
This article will cover the final option, Security Group Tagging.
Security Group Tagging is a means to provide identity within a network entirely topology-free. Unlike VLANs or using dACLs, SGTs are easier to implement, keep up to date and map to the businesses security policy.
This is achieved by tagging each frame with a security group tag. These tags are assigned at layer 2 and transported within an IEEE 802.1AE frame.
The classic example is that a AAA server provides a tag to the network access device (i.e. switch) which identifies that user. Although the tag itself is numerical, the management system (such as ISE) abstracts this in to a canonical name.
Let's take the same example as before:
|HR Server||Public Services||Intranet Services|
Note how there is no network topology information above. These users could be in the same subnets or VLANs - their identity is totally separate from my network infrastructure.
Instead, each user is tagged by the network access device. The services are also tagged either using physical infrastructure or a virtual switch such as the Nexus 1000V.
The Identity Services Engine allows you to create a full matrix based on those interaction points. For example:
The business policy above is directly mapped in to this matrix. Any empty cells will use my default policy (in this case fully permitted). This way I can blend existing ACLs and Firewalls with the enhanced security of TrustSec.
The rules in the screenshot above (for example "permit_https" from HR_Director to HR_Server) are topology-independent. For example:
ip access-list role-based permit_https permit tcp eq 443 deny ip
A second rule might allow anything:
ip access-list role-based full_access permit ip
These rules are automatically populated on all TrustSec devices and expanded on a per-session basis, allowing both scale and dynamic security.
Rules can also be manually defined. Assuming the above example where HR_Director is tagged as 2 and HR_Server has the tag of 3 then a rule controlling that interaction would appear as follows:
cts role-based permissions default full_access cts role-based permissions from 2 to 3 permit_https
Of course it's much easier to manage this centrally via ISE or similar, but it's not a requirement and you can implement TrustSec today on almost any Cisco switch, router, firewall or Wireless LAN controller.
In my next (future) blog entry I'll go through using Security Group Exchange Protocol (SXP) to support mixed environments, where TrustSec and/or 802.1AE is not widely supported.