By RUGERO Tesla (@404Saint)
The air-gap is a lie
Every ICS engineer will tell you their critical systems are air-gapped. Isolated. Untouchable.
Then you watch someone walk up with a USB drive.
The air-gap was never a technical guarantee. It was a policy. And policies fail the moment someone needs to transfer a firmware update, a vendor installer, or last week's historian backup onto a machine that "can't" touch the internet. Removable media is the bridge that's always there, always trusted, and almost never inspected properly.
Stuxnet didn't compromise Iranian centrifuges through a network intrusion. It rode in on a USB drive. That was 2010. The vector hasn't changed.
Standard antivirus doesn't help much here either. It's built for IT environments. It doesn't know what Modbus looks like, or why a legitimate-looking Siemens installer with suspiciously high entropy should be treated differently than a clean one. It scans for known signatures and moves on. In ICS/OT, what you're looking for is often subtler than that.
So I built something for this specific problem. I called it Guardian-OT.
What it actually does
Guardian-OT is a forensic audit tool for removable media before it touches a critical engineering workstation. Not a full-blown enterprise platform. A focused, high-signal tool that tells you what's actually on a drive and whether it matches what's supposed to be there.
It runs four checks, and each one is doing something different.
Hardware fingerprinting
The first thing Guardian-OT does is ignore the filesystem entirely and go straight to the hardware. It extracts the USB hardware UUID and checks it against a local SQLite vault of known, approved devices.
This matters because USB spoofing is real. You can make a drive present itself as something it isn't at the filesystem level. Hardware UUID is harder to fake. If the ID is unknown, or if it doesn't match what the vault expects for that device, the audit flags it before a single file gets scanned.
Recursive integrity verification
Every file on an approved drive gets tree-hashed and stored during the first "known-good" scan. Every subsequent scan compares against that baseline.
If anything has changed since the last clean scan, even one file, it triggers a full deep audit. Not a warning. A full forensic pipeline. The assumption is that in an ICS environment, unexpected changes to a trusted drive are not a routine event.
The forensic pipeline itself
Three things run here in sequence.
YARA scanning hunts for ICS-specific strings — Modbus, S7Comm, Ethernet/IP function codes, things that have no business being in a standard office document or a routine software update. If those strings show up somewhere unexpected, that's worth knowing about.
Entropy analysis scores every file between 0.0 and 8.0. Anything above 7.8 gets isolated for manual review. Encrypted payloads and packed executables both score high. So does compressed data. The score alone doesn't condemn a file but it tells you where to look first when you only have time to look at ten things out of a thousand.
Magic number validation checks whether a file's actual header matches its extension. Hiding a script inside a file renamed to look like a PDF is a trivially simple technique that still works surprisingly often. This catches it.
The researcher dashboard
Raw JSON forensic output is useful for pipelines. It's not useful for a human who needs to triage a drive in the field.
I added a Streamlit dashboard that takes that output and turns it into something you can actually act on. The goal is fast separation: out of 1,000+ assets on a typical drive, you want to get to the 10-20 things that actually need eyes-on review without wading through everything else manually.
Why I'm building this
I'm four to six years into a long-term roadmap toward becoming a full-time ICS/OT security researcher. For most of that time I've been learning how to use tools other people built. Guardian-OT is the point where I started building my own.
That shift matters to me. Understanding how a forensic tool works at the implementation level is different from knowing how to run it. You find the edge cases. You understand why certain signals are meaningful and others aren't. You build intuition that doesn't come from reading documentation.
Guardian-OT is the first step in a forensic workflow I want to make resilient and reproducible for industrial environments. There's more coming.
github.com/404saint/guardian-ot
If you work in OT security or you're on a similar path, I'd like to hear what you think. Issues and PRs are open.
Built by RUGERO Tesla · GitHub: @404Saint
Top comments (0)