SOC and security engineers

The work is not finding more. It is being able to say why this one matters, and being able to prove it six months later without rebuilding the context from three dashboards.

security correlation engineSOC alert triagedetection engineering platform

What changes

Detections arrive with the reasoning attached, correlation reduces many signals into one incident, and every risk links to the exact signals, rules and raw events that produced it.

Deterministic beats clever

Detection, correlation and scoring are rules over typed signals. No model decides what is worth your attention, which means a score can be reviewed, regression-tested and explained to a customer or an auditor.

One incident instead of five alerts

Signals from different vendors and different weeks land in one window. Tier-2 rules fuse them into a compound risk with a single owner, so the queue reflects incidents rather than raw detector output.

Response lives where the work already is

Remediation routes to Jira, ServiceNow, Cortex XSOAR, PagerDuty or Slack, and code-level fixes go back to the forge as a check run. The finding and the fix stay in the same thread.

A reasonable first fortnight

Not a migration plan — the first two weeks, in the order that produces something useful fastest.

Import the previous 30 days of findings so correlation has history to reason against.
Review the tier-1 and tier-2 rule sets and disable anything that duplicates a control you already trust.
Route the outlets — Jira or ServiceNow for tracked work, Slack or PagerDuty for time-sensitive chains.
Write one runbook per CRITICAL correlation rule; there are few enough of them that this is a finite job.

Questions this role tends to ask

How much does correlation actually reduce the queue?

It depends on your estate, but the mechanism is fixed: many signals inside one time window collapse into a single compound risk with one owner and one evidence list. The rule set is 34 tier-1 and 41 tier-2 rules, small enough to review and tune deliberately rather than accept as a black box.

Does anything use an LLM to triage or score?

No. There are two LLM call sites in the codebase, both in an optional advisory module no engine imports. Detection, correlation and scoring are deterministic. That is a deliberate choice: a score you cannot reproduce is a score you cannot defend in a post-incident review.

Do you ship a SIEM?

No, and it is not trying to be one. It correlates across cloud, identity, code, certificate and AI surfaces and sends the result where your response process already lives — Jira, ServiceNow, Cortex XSOAR, PagerDuty, Slack, or a Splunk or Datadog pipeline. Most teams run it beside their SIEM, not instead of it.

Can I write my own detections?

Yes. Signals are typed on a bus with a declared schema, and both behavioural and correlation rules are declarative entries registered in the tier index arrays. A rule ships with its ATT&CK mapping, its evidence fields and a test; the registration guard fails the build if a rule is exported but not wired in.

What it is not

Hanu is not a SIEM and does not try to be one — it correlates and hands the result to the response process you already run. It is not a certified SOC 2 Type II service for self-hosted customers; the evidence engines and audit trail support your own controls. And it does not cover Oracle Cloud, which exists in the codebase as stubs only.

Run it in your own account

One Docker Compose stack, your datastores, read-only credentials into your clouds. The Community edition is free to run in production.

Deploy Hanu See what is paid