1.0 SONAR High-Level Architecture

High-level architecture requirements for SONAR (SIEM-Oriented Neural Anomaly Recognition) subsystem.

1.1 SONAR subsystem context HARC-009

The diagram below depicts the system context of the SONAR (SIEM-Oriented Neural Anomaly Recognition) subsystem within the IDPS-ESCAPE architecture.

SONAR is a multivariate anomaly detection engine that analyzes Wazuh security alerts to identify unusual patterns that may indicate security threats. It integrates with the Wazuh Indexer (OpenSearch) for data ingestion and result storage.

System boundary

UML Diagram

Key interfaces

Interface Direction Protocol Purpose
Wazuh Indexer API Inbound HTTPS/REST Alert retrieval, query execution
Wazuh Data Streams Outbound HTTPS/REST Anomaly document indexing
RADAR Webhook Outbound HTTPS/REST Real-time anomaly notifications

Related documentation

  • Technical architecture: docs/manual/sonar_docs/architecture.md
  • UML diagrams: docs/manual/sonar_docs/uml-diagrams.md

Parent links: MRS-032 Host and Network Ingestion, MRS-039 Offline AD

1.2 SONAR component architecture HARC-010

The diagram below depicts the high-level component architecture of the SONAR subsystem.

Component diagram

UML Diagram

Component responsibilities

Component Responsibility
cli.py Command-line interface, argument parsing, workflow orchestration
scenario.py YAML scenario loading, validation, configuration merging
engine.py MVAD engine lifecycle, training/detection execution
pipeline.py Post-processing, anomaly document creation, result formatting
features.py Feature extraction, time-series bucketing, data transformation
wazuh_client.py Wazuh Indexer API communication, alert retrieval
local_data_provider.py Debug mode data provider (JSON file loading)
shipper/ OpenSearch data stream management, bulk ingestion
config.py Configuration dataclasses, type definitions

Related documentation

  • Detailed architecture: docs/manual/sonar_docs/architecture.md
  • Component diagram: docs/manual/sonar_docs/uml-diagrams.md#component-diagram

Parent links: MRS-032 Host and Network Ingestion, MRS-039 Offline AD

1.3 SONAR data flow architecture HARC-011

The diagram below illustrates the high-level data flow through the SONAR subsystem for training and detection operations.

Training data flow

UML Diagram

Detection data flow

UML Diagram

Data transformations

Stage Input Output Transformation
Ingestion Wazuh alerts (JSON) Raw event list Filtering, time-range selection
Feature Engineering Raw events Time-series vectors Bucketing, aggregation, encoding
MVAD Processing Time-series vectors Anomaly scores Multivariate analysis
Post-Processing Anomaly scores Anomaly documents Thresholding, enrichment, formatting
Shipping Anomaly documents Indexed records Bulk ingestion to data streams

Related documentation

  • Data flow diagram: docs/manual/sonar_docs/uml-diagrams.md#data-flow-diagram
  • Architecture details: docs/manual/sonar_docs/architecture.md#data-flow

Parent links: MRS-032 Host and Network Ingestion, MRS-039 Offline AD

2.0 RADAR High-Level Architecture

High-level architecture requirements for RADAR (Real-time Alert Detection and Automated Response) subsystem.

2.1 RADAR architecture HARC-004

The diagram below depicts the high-level architecture of the RADAR subsystem.

RADAR high level architecture

Parent links: MRS-007 Intrusion Prevention, MRS-012 XDR & SIEM Integration

2.2 RADAR Automated Test Framework architecture HARC-005

The diagram below depicts the high-level architecture of the RADAR Automated Test Framework.

RATF high level architecture

Parent links: MRS-007 Intrusion Prevention

2.3 RADAR deployment: Remote Agent and Remote Manager mode HARC-006

The diagram below illustrates the RADAR build-time and run-time architecture for a deployment in which both the Wazuh Manager and the Wazuh agents are hosted on remote endpoints.

RADAR architecture in Remote Agent and Remote Manager mode

Parent links: MRS-007 Intrusion Prevention

2.4 RADAR deployment: Remote Agent and Local Manager mode HARC-007

The diagram below illustrates the RADAR build-time and run-time architecture for a deployment in which the Wazuh Manager is hosted locally, while the Wazuh agent runs on a remote endpoint.

RADAR architecture in Remote Agent and Local Manager mode

Parent links: MRS-007 Intrusion Prevention

2.5 RADAR deployment: Local Agent and Local Manager mode HARC-008

The diagram below illustrates the RADAR build-time and run-time architecture for a deployment in which both the Wazuh Manager and the Wazuh agent are hosted locally using Docker containers.

RADAR architecture in Local Agent and Local Manager mode

Parent links: MRS-007 Intrusion Prevention

2.6 RADAR risk engine architecture HARC-012

The diagram below depicts the high-level architecture of the RADAR risk engine component, which calculates risk scores by combining anomaly detection outputs, signature-based detection data, and CTI (Cyber Threat Intelligence) indicators.

The risk engine receives three input streams:

  • Anomaly intensity (A): Computed from OpenSearch RCF detector outputs (anomaly grade × confidence) or SONAR MVAD results
  • Signature risk (S): Calculated from rule-based detection (likelihood × impact values from scenario configuration)
  • CTI score (T): Aggregated from threat intelligence indicators (IP blacklists, malicious hashes, domain reputation)

The weighted combination produces a normalized risk score $R \in [0,1]$, which drives tier-based response actions:

  • Low tier (0.0-0.33): Email notification only
  • Medium tier (0.33-0.66): Email + case creation + light mitigation
  • High tier (0.66-1.0): Full response + strong containment actions

Architecture Diagram

UML Diagram

Parent links: MRS-007 Intrusion Prevention

2.7 RADAR Ansible automation architecture HARC-013

The diagram below depicts the high-level architecture of RADAR's Ansible-based deployment automation system. The architecture enables flexible deployment across three modes: local Docker, remote Docker, and remote host installations.

Key architectural components:

  • RADAR Controller: Orchestrates deployment via build-radar.sh and run-radar.sh scripts
  • Ansible Playbooks: Define scenario-specific configuration and deployment workflows
  • Role Modules: Modular roles for wazuh_manager, wazuh_agent, and scenario configurations
  • Volume-Based Strategy: Direct host-side manipulation of bind-mounted Wazuh configuration directories, eliminating docker cp overhead

The volume-first approach maps Wazuh configuration directories (etc, active-response/bin, filebeat/etc) from host to container, enabling idempotent configuration updates without container rebuilds. Configuration injection uses marker-based appending for scenario isolation.

Architecture Diagram

UML Diagram

Parent links: MRS-007 Intrusion Prevention, MRS-012 XDR & SIEM Integration

2.8 RADAR helper architecture HARC-014

The diagram below depicts the high-level architecture of the RADAR Helper component, a multi-threaded log enrichment service deployed on Wazuh agents.

The RADAR Helper monitors authentication logs in real-time and enriches them with geographic and behavioral context before Wazuh ingests them for analysis. This enrichment enables geographic-based detection scenarios (GeoIP detection, impossible travel) and behavioral anomaly detection (ASN novelty, velocity calculations).

Key architectural components:

  • RadarLogger: Module-level singleton encapsulating all logger setup; provides a shared debug logger and a factory (build_out_logger) for per-watcher output loggers
  • BaseLogWatcher: Abstract base class implementing tail-like log following with rotation handling
  • AuthLogWatcher: Processes /var/log/auth.log, enriches SSH authentication events
  • UserState: Per-user state tracking (last location, ASN history, timestamps for velocity calculation)
  • GeoLookup Service: Interfaces with MaxMind GeoLite2 databases (City and ASN)
  • Enrichment Pipeline: Adds 9 fields including country, region, city, ASN, geo_velocity_kmh, country_change_i, asn_novelty_i

Enriched logs are written to /var/log/suspicious_login.log where Wazuh monitors and applies detection rules.

Architecture Diagram

UML Diagram

Parent links: MRS-007 Intrusion Prevention

2.9 RADAR adversarial ML defense architecture HARC-015

The diagram below depicts the defense-in-depth architecture for protecting RADAR's anomaly detection systems against adversarial machine learning attacks.

The architecture implements multiple defensive layers:

Layer 1: Baseline Protection

  • Clean data initialization from verified periods
  • Gold-standard training dataset management
  • Digital clean room exercises for pristine baselines

Layer 2: Concept Drift Detection

  • Baseline shift velocity monitoring
  • Automated alerts on sudden baseline changes
  • Manual approval gates for model updates

Layer 3: Multi-Layer Validation

  • Signature-based detection (Wazuh, Suricata)
  • Multivariate AD (SONAR MVAD, ADBox MTAD-GAT)
  • Streaming AD (OpenSearch RRCF)
  • Cross-layer anomaly correlation

Layer 4: Human-in-the-Loop (HITL)

  • Transparent model reasoning exposure
  • Analyst review workflows
  • Feedback loops for model improvement
  • Alert fusion and enrichment

Layer 5: System Hardening

  • Cryptographic log integrity (SHA-256 hashing)
  • Model file access controls and versioning
  • Training pipeline authentication
  • Audit logging of all model operations

Defense Architecture Diagram

UML Diagram

Parent links: MRS-007 Intrusion Prevention, MRS-019 3rd-Party Open-source Signature-based NIDS

3.0 ADBox v1 High-Level Architecture (Maintenance)

High-level architecture for ADBox v1 (MTAD-GAT legacy system) - maintenance mode only.

3.1 ADBox subsystem HARC-001

The diagram below depicts the context of the ADBox subsystem.

ADBox context diagram

Parent links: MRS-002 Command & Control, MRS-004 Multivariate Anomaly Detection, MRS-032 Host and Network Ingestion, MRS-033 API Data Retrieval, MRS-039 Offline AD, MRS-041 Standalone AD Subsystem

3.2 ADBox architecture HARC-002

The diagram below depicts the high-level architecture of the ADBox subsystem.

ADBox high level architecture

Parent links: MRS-004 Multivariate Anomaly Detection, MRS-031 Multiple ML Techniques, MRS-032 Host and Network Ingestion, MRS-033 API Data Retrieval, MRS-039 Offline AD, MRS-041 Standalone AD Subsystem

4.0 Infrastructure High-Level Architecture

High-level architecture for deployment, integration, and system-wide infrastructure.

4.1 IDPS-ESCAPE context HARC-003

The diagram below illustrates the overall context of the IDPS-ESCAPE system.

IDPS-ESCAPE context diagram

Parent links: MRS-002 Command & Control, MRS-003 Agent Data Centralization, MRS-004 Multivariate Anomaly Detection, MRS-005 Host-based Intrusion Detection, MRS-006 NIDS Support, MRS-007 Intrusion Prevention, MRS-008 Network Capture Forwarding, MRS-011 Signature-based Host IDS, MRS-012 XDR & SIEM Integration, MRS-013 Visual Dashboard, MRS-017 Monitoring Frontend, MRS-018 Data Management Subsystem, MRS-019 3rd-Party Open-source Signature-based NIDS, MRS-020 Platform Independence, MRS-022 Network Endpoint Monitoring, MRS-032 Host and Network Ingestion, MRS-033 API Data Retrieval, MRS-037 Multiple Deployment Models, MRS-039 Offline AD, MRS-040 Signature-Based NIDS, MRS-041 Standalone AD Subsystem