Designing Security: Who Does What, Where?

I was reviewing some SD-Access documentation I’d written and came across a diagram I found useful in discussing security and where it is enforced. There’s only one aspect of it that is specific to SD-Access (“SDA”). If I’ve put this into a blog before, apologies, I’m not seeing it.

I call this the “Who Enforces What” security diagram and related discussion. It can be very helpful when trying to understand requirements, who owns which aspects of security, etc.

Ideally, you cover all the types of flow discussed below at least once. And at most once – duplication of ACL enforcement rules generally leads to wasted effort and additional troubleshooting due to increased complexity.

Who Enforces What?

Here’s the famous (infamous?) diagram…

Discussion: User Traffic

Let’s dispose of the left SDA part quickly.

If you have SDA in your campus network(s), you can use SDA policy to have distributed enforcement of policy between different user/device SGTs (Security Group Tags). If you don’t have SDA, then something else needs to do that, perhaps VRF-Lite and/or VLANs to a firewall. This sort of flow is indicated by the pale blue arc in the above diagram.

The VNs are just VRFs (for non-SDA people, anyway). I think of VRFs as heavier isolation mechanisms. They are heavier because more configuration effort is required to deploy them, but also because they provide stronger boundaries between different user or device groups, logically separate networks for differing security needs.

Generally, one runs VRFs (or VLANs) over to a fusion firewall (FFW) pair to control what traffic is allowed between VNs which might contain users, PCI traffic, IOT device traffic, etc.

This sort of flow is indicated by the green arc in the above diagram.

Flavors of Enforcement

So, the above covered the following types of flows:

User to user (same SGT) – rarely any enforcement
User to user (different SGT)
VN/VRF to different VN/VRF

The various remaining and colored lines in the above diagram indicate traffic flows you might want security rules applied to. The flows in question are:

User to physical server
User to VM
Physical server to physical server
Physical server to VM
VM to VM
User to Internet
Server to Internet
VM to Internet

Discussion: Internet Bound Flows

Let’s take a closer look at the flows just listed. We’ll tackle the list from the bottom up, sort of by the process of elimination.

The flows to the Internet, the last three above, are probably easy: that’s why you have an Internet firewall. Done! (And maybe some anti-malware etc., measures thrown in as well, but that’s a broader scope than I want to tackle here.)

Discussion: VM and Server Bound Flows

That is, it flows to a VM or a server.

If you’re running VMware NSX, you are almost certainly (in my experience) using its security, or a firewall solution integrated with NSX to control who or what can get to each VM or group of VMs. Done.

If you’re still doing ESXi, then ACI might be providing controls on what gets to VMs and servers.

No ACI? Then you may not be filtering what gets to servers and VMs. Or you have a firewall somehow located “in front of” the VMs and servers, just for that purpose.

Discussion: User Flows

And that’s where the FFW starts being rather handy. It is in a good position to (A) intercept user to server or VM flows, and (B) do so based on characteristics like ISE or Windows groups or SGTs.

That can be handy in another way. Maybe you then have ACI or NSX or a firewall intercepting server-bound traffic. Then maybe you don’t need to have complex *user* to server rules there, just permit statement(s) for user source addresses. Separation of functionality and workload?

SGTs have limitations. That’s a more advanced topic, which I may discuss in a future blog.

Discussion: But Those Physical Servers?

If none of the above quite work for the physical servers, well, you can always put just them behind a firewall. Or may have done so in the past as you migrate most workloads to VMs.

New Forms of Enforcement / Zero Trust

With agent-based Zero Trust or other enforcement mechanisms, you effectively can put the enforcement of ACLs (or other security) in the servers and VMs, except for perhaps antiques and mainframes. And similar products, sometimes from the same companies, for end users.

For me, Illumio kicked off this set of products, albeit perhaps before Zero Trust became as hot a term. And now many security vendors have agent-based security solutions with centralized controllers.

There is one big reason I see for the popularity of such solutions. And that is throughput versus cost. Firewalls with N high speed ports have always been costly, usually some multiplier in the 4 to 10 range of the cost of a comparably fast switch. The problem is that firewalls centralize and aggregate all the traffic.

By way of contrast, agent-based solutions distribute the workload. They do, in effect, cause a performance tax on the VM or server side. Although some recent tech blogs seem to suggest that impact can be greatly reduced for some operating systems (Linux, BPF?).

Another major advantage of agent-based mechanisms is virtual segmentation: isolating groups of users or devices (or a mix of the two) without network plumbing in the form of VLANs, VRFs, and similar added complexity. Trades device-based “plumbing” for virtual isolation, keeping the network device part simpler.

I’ll now quickly change the subject, as I’m not tracking that particular area at all closely.

Conclusion

I highly recommend that everyone in IT understand where each form of security ACL/filtering is being done and who is responsible for that piece of overall security. The diagram above is one tool for discussing this and overall network security design. And if you don’t like it, it’s easy enough to come up with something more suited for your network or the way your brain works.

Let’s start a conversation! Contact us to see how NetCraftsmen experts can help with your complex challenges.