SentinelIQ: Why I Built a SOC That Reconstructs Attacks Instead of Just Alerting on Them

⋅


Built for the Decentralized Compute Track, this project explores how SOC intelligence systems can run on decentralized GPU/CPU infrastructure instead of traditional centralized SIEM backends.

The problem I kept running into

Every SIEM I’ve ever poked at does the same thing: it watches logs, applies a rule, and fires an alert the moment a condition matches. A failed login. A new IP. A privilege change. Each one lands in a queue as its own isolated event, and it’s left to a human analyst to mentally stitch five or six of those alerts together into “oh, this is actually one attack.”

That stitching-together step is where most of the real analyst time goes, and it’s the part that scales worst. The more telemetry you ingest, the more isolated alerts you get, and the harder it becomes to see the shape of an actual attack chain underneath them.

I wanted to build something that did the stitching automatically — that treated security events not as a list to triage, but as a graph to grow. SentinelIQ is the result: a system that turns fragmented security logs into a continuously evolving attack narrative.

What SentinelIQ actually does

SentinelIQ is a self-hostable FastAPI service that ingests security events in real time and runs them through a pipeline:

Event → Ingestion API → UEBA Risk Scoring → Correlation Engine
      → MITRE ATT&CK Mapping → Attack Graph → Response Layer

A security event — a login failure, a privilege escalation attempt, an anomalous IP — comes in through a single /event endpoint as plain JSON:

{
  "user_id": "admin",
  "event_type": "LOGIN_FAILURE",
  "ip_address": "8.8.8.8"
}

From there, every component in the pipeline updates a shared, persistent model of what’s happening, rather than evaluating the event in isolation.

Live API: FastAPI deployment running on Nosana compute — interactive /docs endpoint, you can send a test event directly from there.

UEBA risk scoring

Instead of a static rule (“3 failed logins = alert”), each entity (a user, an IP) accumulates a behavioral risk score based on things like repeated auth failures, velocity of events, and deviation from that entity’s own baseline. A single failed login barely moves the needle. A burst of them from the same IP, especially one with no prior history against that account, moves it a lot more. The score is a running state, not a one-off judgment.

Correlation engine

This is the part that actually solves the problem I described above. Instead of treating LOGIN_FAILURE, LOGIN_FAILURE, LOGIN_FAILURE, PRIVILEGE_ACCESS as four separate alerts, the correlation layer groups them temporally and by entity relationship (user ↔ IP), so the system recognizes the sequence as a single brute-force-then-escalation pattern — the kind of thing a human analyst would normally have to notice by eye, across multiple alert tickets.

MITRE ATT&CK mapping

Correlated patterns get tagged against MITRE ATT&CK techniques — a brute-force pattern maps to T1110, for example — so the output isn’t just “weird stuff happened,” it’s a standardized technique label that a SOC team can act on, report on, or feed into existing tooling that already speaks ATT&CK.

The attack graph

This is the piece I’m most proud of. Rather than storing events as a flat log, SentinelIQ builds an actual graph: entities as nodes, events as edges, accumulated risk as edge weight, with temporal ordering preserved. So instead of querying “show me all events for user X” and reading them top to bottom, you get a structure that visually shows the attack progressing — failed logins thickening into a heavier edge, then a new edge appearing for the privilege escalation that followed. The graph is the incident narrative.

Response layer

Right now this simulates the kind of action a SOAR platform would take — IP quarantine, risk escalation, incident logging — without taking destructive action. It’s there to show the shape of where this goes next, not to claim it’s production-hardened incident response yet.

Deployment architecture (Nosana compute layer)

SentinelIQ runs as a containerized FastAPI service deployed on Nosana’s decentralized compute network — the ingestion API, risk engine, correlation engine, and graph builder all run inside a single Nosana GPU/CPU job rather than a managed cloud SIEM stack.

That deployment model matters: the architecture is built around elastic, on-demand compute rather than a fixed, always-on backend. Today’s risk scoring is heuristic-based, so it’s genuinely lightweight CPU work — I’m not going to pretend otherwise. But the engine is structured so that the UEBA scoring step can be swapped for ML-based anomaly inference without touching the rest of the pipeline. That’s the part of the architecture where GPU-backed decentralized compute actually starts to matter, rather than just being a hosting choice.

What makes this different from “just another SIEM demo”

Three things, honestly:

  • It’s graph-native, not log-native. Most lightweight security tooling at this scale stores events as rows. Modeling them as a graph from the start is what makes multi-step attack reconstruction possible without a separate batch job.
  • It’s streaming, not batch. Every event updates state immediately. There’s no nightly correlation run.
  • It’s small enough to self-host. No dependency on a heavyweight SIEM stack — it’s a FastAPI service you can run on a single GPU/CPU node, which is exactly why it was a fit for Nosana’s decentralized compute track.

What it isn’t, yet

I’d rather say this directly than have a judge find it for me: there’s no distributed graph backend yet (it’s in-memory/local, not Neo4j-backed), no LLM-based incident summarization, and no multi-tenant isolation. The response layer is simulated, not destructive. Those are the next things I’m building, not things I’m claiming already exist.

Why I deployed SentinelIQ on Nosana

The point of the Decentralized Compute Track isn’t just to host an app somewhere decentralized — it’s to show a workload that actually benefits from that model rather than a fixed cloud backend.

SentinelIQ’s pipeline fits that in two stages. Right now, the heuristic-based UEBA scoring and graph correlation are lightweight — they don’t need a GPU to run, and I’m not going to claim otherwise. What they do benefit from is on-demand, pay-for-what-you-use compute instead of committing to fixed cloud infrastructure for a service that, by design, should scale up and down with event volume.

The stronger case is where this goes next: as the risk-scoring heuristics get replaced with actual ML-based anomaly detection — the planned next step — that inference workload is where GPU-backed decentralized compute stops being optional and starts being the thing that makes the architecture work at all. Deploying on Nosana now isn’t just a hosting decision — it’s building the deployment path that the heavier, ML-driven version of this system will actually need.

What’s next

Graph database backend (Neo4j or TigerGraph) so the attack graph survives restarts and scales past memory. An LLM-based analyst layer that can narrate an attack graph in plain language for a non-technical responder. Real threat-intel feed ingestion instead of synthetic test events.

Final takeaway

SentinelIQ isn’t trying to replace SIEM systems. It’s trying to change what they represent. Instead of treating security as a stream of disconnected alerts, it treats it as a continuously evolving structure — where every event contributes to an unfolding attack narrative that can be read as a graph, not a log file. In practice, that turns multi-step attack detection from manually correlating across separate alert tickets into a single graph traversal.

Code: github.com/Drechi3/SentinelIQ


Liked Liked