Many organisations grew their network the way a house grows: a room added here, a cable run there. Years later, the accounting PC, the CCTV recorder, the guest Wi-Fi and the database server all sit on the same flat network and can all talk to each other. Everything works, which is exactly why nobody questions it.
The problem appears on the day something goes wrong. One infected laptop, one stolen password or one careless contractor device is enough to reach everything else. This article explains network segmentation without jargon, why auditors keep asking about it, and how to introduce it step by step without stopping the business.
What segmentation actually means
Segmentation means dividing one large network into smaller zones and controlling what may pass between them. A useful comparison is a building with locked doors between departments instead of one open hall. A visitor who gets through the front door still cannot walk into the finance office or the server room.
Technically, zones are usually built with VLANs (separate logical networks on the same switches) and enforced by a firewall or a layer 3 switch with access rules. Traffic inside a zone flows freely; traffic between zones is allowed only if a rule says so, and everything else is denied.
Why flat networks fail
A flat network has three weaknesses that show up repeatedly:
- Attackers move sideways. Most intrusions do not start on the valuable system. They start on an ordinary workstation and then spread. On a flat network nothing stops that spread.
- Faults spread too. A looping cable, a misconfigured device or a broadcast storm in one corner can slow the whole organisation, which is painful on links that are already limited.
- Nobody can prove who talks to whom. When an auditor asks which systems can reach the core banking database or the patient records server, a flat network can only answer "all of them".
Auditors and regulators do not demand a particular product. They expect you to show that sensitive systems are isolated and that the rules between zones are deliberate, documented and reviewed.
A practical set of zones
There is no universal design, but most organisations in our region can start with a small set of zones:
| Zone | What lives there | Typical rule |
|---|---|---|
| Users | Staff workstations and laptops | Reach approved applications and the internet through the firewall |
| Servers | Application and file servers | Accept only the specific ports their users need |
| Critical data | Databases, finance, patient or customer records | Reachable only from named application servers and admin hosts |
| Management | Switch, firewall and server admin interfaces | Reachable only from a small admin group |
| Guest and BYOD | Visitor and personal devices | Internet only, no access to internal systems |
| Cameras and IoT | CCTV, door controllers, printers, sensors | Talk only to their recorder or controller |
| Operational (OT) | Industrial or plant control systems, where present | Strictly separated from office IT |
Seven zones are plenty for a first phase. Resist the urge to create dozens; every zone is a set of rules someone has to maintain.
Rules that make segmentation real
Drawing zones achieves nothing if the firewall allows everything between them. A few principles matter more than any product choice:
- Default deny. Block traffic between zones unless a rule explicitly permits it.
- Least privilege. Allow a specific source to reach a specific destination on a specific port, not "any to any".
- Name every rule. Each rule should have an owner and a reason written down. Rules nobody can explain are the first thing an auditor questions.
- Separate management traffic. Administrative access to network and server equipment should come from a dedicated management zone, ideally with multi-factor authentication.
- Log the boundaries. Denied and unusual connections between zones are valuable signals. Send firewall logs to a central place where someone actually reads them.
Considerations for multi-site and unstable environments
Libyan organisations often run several branches, depots or field sites connected over links of varying quality, with power that cannot always be taken for granted. That shapes the design:
- Use the same zone model at every site. Branch offices should follow the same layout as head office, so staff and engineers do not have to relearn it at each location.
- Keep local essentials local. If the link to head office drops, a branch should still be able to print, authenticate and use local services. Plan which functions must survive a link outage before you move traffic through a central firewall.
- Protect the firewall itself. A segmentation design that relies on one firewall needs that firewall to be redundant and on protected power, otherwise you have created a single point of failure. See our notes on designing resilient networks.
- Secure the site-to-site tunnels. Encrypted tunnels between sites should terminate in a controlled zone, not directly on the user network.
A phased plan that does not stop the business
Segmentation fails when it is attempted as a weekend big bang. A safer sequence looks like this:
- Map what exists. List devices, systems and who needs to reach what. A current network diagram is the foundation of everything that follows.
- Define zones and owners. Agree the zone list above (or your own) with the business, and name one owner per zone.
- Start with the easy wins. Isolate guest Wi-Fi, then cameras and printers. These carry the least business risk and produce immediate benefit.
- Protect the crown jewels. Move databases and sensitive records into their own zone and allow only the application servers that need them.
- Run in monitor mode first. Before enforcing a deny rule, log what it would block for a couple of weeks. This reveals forgotten dependencies without causing an outage.
- Enforce and document. Switch rules to enforcing, record each rule's owner and purpose, and update the diagram.
- Review on a schedule. Re-check rules at least twice a year and after any major project. Remove rules for systems that no longer exist.
Checklist before your next audit
- A current diagram showing zones, firewalls and inter-site links
- Guest, camera and IoT devices separated from the user and server networks
- Databases and sensitive records in a dedicated zone with restricted access
- Default-deny between zones, with each exception documented
- Administrative access limited to a management zone
- Firewall logs collected centrally and reviewed
- A dated record of the last rule review
Where to start
If you can only do one thing this month, separate guest and camera traffic from everything else and write down the diagram. Those two steps cost little, carry low risk and give you something concrete to show an auditor.
Our engineers design and implement segmentation as part of cybersecurity and network infrastructure projects for banks, energy companies, public bodies and other multi-site organisations, backed by 24/7 monitoring and support. Planning a segmentation project? Tell us what you need — an engineer will reply with a plan.