Challenge the Firewall: If Critical Infrastructure Does Not Need a Return Path, Remove It
By Benny Czarny
·
Critical infrastructure depends on connectivity, but every connection creates a potential path for attack. Through recent attacks, lessons from my new docuseries Into the Breach: Breaking the Firewall, and the evolution of isolation technologies like data diodes, we need rethink how our most critical systems are designed—and explore why governments and industries alike should begin with a simple question: Does this connection need to exist at all?
1. Why I Made Into the Breach
This weekend we released Into the Breach: Breaking the Firewall, the first episode I produced through Cyber King Productions, hosted by MythBusters’ Kari Byron.
Why did I decide to produce a cybersecurity show?
For years I have tried to explain critical infrastructure cybersecurity to customers, government officials, reporters, partners, friends, and sometimes even my own family.
It usually does not take very long before we talk about firewalls, air gaps, PLCs, IT, OT, segmentation, Zero Trust, data diodes, malware, and vulnerabilities.
And I can see when I start losing people.
At some point I realized that maybe the problem was not the audience.
Maybe cybersecurity has become terrible at telling its own story.
Think about what this industry deals with: nation-state attackers, power plants, water systems, satellites, factories, AI, quantum computers, and attacks that can create real physical consequences.
Yet somehow, we keep explaining all of this with another PowerPoint.
I wanted to do something different.
Take something people think they understand. Build a real experiment around it. Attack it. Test it. Bring in experts who know the technology. Make it visual. Make it entertaining. And most importantly, challenge assumptions that the cybersecurity industry has repeated for years without questioning enough.
That became Into the Breach. The series combines real cyberattacks, hands-on experiments, expert interviews, and demonstrations to make cybersecurity tangible and understandable.
For Episode #1, I wanted to start with one of the biggest assumptions of all:
“Put it behind a firewall and it is protected.”
Then, almost perfectly timed with the release of the episode, what’s going on in Minnesota took over the news cycle.
2. When Cybersecurity Starts Moving Water
On July 26 and 27, a coordinated cyberattack targeted operational technology at more than 30 community water systems in Minnesota. Minnesota activated its statewide cybersecurity response to investigate the attacks and support the affected communities.
Two days later, the FBI and EPA issued a broader warning. Since July 27, water and wastewater utilities in at least seven states had reported incidents involving internet facing PLCs.
Attackers remotely accessed devices, changed IP addresses and passwords, and caused operators to lose monitoring and control. The FBI reported operational effects including loss of pressure and flooding. It also found similar third-party network configurations across several victims that may have allowed attackers to repeat the same success.
Stop and think about that.
We are talking about computers controlling water.
This is not somebody stealing a credit card number. It is not only ransomware encrypting an employee laptop.
When an attacker can interfere with a pump, valve, electrical breaker, pipeline, production line, or another physical process, cybersecurity becomes something much bigger.
It becomes a public safety issue.
And Minnesota is not the first warning.
3. We Have Seen This Before
Volt Typhoon is one of the clearest examples.
U.S. and allied cybersecurity agencies documented Chinese state sponsored actors establishing persistent access inside critical infrastructure organizations across communications, energy, transportation, water, and other sectors.
In one confirmed compromise, the attackers likely gained initial access by exploiting CVE 2022 42475 in an unpatched FortiGate 300D perimeter firewall.
Think about what happened there.
The device installed to protect the perimeter became the path through the perimeter.
That is not a criticism of Fortinet.
Every sophisticated software platform can eventually have vulnerabilities. Firewalls need patches. VPNs need patches. Operating systems need patches. Credentials can be stolen. Configurations can be wrong. Administrators make mistakes. Zero days happen.
That is the reality of software.
Ukraine showed the physical consequences even more dramatically. In December 2015, attackers compromised three electricity distribution companies. They moved from IT into operational systems, accessed the ICS environment through VPN infrastructure, operated electrical breakers, and caused outages affecting approximately 225,000 customers.
There is a big difference between an attacker reaching one of your computers and an attacker reaching the computer that controls your electricity.
The consequences can leave the screen.
4. I Am Not Against Firewalls
Let me make this very clear.
We need firewalls.
OPSWAT uses them. Our customers use them. Almost every modern network depends on them.
What I am challenging is the assumption that a firewall equals isolation.
I think of a firewall as a very smart security guard standing in front of a door. The guard knows thousands of rules. It looks at credentials. It examines traffic. It decides what is allowed to enter and leave.
That is extremely valuable.
But there is still a door.
If somebody steals the right credential, finds a vulnerability, takes advantage of a configuration mistake, or compromises the security technology itself, the path still exists.
So I started asking a different question:
What if nobody actually needs to come through the door?
Why spend so much money making the door smarter if the business requirement does not need a door in the first place?
That is where a data diode is fundamentally different.
A data diode is not a better firewall.
It solves a different problem.
Instead of relying only on software rules to decide which traffic is allowed, a data diode can enforce the direction of communication in hardware.
NIST has demonstrated exactly this type of architecture in an electric utility reference design. Operational monitoring data travels outward through a unidirectional gateway, and the architecture prevents data from traveling back through that same connection into the protected industrial environment.
That is a fundamentally different security property.
5. No Unnecessary Return Path
I think the principle is simple enough that it deserves a simple name:
No Unnecessary Return Path
A water utility may need to send alarms.
A power station may need to send telemetry.
A factory may need to export historian information.
A pipeline operator may need centralized monitoring.
A defense environment may need to export logs.
All of that information can leave the protected network.
But if there is no operational reason for communication to come back through that same boundary:
Why create the return path?
I know not every environment can work this way. There are legitimate reasons for remote maintenance, remote control, software updates, acknowledgments, and other bidirectional processes.
If you need the connection, protect it aggressively.
The FBI’s latest guidance for the water sector tells operators to remove PLCs from direct internet exposure, mediate remote access through secure gateways, restrict access, validate PLC project files, secure cellular connectivity, and maintain the ability to operate manually after an incident.
I agree with all of that.
But I think we have the default backwards.
Today we too often begin with connectivity and then ask the cybersecurity team to protect it.
For our most important systems, we should begin with isolation and ask:
Why do you need to open the path?
6. One Way Is Not Enough — And it Has to Be Clean.
There is an important part of this discussion that is sometimes missed.
A data diode solves direction.
It does not automatically solve content.
If a malicious file is allowed to move in the permitted direction, it is still malicious.
If a compromised software update crosses the diode, it is still compromised.
If someone carries a poisoned document into an isolated environment, isolation alone does not make the document safe.
That is why I believe the next generation of this architecture needs to be:
One Way and Clean
Use the diode to control the direction.
Then inspect what is allowed to cross.
That means combining hardware enforced one way communication with technologies such as Multiscanning, Data Sanitization and Deep CDR™, sandboxing, DLP, AI-based content inspection, file validation, and policy enforcement.
OPSWAT’s current MetaDefender architecture already combines Deep CDR, Metascan™ Multiscanning, sandboxing, Proactive DLP, and AI-based inspection in controlled file workflows, and our cross-domain products combine these prevention technologies with secure transfer architectures. MetaDefender™ Core can use more than 30 antimalware engines in parallel as part of these workflows.
The goal should not simply be:
Can this data move from A to B?
The questions should be:
Should it move in this direction in the first place?
...or better still...
Should this content be allowed across at all?
That is the difference between simply creating an air gap and creating a secure process for moving information across one.
7. My Challenge to CISA
I want to challenge CISA, but I also want to give them credit.
The direction is changing.
A new 2026 critical infrastructure isolation guide says operators should be able to isolate vital OT systems from other networks, describes physical isolation as the most effective form of protection, and specifically recognizes data diodes and cross domain solutions as providing higher assurance than standard network gateway architectures when properly implemented.
That is important progress.
My challenge to CISA is this:
Do not make isolation only something we prepare to do during a crisis. Make it part of how we design critical infrastructure from the beginning.
Before asking how we secure remote access, ask whether remote access is actually required.
If the answer is yes, secure it.
If the answer is no:
Remove the path.
8. Regulation Should Ask a Better Question
This questioning extends beyond the borders of the United States. Europe’s NIS2 framework now establishes a common cybersecurity framework across 18 critical sectors, including energy, transportation, health, drinking water, wastewater, digital infrastructure, manufacturing, government, and space.
Governments around the world are increasing requirements around risk assessment, authentication, incident reporting, patching, monitoring, detection, and recovery.
All of that matters.
But I think regulators need to add more questions:
Why does this connection exist?
How are you protecting the connection?
Does the connection need to exist at all?
These questions should be asked everywhere critical infrastructure operates.
9. America Should Lead
All that said, I believe the United States should move first.
I am calling for a U.S. Executive Order based on one simple principle:
No Unnecessary Return Path.
For our most critical infrastructure it boils down to five concepts:
No critical controller should be directly exposed to the internet.
If data only needs to go out, make the connection one way, and make the data clean. Use hardware enforced, one-way communication together with content security, multiscanning, data sanitization, and Deep CDR so information crossing the boundary is inspected and sanitized.
Remote control should be an exception. If it is truly needed, secure it, restrict it, monitor it, audit it, and make sure operators can recover safely.
Help smaller utilities modernize. A small water system should not be expected to defend itself against sophisticated cyber actors with the resources of a national utility.
Set the security requirement, not the vendor. Governments should define the outcome and let the industry compete to deliver the best solution.
The principle is simple:
If traffic does not need to come back, remove the return path. And whatever crosses the boundary should be clean.
America can lead, but I would encourage governments around the world to adopt the same principle.
10. Quantum Is Teaching Us the Same Lesson
There is another reason I think we should act before the next crisis.
On June 22, 2026, the White House issued Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks. It recognizes the future threat large scale quantum computers pose to widely used cryptography, accelerates the federal transition toward NIST approved post quantum cryptography, and directs agencies to help critical infrastructure owners prepare for their own migration.
I like this logic.
Act before the crisis.
That is prevention.
I think the same philosophy should apply to critical infrastructure architecture.
There is also an interesting connection between data diodes and the quantum era.
To be clear, a data diode does not make today’s cryptography quantum resistant. Post quantum cryptography solves that mathematical problem.
But encryption keys still live somewhere.
They are generated somewhere. Stored somewhere. Used somewhere.
HSMs, key management systems, quantum computing infrastructure, and future quantum networks will still involve hardware, software, operators, and network connections.
They will still have attack surfaces.
Imagine a highly sensitive cryptographic environment that needs to send telemetry, audit information, security events, or approved computational results outward, but has no reason for an ordinary enterprise network to initiate communication back toward the systems protecting those keys.
I believe this is an important future application for hardware-enforced isolation. This is an architectural inference, not a replacement for post-quantum cryptography. NIST’s unidirectional architectures show how one-way paths can reduce network reachability, while the new federal quantum policy shows how important protecting future cryptographic systems is becoming.
My view is simple:
Post-quantum cryptography protects the mathematics.
Hardware-enforced isolation can protect the path to machines by protecting the mathematics.
For our most sensitive environments, I believe we will need both.
11. We Invested in This Belief
I should disclose the obvious.
OPSWAT sells data diodes.
But we did not suddenly discover this architecture because Minnesota was attacked last month, and we did not enter the market because I decided to produce a cybersecurity show.
For years, OPSWAT has integrated our technologies with diode vendors inside sensitive government, defense, energy, and industrial environments. The more time I spent with these customers, the more convinced I became that if our mission was really to protect the world’s critical infrastructure, we needed to own more of this technology ourselves.
We did something that was not obvious for a company historically known for software.
We bought two hardware companies.
In 2021, OPSWAT acquired the assets of Bayshore Networks, bringing industrial security, OT, ICS, and secure data transfer capabilities into the company.
In 2024, we acquired Fend, expanding our data diode capabilities and giving us another architecture particularly well suited to distributed and remote infrastructure such as water utilities.
And acquiring those companies was only the beginning.
We have tripled the R&D resources behind this area.
We also made another decision.
If we are going to build hardware that governments and critical infrastructure operators depend on, I want to know where that hardware comes from, who assembled it, which components went into it, how it was tested, and how we control its quality.
So, we brought manufacturing much closer to us.
In November 2025, OPSWAT opened a production facility in Tampa, Florida, bringing hardware production in house and increasing our control over quality, compliance, product development, and supply chain integrity.
And Tampa is not the end of this strategy.
We are building additional regional capabilities and hubs in Europe and Asia, because governments increasingly care not only about what cybersecurity technology does, but also where it is built and who controls the supply chain.
This is not a side project.
It is a long-term bet on where we believe critical infrastructure security needs to go.
12. This Is Prevention First
All of this comes back to the argument I made in my book, Cybersecurity Upside Down.
Our industry has become incredibly good at detecting bad things after we give those bad things a path into the environment.
We absolutely need detection. We need SOCs, threat intelligence, monitoring, and incident response.
But prevention should come first.
If you can remove malicious content before it executes, remove it.
If you can eliminate an unnecessary privilege, eliminate it.
If you can isolate the critical environment, isolate it.
And if a critical system does not need an inbound network path:
Remove the path.
That is prevention first cybersecurity.
13. Why I Created CyberKing Productions
And this brings me back to where this story started.
Into the Breach is not just another OPSWAT marketing video.
I created Cyber King Productions because I believe cybersecurity needs a completely different way of communicating with the world.
I do not want to make corporate commercials.
I want to tell cybersecurity stories that people actually want to watch.
Take something everyone thinks they understand. Find the assumption underneath it. Build an experiment around it. Test it. Attack it. Maybe break it. Maybe blow something up. Then bring in experts and explain what actually happened.
That is what we tried to do with the first episode of Into the Breach, “Breaking the Firewall.”
Before the official release, the episode started playing on United Airlines. Then at Black Hat something happened that made me particularly happy; people came to the OPSWAT booth after watching the episode on their flight, and some wanted to talk to us about data diodes.
Think about that.
Someone watched a cybersecurity show on an airplane, arrived at Black Hat, came to our booth, and wanted to understand how to better protect a critical network.
That is exactly what I hoped Cyber King could do.
14. The People Behind Cyber King
Having an idea is easy. Producing it is not.
I serve as the Creator and Executive Producer, but was fortunate to have an incredible team behind the first episode:
Kari Byron was Host and Executive Producer
Berry Blanton was Director and Producer
Jason Richard was Producer and Editor
Linda Wolkovitch was Producer
Erik Weinbrecht was Writer
Joanna Shemesh was Associate Producer
Scott Sorensen was Director of Photography
Shannon Wilkerson handled 3D and Motion Design
Christopher Gore Gammon was Assistant Editor
The production team also included Jesus “Chuy” Valadez, Mahlik Hailu, Jan Reichle, Christina Robles, Jesus Ocejo, and Roman Molla.
...and, of course, Maxx the Robo Dog played himself.
A very special thank you to Kari, Berry, Jason, Erik, and everyone who helped take this from an idea and make it real.
15. This Is Only The Beginning
Episode #1 was about firewalls.
We are not stopping there.
Episode #2 is in production right now, and I already have narratives and ideas for many more episodes.
There is no shortage of cybersecurity assumptions worth challenging. Air gaps, removable media, AI, ransomware, supply chains, cloud security, Data Sanitization, Zero Trust, critical infrastructure, quantum, and plenty more.
But I also do not want Cyber King to become only about OPSWAT.
I want other people in the industry involved.
If you are a current OPSWAT technology partner or channel partner and you have a technology, customer story, cybersecurity assumption, or experiment that you think deserves to be put on camera, reach out to me directly.
Maybe we will test something together. Maybe we will attack it. Maybe we will prove it works. Maybe we discover that conventional wisdom is wrong.
In the end? Maybe we produce an episode together.
Send me a private message on LinkedIn or Facebook.
I am serious.
Cybersecurity has enough webinars and PowerPoints.
I want to make cybersecurity something people actually want to watch.
Watch Into the Breach: Breaking the Firewall. Share it. Challenge CISA. Challenge regulators. Challenge OPSWAT. Challenge me.
But most importantly — go back to the architecture protecting your own critical systems and ask one simple question:
Does traffic really need to come back?
If the answer is “yes,” protect that connection like your operations depend on it.
If the answer is, “no?”
Remove the path.
And make sure whatever you allow across is clean.
Watch Into the Breach: Breaking the Firewall, Episode #1:
Episode #2 is in production right now. If you are a current OPSWAT partner and think we should make an episode together, message me.