A firewall rule-base can be immaculate — no any-any rules, no shadowed entries, every port justified — and an attacker who lands on a single laptop can still reach the finance server, the domain controller, and the backup share within an afternoon. Those are two separate facts about two separate parts of the network, and a lot of security programmes only ever check the first one.
That gap is not a hypothetical. Phishing, a compromised contractor VPN account, an unpatched endpoint, a rogue USB drive — any of them puts an attacker (or a piece of malware) on the inside of the perimeter with no further need to breach anything at the edge. From that point on, whether they can reach anything valuable depends entirely on internal design: segmentation, credential reuse, service exposure between hosts, and how the internal directory is structured. None of that is visible from a rule-base review, because a rule-base review never looks at what happens after the packet crosses the boundary it controls.
What a firewall audit actually checks
A firewall audit is a review of configuration, not a test of reachability. It reads rule-bases — often as offline configuration exports plus, where available, read-only console access to check hit counts — and looks for the specific ways rule-sets rot over time: overly permissive or "any-any" entries that were meant to be temporary, rules that are shadowed by an earlier, broader rule and never actually fire, entries nobody can explain because the person who added them left two reorganisations ago, and gaps between what the rule-base permits and what the intended segmentation policy says it should permit.
This is genuinely valuable work, and it is entirely static. It does not send traffic anywhere and it does not change anything — it is read-only by design, which is exactly why it is low-disruption and can run against exports without touching production. But a clean rule-base tells you the policy, as written, is sensible. It does not tell you whether the policy holds up once a host on the inside starts making its own connections, because the audit's field of view stops at the device it is reviewing. If a switch, a flat VLAN, or a trust relationship elsewhere in the network lets traffic bypass the firewall entirely, the audit will never see it — there is nothing in a configuration export that says "this control can be routed around."
The assumption a perimeter-only programme is making
Perimeter-first security rests on an old assumption: that the boundary between "outside" and "inside" is the meaningful one, and that anything inside it can be trusted at least a little more than anything outside. That assumption predates laptops that leave the building, VPNs that hand a home network the same routes as the office, SaaS credentials that live in a browser, and contractors who connect from unmanaged devices. Once any of those exist — and nearly every organisation has all of them — "inside the firewall" stops meaning "trusted" and starts meaning "one phishing email away from being the attacker's vantage point."
The practical consequence is that the interesting question is rarely "can someone get in." Given enough time, a large enough workforce, and enough internet-facing surface, the answer trends toward yes regardless of how well the perimeter is defended. The question that actually determines how bad an incident becomes is: once one host is compromised, what can be reached from it, and how quickly? Security teams that only ever budget for perimeter work — firewall rule cleanup, WAF tuning in front of the public web app, patch management on internet-facing hosts — are optimising the part of the estate an attacker touches for the shortest amount of time. The internal network is where an intrusion actually plays out, and it is usually the part nobody has looked at with adversarial eyes.
What segmentation validation actually involves
"We have segmented environments" is a claim, not a fact, until someone tries to move between them without the credentials the segmentation is supposed to require. Segmentation on a network diagram is a statement of intent — VLANs drawn, subnets allocated, a firewall placed between corporate and production. Segmentation in practice is whatever traffic the network actually permits once you attempt to cross those boundaries, and the two routinely diverge: a management interface left reachable from the general office VLAN, a jump host with a route back into a network it was meant to isolate, a legacy switch port that was never moved when the VLAN plan changed, or a cloud security group that mirrors an old on-premises assumption rather than the current one.
Validating this is exactly what a network security assessment is built to do, and it is a fundamentally different exercise from reading a rule-base. Rather than reading what a device is configured to permit, the assessment attempts the crossing — from a defined starting position, such as a foothold on the corporate network, testers try to reach production, management interfaces, or another business unit's environment, and report the routes that actually worked. It is the same relationship that exists between a manual penetration test and an automated scan in application security: reading a policy tells you intent, and only testing tells you what the system actually does when someone pushes on it.
Internal discovery and the attack surface nobody inventories
External attack-surface mapping — what is reachable from the internet — gets attention because it is the part facing outward and the part a scanner can reach unassisted. Internal attack surface gets far less, because reaching it requires either physical presence or an existing internal foothold, and most organisations never test past the assumption that internal footholds don't happen.
They do, and once one exists the questions become concrete: which hosts respond on the internal network at all, and which of them are running something they should not be. In practice this repeatedly turns up a similar shortlist:
- Internal services still using default or weak credentials because they were never intended to be reachable by anyone outside a small original team.
- File shares and management consoles — print servers, hypervisor management, backup consoles, network device admin pages — with far broader read or write access than the task in front of them requires.
- Legacy protocols still enabled on the internal network out of habit or compatibility, offering weaker authentication than anything newer replacing them.
- Old or forgotten hosts: a decommissioned application still running on a server nobody remembers to patch, discoverable the moment anything scans the internal range.
None of this shows up in a firewall audit, because none of it is a firewall rule. It shows up only when someone actually enumerates the internal network — host by host, service by service — the way the internal half of a network security assessment is scoped to do.
Active Directory and the paths an attacker actually takes
For organisations running Windows-centric environments, the internal attack surface has a specific shape, and it is one that MITRE ATT&CK documents at length under lateral movement and credential access. Active Directory is the component most internal compromises eventually touch, because it is the system that decides who is allowed to do what across the whole estate — which makes it the highest-value target once an attacker has any foothold at all, and also the component least likely to have been examined by a purely perimeter-focused programme.
The patterns a genuine internal assessment looks for are well established and not exotic: credential reuse across machines, so that compromising one low-privilege workstation yields a local administrator hash that turns out to be identical on fifty other machines; over-broad group memberships, where users or service accounts carry far more delegated rights than their actual job requires; unconstrained delegation and misconfigured trust relationships that let a compromised service account impersonate other identities; and stale accounts — former staff, decommissioned service accounts, test accounts — that still authenticate and still carry whatever privilege they were given when they were created. Chained together, these are frequently how a single compromised laptop becomes a domain-wide compromise, and it happens without a single firewall rule being violated, because Active Directory operates above the layer firewalls control.
Lateral movement, in this context, is the general term for an attacker using a foothold on one host to reach, authenticate to, or take over additional hosts and accounts elsewhere on the same network — the stage of an intrusion between initial access and reaching whatever the actual objective is.
Where the two disciplines actually meet
None of this is an argument against firewall audits — it is an argument against treating one as sufficient on its own. The rule-base review and the network assessment answer different questions and are genuinely complementary: the assessment shows you what is reachable in practice, and the rule-base review usually explains why — which permissive rule, which forgotten exception, which drift from intended policy created that reachability in the first place. Testing shows the symptom; the firewall audit more often shows the cause. Run only the audit and you get a tidy configuration with an unverified claim of what it achieves. Run only the assessment without ever cleaning up the rule-base it identified as the route in, and you fix the same finding again next year.
The estates most exposed to this gap tend to share a profile: infrastructure grown over many years through mergers, office moves, and cloud migrations, without one team ever holding a complete, current picture of it; environments where segmentation was designed once and never re-verified after the next change; and any organisation that has, so far, only ever been asked by an auditor or insurer for a firewall review rather than a test of what an attacker inside the network could actually reach — a distinction worth raising directly with whoever is asking, since the two are not interchangeable evidence.
What a balanced programme looks like
If your most recent network-security spend was a rule-base clean-up and nothing has ever attempted to move laterally from an assumed foothold on your own network, you have evidence about your policy and none about your exposure. The two are not the same deliverable, and treating a firewall audit as a substitute for internal testing is the single most common gap we see in network security programmes that otherwise look mature on paper. If you are trying to work out whether your next spend should be a rule-base review, a full internal-and-external assessment, or both run together for a complete perimeter picture, that is a scoping conversation worth having early — it is usually a short one once we know what your network actually looks like today.