Many organizations believe they have solid cybersecurity protections in place. But what happens when those controls don’t work the way they’re supposed to?
In many cases, it’s not that security tools are missing – they’re misconfigured, misunderstood, or not being validated. Firewall rules are too broad. Network segments are connected in ways no one realized. Backups are stored on the same network they’re meant to protect.
Here are four examples, drawn from actual assessments, where OT security measures weren’t providing the protection companies thought they were.
Example 1: The Firewall That Wasn’t Really Protecting Anything
A facility had a firewall separating IT and OT networks. On paper, this should have been a solid layer of defense. But when we took a closer look, they found:
- Firewall rules were too loose, allowing more traffic than intended.
- Some rules were so broad they effectively let anything through.
- As a result, the IT and OT networks weren’t truly separated.
What could have helped
Regular firewall reviews and a look at actual network traffic would have uncovered these issues – before they became a risk.
Example 2: The “Segregated” OT Network That Had a Hidden Backdoor
At another site, leadership believed their OT network was completely separate from IT. Firewalls were in place, and management was confident that outside threats couldn’t reach their control systems.
But a closer look revealed:
- An engineering laptop was connected to both the IT and OT networks at the same time.
- This laptop also had internet access, creating a direct path into OT.
If that laptop were ever compromised (for example, by malware or a phishing attack), it could have created a direct path into the control system.
What could have helped
A basic review of how devices were connected would have flagged the risk and prevented an unsafe setup from flying under the radar.
Example 3: The Remote I/O System That Wasn’t So Isolated
A company managing tank farm operations relied on remote I/O to monitor and control fuel storage – something you’d expect to be tightly protected. They believed these systems were completely separate from the business network.
But after taking a closer look, they found a major security gap:
- The remote I/O system was on the same network as business systems.
- Instead of being isolated, it was exposed to other parts of the network that weren’t meant to interact with it.
This setup increased the chances that someone could unintentionally – or intentionally – affect the control system from another area of the network.
What could have helped
Simple network architecture reviews and traffic analysis would have made the overlap obvious and allowed teams to fix it.
Example 4: The Backup System That Could Have Been Locked Up Too
In many ransomware events, the biggest disruption isn’t stolen data – it’s that systems go offline and can’t be used.
That’s why backups are so important. But in one case, a company learned:
- Their backups were stored on the same network as the control system.
- If ransomware hit OT, it could also encrypt the backups, making recovery impossible.
- No one had tested how long it would actually take to restore operations.
What could have helped
Testing the restore process and storing backups on a separate network would have reduced the risk of losing everything at once.
How Do You Connect the Dots Between These Failures?
All of these examples had one thing in common: on paper, the right controls were in place. But in practice, those controls weren’t doing what they were supposed to. To truly understand whether your security measures are working, and whether they’re enough, you need a way to model the threats, gaps and consequences in your environment.
That’s where Cyber Bowtie Analysis comes in.
What Is Bowtie Analysis?
Bowtie Analysis is a visual risk modeling method originally developed for safety engineering, and it’s a powerful tool for OT security.
Here’s how it works:
- In the center is the Top Event – the moment when control is lost, systems become unavailable, or visibility is compromised.
- On the left are threats that could lead to that top event.
- On the right are the consequences – the operational impact if the event occurs.
- Between them are barriers: controls meant to prevent the threat or mitigate the consequence.
By mapping this out, Bowtie Analysis gives teams a clear view of:
- Where threats can exploit vulnerabilities
- What happens if a system is compromised
- Which controls are in place – and how effective they really are
Why We Use It
Our team uses Bowtie Analysis as part of a larger, consequence-based risk assessment model. It helps answer the question many organizations are struggling with:
Have we done enough?
We’ve applied this methodology hundreds of times across critical infrastructure environments.
It’s been especially helpful in cases where teams were unsure whether their existing controls were truly effective – or just looked good on paper.
Bottom Line:
Having cybersecurity controls in place isn’t the same as knowing they work.
Regular assessments help you find out whether your current setup is actually protecting you – or just giving a false sense of security. If it’s been a while since you’ve taken a close look at your OT cybersecurity, now’s the time – before a real incident forces the issue.
Not Sure If Your OT Cybersecurity Measures Are Actually Working?
We’ve helped organizations of all sizes take a closer look at their cybersecurity through focused, consequence-based assessments aligned with industry standards like ISA/IEC 62443-3-s.
If it’s been a while since you’ve had a real assessment, now’s a good time to talk. We’re here to help you figure out what’s working, what’s not, and what to do next.
