Asset Inventory From Traffic You Just Made

The hardest part of OT asset inventory is not the tool.

It is finding traffic to point it at.

The tool installs in five minutes. Plant traffic does not. Public captures are small, old and cleaned up, and your own plant is the one thing you are not allowed to touch.

So We Closed The Loop

The lab runs a real process — real PLCs, real SCADA, real protocols moving between them.

Traffic is captured while you work, and the PCAP goes to the asset inventory tool automatically.

You do not export. You do not upload. You do not convert anything.

What Comes Back

• A device inventory, built from traffic you just generated
• A Purdue level for each device
• A cross-zone violation when Level 3 talks directly to Level 1
• CVE matches against what was found

Why This Is How You Learn It

Change something in the lab. Add a device, change a route, open a path that should have stayed closed.

Then look at what the inventory says now.

That loop is the entire skill:

An inventory is a claim about what exists. The only way to learn whether a claim is right is to change the thing it describes and watch whether the claim keeps up.

First Tool Wired In

The first integration is Gridwolf — open source, MIT licensed, fully passive.

It reads Modbus, S7comm, EtherNet/IP, DNP3, BACnet and IEC 104, and its rules map to ATT&CK for ICS. If you are checking those mappings, note that several ICS technique IDs changed recently: labshocksecurity.com/news/attack-for-ics-v19-sub-techniques-revoked-ids

More tools go through the same pipe. The pipeline is the platform, the tool is the plug.

OT security must be testable.

Not documented.

Try It Yourself

• Start free: github.com/zakharb/labshock — runs locally with Docker, no cloud.
• Run a lab, then open the inventory and compare it against what you know is deployed.
• Open a path that should be closed, re-run, and confirm the cross-zone violation appears.
• Which asset inventory tool should we wire in next? discord.gg/bpmaQFfW76