إنتقل إلى المحتوى الرئيسي

Architecture overview

What this page is​

A summary of the AuroraSOC architecture: the seven planes the system is decomposed into and how they interact. It is a reading guide to the canonical architecture document, not a replacement for it. The architecture document remains the source of truth; when this page disagrees with it the architecture document wins, and an issue is filed against this page.

Why it exists this way​

The architecture document is comprehensive and dense. A new contributor needs a map first. This page is that map: short enough to read in one sitting, structural rather than exhaustive, linking out where depth is needed.

How it works​

AuroraSOC is organised into seven planes. The boundaries are real, not decorative; each plane owns specific data and exposes specific interfaces, and the security model assumes a hostile boundary between any two of them.

The dashed lines show telemetry feeding the observability plane; every other plane is observed, and the observability plane is the only one whose feed comes from everywhere.

The planes in one paragraph each​

Edge plane. Anything outside the central deployment that produces telemetry or accepts response actions: EDR sensors on Windows, Linux, and macOS endpoints; the Web Agent that watches browser-mediated activity; the CPS device fleet (environmental, time-of-flight, RFID); and the Collector that runs Vector pipelines on a customer host where logs are otherwise expensive to forward.

Ingest plane. Vector workers parse and normalise the raw feed, emit OCSF 1.3 events, write to NATS JetStream, and apply the dedupe window. ECS is computed as a query-time projection from OCSF and is not stored independently.

Detection plane. Streaming workers in Rust evaluate detection rules compiled from Sigma. Stateless rules are evaluated on every event; short-windowed stateful rules use RocksDB local state with snapshots and replay. Detections produce alerts and feed the correlator.

Agent plane. The orchestrator (Temporal) runs the agent loop and hosts MCP servers that expose data and actions. The inference layer abstracts the LLM provider and meters cost: local Ollama/vLLM by default, with DeepSeek, Gemini, OpenAI, and Anthropic as first-class hosted backends selectable at runtime (see provider configuration). Human-in-the-loop signals are first-class workflow events.

State plane. ClickHouse for events and detections; PostgreSQL for cases, configuration, and small-scale vectors; MinIO for artifacts; Qdrant for large vector workloads; Redis for ephemeral state. The mcp-knowledge MCP server abstracts the vector backend so agent code never references pgvector or Qdrant directly.

Control plane. The site controller reconciles the SiteProfile into running agent pools and shards them. The RBAC service enforces the permission taxonomy with step-up and second-approver workflows where they apply. The config service distributes signed policy bundles. The federation controller handles cross-site case handoff.

Observability plane. Structured logs, traces, and metrics from every service. Decision logs from every state-changing operation. A tamper-evident audit trail. This plane is not optional in any service and not bolted on later.

Where to go from here​

  • The full architecture document is the source of truth: aurorasoc-architecture.md.
  • The seven planes get their own deep-dive pages once their code ships. The build order is in STATUS.md.
  • The non-negotiable constraints (no autonomous life-safety actions, no silent muting, no long-lived edge secrets, etc.) are documented in CONTRIBUTING.md.