The hidden costs of VLAN segmentation
Network segmentation is a simple-to-understand and effective tool for reducing the attack surface and, as a result, the risk to applications, groups of servers, and other critical IT assets. The idea is simple – instead of having a flat anyone-can-talk-to-anyone-on-any-port environment where an infected server has unlimited access to all other servers, with network segmentation you can limit the connection possibilities.
There are three basic approaches to network segmentation. These are:
1) Coarse segmentation, which is the segmentation of different environments, such as the separation of the production environment from the development environment;
2) “Ring-fencing”, which is the separation of a specific, critical application from the rest of the operating environment, and
3) Fine-grained microsegmentation, where each server is only allowed to make connections necessary for its designed purpose (whitelisting).
The more granular the segmentation, the smaller the attack surface, resulting in reduced risk. But this often comes at the cost of complexity, and each organization must make its own decision regarding this trade-off.
In numerous discussions we’ve had with customers, we were able to identify two major practices:
1. Customers are not doing any segmentation or very little of it – mostly because of the implied costs, though the reasoning and the benefits are almost always known to them.
2. Customers are doing segmentation with VLANs, allocating each segment its own VLAN and enforcing communication between VLANs through a firewall or router ACLs.
Using VLANs for segmentation has a nice advantage – it requires no new tools and you can use your existing networking infrastructure. But the reality is that there are hidden costs to this approach which make it expensive (in fact, very expensive). Let’s take a look at some of the often unknown costs associated with VLAN segmentation:
The complexity of managing VLANs
Let’s say you have everything planned out, you listed the servers in each segment, and you’re even familiar with the dependencies among the segments to configure inside your router or firewall. Next, you ask your network engineer to configure the network. This requires a lot of manual configuration changes to network switches, sometimes across multiple switches in different geographies. In many cases, traffic will need to be interrupted during those configuration changes. The maintenance costs of such configuration changes are very high, as it usually takes several days for the networking team to create a new segment. Besides the high costs, the slow speed to execute changes is just not acceptable in today’s fast-changing DevOps environments.
The limitations of VLANs
VLANs were not made for segmentation. In fact, this is somewhat of an abuse of existing technology. As such, they have inherent limitations that make their use far less effective. For instance, it is impossible to extend VLAN technology to the cloud, nor does it work in containers, making this a less preferable choice for organizations that introduce container technologies into the business. An additional limitation of VLANs is that only 4096 segments are supported by the protocol. While this may seem like a lot of segments for a regular organization, to create real micro-segments this can become a limitation, not to mention the maintenance costs of managing so many segments by a networking team.
The lack of visibility
While VLANs do provide a segmentation solution (limited as it may be) there is a huge gap that needs to be bridged somehow. What are the application dependencies? How do I know what ACLs to configure in my firewall to make sure those segments talk securely without breaking anything? And there are more issues. Without relevant visibility into applications, translated into very specific requirements, the networking team will probably break the application, making the process of segmentation much longer and more laborious. What is needed is a tool, preferably an integrated one, that will help you understand the dependencies and translate them into an informed segmentation configuration.
The complexity of an audit
Let’s say you have gone through the whole process and your app is segmented, now the big audit day arrives. Your auditor requires you to prove that your PCI application is segregated from the rest. How will you prove it? Showing the auditor the firewall rules between the segments is not enough. You need to be able to show that the segments (VLANs) are correctly defined, that no one made a mistake and connected one machine to two VLANs and was able to bypass the firewall. The auditor will need to review all the configurations of your switches and routers to make sure everything is well defined. This can be very time consuming and expensive for your business. In fact, in addition to the needs of proof for the auditor, there is the cardinal problem of trust. Without visibility into this process or its results, how will the security practitioner know that no errors were made while creating the segments?
So if you are going through segmentation project and plan on doing it with VLANs – let’s talk.
We can show you how to do it in a way that is quick, affordable, secure, and provable across any environment.
