Loader

Work

02 / 03 · Detect

CYBER-OS

One detection and investigation system, not a verdict engine: it produces evidence a person can actually audit.

Role
Design & build
Period
Since 2026
Layer
Detect

The problem

A classifier that says "malicious" and stops is not much use to whoever has to act on it. They have to decide something, and "the model said so" is not a reason. It is a shrug with a confidence score attached.

So the interesting problem in CYBER-OS was never the model. It was everything around it: carrying provenance the whole way through, correlating findings that arrive from completely different surfaces, and behaving honestly when a component is down instead of guessing.

Constraints

The network side observes and does not touch. That rules out a lot of the easy answers.

The system

  1. Network trafficunidirectional, read-onlyURL · Email · SMS · QRsubmitted for analysis
  2. Zeekconnection telemetryPlaywright sandboxSSRF-guarded
  3. RedpandaKafka-compatible busFeature extractionentropy, lexical, DOM
  4. DetectionXGBoost · Isolation Forest
  5. Evidence Fabricdetector version + input hash
  6. Caseentity graph · SOC view
Two inlets, live traffic and submitted content, converge on one evidence layer, so a case can cite where every part of it came from.

Two inlets. Live traffic goes through Zeek and onto a Redpanda bus. Submitted content (a URL, an email, an SMS, a QR code) goes to a sandboxed headless browser that renders it in isolation and records what it actually did, not what it claimed it would do.

Both converge on detection, and detection converges on evidence.

Detection

Four layers, because no single one of them is trustworthy alone:

  • Lexical and heuristic. Entropy and pattern work, for DGA-style domains and homoglyph tricks.
  • Tabular ML. XGBoost over Zeek telemetry, for the behavioural things: beaconing that is too regular to be human, exfiltration shaped wrong for its protocol.
  • Anomaly. Isolation Forest, for the traffic that is not like the rest without matching anything known.
  • Threat intelligence. Reputation, for what is already known.

The point of stacking them is disagreement. When three layers agree the case is easy; when they disagree, that is the case worth a person's time.

Evidence

Every detection carries which detector produced it, at what version, over what input hash. That is the Evidence Fabric, and it exists because of one question that has no good answer otherwise: six months from now, can you reconstruct why this was flagged?

The sandbox gets the same treatment in the other direction: it refuses RFC-1918 addresses and cloud metadata endpoints, because a tool that fetches arbitrary URLs on request is an SSRF primitive unless you make it not one.

Where it stands

Not yetDetection rateNot yet benchmarked against a labelled corpus under controlled load
Not yetThroughputNo sustained-load testing on representative hardware yet

I would rather publish that than a number I cannot defend. The detection logic runs and the pipeline holds together end to end; what it does not have yet is evidence of how well, and those are different claims.

What I would change

The correlation engine grew feature by feature and it shows: it does too much in one place. If I started again I would define the entity graph first and make correlation a consumer of it, rather than the thing that builds it as a side effect.

The broader lesson, and the one I keep relearning: security engineering is mostly about everything around the model.

Next projectIdeaspaceA campus innovation platform built around proof: ideas are cheap, so the system scores evidence instead.