What goes in.
What comes back.
SIET sits between your telemetry and the SIEM you already run. Telemetry arrives in a schema you almost certainly already produce, and what comes back is three streams your SIEM reads as ordinary indices.
There is no console for your analysts to learn and no second queue to work. SIET is judged by what arrives in the tool your team already lives in.
Normalised telemetry, however you already ship it.
SIET reads every field you send. What it needs is not a particular subset, it is a consistent schema: ECS or OCSF. If your pipeline already normalises to one of those, which most do, the integration is pointing it at an endpoint.
Normalisation stays on your side of the line, deliberately. You already own the mapping for your own sources, you know when they change, and a translation layer in the middle would be one more thing to maintain between your logs and your detections.
Over HTTP
POST batches to the ingest endpoint. NDJSON, a JSON array, or a single document. Authenticated per source, so a compromised token affects one feed rather than the pipeline.
Responses are specific. A rejected batch names the reason, and a partially usable batch says how many records moved the graph and how many did not, rather than accepting everything and failing quietly.
As files
Drop files into a directory and SIET reads them in order. Useful where the sender is already writing to disk, or where a shipper is easier to point at a folder than at an endpoint.
Either route is the whole integration. There is no agent of ours to install on your endpoints and no collector to run alongside the ones you already operate.
Send process telemetry
Without it, SIET is a network detector. It sees an attack when the attack reaches for something, and it cannot see what stays local: credential access from memory, ransomware encrypting a local disk, defences being switched off.
Measured, on a chain that never touches the network. A document spawning a shell, which spawns two further processes: on network telemetry alone, nothing at all. With process telemetry included, one critical case naming five machines and the process that started it. Parent process is worth sending too: an office document spawning a shell and an administrator spawning a shell are the same event without it.
Three streams into the SIEM you already run.
Output is written as ordinary files. Whatever shipper you already use tails them into three indices, which means retry, backpressure and queueing are handled by tooling your team already trusts, and SIET going down does not lose anything.
There is no client of ours writing into your SIEM, and no integration to certify with your SIEM vendor.
Cases
Alert on every document
The analyst queue. One case is one investigation, already correlated, with the timeline and the machines involved attached. Cases open and update under the same identifier, so a developing incident threads rather than arriving as unrelated alerts.
Also carries observations: a departure on a single machine with nothing to correlate against. Those do not alert. They are there for hunting, and so that nothing is detected and left unsaid.
Logs
Never alert on this
The evidence. Raw logs, in full, but only the ones belonging to a case. An analyst pivots into this from a case identifier and finds exactly the records behind the finding, without querying twenty sources to assemble them.
This is the index that is not your whole log estate. Everything not implicated in a case never arrives here, which is where the indexing saving comes from.
Health
Alert on every document
For the engineers who own the pipeline rather than the analysts. Records SIET could not read, and why. A source that changes its schema, a feed that stops, a mapping that silently drops a field.
Ingestion problems are usually discovered weeks later, when somebody notices a gap during an investigation. This makes them arrive as alerts on the day they start.
Why the evidence index must never alert
This is the difference between a case queue and an alert stream. On the busiest day of our benchmark, alerting on the evidence as well as the cases would have produced 160,920 alerts. Alerting on cases alone produced 11. The evidence is there to be pivoted into once an analyst has a case in front of them, not to be notified about.
The rest goes to archive, not to the index.
Everything that is not evidence for a case is written to archive-class object storage, at full fidelity. Your own bucket, your own retention policy, your own encryption.
Nothing is dropped, trimmed or sampled. Every event is read before the decision is made, so what reaches the archive is what SIET understood and found unremarkable. That is why retention is unchanged while the indexed volume is not.
What goes where
Inside your environment.
Your infrastructure
Deployed inside your environment on commodity hardware. No cloud dependency, and nothing about your estate is reconstructable from what leaves it.
In memory
The structural model is held in memory rather than in a graph database, so there is no additional datastore for your team to run, back up or tune.
Alongside what you have
No rip and replace. Your existing detection content keeps running throughout, so you are never less covered during deployment than you are today.
Full integration detail on request.
Field mappings, endpoint reference, response codes and shipper configuration. Tell us which sources you run and we will tell you what the mapping looks like for them.