Most industrial security products watch for known-bad traffic. That misses the plant that is running perfectly and still cannot do its job.
Industrial security tooling is built around two ideas: match known-bad traffic, and list known vulnerabilities. Both are useful. Neither sees the plant that is running exactly as programmed and still cannot meet its target.
CAVER decodes more than a dozen industrial protocols off a mirror of the traffic, learns the control conversation between each source and each device, and models what the process is for. That last part is what produces findings nothing else reports: a pump that will never fill its tank, an interlock that quietly disappeared, a duty schedule that makes a healthy plant unable to do its job.
It installs in one of two modes, whichever fits the plant. Read-only mode is a passive sensor with no writes and no response actions. Interactive mode adds signed, audited response actions, including block and manage on OT, and you choose per site. The network sensor itself stays passive in both.
A plant is not an office network, and the tools built for one do not transfer.
CAVER charges a flat fee per deployment. There is no charge per gigabyte.
That is a pricing decision, but it only works because of how the system is built. On a storage lake, what a search costs depends on how many files it opens, not how many bytes you have kept. CAVER continuously merges small files into fewer, larger, sorted ones.
On a real production system running about 100GB a day, that change did two things:
Older data moves to a sealed tier that is simply a folder. Months outside your search window are never opened at all. There is no separate index to rebuild before a search or an alert can reach that folder: detections and dashboards query it directly, measured at 172 milliseconds for an alert and 76 milliseconds for a dashboard panel over a million events.
What this means for you: "how far back can I search" becomes a storage question, not a performance question. You stop choosing between logging the whole plant and staying inside budget.
CAVER decodes Modbus/TCP, DNP3, EtherNet/IP with CIP, S7comm, BACnet/IP, IEC 60870-5-104, OPC UA, PROFINET, IEC 61850 GOOSE and MMS, IEEE C37.118 synchrophasor and ANSI C12.22 metering from a SPAN port, a tap or a capture file, with device recognition for Schneider, Siemens, Rockwell, Honeywell and ABB. It also imports SCL substation configuration.
It reads the process, not only the packet headers: Modbus register pairs, DNP3 objects, EtherNet/IP tag values, S7 reads and writes, BACnet properties and OPC UA session identity, all joined into one cross-protocol operation verb so a write looks the same whichever protocol carried it. Devices identify themselves passively, from S7comm SZL, DNP3 and EtherNet/IP ListIdentity answers already on the wire. Nothing is probed.
Then it learns the conversation. Not the packets: the relationship.
Almost all of this works the day your data lands. One part does not, and it is worth being exact about which part, because the difference is usually explained badly.
That last point is the one that matters. "We found nothing" and "we are not ready yet" look identical on a screen, and only one of them is good news. A tool that does not distinguish them is quietly telling you that you are safe during the exact period it cannot tell.
Consider a pump filling a 30,000 gallon tank at 11 gallons a minute, scheduled to run three hours a day.
That is a fault in the goals, not in the equipment. Every product that compares traffic against signatures is silent, and the operator finds out when the tank is empty two weeks later.
CAVER proves it by arithmetic on day zero, and names the binding constraint: the three-hour duty window, not the pump. That distinction is what makes it actionable, because one is a settings change and the other is a capital project.
The engine multiplies gallons per minute by minutes and compares to gallons. A unit mismatch refuses to produce a verdict rather than coercing, because a confidently wrong number about a water system is worse than no number. A missing pump curve yields "cannot determine, here is what is missing", never an assumed value.
Three things produce unusual activity in a plant, and treating them alike is how an operations team learns to ignore a security tool.
CAVER separates them, and routes them differently. Operations findings go to operations, in their own vocabulary, and never into the security alert queue.
CAVER learns operating practice by shift, crew and season, classifies each deviation by likely cause, and shows competence and staffing drift. A pattern of the same mistake from the same shift reads as a training finding, not a security alert. Never-touch guardrails for protected points are enforced in code. An OT change ledger fed from CMMS work orders separates approved maintenance from unapproved change, and the finding records who approved it.
It also watches the logic itself. CAVER acquires controller programs, lifts them into a vendor-neutral control-logic representation, diffs them semantically and extracts the alarms, so a removed interlock shows up as a removed interlock and not as a changed binary. Siemens SCL and AWL and Rockwell L5X programs can be brought in through binary export, EWS or a backup share, with a program-change alert on any logic change outside a change window. Available on request, typically delivered within 30 days of order.
Shipped detections include IT-VLAN-origin initiation to six OT protocols, Modbus register sweeps, DNP3 Direct Operate and unsolicited bursts, S7 port-102 sweeps, deadband thrash, invalid state transitions, intermittent faults, machine-cadence breaks, and attack paths from enterprise to ICS. CISA ICS advisories feed the vulnerability screen, and advisories matched to your asset model are available on request, typically within 30 days. Control-chart run rules on process values and goals bound to specific equipment are available to design partners.
An operational recorder keeps a hash-chained record of process activity with redaction, and an evidence-bundle export packages an incident window for an investigator or insurer.
The OT work has its own place in the product, because a plant engineer and a SOC analyst are not the same reader and should not be handed the same screen.
It is a place in the product with its own entry, its own landing page and its own screens, not a folder of dashboards filed between two vendors you have never heard of. A plant engineer opening this sees their process, not a security product with their protocol names pasted into it. Design partners can run the process view, program timeline and cause panel against their own plant. The screens are in the order a plant person thinks in, and ATT&CK is last on purpose: it is what an auditor needs, not where an operator starts.
A panel whose field this deployment does not carry says so, by name, instead of drawing a zero. That distinction is not decoration: a zero means nobody did it and an absent field means we cannot tell, and a product that spells both of them the same way is quietly telling you that you are covered during the exact period it cannot see.
Rural control sites run on radio. A pump station reports back to the plant over an unlicensed 900 MHz SCADA radio, and that link sits before the firewall, before the VPN, outside every network segment, and off the internet entirely. Every control a site bought protects the wire. The radio is not on the wire.
So the softest way into a control process is often the one no security tool watches. Someone parks near the fence line with the same $25 receiver a hobbyist uses, listens to the traffic, and on most rural links reads it in the clear, because the radios were installed to move telemetry, not to keep a secret. Replaying or injecting a frame from there steps around the firewall, the VPN and the segmentation at once, and no exposure scanner will ever index a link that was never on the internet.
A software-defined radio the size of a thumb drive, plugged into the Windows machine already sitting at the site, listens to the band and learns its normal picture: which radios are present, on which frequencies, at what strength, hopping in what pattern. From that learned baseline it reports the departures rather than a wall of raw signal:
Watching a whole band around the clock sounds expensive to keep. It is not. The spectrum picture, the learned baseline and the departures together come to a few megabytes a day per site, because CAVER stores a compact snapshot and the events instead of a raw firehose. A site holds years of its own radio history and queries it the way it queries everything else, on storage it already owns.
And it lands where the plant already lives. A radio becomes an asset next to the controller it talks to, a departure becomes a detection on the same triage board as the wired alerts, and the link's health sits beside the process it carries. No platform that pairs a radio sensor to its own data store has drawn that picture, because no incumbent owns both halves.
The Caver RF add-on runs this sensor continuously and streams to your deployment. Sweeps, learned baselines and departures land as OCSF events beside the wired traffic. Sub-GHz SCADA radio profiles are configured per site and are available to design partners. The limit that never moves: the sensor only listens, it never transmits. Where a link is encrypted, reading it needs your own radio key, which on your own site you already hold. Everything else is receive-only by design, which is what keeps an RF capability on the defensive side of the line.
Most facilities run their physical security, badge access, door contacts, cameras, entirely apart from the cyber side. Caver takes the events those systems emit, not the raw video, into the same store as the network and identity record.
That is where the cross-silo detections live: a badge at a restricted door while that account is logged in elsewhere, a tailgate followed by a login from inside the room, a terminated worker whose badge and account are both used after the end date.
Events and counts only, never the raw video, and never a face. Anything that identifies or tracks a specific person is off by default and governed, an explicit and audited choice, so the capability stays on the defensive side of the line.
The reason teams turn detections off is not that the detections are wrong. It is that nobody is left to work the output.
Roughly a third of alerts are never investigated, an investigation takes over an hour, and an analyst closes twenty to thirty in a shift. A three-digit queue does not fit inside a staffed team by arithmetic. So CAVER ships named workers rather than more alerts: each one holds a single job, runs it on its own beat, and reports what it found.
An agent that speaks only when it finds something is indistinguishable from one that is broken, and the second is far more common than anyone admits. Every run is written down whether or not it found anything, carrying what it checked and over what window. A quiet morning becomes evidence rather than an absence of evidence.
Twenty of the thirty-six are rules, joins and thresholds: the same data gives the same answer on any day, and it can be explained to an auditor as a query. The other sixteen are baselines, peer groups and rarity, which is still arithmetic over your own history. Five can use a language model to write their summary in prose; turn it off and you lose the wording, not the finding.
Six of them are for a plant: setpoint drift against a learned band, a change made outside an approved window, the command chain behind an action, an integrator laptop, a device that has gone quiet, and load against forecast.
Every agent ships disabled, and you enable them one at a time from the product. That is deliberate. A plant has to agree which of its own changes are routine before an agent starts reporting them, and that conversation is yours to have first.
The workforce, the roster and the controls are shipped and in the product. The connections that feed individual agents land per data source, so an agent whose source is not connected yet says exactly that and names what it needs, rather than reporting a confident nothing. Ask us which of the thirty-six are live against your feeds before you count on any one of them.
Most estates buy endpoint telemetry from somewhere, and CAVER reads what you already run: CrowdStrike, Defender, SentinelOne, Sysmon, syslog and the forwarders on your servers. For the hosts where the options are bad, CAVER ships its own agent, Carbide, at no extra charge.
Sysmon process, network, file, registry, module-load, DNS and memory events all arrive as OCSF with the parent and child identifiers carried in the event, so a chain of executions joins across hosts rather than only inside one log line. A coverage screen shows which Event IDs are arriving now, which were seen in the last week and not in the last day, and which hosts are reporting. Every freshness figure is the time of the last event, never a count, because a count is satisfied by history: a source that died last week still has a large one.
| Same host, same workload | Kernel capture | Polling |
|---|---|---|
| 300 short-lived processes in a loop | 300 captured | 0 captured |
That row is why the agent exists. A process that starts and exits between two polls is most of what execution telemetry is for, and a poller cannot see it.
Carbide ships for Linux, Windows and macOS, installed as a system service. AIX coverage is available to design partners. Where you already run CrowdStrike, Defender or SentinelOne, Carbide sits beside it or CAVER reads that instead. Sysmon process, network, file, registry, module-load, DNS and memory events are all normalized to OCSF and addressed by the same detection content.
A vulnerability list ranked by severity score tells you what could be exploited. Two public feeds tell you what is.
CAVER ingests CISA's Known Exploited Vulnerabilities catalog, about 1,200 CVEs with confirmed exploitation, and FIRST's EPSS scores, an exploitation probability for roughly 200,000 CVEs, every day, and joins both onto your findings by CVE. The vulnerability screen gains an exploited-in-the-wild filter and a sortable probability column.
The effect on a real board is the difference between "4,000 findings" and "these eleven are being exploited right now, start here".
In 2026 CISA published an advisory in which two organizations faced the same red team with the same tradecraft and both fell to full domain compromise. One isolated three phished workstations in 10, 2 and 20 minutes and cut the command channel. The other actioned zero alerts. The difference was not the tooling and not the detection content; it was how fast a person acted on what the tooling already knew.
So CAVER measures that interval, per incident, from the case record:
We publish compression and query speed as first-class numbers because they are how CAVER beats a per-gigabyte platform. Time to contain is the number that decides whether any of that mattered, and it is on the same screen.
Real measurements from a production system handling about 100GB per day.
| Search | Time |
|---|---|
| Empty hour | 6 ms |
| One hour of data | 38 ms |
| 24 hours of data | 453 ms |
| 48 hours across two data centers | 627 ms |
Published figures show searches under 50 ms at the 95th percentile. The counterpart matters just as much: a 120-second ceiling still applies to large summarized searches, and searches over recent data under load run around 1.1 to 1.2 seconds. We are working on that ceiling. Both numbers are published because a best case is not a guarantee.
Ask any vendor, including us, for the range across your own data types during a trial. Not just one blended figure.
| Area | Typical SIEM | CAVER |
|---|---|---|
| Pricing | Per gigabyte; retention becomes a budget lever | Flat per deployment |
| Data ownership | Often vendor-hosted, proprietary format | Your storage, your keys, open format |
| Archived data access | A restore or rehydration job, often billed per query | Queried directly from your own bucket, no restore step |
| Encryption at rest | Assumed, rarely verified | Checked before start; refuses to run on storage it cannot confirm |
| Industrial protocols | Usually a separate product or none | More than a dozen decoded natively, included |
| Process understanding | Signature and CVE matching | Models what the process is for, and proves a goal cannot be met |
| Writing to equipment | Some products offer to "optionally correct" | Read-only mode never writes; interactive mode acts only through signed, audited actions you enable |
| Compliance evidence | A matrix of green ticks | Four OT frameworks, gaps printed |
| Your existing detection content | A rewrite, or left behind | Sigma, Splunk, Elastic, Sentinel, QRadar and Defender rules convert in, with a report on what did not |
| Evidence handling | Export logs; chain of custody is manual | Cryptographic custody, verifiable offline |
| Compliance reporting | Usually a separate product | More than 20 frameworks built in, signed export |
| Where it runs | Many are cloud only | Cloud, on-premise, air-gapped, single box |
An established SIEM has real advantages we will not pretend away:
Those are genuine switching costs. Our answer is the parallel-run and collector-only options above, which let you measure the difference instead of taking it on faith.
In August 2026 CISA published a Logging Reference Architecture implementing OMB memorandum M-26-14. It is not a list of sources to collect. It asks whether a logging capability can be shown to still be working, and it names the failure modes that make a healthy-looking estate useless.
| CISA asks for | CAVER |
|---|---|
| 4.7 Detect coverage gaps and delivery failures even when systems appear to be functioning | A source that goes quiet is a finding, not a quiet week. Agents heartbeat on the channel they ship on, and the coverage screens report last-seen time per source rather than a count. |
| 6.2.5 Endpoint records with process context rich enough for lateral-movement analysis and timeline reconstruction | Process lineage is part of the event contract, from Sysmon and from Carbide, so a chain joins across event types. |
| 7.1, 7.2 Durable normalization, with source-native context preserved | The raw event is kept and the normalized class is a layer over it, applied on the way in. Every event names the normalizer and version that produced its view. |
| 8.2 Integrity at collection, in transport, in storage and during access | The Evidence Locker: hashed on arrival, an append-only transparency ledger, signed export, verifiable offline by someone who does not trust us. |
| 4.5 Separate actively searchable data from lower-cost retrievable tiers, and decide how long each stays searchable | Set per index, and re-measured in the product. 48:1 compression (raw log volume against what the lake stores) is what decides whether the answer is a year or ninety days. |
The full mapping, in CISA's numbering, is at getcaver.com/cisa-logging. The most useful version of the conversation is section by section against your estate, including the parts where the answer is that you have work to do.
It is a reading of a public document against a product, done by the product's vendor. It is not an endorsement, a certification or a relationship with CISA, and nothing here should be read as one.
For the moment an incident becomes a legal, regulatory or contractual matter.
At that point someone outside your security team needs to trust the record without trusting your vendor. The Evidence Locker is built for that:
What this means for you: a record that stands up when an incident becomes a regulatory or insurance matter.
The AES-256 password protects the contents of the archive. The list of file names and their sizes is still readable without the password, which is how the ZIP format works. If a file name would itself reveal something, rename it before export.
One product, not a different tool for every environment.
CAVER runs on Kubernetes, a virtual machine, an isolated network, or a single box. License activation does not need an internet connection, and a lapsed license gives you a 14-day grace period rather than shutting off mid-incident.
This is your risk decision. Both are real products. Neither is a discouraged version of the other.
SAML 2.0 and OpenID Connect are both configured in the product: paste or fetch your identity provider's SAML metadata, or point at your OIDC issuer for discovery, then map the attributes or claims to roles. Test against the live provider before you can turn it on: enable is refused without a successful test in the last 24 hours. A saved change or a disable takes effect on the next request, no restart, and local login stays reachable so an identity-provider outage cannot lock your operators out. An OIDC client secret is sealed in the product's credential vault, never stored in the clear.
SCIM provisioning is configured the same way: an operator mints a bearer token for the identity provider, shown once and stored only as a hash, revoked on the very next request rather than the next restart. Group membership from SAML, OIDC, or SCIM maps to roles by the same rule.
Nothing here requires an agent on a controller, and nothing scans.
| Category | How it reaches CAVER | Status |
|---|---|---|
| Control systems | More than a dozen protocols decoded passively from a SPAN port or a capture file | Included |
| Historians and HMIs | Their own logs and databases | Ready-made packs |
| Existing OT security products | Dragos, Claroty, Nozomi, Armis, Forescout, Radiflow, Tenable OT, Defender for IoT and Zeek ICSNPP feed in alongside | Supported |
| Historians | sql_historian reads process history from any SQL database; operator-attributed events from ABB 800xA, Rockwell, Schneider and Siemens SIMATIC name the point, the value and the mode | Included |
| IT estate | The same platform covers it, so the two are searchable together. Network and server telemetry arrives by NetFlow, IPFIX, sFlow, SNMP polling and traps, syslog, Kafka, OTLP, Prometheus, or agentless Windows Event Forwarding that needs no collector box | More than 400 vendor packs |
More than 400 ready-made vendor packs ship for the common systems, so the bespoke work is the exception rather than the starting point.
A trial is 60 days, $25K to $75K, credited fully toward your first year if you proceed. If you are replacing Splunk, a displacement credit of 25% to 50% off year one is available separately.
Do not take this paper on faith. Test it directly: