Products

OT Asset Inventory

An offline tool that would build an asset inventory of an industrial network from a saved packet capture, without touching the live network.

Idea gate An idea under review. Work starts only if it passes.

The problem

Small water, power and facility operators are expected to keep an inventory of their control systems, often without a security team, and CISA has published guidance on how to build one.

NSA's free GRASSMARLIN did this from packet captures for years. It is no longer maintained and its repository is archived. Active scanning is not a safe substitute on many control networks, because a scan can crash a controller.

What it would do

Read a saved packet capture and list the devices in it, the protocols they speak and which devices talk to which.
Parse Modbus, DNP3, EtherNet/IP, S7 and BACnet.
Map the inventory to CISA's asset inventory categories and produce a report you can keep as evidence.
Run on Windows, Mac and Linux using only the Python standard library.

What it would never do

Send a packet onto the network it describes. It would read saved captures only.
Connect anywhere while it works. It would run offline.
Read a capture without limits. Every protocol parser would be fuzz tested, with limits on size and depth.

Reviews

Every product passes three reviews: an idea review before design, a design review before code, and a release review before it is listed here. A product that fails one is stopped, and the reason is recorded.

Idea
Not yet held

The idea review asks whether CISA's free Malcolm toolkit already serves small sites well enough, and whether small operators want this, before any design work.
Design
Not yet held

Only if the idea review passes.
Release
Not yet held

Only if it is built.

What this page will carry at release

The version number and its release notes.
A summary of the release review: what was tested, what was found and what was fixed.
A demo run against a synthetic or lab capture, never a real operator's traffic.
A network table generated from the code.
The hash of the release archive tied to its source tag, published in two places.
The fingerprint of the signing key.
The commands to check all of the above yourself.

The rules it is built under

The same rules apply to every product we build. The security page covers them in full. The products page lists the others.

Auditor by default: Every tool observes, inventories and reports. Read-only is the default and needs no confirmation.
Active only on targets you placed in scope: Anything that probes a live system runs only against a target inside a scope you set, after a confirmation that software, including an AI model, cannot give on your behalf.
Never a false clean: Results say what was checked and what was not. No tool will tell you something is safe.
Threat model before code: Each module gets a written threat model at its design review, before any code.
Fuzzing on every parser: Anything that reads untrusted input gets a fuzz harness and limits on size, depth and paths.
Signed and reproducible builds: Releases will be signed, with separate keys for separate jobs, and built so that anyone can match the published source to the published binary.
Outside review once there is revenue: A security firm checking its own work is not an independent check, so an outside firm will review the platform once it earns.

Follow: release notes will go out in the research feed as posts of kind Tools, and our open-source code is on GitHub.