This is part 2 of a long blog. You should probably start with Part 1 if you haven’t already read it!
Given the title, I hasten to state that nothing crude is meant. Just trying to get your attention. Now that I have it …
Segmentation Basics
There are two possible forms of segmentation: macro- and micro-segmentation. And that’s enough to last us quite a while, I think.
The terminology is inconsistent across vendors. For example, it appears that for some vendors “micro-segmentation” is group-based segmentation in data centers only. So for each vendor, you have to be careful about what they mean.
Pete’s Basic Definitions: To me, macro-segmentation equates to VRFs, and micro uses centrally coordinated groups and tags (for either users or servers).
Having done Cisco SD-Access, campus segmentation means VRFs / VNs for macro-segments, typically forced to connect through a firewall. And for Cisco and Juniper, campus micro-segmentation is either SGT or GBP (Group Based Policy) tags, with campus switches and/or APs as enforcers. (GBP may also be capable of being used for macro-segmentation: I and a peer both think we see that implied in the documentation.) I have yet to see anything in Arista documentation that makes me think “tags” or “user micro-segmentation.”
Thus, Cisco and Juniper appear to me to do campus and data center macro and micro-segmentation, albeit in different ways on campus than in the data center. Arista’s solution looks to me as being more like data center macro and micro-segmentation, with the macro perhaps extending to the campus (“perhaps” because I may be missing something).
Data center micro-segmentation for all three of the above vendors strikes me as basically application/port groups and access lists under central control. Arista’s approach appears to, in effect, make VMware the controller, deploying bare-metal policy to the data center switches. Hey, if you’re a smaller company, not having to code your own solution and getting tighter integration with customer tools is a double win, smart!
With crypto-locker and other forms of malware, we now also need to control the lateral spread of malware. That means segmenting into groups of users (or servers) and tightly controlling traffic between the groups.
My definition of macro segmentation is that it usually deals with a “few” big segments, each with potentially many members. And there is generally a requirement to only connect those segments via a firewall. This means macro-segments might be things like users, PCI, HIPAA, IOT, and other segments, where either audit boundaries are needed, or like IOT/OT, where we generally regard the segment members as more likely to have security vulnerabilities.
Micro-segmentation is where you divide things up more finely. So you might have a macro segment “IOT” for IOT devices. You might sub-divide that into micro-segments by the vendor and/or device type. The intent of doing so is to prevent any malware from laterally spreading between the micro-segments. This might be simple: e.g., allow devices in a micro-segment to only talk to their controlling server and/or gateway.
This reminds me of a design I did that more or less did this with a small bank a while ago: ACLs and VLANs so that a branch ATM or other service could only talk to the relevant server, which the internal or third-party vendor used to externally manage and provide ATM services, etc. At the time, we used one VLAN for each type of device and one for the one teller present in a “micro-branch.” In most cases, there was just one device in each VLAN. The slick thing about this was that we didn’t have to specify per-branch addresses of things, and so the switch configuration was easily cloned. The per-VLAN ACL just said that anything in the VLAN was allowed to talk to the relevant server(s).
Segmentation: Where Do I Put the Enforcement?
This assumes you’re using a firewall, not agent-based security.
Firewalling etc., for the Internet Edge is relatively straightforward. Put the firewall between DMZ or all servers and the Internet. Add other security devices to taste. Stir well.
What gets challenging is how you best position a firewall between user segments and also between the user segments and the server farm. The volume of traffic is much greater, and thus so is the cost. If you segment users and force traffic between segments to go via a firewall, you may or may not be significantly increasing the load on any firewall between the users and the data center servers.
Where’s the challenge?
If you have a user-to-server firewall, it’s likely in the data center. If you re-use that for macro segmentation, that makes sense.
Consider, however: for user segment to user segment traffic, do you want to backhaul all the traffic through a HA firewall pair in the data center? But what else can you do?
There certainly is no other obvious good place to put such a firewall.
The Arista technology mentioned earlier apparently lets you use service chaining to force inter-segment traffic through one or more firewalls at any location. Yeah, they’re probably still in the data center. And this would typically be per-VRF or maybe per-VLAN control, with VRFs providing the macro segmentation in the switched network. (I don’t have access to their design best practices document, nor do I have an Arista lab.)
The Arista documentation seems to treat this as more for data center segmentation (their primary market), but in an all-Arista network, it apparently can also be used for the campus.
That’s sort of what Cisco SD-Access does in an SD-Access Transit design with a fusion firewall. SD-Access Transit tunnels traffic from sites back to one (or with some extra effort, two) data centers. VRFs then force inter-VRF (VN) and exit traffic (Internet or data center) through the fusion firewall.
The Arista approach arguably has fewer moving parts and is easier to integrate with certain third-party firewalls, which Arista has done/is doing. Does it scale as well as Cisco SD-Access?
In any case, either approach sure beats manually building VRFs all over the network for segmentation.
But both essentially do backhaul all inter-segment traffic to the fusion firewalls, wherever they are located. That’s probably what you want, for macro-segmentation.
The fusion firewalls are probably big and costly since they handle the aggregated traffic from all the users. You can inefficiently scale that by using multiple firewall pairs. The drawback to doing so is that you then need to replicate policy rules across the pairs, at least for any two segments that are connected to different firewalls. Yes, perhaps it would be simpler to just replicate all the rules to reduce human error.
With “dynamic segmentation,” Aruba switches plus ClearPass can apparently GRE tunnel back to the central controller farm for the PEF (Policy Enforcement Firewall) enforcement mechanism. This is done either by switch port or with user-based tunnels (with local authentication of the user). At first, I wanted to say “bottleneck,” but upon consideration, this seems rather similar to the inter-VRF forwarding behaviors of Cisco and Arista, perhaps distributed across a firewall farm. Substituting the tunneling being done on high-speed switches, and apparently, Aruba instead terminating the tunnels (WLAN controller style) on the PEFs.
Micro-Segmentation Enforcement
We’ll again ignore agent-based security for this discussion.
Design-wise, what’s elegant about Cisco’s SD-Access approach for a campus is that if you segment within a VN (VRF) macro segment, enforcement can be distributed across the fabric switches. So, you can at least localize forwarding of intra-VN (intra-macro-segment) traffic. That is, it can be filtered locally without a detour to a firewall. I believe Juniper MIST GBP on EX switches can do something similar.
I think it best to call this “user (or desktop) centric micro-segmentation.” The next section explains why.
Micro-Segmentation Research Results
I did some Google research and learned a few things.
First, almost all mention of micro-segmentation seems to be in the context of workload segmentation, i.e., apps, servers, VMs, containers.
There seem to be a fair number of vendors in this space, including VMware. I see this as primarily composed of tools to figure out which servers or services need to communicate and come up with logical groupings that are allowed to communicate on the necessary ports. Potential product differentiation may lie in making that easy. Or to avoid misleading, making a hugely complex task (understanding all the app flows) somewhat more feasible.
I looked around the Cisco Secure Workload (“CSW”) (formerly Tetration) and Illumio websites a good bit. Both cover visibility and the ability to do workload micro-segmentation.
CSW does use endpoints for “telemetry”: info about the user, process, etc., accessing a service. This can apparently be done via the AnyConnect Network Visibility Module or ISE. This appears to provide differentiated user access to applications for CSW.
CSW has workload agents for Windows VDI.
So as far as I can tell, Cisco’s answers for user segmentation or micro-segmentation appear to be “raw” TrustSec, ISE, or SD-Access (“ISE plus DNAC”). (“ISE on steroids” would probably make someone very unhappy with me.) With VRFs for what I’m calling macro-segmentation.
In particular, ISE and DNAC each provide a “Policy Matrix” (source vs. destination group table) where each grid cell provides access to the relevant Security Group Tag-based policy, specifying user group to user group policy.
The key thing to note here: with Cisco, the micro-segment endpoint security enforcement is done by a network device (firewall or switch) and not by the endpoint/endpoint agent.
Illumio Core is their server (etc.) data center product. It does workload micro-segmentation per the definition of display app dependency maps. It allows you to create security rules around that. Their SecureConnect products add agent-based IPsec flows between services.
The core can apparently tie into Microsoft AD to allow user group-based access to applications.
Illumio Edge is their user/desktop application. It appears to be cloud-based analysis and control of user desktop to user desktop traffic (with Illumio Core handling traffic involving servers). Edge integrates with CrowdStrike for anti-malware protection.
Edge allows you to create user groups and inbound and outbound policies. Edge groups can apparently map to Microsoft AD groups, as well as being defined in other ways.
Inbound, Edge can enforce based on groups, IP ranges, and services.
Edge can enforce outbound traffic controls using DNS FQDN patterns in addition to IP ranges, ports/services, and groups.
Edge also provides for a global default outbound policy.
It also allows for network profiles, allowing for different policies depending on how the endpoint is connected, specifically home versus office (“Corporate” versus “External,” or both).
My first take on this is that it is roughly equivalent to what Cisco ISE/DNAC does in terms of control based on groups, IPs, port ranges. Having said that, I hasten to add that Cisco’s ISE allows for classifying users and devices into groups that are more flexible and can take a lot more machine and user context into account.
In case you want to dig into this for yourself, the Illumio Edge documentation I’ve been using is here. The usual caution applies: I read the material hastily, and even with slow reading, I’m quite capable of getting something wrong. And there were months of latency between reading and finalizing this blog.
Questions: Does the user space need user macro- or micro-segmentation? Is macro-level enough? How much do user workstations talk to each other? Softphones and conferencing software come to mind. What else? Yeah, printers.
What level of differentiation do you need, assuming you’re trying to control only user endpoint to user endpoint traffic?
Yes, I’m still trying to figure out what the “right answer” here might be. It might well vary in different organizations.
Conclusions
The material above has attempted to describe the options I’m aware of. If there are some I’ve missed, or if you think about some of this in a really different way, please let me know or blog about it. I’d like to think I’m still learning after all these years!
It would be great to have one unified approach to defining tags and groups. The MIST GUI appears to do that. Cisco ACIs End Point Groups (EPGs) map to non-data center SGTs so their campus switches and firewalls can enforce tag-based policies.
So we’ve got some pretty good solutions now, and they will no doubt be refined and become easier to use over time.
Addendum
Ivan Pepelnjak emailed me some good feedback comments, and a short email exchange ensued. He gave permission to post the gist of the emails.
- For me, microsegmentation is the ability to protect every endpoint, which means a (stateful?) packet filter in front of every VM, container, or end-user device.
- Tags are just a convenient configuration mechanisms. In the end, your specs are transformed into a 5-tuple packet filter (modulo optimizations like object groups). There’s no other way to do it at reasonable speed.
- Furthermore, while Matthias Luft somewhat disagrees with me, I think the packet filter should be outside of the protected endpoint to prevent root exploits from disabling it.
- I know this is a windmills fight and microsegmentation already got to the point where it has as much meaning as SDN or cloud, but supposedly hope dies last ;))
My responses:
- I hadn’t really thought about the aspect of protecting every endpoint, although these days with lateral spread of malware, that would be a Good Thing. SD-Access does non-stateful access lists enforcement and potentially can protect every endpoint.
- We agree, TCAM and switches do non-stateful enforcement. Resource constraint. Stateful enforcement might be a feature to consider when shopping. And perhaps a potential benefit of enforcement on a non-switch device.
- I agree re tags and why they’re there: hardware forwarding / performance booster.
- Good point re root exploits, hadn’t thought about that potential limitation of e.g. Illumio.
- Re windmills, I agree the terminology is a bit vague, and that was one of my objectives with the two blogs: trying to “nail down the jello” some more. In particular, both macro- and micro-segmentation are NOT just in the data center.
