FEATUREDApplication Development & Modernization
PETER WELCHER | Solutions Architect
This blog describes the concepts underlying SD-Access segmentation. It covers the forms of segmentation, where enforcement can occur, and some practical advice.
Prior blogs in this series:
- Defining SD-Access and Cisco Catalyst Center: Why You Should Care
- Cisco Catalyst Center: Pros and Cons
- SD-Access Concepts: The Big Picture
SDA’s Forms of Segmentation
SD-Access provides a two-tier hierarchy for segmentation.
The “top” tier is virtual networks or VN’s. These are actually VRF’s in terms of implementation: separate routing domains. The SD-Access switches provide no direct way for traffic to move between VN’s. Instead, an external device is used. A “fusion router” connects to the various VN’s (VRF’s in its configuration), either leaking routes or exchanging routes selectively with global routing. A “fusion firewall” does the same thing, generally treating the VRF’s as different zones and applying stateful enforcement.
The second tier of SDA segmentation is Scalable Groups, sometimes also called security groups, or SG’s.
Every VN must have at least one SG in it. There may be more than one SG in the VN. They can re-use the same names but will be separate microsegments for all intents and purposes.
SG’s can be assigned statically as VLANs on ports, or dynamically via ISE assignment of SGT (SG tag) and associated VLAN.
By default, SG’s within the same VN can route traffic to each other.
The following diagram illustrates this.
On the left, the dotted line indicates segmentation into two different SG’s in one VN, the black and the orange SG’s. The green curved lines with arrows indicate traffic between the two SG’s, as allowed or denied by SGACL’s applied to the site fabric switches via Cisco Catalyst Center (CCC, formerly CCC).
On the right, the black and red workstations are in two different VN’s. The heavier double line on the switches indicates this stronger segmentation, macro-segmentation. The red curved line with arrows indicates how traffic would flow between a black and a red workstation. Traffic would be denied unless a SGACL on the firewall permits the flow(s).
As we will see below, CCC can be used to create SG policies as to what traffic is allowed between any pair of SG’s. Each policy rule can be applied uni- or bi-directionally.
You may experience one mild surprise in CCC: IP pools are per-VN, meaning all SG’s in a VN will normally be addressed out of the same IP pool. For those of us used to thinking SG = VLAN = subnet, that seems a bit odd.
The key point here is that with SGACL’s and SDA, the whole point is to leverage SG’s and stay out of the IP address business as far as security. Also to avoid using VLANs for micro-segmentation. So this default addressing scheme in CCC emphasizes that and saves us from having to specify which IP pool or subnet goes with each VLAN – just do one big IP pool/subnet, and secure traffic via the SG tags.
Put briefly, VN = subnet with SDA. Because micro-segmentation no longer revolves around addresses!
Practical Advice
SG’s and VN’s provide device groupings for segmentation and policy enforcement. In general, it appears simplest to view them as being global to the network, even if some are not present in some switches or sites.
One common practice is to have certain SG’s that repeat for some or most VN’s. This approach might tie VN’s to business units, in which case each VN having an Employee and a Contractor SG would make sense. If you require stronger security for Contractors, or perhaps Guests, that might call for them to be put into a separate VN.
Some of Cisco’s documentation takes such an approach. What I believe is that, having many VN’s can be a bit painful to work with, in the sense that adding a VN creates work. At the borders, each VN will require a matching VRF that has to be manually configured on a fusion device, plus policy ACL rules if a firewall is used as the fusion device. My advice is to create a new VN when and only when strong segmentation is required.
Another way of thinking about this is that VN’s are strong boundaries, which should be used where a firewall is advisable to enforce traffic controls between VN’s, or between a VN and the datacenter or rest of the network. In particular, if local compliance policy for something like PCI or HIPAA requires a firewall, that’s a good indication that it should probably be a separate VN. If compliance requires an audit of what’s within the boundary, having a separate VN with firewall as boundary might be a very good idea.
Having said that, there is a Verizon-Cisco case study on the web that suggests VLANs may be good enough segmentation. If so, SG’s might be good enough. (“YMMV”).
If you have N VN’s, there are in principle N x (N-1) policies needed. You can visualize this as a matrix, which is exactly what CCC does for SG to SG security.
The conceptual VN to VN matrix is an N x N grid with each box representing a policy pair. The N-1 comes in because the diagonal isn’t needed: there’s no policy from a VN to itself. This is NOT N x (N-1) / 2, the number of pairs of different VN’s, because you will have separate policies for each direction of traffic between a given pair of VN’s.
Concerning SG’s, if there are M of them (M > N), then M x (M-1) is likely a bigger number. Not great, but it comes with the territory. This does suggest we do not want to get carried away with SG’s either.
My advice: start small and add VN’s and SG’s where you need to, slowly. That way you won’t discover you’ve created a maintenance nightmare.
You can re-assign users and devices to a new SG (and possibly thereby to a new VN) via ISE. Deploying new SG’s or VN’s is automated in CCC, so is not that onerous.
Thus, adding segments over time is a quite reasonable thing to do. Doing things this way also means you do not set yourself up for failure when migrating to SDA or first deploying SDA. And please, do stop adding before managing all that you’ve created becomes overly complicated. (Job security of the wrong kind?)
As an example, you could have a VOIP SG in each VN, but why? That would mean either firewall rules to get to voice gateways in the datacenters, or per-VN interfaces on the voice gateways. Worse, it would mean that calls from a phone in VN1 to someone in VN2 would have to traverse the fusion firewall. So physical VOIP handsets, conference room systems, etc. might belong in an SG within a single large VN, or perhaps a dedicated Voice VN.
On the other hand, soft phones on workstations are going to be in the workstation’s SG and VN. So, you would still need to permit phones to talk to such softphones through the fusion firewall.
Yes, that’s a bit clumsy. I haven’t seen a good clean way to deal with that.
There seems to be a knee-jerk reaction of putting guests into a separate VN. I’ve seen this at several sites. Should that be done, or could they just be in a Company VN, with SG rules applied?
The point of bringing this up is that another question when planning is “what happens if I mess up on the SG policy ACL’s?”
If two endpoints are in different VN’s, there will be no traffic between the groups. That’s good for security: what is not explicitly permitted is forbidden. If you mess up, there is no security breach, the endpoints just cannot talk to each other.
If two endpoints are in the same VN and you mess up a SGACL between SG’s, then traffic can flow. So guest workstations might be able to send traffic to employee workstations. How strongly do you feel about that risk and its consequences?
By way of contrast, suppose you deploy multiple SG’s for say employee groups, say to minimize lateral malware spread. If you get the SGACL’s wrong, their workstations might be able to communicate with each other. That does not have immediate consequences unless malware is already present and probing. Of course, if you don’t notice the lapse for months, then you’ve got exposure.
Networks come with trade-offs (as Russ White is fond of pointing out). Here, the trade-off is added security or risk with policy error, versus support effort.
Where Does Enforcement Occur?
Traffic is classified and tags applied inbound (“ingress”). Enforcement is on egress, exit from an SDA switch.
The switches themselves do enforcement of SG to SG and other rules on egress. So, traffic from A to B is discarded at the SDA switch B is attached to.
We noted above that VN to VN traffic is enforced on the fusion device. If the fusion device is a router, and if you set up routing between all the assigned subnets, then VN to VN traffic will be applied until you set up ACL’s. If you’re using a Cisco fusion firewall, then no traffic will flow between VN’s unless you create ACL’s. For simplicity, I am dodging discussing the per-interface security levels and rules in Cisco firewalls – they would work the way they normally do.
What Do I Enforce Where?
We have seen that the fabric switches do SG to SG enforcement, controlling user traffic near the users (and end devices, including IOT devices).
Exiting from a VN to another VN, or perhaps to global routing (WAN, datacenter, or Internet) typically occurs in a fusion firewall. This can also be viewed as near the users. While the fabric might be used to control user to datacenter traffic, it makes more sense to me to do so in the fusion firewalls. An added advantage would be generating flow records for security monitoring purposes.
The fusion firewalls would see all user to datacenter and cross-VN traffic. They would not see user to user traffic within or between fabric sites (assuming SD-Transit).
We will revisit fusion firewalls in the next blog, where we cover fusion firewalls in more detail.
References
Cisco Press book, Software Defined Access
Cisco SDA Segmentation Design Guide (a bit dated but useful)
