Organizations have spent decades adding security controls to their networks. Firewalls, NAC, endpoint protection, identity systems, segmentation, and increasingly sophisticated detection tools are everywhere.
Yet one of the hardest Zero Trust principles to implement remains surprisingly basic: preventing a compromised system from reaching something it shouldn’t. Mostly because vendors are still having customers use VLANs behind a security construct, mistaking basic network segmentation for actual access control.
The idea of segmentation has existed for decades, but implementing and maintaining it across users, devices, IoT, applications, and changing network environments makes it even more difficult today.
Solving the problem requires add-on solutions, policies become broad, exceptions accumulate, assets are misclassified and controls that looked right when first deployed gradually stop reflecting how the environment actually operates.
The uncomfortable question is, How do you know if your controls will actually contain an attack before an attacker tests them for you?
Unfortunately, the answer typically comes to light after an actual attack.
As far back as 2023, attackers exploited an unpatched, unauthenticated remote-code-execution flaw in a NetScaler ADC appliance (CVE-2023-3519) to plant a webshell within an organization. From there, they mapped the victim’s Active Directory and pulled out data. Then to go further: they attempted to move laterally to a domain controller.
Interestingly, the attack failed to progress because this large customer had invested significant time, effort, and resources into segmenting their network — a proven security practice that demands substantial investment. They had the budget for add-on security tools, integration expertise, and ongoing IT operations resources, which is difficult for many organizations to accomplish for various reasons.
CISA’s advisory on the incident pointed out why: network-segmentation controls around the appliance blocked the movement.
The vulnerability was real, the exploitation was real, and the compromise was real. But none of that determined how the incident ended. What determined the outcome was the customer’s ability to spend the time and money to get ahead of the problem.
Getting in and moving throughout are different problems
It’s tempting to read incident reports in a single way:
Attacker finds a way in – Attacker causes damage
In practice, two different problems, governed by a different set of conditions.
- Getting in is usually about a vulnerability, phishing email, or a stolen credential. Those conditions matter, causing organizations to invest in patching, email security, and credential hygiene in an attempt to address them.
- What happens next is a different story governed by identity, reachability, and privilege. It depends on whether a compromised appliance can talk to a domain controller. Or if basic user accounts are allowed to reach privileged infrastructure. There’s also the ability for an account that no longer belongs to anyone to still establish a valid session or if contractor or supplier’s access comes with more network accessibility than the relationship actually requires.
Most coverage regarding breaches typically focuses on the first part of the story.
This blog series targets the second part because it’s the s part of the story that determines whether an incident stays contained or becomes a headline.
The question worth asking about any incident isn’t only how they get in. It’s
What did your network and access controls allow them to do next?
Why What Attackers Can Reach Comes as a Surprise
If unnecessary access privileges and stale trust factors are such consequential problems, the reasonable question to ask is why IT teams just don’t find and fix them ahead of time.
The honest answer is that nobody typically was thinking or looking ahead. It’s not because no one cares, but because the way most organizations govern their own posture doesn’t hold up over time!
- Segmentation gets reviewed at deployment, and then the network changes around for the next five years or more.
- A firewall rule gets added for a short-term migration project and never gets removed once the project ends.
- An account gets disabled in the HR system but not in every downstream directory that it was granted access.
Each of these is a small, reasonable decision made at the moment. None of them get revisited unless something forces a change.
A Zero Trust posture is treated as something that gets established once, rather than something that needs continuous updates and verification.
Two More Examples Of Preventable Breaches
In one scenario, CISA and the Multi-State Information Sharing and Analysis Center investigated a state government network after documents turned up on a dark web brokerage site. The cause of the incident traced back to the compromised account of a former employee, which allowed the user to authenticate to the internal VPN and query their Active Directory.
The advisory’s recommendation is telling: IT teams need to continuously remove and disable accounts and groups that are no longer required, particularly privileged ones. Nothing about that account’s authentication was invalid. What was invalid was the assumption that it still needed to exist.
In another scenario, CISA reported that Internet-connected Unitronics Vision Series programmable logic controllers – devices used in water and wastewater facilities, among other sectors, were compromised using default communication ports and default or absent passwords. At least 75 devices were affected.
These are not laptops that can be patched with an agent-based tool. They are exactly the kind of headless IoT, hard-to-manage assets that must be accounted for today: is it a known device, is it identity established, is it reachable even though it shouldn’t be, and is anything communicating with it that it doesn’t need to?
Different types of assets, with different attack techniques used, but the same underlying lesson: the network’s existing security posture – specifically weak isolation and access controls — determined how far the attacker could go after the initial compromise.
What Can Continuous Reviews Fix and Not Fix?
Asking these questions on an ongoing basis rather than just once at deployment, is what turns “we believe we have segmentation” into “we can currently show which paths exist, which are necessary, and which are exceptions.”
Done well, continuous posture assessments can surface unnecessary administrative reach, insufficiently isolated systems, access that outlived the relationship that justified it, and segmentation policies that no longer match what the network is actually doing.
It’s worth being equally clear about what this doesn’t do:
- It doesn’t predict which vulnerability will be exploited next
- It doesn’t detect an active intrusion
- It doesn’t replace vulnerability management, patching, endpoint detection, email security, or the rest of a security program
A clean read on posture is not a claim that an organization is immune to compromise. Nor can you determine that if some other preventive control will eventually fail, what happens next. That’s the scope of the problem.
Decisions Are Guided by Verified Evidence rather than unproven Assumptions
There is a critical difference between asking how a control works and asking whether it is sustainable.
- A question that always gets answered with a “yes”, regardless of whether the segmentation actually works and is consistent, current, enforced, or easy to maintain is, “Do you segment your network?”
No one ever believes they’ve not done enough. - The second is, “Can you show the effective communication paths between workforce endpoints and sensitive infrastructure, including current exceptions?” It’s a different kind of question pertaining to evidence, rather than a broad self-assessment. Evidence is what actually reveals whether a practice is comprehensive, consistent, and continuous – or whether it just exists on a list somewhere.
The distinction between controlled presence versus operational maturity is the thread running through the rest of this series.
What’s the Network Security Question Worth Asking Ourselves?
A Zero Trust posture assessment will not guarantee that an attacker won’t find a way in. But it can help determine how far an attacker can go if they do.Organizations often focus on identifying vulnerabilities and preventing initial compromise.
Equally important is understanding what happens when those defenses fail.
Can a compromised device reach systems it shouldn’t? Are identities properly verified? Is access limited to what’s necessary? Are sensitive systems adequately isolated?
These are questions organizations need to answer before an attack happens.
The objective is to proactively identify and address gaps in identity, verification, network segmentation, and least-privilege access that could allow an attacker to move further into the network.
We may not know where the next attack will come from, but we can control how much damage it can do.
This is the first in a series where I examine real, documented security incidents and the Zero Trust posture gaps they reveal. Sources: CISA Cybersecurity Advisories AA23-201A, AA24-046A, and AA23-335A.