Network Segmentation: Why UAE Banks Keep Failing to Stop Lateral Movement

Segmentation fails at enforcement, not design

UAE banks do not fail at segmentation because they lack VLANs or firewalls. Almost every bank network has zones on the diagram: a user LAN, server VLANs, a DMZ, usually a formally defined SWIFT secure zone. The failure sits in what the policy between those zones actually permits. Rulebases grow for a decade. Exceptions accumulate for every core banking upgrade, every vendor support session, every integration that was urgent at the time. The effective policy between segments ends up close to any-any for the protocols that matter, and an attacker does not need to break segmentation that was never enforced.

There is a second, subtler failure: segmentation projects concentrate on network paths, while attackers move on identity. Zone firewalls filter packets. Lateral movement in a Windows-heavy bank estate mostly rides valid credentials over protocols the zones deliberately allow.

How lateral movement actually works on a bank network

Forget the image of an attacker chaining exploits from server to server. The real sequence is shorter and quieter: one workstation compromised, usually through phishing; credentials harvested from memory or disk; then reuse of those credentials over SMB, RDP, WinRM or WMI against whatever the network permits. If a helpdesk account or a service account with broad local admin rights turns up on that first machine, the attacker now moves as a legitimate user. No exploit, no IPS signature, very little noise.

This is why VLAN-based segmentation alone disappoints. A VLAN boundary behind a permissive rule passes authenticated SMB as happily as anything else. The question that decides whether an intrusion stays contained is not "do we have segments" but "from a standard user workstation, what can I authenticate to?" In most bank estates the honest answer is: the domain controllers on far more ports than authentication needs, the file servers, the jump hosts, and often the database tier directly, because an application team once needed that path and the rule never expired.

Three patterns do most of the damage:

• Active Directory as the bypass. Every zone must reach the domain controllers, so the DCs end up reachable from everywhere. Compromise one credential with a path to Tier 0 and the zone model is irrelevant; the attacker inherits the trust of the directory itself. Segmentation design that ignores AD tiering protects nothing that matters.
• The management plane. iLO and iDRAC interfaces, vCenter, backup infrastructure, monitoring platforms. These reach into every zone by design, are patchy on MFA, and hold credentials for the whole estate. An attacker who cannot cross a zone boundary directly goes through the systems that manage both sides of it.
• The jump server that is not a control. Routing admin access through a jump host only helps if the host enforces something: MFA, session recording, no clipboard or file transfer, no alternative path around it. A jump server that admins can bypass, or that simply forwards RDP, is a hop, not a control.

What micro-segmentation adds, and what it honestly costs

Micro-segmentation moves enforcement from the network core to the workload: host-level or hypervisor-level policy defining which specific systems may talk to each other, on which ports, regardless of VLAN. Done properly, it shrinks the reachable set from "everything in the server zone" to "the three systems this application actually needs". It applies the same allow-list logic to servers that a zero trust network access design applies to users, and it is the right end state for core banking, payment switches and the SWIFT environment.

The tradeoffs are real, and they decide deployments:

• Discovery is the project. You cannot write allow-lists for flows you do not understand, and application owners rarely know what their systems talk to. Expect months of traffic mapping before the first enforced policy.
• Enforcement mode is where projects stall. Many deployments run in monitoring mode indefinitely because nobody will sign off on blocking production traffic. Visibility is genuinely useful, but it stops zero attacks.
• Agent coverage is never complete. The legacy AIX box running core banking, the appliances, the branch kit: the systems you most want to isolate are often the ones that cannot take an agent, and still need network-level controls.
• The operational cost is permanent. Every application change now carries a policy change. Without a named owner and a working process, exceptions accumulate and you have rebuilt the old problem one layer down.

The decision rule is simple: if zone-level enforcement is still permissive, fix that first. Micro-segmentation layered over an unenforced zone model is expensive decoration.

What assessors actually ask for

Assessors reviewing UAE banks have moved past accepting a network diagram as evidence. Expect requests along these lines:

• The firewall rulebase between user and server zones, with its review history. Broad any-source rules with no expiry date and no ticket reference tell an assessor everything they need to know.
• Evidence that the SWIFT environment sits in an enforced secure zone. The SWIFT Customer Security Controls Framework makes segmentation of the SWIFT infrastructure an explicit expectation, and attestation means demonstrating it, not asserting it.
• Proof that lateral-movement protocols are restricted: SMB and RDP from workstation subnets to servers limited to defined sources, workstation-to-workstation traffic blocked or at least alerting.
• Penetration test reports that attempted lateral movement from an assumed-breach position, not just an external scan. The CBUAE's cybersecurity expectations for banks lean the same way: controls demonstrated through testing, not described in policy documents.

If the only evidence for segmentation is a Visio file, assume the assessor will treat the control as unimplemented. They usually do.

Testing whether your segmentation actually holds

Segmentation is one of the few controls that can be tested cheaply and conclusively. Three approaches, in increasing order of effort:

Start with an assumed-breach penetration test: give the tester a standard user laptop and a domain account, then ask one question: how far can you get, and through which paths? This is a different scope from a perimeter test and far more useful for this problem. A VAPT engagement scoped for lateral movement maps the real reachable set in days and produces exactly the evidence assessors want.

Add continuous validation where the estate justifies it. Platforms such as Pentera run the same lateral-movement techniques safely in production on a schedule, which matters because segmentation decays: every firewall change is a chance to reopen a path, and an annual test leaves eleven months of blindness between checks.

Then instrument east-west traffic in the SIEM. Most banks log the perimeter heavily and the interior barely. Workstation-to-workstation SMB, a new RDP path into the server zone, authentication from an unexpected subnet: these detections are cheap to build and they catch precisely the movement segmentation was supposed to prevent.

People Also Ask

What is the difference between network segmentation and micro-segmentation?

Network segmentation divides the estate into zones, typically with VLANs and firewalls, and controls traffic between zones. Micro-segmentation enforces policy per workload, controlling which individual systems may communicate even inside the same zone. In practice the difference is granularity and enforcement point: zone firewalls at the network core versus allow-lists at the host or hypervisor.

The order of work that contains an intrusion

1. Measure the current state by testing, not by asking. Map what a standard workstation can actually authenticate to.
2. Enforce default deny from workstation subnets to the server zone, then open only documented flows. Block workstation-to-workstation SMB and RDP outright; almost nothing legitimate needs it.
3. Implement AD tiering so that Tier 0 credentials never touch workstations, and restrict the ports on which domain controllers are reachable.
4. Constrain the management plane: separate network, MFA on every interface, no path from user VLANs.
5. Only then micro-segment the crown jewels: core banking, payment systems, the SWIFT zone.
6. Prioritise continuous validation over annual attestation, because every change to the network is a chance for a path to quietly reopen.

Banks that follow this order stop treating segmentation as an architecture artefact and start treating it as a live control. That shift, more than any product purchase, is what finally stops lateral movement.