Image source: DepositPhotos
For a long time, network security was described in terms of exposure. Which ports are open? Which IP addresses are allowed? Which services can be reached from the internet? Those questions still matter, especially for hosting environments where a single unnecessary service can turn into an easy entry point.
But they are no longer enough. Once an attacker gains a foothold, the important question changes from what is exposed to what is reachable. A compromised web server may already be allowed to talk to a database, a backup target, an internal API, a control plane, or another management service. None of those connections has to look malicious at the packet level. The attacker can simply inherit the paths the workload was already trusted to use.
That leads to a more useful way to think about modern network security: the objective is not only to close ports. It is to control which paths are allowed to exist, under what conditions, and how far a compromise can travel if one endpoint in that path becomes untrustworthy.
An open port is not the same as an allowed path
Traditional firewall thinking tends to compress a relationship into a rule such as “allow TCP 443” or “allow this subnet to reach that subnet.”
Port 443 does not describe intent. It could represent a customer reaching a website, a web server calling an internal API, an administrator accessing a management interface, or a compromised host tunneling traffic through HTTPS. The protocol is the same, but the risk is completely different.
Get exclusive access to all things tech-savvy, and be the first to receive
the latest updates directly in your inbox.
In hosting stacks, each workload should have only the connectivity its role requires. A front-end server may need one database, while a backup process may need one destination rather than broad administrative reach.
The better question is therefore not “Is this port allowed?” but “Should this source be allowed to reach this destination, for this purpose, under these conditions?” That is a path question.
The network after compromise is the real design test
Many security architectures look strong when every component is behaving normally. The more revealing test is what happens after one component is compromised.
Imagine an internet-facing application server. A WAF may filter malicious requests, the operating system may be patched, SSH may be hardened, and the firewall may expose only the ports the service requires. Yet if the application is compromised through a zero-day, stolen credential, vulnerable plugin, or application flaw, the attacker now operates from a trusted location.
At that point, the attacker does not need another externally exposed port. They need an allowed path.
If the compromised server can connect to a database, mount a backup location, query an internal management service, reach a metadata endpoint, or initiate SSH toward other hosts, those legitimate dependencies define the attacker’s next options.
The UK National Cyber Security Centre’s 2026 ZTNA implementation guidance says segmentation should minimize blast radius and constrain movement between network segments, with the model shaped by application architecture and risk. The useful insight is that segmentation is not valuable because a network has more VLANs, firewall objects, or policy rules. It is valuable when a problem in one component has fewer legitimate paths through which to spread.
Segmentation should follow dependencies, not subnets
One reason segmentation projects become difficult is that network topology and application topology are not the same thing.
Two systems can sit in the same subnet and have completely different trust requirements. If policy is built mainly around IP ranges, teams eventually create exceptions to make real applications work.
A more durable model starts with an application dependency graph. For each workload, document what it actually needs to reach: which database, which API, which DNS resolver, which update service, which management plane, which backup destination. Then build policy around those required relationships.
This complements server hardening. Host-level controls reduce the chance that a server is compromised; path-level controls reduce the consequence if it is. Hardening the server without restricting its reachable dependencies leaves unnecessary blast radius. Segmentation without hardening leaves too many opportunities to obtain the first foothold.
The goal is not maximum isolation. It is minimum necessary connectivity.
Egress is part of the security boundary
Inbound rules receive most of the attention because they define what outsiders can reach. Outbound rules are often broader because applications need updates, APIs, package repositories, monitoring, email delivery, DNS, and cloud services.
After compromise, outbound access is often how an attacker converts local execution into a durable operation. A server that can reach arbitrary internet destinations over HTTPS may be able to download tooling, contact command infrastructure, move stolen data, or establish a tunnel that makes internal services reachable from outside.
This is why egress policy should be treated as part of segmentation rather than as a separate hygiene task. The question is not whether a workload needs “internet access.” It is which external dependencies it genuinely requires, whether those destinations can be constrained, and what should happen when traffic deviates from that normal path.
Egress control can change attacker economics. A compromised workload that cannot freely resolve arbitrary domains, open outbound tunnels, or connect to unfamiliar services is harder to operationalize.
A useful policy unit is a relationship
Modern environments need a richer policy model than source IP, destination IP, and port. The useful unit is a relationship:
source workload or identity → destination service → required protocol → permitted action → relevant context.
Context might include user identity, workload role, device state, application, risk level, location, or whether the connection is part of an expected workflow. The principle is that policy should describe why a connection is allowed, not only how it travels.
This is where Network Security Solutions are most valuable when they bring multiple enforcement layers into the same decision model: firewalling, intrusion prevention, threat prevention, encrypted-traffic inspection, segmentation, remote access, and centralized policy. The objective is to reduce the gap between what the network permits technically and what the business intended to permit operationally.
Policy should also survive infrastructure change. If an application moves to a new host, autoscaling group, cloud network, or data center, the intended relationship should remain clear even if the addresses change.
WAFs and firewalls protect different failure domains
For hosting teams, it is tempting to treat the WAF as the main security boundary because most attacks arrive through HTTP and HTTPS. That gives the WAF an important role, but it solves a different problem from segmentation.
A WAF asks whether an incoming application request looks acceptable. Network policy asks what the application is allowed to reach after that request is processed.
They are strongest when they assume the other can fail. The WAF should make exploitation harder, while the network should assume that an application may still become compromised. The network firewall should block unnecessary connectivity, while host controls should assume that an allowed connection can still carry malicious content.
Measure reachable blast radius, not firewall rule count
Security teams often measure the network by its controls: number of firewall rules, blocked attacks, IPS signatures, segmented zones, or denied connections.
A more useful metric is reachable blast radius.
Pick a workload and assume it is compromised. What high-value systems can it reach directly? Which credentials or services available from that workload create a second hop? Which management interfaces become accessible? Which outbound destinations can be used to extend control? How many additional systems become reachable after one permitted pivot?
This changes the review. Instead of asking whether every rule has an owner, teams ask whether every path has a defensible reason to exist.
It exposes policy entropy. Environments accumulate temporary rules, broad service groups, legacy exceptions, forgotten admin paths, and connectivity that was once necessary but no longer is. Individually, each may look harmless. Together they create a larger graph of reachable assets than anyone intended.
Network security is becoming path governance
The perimeter still matters. Exposed services still need to be minimized, patched, monitored, and protected. Firewalls still need strong default-deny policies, and application-facing systems still benefit from WAFs and other preventive controls.
The shift is that perimeter protection is now only the first decision.
Modern network security also has to govern what happens after access is granted. It has to distinguish a necessary application dependency from an unnecessary trust path, constrain outbound connectivity, reduce lateral movement, and keep policy aligned with the way applications actually communicate.
The most mature network is not the one with the most rules or the most segments. It is the one where every important path is intentional, explainable, and limited enough that the compromise of one component does not silently become access to the rest of the environment.
That is the standard worth designing for: not simply fewer open ports, but fewer unjustified paths.
