Let’s take a look at an often under-utilized aspect of network topology in the small to medium business realm: that’s right, a networking article. But before you run off, what if I told you you could increase performance and lower your production down time with equipment you (might) already have!?
Joking aside, properly deploying network segmentation won’t only increase productivity and free up some network overhead, it can also help to greatly reduce recovery time should there be a security event. And it’s easier to roll out than you might think: the biggest barrier to entry is time. I will put an emphasis on might, as most modern networking equipment will have the capability built in, but some switches may need to be supplemented with a multilayer switch (or layer 3 router) to get this nailed down. First let’s clear some things up…
Network segmentation isn’t a new concept. In fact, the original implementation of Virtual local area networks (or VLans) is from back in the internet dark ages of 2003, in which the IEEE standard 802.1q (colloquially referred to as dot1q) was first described. However, its foundation is based from farther back to the early 1980’s by research of Dr. Walter David Sincoskie at Bellcore. Dr. Sincoskie was working on a project to resolve issues that arose from scaling up networks by attaching multiple ethernet networks together (go figure).
Network Segmentation:
Network segmentation is the art of carving a network into smaller broadcast domains and creating multiple subnetworks (or subnets) on a single physical switch or device. The idea behind this is to allow for a smaller scale virtualized network, and broadcast domain, which can help to alleviate stresses on network through conditions like broadcast storms (a result of many multiple machines using the broadcast function of a network to send large amounts of traffic to all devices on the network all at once; think a large highway packed with cars) or other packet floods.
Network Segregation:
Network segregation is a term that often gets lumped in with network separation but is an entirely different concept. Instead of carving out individual subnets within the same switch, this technique goes a step further by adding some routing and security to the mix. By segregating the already separate broadcast domains, you can further separate them from each other through use of rule sets that only allow specific VLans or ports on a switch to communicate with one another. This is usually done through internal switch configurations, routing, or firewalling on the network core/supply side of things. Some other methods such as media access control (mac) address access control lists (ACLs) or mac filtering can also be used on certain switching devices, again it all depends on what hardware you have in place.
With that being said, I’m a proponent of using the terminology ‘network partitioning’ rather than segregation, simply to help differentiate between separation and segregation, which have been lumped together for a decade plus and partially forgotten.
To better explain the theoretical designs, let’s look at some handy dandy graphics to help get a visual grasp of what we’re talking about.
Here we have a fairly standard network topology for a small business:
When we look at this network we see that any computer or server can talk to any other machine on the network. This is what we refer to as a flat network. In this instance, if a broadcast storm were to start in accounting, all machines would be affected, and the network would grind to a halt.
If we add on our VLans by carving the network up a bit, we can separate the networks out into a logical set like so:
In this network, we see that each VLan is treated as its own little subnet on the switch by the different color border surrounding each one. Think of the VLans and subnets like this: While servers live on the main switch, vlan 2, which is a separate virtual switch inside the actual physical switch, carves them out from the entire broadcast domain of the switch itself. The same applies for VLan 3 & 4, so now this single switch is hosting three smaller switches within its own logic. Going forward, should a packet storm in accounting start, only the “accounting switch” (VLan4) would be affected.
However, each network is still able to reach one another unrestricted passed the broadcast domain, that is, the switch knows that vlan2 and vlan3 live on itself and can move non broadcast packets to each. This is the most typical configuration we see in production networks across businesses and enterprises of all sizes. While this helps to limit broadcast storms, as well as to identify and classify logical network locations, it’s still flat from a security aspect.
If we go ahead and move a step further and configure our ACLs we end up with the below. While this final image may look very similar to the others, by looking closely at the connecting lines you’ll notice each has its own distinct color. Each color relates to a different Access Control List (ACL) schema, meaning each VLan is configured individually, allowing only specific hosts to talk to those allowed by the ACL. By specifying which VLans can communicate with which others we can get a much finer level of control on each individual VLan, and who they are talking to. In this design, both accounting and helpdesk need access to the servers on a daily basis, however they don’t necessarily require unfiltered access to each other (with the exception that Helpdesk might need some specific access to accounting for troubleshooting, sure).
In this scenario we’ll stick with the theory that accounting is the trouble maker. If the second machine in accounting is creating a broadcast storm, much like the second image, then only computers on that VLan will be affected.
You may be asking yourself “So what’s the benefit of all this extra work” or “What’s the cost of a layer 3 switch if your network equipment doesn’t support ACLs”? Let’s move out of the realm of broadcast storms and networking into something a little more tangible into the more sinister world of ransomware.
If we replay each network design scenario with a ransomware attack instead, we can see some significant benefits.
Let’s say ransomware was detonated on the middle machine in accounting. In images one and two, everything on the network is at a very high risk of the ransomware spreading to those machines. However, if we set up network partitioning within those subnets and restrict access of each machine to only the resources it needs to have access to—as we have in the third scenario, then only that single machine in the middle of accounting (and potentially the servers it has access to) will be compromised. This will save a huge amount on resources for the remediation stage of the event. Most likely, only that single machine would need to be reimaged and in a worst-case scenario that single machine and a server or two. It should be obvious how this type of defensive posture can scale upwards for any business. Reimaging a few machines and restoring a server from backup is far less time consuming and impactful to a business than having to take all of accounting down for days of repairs.
When building a network from the ground up, rolling in-network segmentation and network partitioning can be seamless and done by design, but how would we tackle this from a pre-built or organically grown network that is already screaming along in production?
The same way you eat an elephant! One bite at a time. By utilizing some network baselining on the systems you have access to, you should be able to identify what resources any given machine needs to have access to based on its role on a day-to-day basis. From here you can create your VLans with ACLs statically and drop a single machine into the VLan for testing. If all results are shiny, migrate the entire department. If you see issues with the initial box, resolve them as they come up, and eventually things will fall into place. It will be somewhat time consuming to get all the details lined up for a migration of any size, but in the end you are actively hardening your network from attacks and lowering your overall attack surface from multiple facets. Besides, building standard roles and images for machines and network deployment is another fantastic place to step up your cybersecurity game, and yet another critical part of any security program.
As always, it’s important to keep in mind that we should be building our defenses in depth and taking a layered approach to any security measures or risks present for a business. While the old axiom of “We as defenders have to be right 100% of the time.” will always stand true, building in some access controls to the network level will help to really slow an attacker down, giving you more time to detect and respond. And time is the luxury that defenders have the least of.
About the Author:
Zach Zaffis is a bona fide expert in network, data, wireless, and communications technology. He firmly believes cybersecurity starts with research, exploration, and practice to acquire as much technical knowledge and practical experience as possible. It ends with imparting all that wisdom to others, so they can apply it in their own lives. It’s an ever-changing world of cyber threats and responsibilities, which is why Zaffis endeavors to stay on its cutting edge, and help make the cyberworld a safer place.
Conducting both red and blue team operations, as well as directing incident responses, Zaffis methodically applies his wealth of knowledge to strengthen systems and networks against incursion. He thrives on educating clients and the public on how to protect themselves in advance, and what to do if they’ve experienced a breach. If he’s empowered someone to be their own protector, he knows he’s done his job.