For security teams#

Security tooling today is a triangle: a SIEM for detection, a graph or link-analysis tool for investigation, and a data warehouse for the cold store — glued together by ETL that loses context, identity, and provenance at every hop. RelataDB collapses the triangle into one engine. Ingest → detect → investigate → prove is one closed loop over one governed store, with your existing tools (Sigma, MITRE ATT&CK, psql, your SOAR webhook) working unchanged.

What you replace#

Detection rules — commit-driven, Sigma-native#

Write a rule as a SQL WHERE against any governed type. It fires within the request cycle on commit (the GraphChangeEvent commit bus), not on a 30-second poll. A bitmap-indexed candidate filter keeps the per-write check cheap.

curl -X POST http://127.0.0.1:9090/rules \
  -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' \
  -d '{
    "name": "suspicious-dns-exfil",
    "target_type": "DnsEvent",
    "condition_sql": "query_length > 100 AND rdata_type = '\''TXT'\'' AND query LIKE '\''%.xyz'\''",
    "severity": "high",
    "mitre_technique": "T1048.002",
    "purpose": "security"
  }'

Import Sigma rules directly:

relata import-sigma rules/azure-ad-anomalous-signin.yaml

Alerts are bi-temporal Alert rows with full PROV-O — so "would this rule have fired last Tuesday?" is one AS OF query (impossible in a SIEM that overwrites alerts). Push to your SOAR over per-tenant webhooks with queryable delivery status:

# Find alerts whose webhook delivery failed
curl 'http://127.0.0.1:9090/alerts/list?delivery_status=failed' \
  -H 'Authorization: Bearer <token>'

Stream alerts live over SSE for a dashboard: GET /alerts/stream. Full deep-dive: Detection Rules.

The investigation graph — it forms itself#

Every phone / email / IP / username that lands through any door (HTTP, Mongo, S3, OTLP, Kafka) is canonicalized and auto-linked. You query a graph that built itself — no separate edge-loading pipeline.

PURPOSE 'investigation'
-- How are these two entities connected, in ≤5 hops?
SELECT * FROM PATHS_BETWEEN('Person:alice', 'Person:suspect', 5);
 
-- Who are the influencers in the observed comms graph?
SELECT id, pagerank FROM GRAPH_PAGERANK('Person', 'CONTACTED')
ORDER BY pagerank DESC LIMIT 10;
 
-- Match Cypher over Bolt with the Neo4j driver — same graph
-- CALL gds.pageRank.stream('Person', {maxIterations: 20})

10+ algorithms (PageRank, SCC, community detection, link prediction, triangle count, SSSP/PLL…) callable as SQL TVFs, CALL traverse.*, or CALL gds.* (Neo4j-GDS portability). See Graph Analytics.

OTLP-native — spans link into the identity graph#

Native OTLP JSON receivers (/ingest/{traces,logs,metrics} and /v1/{traces,logs,metrics}). Spans map to bi-temporal TraceSpan rows, and identities in span attributes flow into the IdentityIndex — so a trace_id links to Person/NetworkFlow/Transaction through the shared identity graph. This is the cross-dataset correlation SIEM tools lack.

Court-grade replay — defensible findings#

Every executed query persists an immutable replay record (plan SHA, params, ACL bitmap digest, branch HEAD, MV-set digest, snapshot pointer). EXPLAIN_REPLAY re-executes that plan against the recorded snapshot and asserts byte-identical output — the "court-grade" answer to "what did the system tell the analyst on date X?"

PURPOSE 'legal'
EXPLAIN_REPLAY('exhibit-7', SEQ => 5);
-- → reconstructed exhibit seal + chain_valid: true
 
VERIFY_CUSTODY('exhibit-001');   -- chain-of-custody assertion

Plus tamper-evident audit (GET /audit/proof), signed PDF reports (POST /report/pdf), and AuditClient.sign_receipt(...) in every SDK. See For Legal & Compliance.

Per-door least privilege#

Every one of the 13 wire doors presents a distinct Cedar principal. The S3 ingest scraper gets read-only; the BI tool's psql gets read-write on specific types; the compromised scraper cannot write even if its credentials leak. Every audit row is forensically attributable to the protocol that wrote it.

# Audit every row the S3 door touched
curl 'http://127.0.0.1:9090/audit/entries?purpose=s3-client&limit=50' \
  -H 'Authorization: Bearer <token>'

See Per-Door ACL.

How to start#

1. Ingest your logs via OTLP (/ingest/traces) or Kafka/CDR doors — see Ingestion.
2. Import your Sigma rules — relata import-sigma <dir>.
3. Wire your SOAR webhook: register_webhook(url, event_types=["alert.high"]).
4. Investigate with PATHS_BETWEEN, Cypher over Bolt, or the MCP investigate_entity / find_threats tools.
5. Prove with EXPLAIN_REPLAY + signed PDF reports for the case file.

See also#

• Detection Rules — the full rule engine
• Cyber — Sigma detection — worked use case
• Graph Analytics
• Per-Door ACL
• For Legal & Compliance — court-grade replay