Cisco TrustSec is a network segmentation solution, like iWAN it isn't a physical piece of kit or a protocol, but a solution. So what is the problem? Typically in IP networks ACL's (Access Control Lists) are used to permit and deny access, for a small network this makes sense and typically works well. The issue with ACL's is that you are classifying traffic based on selected network interfaces, IP addresses and / or port numbers which doesn't scale very well.
An example ACL in it's simplest form would look something like this
ip access-list standard PERMIT-HTTP Remark Allow HQ to talk to DC1 Web Servers 10 permit tcp 10.0.0.0 0.0.0.255 172.16.1.0 0.0.0.255 eq 80 20 deny ip any any
The above ACL would typically be applied on a network interface inbound or outbound and traffic would be checked against the ACL so the decision can be made on whether the traffic can continue to be forwarded or dropped. The ACL is permitting traffic sourced from the 10.0.0.0/24 network to any host on the 172.16.1.0/24 network on port 80.
All of our users at HQ office are on the 10.0.0.0 /24 network and all of our web servers are located at DC1 on subnet 172.16.1.0 /24 so this ACL operates as expected. Happy days right? Well if our business doesn't expand then yes this will continue to work without any issues.
However if our company expands and we open some new offices this same ACL would have to be applied to routers at the new sites and we may also have to update it to add new IP ranges in. This can lead to ACL's becoming very large (I have seen ACL's in production networks with over 1000 entries) and if that ACL is applied on thousands of routers, every time we need to update that ACL we have to update it on 1000 devices.
Any organisation with thousands of devices is likely to have a change control process which involves out of hours change windows for any configuration changes on live devices so something as simple as updating an ACL is suddenly costing lots of money. Time is money.
This is where Cisco TrustSec comes in, it uses a central server (Cisco ISE - Identity Services Engine) to define network segmentation. When a user connects their device to the network ISE allocates the user a tag (SGT - Security Group Tag) based on various parameters such as Active Directory group, physical location, asset type, posture assessment etc. This alone is already a big improvement on our ACL example as we no longer have to worry about updating the ACL with new IP ranges as we expand. We no longer care what IP address the end user ends up with as we can tell what office they are based at, what device they are using and where they sit within the organisation using our existing Active Directory server.
For non-user headless devices such as IP Phones, printers, servers etc we can use MAB (Mac Authentication Bypass) to authenticate these devices.
Now that we have classified the users of our network, how do we define our security policies? It's all done within ISE, allowing the configuration on our routers and switches to remain minimal - a few lines to enable TrustSec and a few lines to enable DOT1X authentication. Everything else is done from ISE.
ISE provides a matrix view of our SGT's where we can decided who can talk to who, the image below (source: cisco.com) shows an example of this.
ISE translates our matrix into SG-ACLs which get downloaded to our network devices on the fly - no more worrying about having to arrange change windows to update ACL's on thousands of devices across the estate.
I will write up further posts on enforcement and SXP (The protocol that can be used to propagate IP to SGT bindings if parts of our network are not TrustSec aware).
Please also note that this is one example of TrustSec and takes a very narrow view of it's capabilitys please refer to documentation on Cisco's website such as http://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/index.html to find out more.