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

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

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

Detection data flow

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

RADAR (Risk-aware Anomaly Detection-based Automated Response) is a security orchestration subsystem within IDPS-ESCAPE that combines signature-based detection with anomaly detection, and drives both into a single risk-scored, tiered automated response.

Core technologies

• Wazuh: security monitoring platform providing the manager, agents, and event pipeline.
• OpenSearch: data storage and the Anomaly Detection plugin (Random Cut Forest) used by the ML-based scenarios.
• Docker / Docker Compose: containerised deployment of the manager, indexer, dashboard and webhook.

Design principles

Modularity. Each detection use case is packaged as a self-contained scenario — decoders, rules, agent configuration, active-response bindings, and risk parameters — that can be deployed independently of the others and coexists with them on the same manager. A new scenario is added without modifying the core framework (SWD-034, SWD-027).

Idempotency. Deployment goes through the Wazuh REST API and idempotent Docker operations (SWD-042), so re-running the same deployment step produces the same end state rather than accumulating configuration.

Separation of concerns. The architecture separates data collection (Wazuh agents), data enrichment (manager-side, for the scenarios that need it — SWD-030), detection logic (rules and anomaly detectors — SWD-026, SWD-028, SWD-034), response execution (SWD-027), and orchestration (SWD-042, SWD-041).

Hybrid detection. Signature-based rules give fast, deterministic matching for known patterns without a training period; anomaly detection gives behavioural coverage for patterns no rule anticipates. A scenario may use either or both; the risk engine (HARC-012) combines whichever sources a scenario configures.

Configuration-driven deployment. Scenario parameters — index patterns, features, thresholds, detector settings — are centralised in config.yaml; risk weights, tiers, and mitigations in ar.yaml. Neither requires a code change to retune (SWD-032).

System architecture

RADAR consists of five components working together in an orchestrated pipeline:

Component	Role	Key functions
Wazuh agents	Endpoint monitoring	Log collection, active-response execution
Wazuh manager	Central control	Log processing, manager-side enrichment, rule evaluation, active-response dispatch
OpenSearch / Wazuh indexer	Data platform	Storage, indexing, anomaly detection (RCF models)
Webhook endpoint	Alert routing	Bridges an OpenSearch monitor's HTTP notification back into a Wazuh-ingestible log line
RADAR scripts / GUI	Orchestration	Deployment automation, scenario and agent lifecycle management

Module structure

Wazuh agent. Collects logs and executes dispatched active-response commands. Agents forward logs unmodified; enrichment, where a scenario needs it, happens centrally on the manager, not on the endpoint (SWD-030) — see the rationale there for why this replaced an earlier per-agent design.

Wazuh manager. The central control plane: manager-side enrichment (SWD-030) for scenarios that need it, decoders and rules (SWD-034), active-response dispatch and risk scoring (SWD-026, SWD-027), and OpenSearch monitor-driven alerting via the webhook (below).

OpenSearch / Wazuh indexer. Storage and search for processed logs, and the Anomaly Detection plugin used by ML-based scenarios (SWD-028). Detector and monitor lifecycle for a scenario is managed by run-radar.sh and the anomaly_detector/ Python modules it runs inside the radar-cli container.

Webhook endpoint. A small HTTP service (webhook/) that receives an OpenSearch monitor's POST notification and writes it as a log line the Wazuh manager can decode and evaluate like any other event, closing the loop from anomaly detection back into the rule engine and, from there, into active response. Brought up idempotently by build-radar.sh alongside the rest of the stack.

Deployment control plane. The entry-point scripts (radar.sh, build-radar.sh, run-radar.sh, health-radar.sh, stop-radar.sh, bootstrap-agent.sh), the radar_deploy/ manager-side backbone, and the wazuh_api/ Wazuh REST API integration layer. Specified in full in SWD-042.

Scenarios

Four scenarios ship in the current codebase:

Scenario	Detection	Response
GeoIP detection	Signature	Notification, mitigation
Suspicious login	Signature (an anomaly-detection weight is configured in ar.yaml but no detector is currently wired to this scenario — see the RADAR code fix list)	Notification, mitigation
Scanning detection	Signature	Notification, mitigation (disabled by default)
Log volume growth	Anomaly detection	Notification, mitigation

No other scenarios are present in this codebase. Earlier design material referenced additional demo scenarios (insider threat, DDoS detection, C2 malware communication) intended to show the anomaly-detection path against synthetic datasets; none of that material — code, configuration, or an archive of it — currently exists in the repository, and no such scenario can be deployed.

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.

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.

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.

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.

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. Four tiers are defined, delimited by the three configurable boundaries tier1_min, tier1_max and tier2_max; the normative tier semantics are specified in SRS-061.

• Tier 0 (R < tier1_min, default boundary 0.0): audit logging only, no notification
• Tier 1 (tier1_min ≤ R < tier1_max, default boundary 0.33): email notification and Flowintel case creation
• Tier 2 (tier1_max ≤ R < tier2_max, default boundary 0.66): Tier 1 actions plus scenario mitigations, subject to allow_mitigation
• Tier 3 (R ≥ tier2_max): Tier 2 actions plus the scenario's strong containment mitigations

Architecture 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

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

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

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.

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.

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.

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