SIEM Integration

AuroraSOC acts as a meta-SIEM, ingesting and correlating events from multiple SIEM sources through a unified interface. Rather than replacing your existing SIEM, AuroraSOC sits above it, adding AI-powered analysis.

Supported SIEM Sources

Source	Protocol	Description
Wazuh	REST API / Syslog	Host-based IDS, file integrity monitoring
Suricata	EVE JSON / Redis	Network IDS/IPS with full packet inspection
Zeek	JSON Logs	Network traffic analysis and protocol logging
Velociraptor	REST API	Endpoint visibility and digital forensics
Custom	Syslog / JSON	Any source via the Rust normalizer

Event Normalization Pipeline

Why a Rust Normalizer?

The normalizer is written in Rust for performance-critical event processing. At high event volumes (10,000+ EPS), Python's GIL becomes a bottleneck. Rust provides:

• Zero-copy parsing for known formats
• Async I/O with tokio for concurrent source handling
• Guaranteed memory safety without garbage collection pauses
• Sub-millisecond per-event processing latency

SIEM Dashboard Page

The SIEM page shows:

Log Sources

A card for each connected SIEM source showing:

• Status — Connected / Disconnected
• EPS — Current events per second
• Total Events — Cumulative count for the day
• Last Event — Timestamp of most recent event

Event Search

Full-text search across all ingested events with filters:

• Time range — Last 15m, 1h, 4h, 24h, 7d, custom
• Source — Filter by origin system
• Severity — Filter by normalized severity
• Search query — Lucene-like query syntax

In real mode, raw SIEM rows are now persisted in AuroraSOC's siem_logs table instead of living only in an in-memory demo buffer. That means the SIEM workspace survives API restarts and can be fed directly by lightweight local bridges such as:

• scripts/local_siem_bridge.py for Linux host logs like /var/log/auth.log, /var/log/syslog, and /var/log/kern.log, with automatic journalctl -f fallback on journald-based hosts
• scripts/suricata_eve_bridge.py for Suricata eve.json network telemetry

The bridge caller must authenticate with a role that has siem:write. The built-in local admin account now includes that permission by default, so the example bridge commands in this guide work unchanged in a single-host real-mode lab.

For a single-machine lab, the intended shape is:

1. Run AuroraSOC in SYSTEM_MODE=real.
2. Start the local A2A agent mesh and the Redis task worker.
3. Start one or both bridge scripts depending on whether you want host logs, network detections, or both.

The dashboard then shows real SIEM rows, live source counts, and live statistics without falling back to seeded showcase data.

Saved Hunts

Operators can persist the current search state as a reusable hunt directly from the SIEM workspace.

• Save current filters — Store query, source, severity, and host pivots as a named hunt.
• Persist in the database — Hunts are stored server-side in real mode instead of in browser memory, so they survive refreshes, restarts, and analyst hand-offs.
• Share by audience — Each hunt can be kept private, shared with the whole team, or shared only with selected AuroraSOC roles such as analyst or operator.
• Run on demand — Re-execute a saved hunt and refresh the result table with the latest matches.
• Track hit counts — Each hunt shows its last run time and the most recent match volume.

This makes recurring threat-hunting patterns first-class workflow objects instead of ad hoc notes.

Detection Engineering From the SIEM Workspace

AuroraSOC now extends hunt promotion into a full detection-engineering workflow without leaving the SIEM page.

• Author a rule from the current hunt context — Analysts can take the current query, source, severity, and host pivots and save them as a reusable detection rule.
• Define alert semantics — Rules capture alert severity, title/description templates, MITRE technique tags, and whether a match should auto-create a case.
• Schedule recurring execution — Rules can be switched from manual-only execution to a recurring minute-based schedule directly in the SIEM workspace.
• Run and tune in place — The active rule view shows the current match set, the number of suppressed matches, the most recent trigger state, and the next scheduled execution time.
• Suppress noisy patterns — From any returned log row, analysts can create a suppression against the active rule to mute repetitive hosts or other matching criteria for a bounded window.
• Record feedback loops — Promoted detections can be marked true_positive or false_positive, updating the rule counters and helping tune future response.
• Review persisted run history — Each active rule shows recent manual and scheduled runs with match counts, suppressed counts, and sample-hit telemetry.
• Track detection trends — Detection KPI cards summarize scheduled rules, runs in the last 24 hours, matches in the last 24 hours, and recently suppressed volume.

This turns the SIEM page into both a hunting surface and a rule-tuning console for analyst-driven detection engineering.

Promote Into Triage Or Investigation

Every log row can now be promoted into the IMS workflow without leaving the SIEM workspace.

• Promote to Alert — Create or deduplicate a triage alert from the selected event.
• Create Case — Escalate the event into a linked case when the log already warrants investigation.
• Promote with active rule context — When a detection rule is active, promotion carries the rule identifier so suppressions, auto-case creation, and feedback counters stay aligned.
• Pivot and enrich — Host, source, and severity pivots remain available alongside extracted indicators so the operator can widen or narrow the hunt before promoting.

When a log has already been promoted, the workspace displays linked alert and case references so analysts can jump directly into the alert or case views.

Deep Links Into Alerts And Cases

Promoted workflow chips now open the exact linked record instead of only taking the analyst to the top-level page.

• Alert links open the Alerts workspace with selectedAlert in the URL so the detail dialog is opened automatically.
• Case links open the Cases workspace with selectedCase in the URL so the correct case is expanded immediately.
• Close actions clear the route state so analysts can return to the regular workspace view without stale selections in the address bar.

Event Correlation

The CorrelateEvents tool automatically finds relationships between events:

Correlation Type	Method	Example
IP-based	Same source/destination IP	Port scan followed by exploit attempt
User-based	Same username across events	Brute force followed by successful login
Time-based	Events within a window	Multiple alerts within 5 minutes
Technique-based	Same MITRE technique	Different hosts showing same attack pattern

Correlation Window

The default correlation window is 15 minutes. Events arriving within this window that share common indicators are automatically linked. Adjust via the AURORA_SIEM_CORRELATION_WINDOW environment variable.

MITRE ATT&CK Mapping

Every normalized event is mapped to MITRE ATT&CK techniques by the AI agents:

The SIEM page includes a MITRE heatmap showing technique prevalence across your environment over time.

Resilient Section Loading

The SIEM dashboard loads data in two phases to maximise availability:

1. Primary log fetch — the current log set (hunt, detection rule, or search result) is fetched first. If this call fails, a toast error is shown and the page stays at the previous log state.

2. Supplemental data — eight independent sections (sources, stats, hunts, detection rules, suppressions, feedback, rule run history, detection metrics) are fetched with Promise.allSettled so they never block each other.

This means a transient permission failure or timeout affecting one section (for example, the detections:read permission not yet granted to a new role) does not blank the other seven sections. Any section that resolves renders normally; any that fail show a brief toast count (N SIEM section(s) failed to load) and retain their last-known value.

Partial data is always better than no data

If you see a "sections failed to load" toast, the log table and any successfully loaded sections remain fully functional. Check the browser console (SIEM supplemental fetch: N section(s) failed) for the underlying API error, then address the permission or connectivity issue and reload.