Network segmentation. How to approach the project and avoid common mistakes?

Network segmentation is one of those solutions that everyone knows in theory, but in practice… things can be a bit different. In many companies, it still operates as “partially implemented” or “we’ll do it someday.” However, well-designed segmentation is the first line of defense against the effects of incidents, infrastructure chaos, and unplanned downtime.

By dividing the network into logical or physical trust zones, we gain not only security but also order, easier management, and a solid foundation for further actions, such as implementing an access control system, monitoring, or NIS2 compliance.

In this interview, we show why segmentation is not an option, but a necessity, and how to avoid the most common mistakes.

Let’s start with the basics. What is network segmentation?

In its simplest terms, segmentation is a way to logically or physically divide a local network, data center, or wide area network. Imagine putting smaller pockets into one bag, which can only communicate with each other in the ways we allow them to. This is segmentation in its simplest sense when it comes to a local network. Translated into technical terms, segmentation is limiting the broadcast domain using VLANs or physical separation of equipment.

What solutions are used for network segmentation? Are the aforementioned VLANs and firewalls sufficient?

You can imagine building trust zones on the firewall. These zones can be reflected in the configuration of firewall interfaces or logical subinterfaces. I’ve seen projects where this was the end of the line. That is, there was no mapping to VLANs for Ethernet switches and the local network. Such an unfinished solution would be pointless.

On a switch, different IP address groups can exist within a single VLAN. I’ve seen examples where people thought they had segmentation because they used different addressing, but that’s not the case. VLANs are a virtual entity within a single physical switch and limit broadcast or multicast traffic, which it then translates into broadcast. Separate addressing within a single L2 segment still doesn’t provide any traffic separation from the Ethernet perspective and still allows communication between these addressing groups. To ensure communication between truly separated VLAN fragments, inter-VLAN routing must be consciously performed for communication to occur at all.

Technically, within a broadcast network, such as Ethernet, end devices that naturally support this protocol use broadcast-like protocols, such as ARP (querying to everyone on the network and listening for responses) within a single segment.

If we have two or more segments on a single physical switch, i.e., separate logical subnets at L2, the broadcast does not extend beyond a given segment, making it impossible to eavesdrop on so-called sniffing traffic from an adjacent segment at the end device level.

The idea of ​​limiting broadcast traffic was once the foundation for creating VLANs. Over time, the Ethernet broadcast medium has become a vector for infrastructure attacks that have begun to exploit its inherent nature. Therefore, segmentation not only limits unnecessary broadcast traffic within the network but also the potential impact of a failure on the entire network or a large portion of it.

How does a network access control system support segmentation?

A network access control (NAC) system introduces dynamics into the resource allocation process and simultaneously ensures the consistency of security policies and rules across the infrastructure by organizing authentication and authorization rules. This supports the segmentation project. Therefore, a NAC system can be considered a tool that facilitates implementation and consolidates the segmentation project and improves network access security.

For example, if we say we have 30 VLANs in the local network, we need our network to understand when to use a given VLAN on a given switch port.

For example, if user John Smith disconnects his device from an Ethernet port (e.g., an IP phone) and moves to another floor, connecting to a different switch port, we would want to dynamically assign him the same set of permissions.

If we don’t have a NAC-class system, we need to do this manually. This means configuring the port by assigning it a specific VLAN. The system ensures that the person connecting to the switch is John Smith. NAC will then automatically assign a VLAN for John Smith or the AD (Active Directory) group he belongs to.

When a guest or user from a different group connects to the same port, they will be assigned a completely different VLAN and, optionally, a different set of permissions.

What about access lists (ACLs)? Does it also support segmentation?

That’s a good question. Access Control Lists (ACLs) are mechanisms rarely used to restrict traffic at the Layer 2 level, and at the local network level, they are relatively difficult to maintain. ACLs are based on the IP packet header and use the Source and Destination IP fields (in some cases, also the transport layer port identifier).

An access list is a structure that “doesn’t understand” the state of the connection passing through it, which is why it’s called stateless. If configured on L3 switches or routers, it interprets the packet without any context. It looks at the header, analyzing where the packet is coming from and where it’s going. If the packet “hits” an ACL rule, for example, a given range of source and destination addresses, it either blocks or forwards the packet. Therefore, paradoxically, it has little to do with segmentation. Currently, LAN segmentation projects are moving away from access lists as a filtering tool in favor of firewalling with stateful inspection.

If segmentation is so important, who in the company should be concerned with it?

Everyone should be 🙂 The problem is that management often doesn’t realize how important a network segmentation project is, and they should be the ones approving it. Why the board and not the technical department? Segmentation concerns business security. Production, logistics, offices, machines—everything connected to the network.

The lack of segmentation may be a result not so much of neglect but of years of infrastructure development, which previously didn’t support VLANs and was built on legacy devices, such as hubs and later switches, that were connected without much thought and operated on VLAN 1. No one bothered with segmentation until it became critical for security.

The most common reason to initiate a segmentation project is an audit recommendation. However, the projects themselves are most often initiated by informed administrators. Very often, the IT department has started implementing VLANs but wants to discuss best practices and architecture, for example, in terms of performance. Here, the devil is in the details.

When designing segmentation, it’s important to ensure that a sufficiently efficient firewall is used for filtering and zone communication. Using a firewall to handle east-west traffic within a local network may require handling several times greater traffic volume than when handling connections to the Internet and WAN, i.e., north-south traffic. Hasty decisions about integrating a firewall into such an architecture can lead to miscalculations.

While we’re on the subject of architecture, let me ask you, what mistakes are most often made in network segmentation projects?

Classic. I see three types of errors most often.

1. Planning errors, and sometimes even a lack of planning. The consequences of a lack of planning include problems with addressing, scale, inconsistent numbering, or naming, such as address pool exhaustion, inefficient firewalls, as we discussed earlier, or problems with building security rules.
2. Execution errors or incorrect configuration. This most often occurs if the IT team used workarounds or “workarounds,” increasing the configuration debt. Then, each subsequent configuration must “take into account” the previous debt, etc. I might not be saying anything groundbreaking, but simpler solutions are simply better, more precise, and easier to understand. If they are well-documented, the network and configuration are clear to every administrator.
3. Post-design errors. Here I would mention the lack of documentation, both descriptive and in digital form, e.g. the lack of a CMDB database or information in the IPAM system, the lack of automation where it would be useful, which quickly leads to chaos and uncontrolled changes.

The good news is that all of these errors can be eliminated if we take the time to properly plan the project.

We need to start with a piece of paper. Seriously. First, a network map, address analysis, and traffic patterns. This will help us understand how services operate and which areas should be separated. Next, we build a segmentation matrix, and only then implement the NAC system as an execution element and select the remaining tools.

What is the biggest challenge when implementing segmentation?

This is a redirection process, in which each segment is assigned a new IP address. This change is directly related to the redirection of existing devices. In the case of office users, it can be implemented relatively easily: we change the DHCP address pool, users come to work the next morning, receive a new IP address, and they don’t even know it.

However, when segmentation affects production areas, we affect the addressing of machines. IT administrators often lack the knowledge, or perhaps the permissions, to make changes to their configuration. They must rely on service technicians, maintenance personnel, or external companies and schedule work during maintenance windows, because production processes cannot simply be halted. These are business challenges. Technically, machines even have IP addresses hardcoded into the software that controls them. Unfortunately, the consequence is unfavorable, as very often no one bothers to change such parameters in the code after many years of device operation.

That is why a segmentation plan is so necessary, thanks to which most risks and consequences can be predicted.

And what next? How do you maintain it?

You need electronic documentation, IPAM for address management, and a CMDB (Configuration Management Database) for configuration management. And all of this needs to be updated with the slightest changes.

The network isn’t static. Everything lives here. Therefore, maintaining consistency and logging changes is always a challenge. There are many systems used to maintain network hygiene, and it’s essential to use them.

Today, these things can be increasingly automated, for example, using systems like Nautobot. We’re currently running several projects that automate tasks such as provisioning—the configuration of a new service, a new segment, or new ports. We’re doing this for one of our clients so automatically that changes are made in the inventory system, which then triggers the process, configures devices in the appropriate locations, and saves the change in the digital documentation.

These are interesting engineering projects, but I would say that in the context of the segmentation project they are optional issues, the icing on the cake.

And now the most important thing. How much does a segmentation project cost?

You’ll be surprised, because it might be less than you think.

A segmentation project sometimes doesn’t require infrastructure investment. Of course, adding NAC to the mix increases the project cost. But it’s still not as expensive as implementing and purchasing large security systems like XDR for 500 endpoints or building your own SOC (Security Operations Center).

The price difference between individual segmentation projects stems primarily from the size of the network, the number of locations, the type of devices, and the nature of the company. We conduct projects where segmentation is completed in 3 months or even a month, while others take 2 years, due to the scale and distribution of the company’s locations spanning the globe, and the company operates 24x7x365 with only a 2-week break each year. Coordinating such a schedule and reconciling the various interest groups is, contrary to appearances, no easy task.

However, I recommend treating the cost of segmentation like an investment in an insurance policy.

Another question is whether segmentation is worthwhile, meaning what is the ROI (Return on Investment) for it? Just calculate the costs in the event of a ransomware attack, production downtime, network recovery, or system unavailability. For example, if the unavailability of a production process or warehouse for an hour is calculated at a million zlotys, that’s our ROI. Segmentation quickly pays for itself.

If a company were considering improving its security, would it be better to invest in XDR or more efficient firewalls, or in segmentation?

I think they should consider both with a reasonable perspective. I assume, and I recommend this to clients, that they start with cleanup, and segmentation is just such a project. If we do the opposite, we’ll be building new ones on top of existing technical debt.

I would start with things that can be done at the start:

• auditing what’s already there,
• organizing addressing,
• designating segments,
• possibly replacing some infrastructure.

I know of examples where administrators added small, unmanaged switches to the network because there were no network outlets. This not only resulted in network loops, but also lost control over who was connecting to the network.

In my segmentation presentations, I demonstrate a set of actions that can be taken without investing in hardware. This involves organizing and using mechanisms that are most often available on our devices, but we do not use them.

It’s still a lot of work. What if we can’t do it ourselves? How can we be sure that the integrator we’re talking to is a reliable partner for a segmentation project?

We should look for partners who have experience not only in the declarative sense, but above all in the practical sense. Those who, when discussing segmentation, highlight the problems they encounter most frequently.

It’s worth asking the partner we’re talking to about the stages of a segmentation project and their duration. Let’s be honest – no one can properly complete such a project in two weeks, if only because of the required maintenance windows.

When assessing the integrator’s competence, I’d expect them to tell us about what segmentation looks like, the scale of projects they’ve handled, the devices they’ve worked with, and the industries they’ve worked for. I’d also like to hear what considerations should be made to ensure the project runs as smoothly as possible.

Finally, what advice would you give to IT managers tasked with securing their organizations against incidents?

If an audit reveals a lack of segmentation, implement it as soon as possible. Clean up your addressing, remove loops, design segments, create a matrix, implement a NAC system, and plan redirection (RE-IP). And if you haven’t conducted an audit, now is a good time to do so. Sooner or later, someone will demand this segmentation.

FAQ