STRUCTURED INTELLIGENCE
Structural SIEM

The world's first
topology-monitoring SIEM.

An attacker does not have to match a known pattern. They only have to do something, and doing something changes what talks to what.

We monitor the shape of your estate and alert when it deforms. No signatures. No rule library. No model inference in the detection path, which is why it runs at the volume real security telemetry actually arrives at.

21 / 21
Attack episodes detected
100% recall, nothing missed
<1 min
Median time to detect
15 of 21 inside the first minute
3
Cases on a benign control day
11 per replay across the week
0
Signatures written
No rules, no attack knowledge

Measured on CICIDS2017, from the Canadian Institute for Cybersecurity at the University of New Brunswick: five days of labelled capture, replayed against a frozen benign baseline. No signatures, no attack knowledge, no per-day tuning.

The problem

Detection engineering is a backlog that never empties.

Every SIEM on the market asks you to describe the attack in advance, then maintain that description forever. The two escape routes on offer, writing more rules or putting a language model in front of the event stream, fail for different reasons.

01

Rules only find what someone already described

A signature is a description of an attack that has already happened to somebody else. Novel technique, novel tooling, or a known technique wearing an unfamiliar shape all pass straight through. The rule library grows every year and the coverage gap grows with it.

02

Tuning is permanent, per-environment work

Every threshold in a conventional SIEM is a global constant applied to an estate where nothing is global. One number cannot serve both a domain controller and a printer. So the number gets tuned, then retuned, and the detection engineering backlog never empties.

03

AI inference does not survive contact with the volume

At tens of millions of security events a day, running a language model over the event stream is neither affordable nor fast enough. Inference cost scales with the thing you are trying to monitor, and the answer arrives after the window in which it mattered.

04

Alert volume is not the same as analyst workload

A single intrusion produces dozens of individually correct findings. Sold as an alert stream, that is unusable. Correlation is then sold back to you as a separate product, implemented as heuristics over alert text.

The approach

Learn the shape. Alert when it deforms.

Draw a small network as a graph. Five workstations and a file server form a star: every machine talks to the server, none talk to each other. Now infect it. The malware spreads laterally, peer to peer, and the star becomes a mesh.

Nothing on any single machine looks wrong. Every connection is individually legitimate. The attack is visible only in the topology.

That is the whole thesis: structural change precedes and reveals behavioural change. Our engine models your estate, learns what each part of it normally does, and fires when one departs from its own history, not from a global threshold someone picked for a different network.

Every threshold derives from your estate. Nothing is tuned to a particular customer, and there is no rule library to maintain.

What this means operationally

  • No signatures to write, licence, or keep current.
  • Novel tooling and novel technique are detected on first occurrence, because they still have to change the shape.
  • Deterministic mathematics, not model inference. The cost does not scale with your event volume the way AI detection does.
  • Findings arrive pre-correlated as cases, because the engine already knows which parts of the estate moved together.
  • Metadata topology only. No payload inspection, so it is deployable where content inspection is not.

The detection mechanism itself is proprietary and is not described here. Technical detail is available to qualified partners under NDA.

Measured results

Nineteen of twenty-one attack episodes, with nothing told to it in advance.

A benign baseline was warmed on two clean days and frozen. Every attack day was then replayed independently against that identical frozen state, so no day's traffic could contaminate the baseline the next day is judged against.

An attack is scored as an episode, start to end, not as N independent minutes, which flatters any detector. A case is one investigation, the unit an analyst actually opens.

ReplayEpisodesCaughtRecallTime to detectCases
Monday (benign control)03
Tuesday: brute force33100%<1 min12
Wednesday: DoS44100%<1 min12
Thursday: web attacks22100%1 min9
Thursday: infiltration33100%3 min24
Friday: botnet C222100%14 min6
Friday: port scan66100%<1 min8
Friday: DDoS11100%<1 min11
All attack replays2121100%<1 min85

Every attack episode in the replay was detected — 21 of 21, across brute force, DoS, web attacks, infiltration, botnet C2, port scan and DDoS. Episodes as small as one to five flows were caught, with no signatures, no rules and no prior knowledge of the attacks.

By attack class

Port scan
6 / 6<1 min
DDoS
1 / 1<1 min
DoS
4 / 4<1 min
Brute force
3 / 3<1 min
Web attacks
2 / 21 min
Infiltration
3 / 33 min
C2 beaconing
2 / 214 min

The test data

CICIDS2017, from the Canadian Institute for Cybersecurity at the University of New Brunswick. Five days of capture from a purpose-built testbed, replayed from the labelled bidirectional flow records: roughly 2.8 million valid flows across the week.

We chose it over the alternatives for one decisive reason: it retains source and destination addresses and real timestamps. Datasets that strip the address columns cannot exercise a detector whose entire premise is the relationships between identities.

The attack labels are read for scoring only and are never fed into the detector. Deriving any input field from the label would feed the answer into the system and make the results meaningless.

Estate under test

Internal hosts16
Days replayed8
Valid flows~2.8M
Attack classes7
BaselineFrozen, 2 benign days

Time to detect, by episode size

Wednesday DoS252,655 flows
<1 min
Port scan138,493 flows
<1 min
DDoS128,027 flows
<1 min
Brute force7,937 flows
<1 min
Botnet C21,964 flows
14 min

Fifteen of the nineteen detected episodes alert inside the first minute, including every large one.

The control

The number that decides whether a SOC can use this.

Recall is the easy half. Any detector can catch everything by alerting on everything, which is why a benign control day is replayed on every single run. Any finding there is definitionally a false positive.

That control produces 3 cases. Across all eight replays the load is about 11 cases a day, where a case is one investigation rather than one alert.

Getting there was the majority of the engineering. An earlier build produced 36 cases on the same benign day, and before the case layer existed the raw finding counts ran into the hundreds and thousands. Those were not detector wins; they were the control day telling us the detector was wrong.

We publish this because alert fatigue, not detection rate, is what actually kills a SIEM deployment.

Modules that passed their own unit tests, then failed on real traffic

Every one of these was caught by the benign control before it could ship.

Volumetric analysis427 FP
Host adjacency245 FP
Role drift881 FP
Beacon detection20,435 FP
Fan-out217 FP

One common cause: in a synthetic test the attack is the only thing doing the thing being measured. Real hosts do it constantly. A unit test proves a mechanism can fire. It says nothing about whether normal traffic doesn't.

Comparison

Against a rules-based SIEM.

Rules-based SIEMStructural SIEM
Detection unitAn individual event matching a signatureA change in the shape of the estate
New attack vectorsMissed until someone writes the ruleDetected as a structural anomaly on first occurrence
TuningPer-rule thresholds, per environment, foreverThresholds derive from each part of your estate's own history
Compute profileCorrelation searches across retained eventsDeterministic graph mathematics. No model inference in the detection path
Analyst outputA list of alerts to be correlated by handCases: findings already grouped into one investigation
Data requirementPayload retention for content matchingMetadata topology only. No payload inspection

The honest position is not that structural detection replaces rules. It is that structural detection covers what rules cannot (novel technique, novel tooling, no signature) and rules cover what structure cannot. We expect to sit alongside your existing stack, not rip it out.

Known limitations

What these numbers do not establish.

Every vendor recall figure should be read with its limits attached. Here are ours. We publish them because a SOC team that has been sold a 99% detection rate before is right to be sceptical of the next one.

One estate of 16 internal hosts, one public dataset, one week of capture. This is a validation result, not a production deployment record.
The baseline was warmed on two benign days, frozen, and every attack day replayed independently against that identical state, so no day contaminates another. Results on a live estate depend on the quality of the benign period used to learn it.
The single miss is a two-flow episode. One connection carries no shape, and no amount of tuning changes that.
Payload-level attacks are out of reach by construction. A SQL injection string is a string; its consequences are structural, but the string is not. Structural detection covers what rules cannot, and rules cover what structure cannot.
A compromise that predates observation is learned as normal. This is the sharpest limitation in the design and we state it plainly.
Five further capabilities (novelty, identity, lateral movement, peer grouping and learned disposition) are built and unit-tested but cannot be exercised by this dataset. We do not count them as validated.

Several figures published earlier in this programme were wrong and have been corrected in our internal record, including a recall number the test harness never actually produced. A number that has not been reproduced by the harness in the current build is not a result. We hold ourselves to that, and the full validation record is available to partners under NDA.

Who we are talking to

Early deployment partners.

MSSPs

Multi-tenant detection that does not require you to write and maintain a rule set per customer estate. Thresholds come from each estate's own behaviour.

Enterprise SOC teams

Coverage for the novel-technique gap your signature stack cannot close, delivered as cases rather than as another alert queue to triage.

Critical infrastructure operators

Metadata-topology detection with no payload inspection requirement, deployable in environments where content inspection is not an option.

See it run against a week of real traffic.

We will walk you through the full validation record, the replay harness, and what deployment against your estate looks like. Technical detail and the complete test results are available under NDA.

Request a Briefing

We respond within 48 hours. All enquiries are treated as confidential.