As promised, in this entry to our ISE blog series we are going to begin our adventure into Cisco TrustSec, or CTS for short. When I am approaching a new technology, I find it helpful to not only understand what it is, but also why it exists. So, in this post, we’re going to attempt to cover just that; what is Cisco TrustSec and why do I care?
TrustSec, what is it?
CTS is a security architecture developed by Cisco comprised of three components. When most of us think about CTS, we think of Security/Scalable Group Tags (SGT’s) and Security/Scalable Group Access Control Lists (SGACL’s). Quite rightly so, as group-based access control is the most sought-after component of CTS.
Components of the CTS Architecture:
- Group-based access control with SGT/SGACL
- Network Device Admission Control (NDAC)
- Secure communication (MACsec - encrypting traffic over switch to switch links)
In this mini-series on CTS, we are going to focus on the group-based access control component of CTS.
What is the difference between a Security Group and a Scalable Group?
Nothing. love Cisco. I really do. While this may read as sarcasm, it isn’t. Cisco is a great company and by in large the success I’ve found in my career I owe to the technologies they have introduced into the marketplace. As a whole, I am grateful. However, sometimes I wonder how many man (or woman) hours were spent in conference rooms deliberating things such as changing the SGT acronym from meaning Security Group Tag to Scalable Group Tag. So, around the same time Cisco announced their DNA Center SD-Access solution, someone in the product marketing department thought it would be better for the “S” in SGT/SGACL to mean “Scalable” as opposed to “Security”. Most documentation produced by Cisco to this day still says “Security” instead of “Scalable”. Time well spent. Speaking of time, we’ve spent too much talking about this already. Let’s move on!
Why make the move to group-based access control?
What is wrong with the status quo (you know, good old IP based access control)? We’ve been enforcing policy on the network for a long time by writing IP based access control lists. It works, but what is wrong with it? It is not a short answer, but I’ll take a stab at this. We’ve given too much purpose to the almighty IP address – we’ve overloaded it. The initial purpose of the IP address was to provide a unique identifier so that other network connected things can connect to you and vice-versa. Network connectivity, ah yes, it’s a great thing! As time progressed smart people understood that ubiquitous connectivity presents a security challenge. Connectivity is great when it is for benevolent purposes, but creating this connectivity also introduces a vector of attack for bad actors (or well-meaning people/machines doing dumb things). The answer to this security challenge was to write IP based access control lists. Eureka! If we write policies dictating what IP addresses are allowed to talk to what IP addresses, then we solve the problem. And we did. And in doing so, we added a second purpose to the IP address. Not only were we using the IP address as a unique connectivity identifier on the network, we were now using it as a unique security identifier on the network. By now you can see what I mean when I said “we’ve overloaded it”. Maybe now your wondering, “so what?”
Ok, so now my access to the network depends on what IP address I have assigned. In reality it probably will depend on what subnet your IP address is assigned from, since in the typical access network we’ll write rules based on subnets (since host IP’s change and are usually DHCP controlled). In the olden days (before the advent of Port ACL and Downloadable ACL), this meant that every device connected to the same subnet had the exact same security policy assigned to them (the ACL was applied at the router, a RACL, so only traffic entering/exiting the subnet was filtered). Yikes! So that means I have to create a new subnet for every unique security policy. This doesn’t scale when you have a different security policy to assign to HR users, Finance users, IT users, Developer users, and on and on. This obviously didn’t scale. Queue the entrance of PACL’s (Port ACL’s) and DACL’s (Downloadable ACL’s).
PACL’s and DACL’s introduced the ability to apply security policy to layer 3/layer 4 IP traffic with the PACL and DACL being applied directly to the layer 2 interface. So now we can filter traffic on a per port/user level. This is much better than the router ACL (RACL). I can use RADIUS authorization to assign a user a specific ACL based on their AD group memberships, independent of the network subnet that they happen to be connected to. It works OK for filtering traffic destined to network hosts with static IP’s. It is not very helpful for filtering anything destined to dynamic IP’s. What if you wanted to filter IP traffic between two devices on the same VLAN? Technically, you can do this since the ACL is applied at the port level, however, practically this would be a total mess. I would say over 99% of access networks today use DHCP. How are you going to reliably block traffic destined to an IP address that constantly changes? You aren’t. So, nobody does this. If I can’t filter traffic between HR user and Finance user at the same site (when using the same VLAN), then I damn sure can’t do it across sites (HR user at site A to Finance at site B – I don’t know what IP Finance user at site B has...its dynamic). So, I guess it is back to creating new subnets for every unique security policy.
The last issue I’ll note with IP based security policies is that IP addresses are location specific. This leads to ACL bloat. Let’s take one small example of this. Imagine you have a web application with web front ends distributed across three data centers. Imagine you want to write a rule that says these web servers can only be accessed on TCP80 and TCP443 (we’ll even assume “any” source IP can access these web servers to make it easier).
Web Server IP’s
DC1 Web Server: 10.1.1.1
DC2 Web Server: 10.2.2.2
DC3 Web Server: 10.3.3.3
Here is what the traditional IP based ACL looks like
ip access-list extended WEB-SERVER
permit tcp any host 10.1.1.1 eq 80
permit tcp any host 10.1.1.1 eq 443
permit tcp any host 10.2.2.2 eq 80
permit tcp any host 10.2.2.2 eq 443
permit tcp any host 10.3.3.3 eq 80
permit tcp any host 10.3.3.3 eq 443
Even though the security policy is the exact same for these three web application servers, we have to write unique security policies for them because their security identifier, AKA the IP address, is location dependent and different! This was just an example of one application server with three hosts. How lengthy are these ACL’s going to get when we account for all the applications in the enterprise? Oh yea, they get bloated! Couple this with the fact that we are applying this ACL with a DACL at the port level. How much ACL TCAM space does your switch have? This is a question you need to ask yourself if you are deploying lengthy DACL at the port level. If you have older switches, it’s likely a problem, and you’d need to revert to using PACL and lose out on the benefits of centrally managed DACL’s.
Without digging into the details just yet, imagine the same ACL from above but written from a group-based perspective. Don’t ding me on the syntax, this isn’t what a real group-based SGACL looks like in the CLI.
From Any_Group to Web_Server_Group:
permit tcp 80
permit tcp 443
Since the security policy for all three of our web application servers is the exact same and my policy is based on groups, we can use the same security policy for any number of web application servers. IP Independence! Scale! Somewhere at the top of this section we asked the question “why make the move to group-based access control?”. The answer is because we’ve overloaded the meaning of the IP address, making all the meanings dependent on one-another, and ultimately the modern networks requirements for connectivity and security are too disparate to rely on the same artifact (IP) for identification.
What’s Next?
I think we’ve covered the largest shortcomings of IP based access control; why it is a problem to use the IP address as our security identifier and why group-based access control having independence from IP addressing is a good thing. If you still aren’t convinced, just think of the poor folks who are going to have to re-create all these ACL’s in IPv6. In the next entry to the TrustSec mini-series, we’ll take a deep dive into how group-based access control works.
Check out our awesome tech talk on ISE:
Written By: Dominic Zeni, LookingPoint Consulting Services SME - CCIE #26686
If you are interested in LookingPoint installing ISE into your network, feel free to contact us here!
