// FINDING / NETWORK

Missing network segmentation

HighNetwork

Networks with different trust levels (user workstations, servers, databases, OT and management) can reach each other freely. There are VLANs on paper, but routing and firewall rules let any host talk to any other on any port.

At a glance

Why it matters
One compromised laptop becomes a compromised company: the attacker moves laterally to domain controllers, backups and payment systems with nothing to stop or even log the traffic. Segmentation is what turns a single incident into a contained one.
How to fix it
Group systems into zones by trust and function, route between them through a firewall and allow only the flows each zone needs. Separate management and backup networks. Our Cisco Config Generator produces VLAN and SVI configurations you can start from, and the Cisco ACL Builder drafts the access-list entries between zones.

Description

Missing network segmentation means devices in different trust levels, a DMZ web server, user workstations, application servers, database servers, can reach each other with no controls between them. Segmentation is the practice of grouping systems by trust and function (VLANs, firewall zones, ACLs) and restricting traffic between groups to only what is explicitly needed, so a flat network is one where this grouping either was never designed or has eroded over time as exceptions accumulated.

Impact

Segmentation is what limits how far a single compromised device can reach. Without it, compromising one workstation or a public-facing web server through any single vulnerability can be enough to reach the database tier, domain controllers, or financial systems directly, turning one incident into a full network compromise instead of a contained one. This is consistently one of the findings that most changes the outcome of a red team engagement: the initial foothold rarely differs much between a segmented and unsegmented network, but what an attacker can reach from it differs enormously.

How we find it

  • During internal assessments and red team engagements we test reachability directly between zones (from a compromised or test host in one segment toward assets in another) rather than only reviewing firewall rule documentation, since the two frequently diverge.
  • We review firewall and ACL rule sets for overly broad allow rules (an any-any rule left from initial setup, a rule scoped to a whole subnet where a single host was intended).
  • We test practical lateral movement paths once inside, since a VLAN boundary that blocks one protocol but not another (SMB blocked, RDP open) still leaves a usable path an attacker will simply take instead.

Fix

Design network zones around trust level and function, not physical location, with default-deny between zones and explicit, narrowly scoped allow rules for what genuinely needs to cross a boundary. Review firewall rule sets periodically to remove exceptions that outlived their original reason, and verify segmentation by testing reachability directly, not only by reading the rule set.

Example zone model for a typical mid-size network:

  Internet
     |
  [ Perimeter firewall ]
     |
  DMZ (public web/app servers)         --  default deny to internal zones
     |
  [ Internal firewall, explicit allow rules only ]
     |
  App tier  <-->  Data tier  <-->  Management/monitoring
     |
  User workstations  (segmented from server zones entirely)

Rule of thumb: every arrow above should be an explicit, documented,
narrowly-scoped allow rule, not an implicit "internal network, trust it".

References

  • NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
  • CWE-653: Improper Isolation or Compartmentalization
  • PCI DSS Requirement 1: network security controls and segmentation

References