Whether you’re adding initial or additional segmentation to a Cisco-based campus network or using Cisco Security Group Tags or SGTs, there are some design basics to consider.
(Alternative usage: SGT = Scalable Group Tag, same thing but different name)
This blog goes into those basics, based on requirements discussions I’ve had with customers. The challenge isn’t the technology; it’s really understanding what your requirements are and what you’re really trying to accomplish. And how that relates to scalability and manageability.
It also contains some deep thoughts about Virtual Networks (SD-Access), aka VRFs. They require more effort, so use only when necessary for security or other reasons!
What Is A Security Group Tag (SGT)?
Cisco created Security Group Tags (SGTs) as a way to “tag” network devices’ traffic. The original intent was (a) segmentation and (b) simpler ACLs with hardware enforcement. SGTs and SGACLs are part of Cisco TrustSec.
For a while now, Cisco switches have supported SGACLs: Security Group access lists based on source and destination group tags. Cisco firewalls also support SGTs. For devices and fine details as to what TrustSec features are supported, see the support documents, including this link.
My co-worker Ash Bekele notes ACLs are applied on switch interface egress. And are stateless, which makes matrix scaling harder to manage.
SGTs started out as tags inside network traffic, which was quite capable but could be painful to deploy: think plumbing between SGT-aware devices (“CTS”) on supported links. This was incompatible with devices or link protocols that did not understand CTS headers. I’m oversimplifying, perhaps, but I don’t want to get into details as this is a somewhat specialized topic. (Government, classified information, strong security needs, etc.)
The ability of devices to leverage Cisco pxGrid to query and cache the “logical” (my term) SGT associated with an IP address provided a simpler and more scalable way to deploy SGT segmentation. Several non-Cisco firewall vendors’ products can query ISE to obtain SGT and other information, just as they can leverage Microsoft Active Directory (“MSAD”) attributes. The instances I’m aware were implemented by extending the central (sometimes dedicated) server functionality that interacted with MSAD.
Note: Admin of the matrix in SD-Access is either in ISE or DNAC, but not both. Either way, ISE pushes the SGTs and SGACLs to devices.
What Do SGTs Do for Me?
SGTs are used for segmentation, allowing access controls over which source user or device can send certain traffic to a destination user or device.
That immediately raises the question: yes, but I can do IP address-based ACLs, and put subnets or IP addresses into ACL groups.
Having said that, yes, but you’d generally only group subnets for ACL purposes.
SGTs can be assigned differently to different users or devices in the same subnet based on ISE policies as to user ID, MSAD and other user or device info.
That is, SGTs are both more dynamic and more scalable. Imagine building ACL groups of the IP addresses assigned to individual users, doing the same for devices (IOT/OT/medical?), and how much work THAT would be! No way! At the very least, you’d probably want to do separate VLANs and IP subnets. That’s fairly scalable and workable.
But if you can achieve that effect more easily, that’s a win!
Among other things, SGTs can change, e.g., when a user or device starts behaving suspiciously. That simplifies any form of user/device “quarantining.” Hence my use of the word “dynamic.” ISE pushes out such changes to devices.
Ok, so you can use SGTs with most recent Cisco switches. They’re implemented via ISE. I’ll refer you to the documentation for How, this blog is more about the design side: what can I do with SGTs, what do I have to consider?
A little background…
Cisco SD-Access and DNAC provide what I view as two layers of segmentation.
The VNs (known as VRFs outside the SDA/DNAC world) provide hard or macro segmentation, logically separating traffic from each VN until the traffic reaches a “mixing” router or firewall, which generally has ACL rules for traffic between the “hard segments.” User, Internet and OT/IOT networks might be common such segments. Credit card/payment another.
Connections between devices supporting VNs generally use VLANs to continue traffic isolation until you reach a device that routes between the VNs, usually a firewall. Separate VPN or other tunnels might be used on the WAN to support this.
Within a VN, SGTs provide micro-segmentation, enforced by SGACLs in the switches.
With VNs’ hard segmentation, inter-segment traffic may have higher latency and more hops in its path. That’s because traffic might have to go across the LAN to what I call the “mixing bowl” device (router or firewall) and then back out to the destination end device.
With SGTs or soft (logical) segmentation, devices IN THE SAME SUBNET can be segmented via SGACL enforcement in each switch. From a different perspective, DNAC and SD-Access do not require VLANs and subnets for segmentation. All users and devices within a given VN/VRF can be in one IP pool.
And the key thing here is that ISE can provide the SGTs, so that user or device roles, trust status, etc. can be accommodated by the security logic. This also allows you (well, ISE) to dynamically react and shift the SGT a given user or device is assigned to. It leaves simpler ACL processing in the switches and firewalls, as traffic throughput requirements limits what is feasible there.
Designing for SGTs
So SGTs are really useful, convenient, easy to use, logical security mechanisms.
You do have to bear in mind that different devices have different levels of SGT support. Also, SGT info from ISE is cached, and there are likely cache size limitations.
One non-obvious implication is that you must factor into your design planning. I call it the “Venn diagram” problem.
Every device can belong to only one SGT at a time. That SGT can be changed by ISE dynamically (within reason).
The challenge comes when you have staff or devices that logically belong to two or more groups. E.g. user, network admin, firewall admin. In how many ways can they overlap?
I like to use Venn diagrams to think this out: draw or imagine one circle for each attribute, and then I look at all the ways they might overlap. Alternatively, think in binary: for each attribute, use a 0 or 1 bit for whether it is included or not, giving you 2^N overlaps. Some of which might not be logically relevant to what you have in mind, as in our example earlier.
In other words, if you want to deal with multiple attributes for some group of users or devices, you have to think about overlaps and combinations of those additional attributes IF you need them at the local switch segmentation level. If you only need to enforce policy at a firewall, then maybe a primary SGT grouping will suffice, with additional attributes such as network or firewall admin being enforced at mixing firewalls or by login controls.
For example, at first, you might come up with something like the following for people on your network:
This view of things (pre-coffee?) is more straightforward in a way since when you’re writing SGACL rules, you don’t have to remember that network and security admins are also users. On the other hand, look at how many other combinations there are.
Another approach would be to separate out non-admin users. Then you’d only need SGTs for U, N, S, and N+S as shown below.
This is arguably simpler but does mean that any time you write a rule allowing users U to access something user-ish (email, time sheets, etc.), you need to replicate that rule for the other SGs (security groups).
A different approach might be to use SGT segments for coarse/first level security and use fancier ACL rules on the firewall. For this approach, maybe you have users as one SGT and selectively have firewall rules to allow admins and other job roles the access they need, the ones denied to ordinary users or guests or devices, etc.
Why VNs/VRFs?
So SGTs are centrally administered, dynamic, and simple to deploy from a networking device (non-ISE) perspective. Why would anyone want to do VNs/VRFs?
Note that like SGT, a given user or device can only be placed into one VN/VRF at a time. This placement is often done manually or semi-automatedly by placing the user or device into a VLAN that is part of the VRF. (Doing it manually doesn’t scale, of course!)
My answer: security requirements.
Guests might need to be a separate VN/VRF if strong (stateful!) security is required. Otherwise, a separate SGT might suffice (and could be simpler).
Types of users or devices such as the following might need separate VRFs rather than SGTs, depending on how paranoid/secure you feel the need to be:
- Guests
- Public Safety (within a municipal or other government entity)
- Building management and related IOT devices
- Building security management IOT, etc. (fire alarms, door locks, whatever)
- Other IOT, IIOT, OT devices
- HIPAA data
- PCI endpoints (especially if there might be something taking credit card data on a network that does NOT do IPsec back to a vendor box in the data center)
- Etc.
Using VRFs means more “plumbing” in your network. But it also (usually) means a firewall (etc.) will control and monitor traffic between differing security VRFs.
Using SGT is easier to build but provides less strong security, with arguably less monitoring potential.
Endpoint ZTNA security agents might mitigate some of all that or obviate the need to do SGT at all. But that moves the problem to a different domain.
Limit the Number of SGTs
Why? THE MATRIX. No, not the movie series.
When you have a GUI managing security rules between pairs of security compartments, a matrix is an obvious and great way to provide an overview. E.g., Cisco DNAC, Elisity.
Having said that, the security rule matrix is a grid of N x N things, where N is the number of security groups (SGTs, VRFs, etc.)
Here’s a screen capture from DNAC of a very simple initial design used in a lab:
This was for VNs/VRFs in DNAC, but the same applies with SGTs. Every box in that diagram is a placeholder for an access list.
If you have 10 SGTs, you’ll have 100 boxes, 100 SGACLs to build. See the potential problem?
You presumably created most SGTs because they needed some limitations on traffic, either to and/or from them to other SGTs. If that is NOT the case, why have two SGTs when one will do? (Ok, future tighter control perhaps…).
Conclusion: At some low number, more SGTs goes from useful security to painful security control. Advice: balance needs versus pain.
SGT Technical Options
SGTs initially came with Cisco TrustSec for encrypted tagged traffic on the wire. That provided physical link security but resulted in a modest deployment hassle. That was popular with some governments or other similar organizations.
The newer variant is more logic-centric, with devices either sharing logical tags with each other (not very scalable?), or with ISE or a central system providing IP to SGT info or updates to devices. As devices become more capable, this latter is probably the way to go, unless you want or need to secure and encrypt traffic on links between devices.
The IP to SGT (or other attribute) lookup is cached, so it should be a minor performance concern. As firewalls, in particular, cache other attributes for more complex enforcement rules, this is probably what you want.
Do I expect Cisco or other switches to provide enforcement based on other attributes? Let’s say I’m unaware of the capability being available outside firewalls, and am not holding my breath for it. Hardware (ASICs) can only do so much/hard problem? To the extent you can do mapping attributes to SGT, that enables switch-based enforcement.
There are some practical considerations here as well:
- How efficiently can a given device process multi-attribute access lists (hardware, software, etc.)?
- How much information can a given device cache?
This blog is getting long, so I’m going to leave you with those questions. Also, I don’t have any great answers to them.
Links
Cisco documentation: https://www.cisco.com/c/en/us/td/docs/security/firepower/610/asa-fp-services/asa-with-firepower-services-local-management-configuration-guide-v610/AC-Rules-SGT.pdf
2020 TrustSec Implementation Guide: https://community.cisco.com/t5/security-knowledge-base/group-based-policy-fundamentals/ta-p/3764433
Cisco Validated Design (2018): SD-Access Segmentation Design Guide: (I skimmed it, the content looks like a much extended version of this blog): https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/CVD-Software-Defined-Access-Segmentation-Design-Guide-2018MAY.pdf
GestaltIT article about SGT consistency:
Conclusion
Whether you’re doing Cisco SD-Access with DNAC or not, VNs/VRFs and SGTs can be valuable security components. How you use them in a particular network of course depends on requirements but may require some thought in nailing down precisely what the enforcement needs are for a given organization. And is subject to change over time!
The overall constraint is not getting carried away with either security mechanism: no more segments than really needed!
Failure to observe this constraint is guaranteed to lower your job satisfaction and raise your blood pressure!
I’ll note in passing that there are other ways to do micro-segmentation. See also my other blogs re Illumio and Elisity, among others. Distributed enforcement may be the future way to avoid costly hardware/ASICs while doing fancier enforcement. Although scaling up the central admin side could be the Achilles’ heel for that. That’s likely why such offerings will likely be cloud-based. (I did NOT say “Kubernetes”.)
Let’s start a conversation! Contact us to see how NetCraftsmen experts can help with your complex challenges.
