1.0 SONAR System Requirements

System-level requirements for SONAR (SIEM-Oriented Neural Anomaly Recognition) anomaly detection subsystem.

1.1 ML Hyperparameter Tuning SRS-018

As a user, I want to modify the default hyperparameter of ML methods used by ADBox.

Access C&C server
Access ADBox
Modify values in siem_mtad_gat/assets/default_configs/mtad_gat_train_config_default_args.json

Rationale

To globally tune ML algorithm to a specify system/scenario

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-015 Software Configuration Management

Child links: LARC-012 ADBox ConfigManager

Attribute	Value
importance	3
urgency	2
risk	2
type	F
version	0.1

1.2 ML-Based Anomaly Detection SRS-027

As a system admin, I want to run a machine learning algorithm to detect anomalous behaviors within my system.

Access C&C server
Access ADBox
Select a trained detector
Run a prediction script using the chosen detection either for a selected time interval or in real time.

Rationale

None

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-030 Deep Learning Technique

Child links: LARC-020 SONAR detection pipeline sequence, TST-007 ADBox use case 1 with a Wazuh connection, TST-008 ADBox use case 1 without a Wazuh connection, TST-011 ADBox use case 3 with a Wazuh connection, TST-012 ADBox use case 3 without a Wazuh connection, LARC-008 ADBox batch and real-time prediction flow

Attribute	Value
importance	5
urgency	4
risk	2
type	F
version	0.1

1.3 Algorithm Comparison Feature SRS-028

As a user, I want to compare the outcome of different anomaly detection algorithms on my data.

Assuming: Two different algorithms A1 and A2 available in ADBox, and two compatible detectors D1 and D2 based on these algorithms, respectively.

Access C&C server
Access ADBox
Establish detection parameters (time interval, features, etc.)
Select a (trained) detector D1 using algorithm A1
Run a prediction script using D1.
Select a (trained) detector D2 using algorithm A2
Run a prediction script using D2.
Compare output using dedicated Dashboard.

Rationale

To validate the AD capabilities.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-031 Multiple ML Techniques

Attribute	Value
importance	2
urgency	1
risk	1
type	F
version	0.1

1.4 Host & Network Ingestion SRS-029

As a user, I want to ingest and transform data generated from both host and network events to feed anomaly detectors.

Access C&C server
Access ADBox
Set up data ingestion and transformation of data derived from CyFORT-Wazuh and CyFORT-Suricata logs arguments.

Rationale

To enable holistic system monitoring.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-032 Host and Network Ingestion

Child links: LARC-003 ADBox preprocessing flow

Attribute	Value
importance	4
urgency	4
risk	1
type	F
version	0.2

1.5 AD Results Visualization SRS-030

As a user, I want to read/plot AD results of training and test data.

Assuming: trained detector with unique identifier uuid available.

Access C&C server
Access ADBox
Open the folder siem_mtad_gat/assets/detector_models/uuid/training
Use either external tools or viz-notebooks to visualize - train subset AD output: train_output.pkl - test subset AD output: test_output.pkl

Rationale

To enable programmatic use of such data to further elaborate and evaluate output of training

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-034 Standardized AD Output

Child links: TST-037 Open prediction file of training data

Attribute	Value
importance	2
urgency	2
risk	2
type	F
version	0.1

1.6 Training Loss Visualization SRS-031

As a user, I want to read/plot losses of training and test data.

Assuming: trained detector with unique identifier uuid available.

Access C&C server
Access ADBox
Open the folder siem_mtad_gat/assets/detector_models/uuid/training
Use either external tools or viz-notebooks to visualize - train : train_losses.png - test : test_losses.png

Rationale

To evaluate quality of output of training

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-034 Standardized AD Output

Child links: TST-038 Visualize train losses

Attribute	Value
importance	1
urgency	1
type	F
version	0.1

1.7 Predicted Anomalies Visualization SRS-032

As a user, I want to read/plot the list of predicted anomalies .

Assuming: trained detector with unique identifier uuid available, use-case scenario uc-x given.

Access C&C server
Access ADBox
Within siem_mtad_gat/assets/detector_models/uuid/prediction folder, open: uc-x_predicted_anomalies_data-*.json

Rationale

To enable programmatic use of such data to further elaborate and evaluate output of prediction

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-034 Standardized AD Output

Child links: TST-039 Open prediction raw outcome

Attribute	Value
importance	4
urgency	3
risk	1
type	F
version	0.1

1.8 Offline Anomaly Detection SRS-035

As I user, I want to perform off-line AD on a SIEM data registered by Wazuh on date YYYY-MM-DD.

Assuming: trained detector with unique identifier uuid available.

Access C&C server
Access ADBox
Add an use-case file siem_mtad_gat/assets/drivers/uc_x.yaml including

yaml prediction: run_mode: "historical" index_date: YYYY-MM-DD detector_id: uuid

Rationale

To detect anomalies without real-time obstacles and possibly after pre-selection, and to review events from the past investigating a possible threat

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-039 Offline AD

Child links: LARC-020 SONAR detection pipeline sequence, TST-009 ADBox use case 2 with a Wazuh connection, TST-010 ADBox use case 2 without a Wazuh connection, LARC-002 ADBox historical data prediction pipeline flow

Attribute	Value
importance	4
urgency	4
risk	2
type	F
version	0.1

1.9 Anomaly-Based NIDS SRS-037

As a user, I want to find anomalies in the network traffic to detect threats not recognized by the signature-based NIDS.

Assuming: CyFORT-Suricata integrated with CyFORT-Wazuh

Access C&C server
Access ADBox
Add an use-case file siem_mtad_gat/assets/drivers/uc_x.yaml including as features attributes from Suricata eve.log decoding
Run ADBox

Rationale

None

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-004 Multivariate Anomaly Detection

Child links: TST-015 ADBox use case 5 with a Wazuh connection, TST-016 ADBox use case 5 without a Wazuh connection

Attribute	Value
status	To detect deviations from an a priori normal baseline system behavior, possibly caused by malicious actors.

importance	4
urgency	3
risk	1
type	F
version	0.1

1.10 Joint Host-Network Training SRS-038

As a user, I want to train a detector to detect anomaly by using both host and network events.

Access C&C server
Access ADBox
Train a detector using features derived from CyFORT-Wazuh and CyFORT-Suricata logs arguments.

Rationale

None

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-030 Deep Learning Technique

Child links: LARC-019 SONAR training pipeline sequence, TST-013 ADBox use case 4 with a Wazuh connection, TST-014 ADBox use case 4 without a Wazuh connection, LARC-001 ADBox training pipeline flow

Attribute	Value
importance	5
urgency	4
risk	2
type	F
version	0.1

1.11 Algorithm Selection Option SRS-039

As a user, I want to be able to select the algorithm to use for AD to run AD according to the most suitable AD principle.

Access C&C server
Access ADBox
Select the ML-package to be used by the training/test pipelines.

Rationale

Adapt AD functionality to different scenarios and maximize accuracy.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-031 Multiple ML Techniques

Child links: LARC-009 ADBox machine learning package

Attribute	Value
status	unavaliable
importance	3
urgency	2
risk	2
type	F
version	0.1

1.12 Data Management Subpackage SRS-040

ADBox should include a Data Management subpackage, centralizing data storage, retrieval and all other operation concerning the management of data along the AD pipelines.

Rationale

To consolidate the data management operation

Acceptance criteria

Code inspection

Parent links: MRS-004 Multivariate Anomaly Detection

Child links: LARC-010 ADBox data manager

Attribute	Value
importance	3
urgency	3
risk	3
type	A
version	0.1

1.13 Time Management Package SRS-041

ADBox should include a Time Management package, handling various aspects of time-related operations given the time-series based approach.

Rationale

To consolidate the time management operation

Acceptance criteria

Code inspection

Parent links: MRS-004 Multivariate Anomaly Detection

Child links: LARC-011 ADBox TimeManager

Attribute	Value
importance	3
urgency	2
risk	2
type	A
version	0.1

1.14 Prediction Shipping Feature SRS-042

As a user, I want the prediction of the anomaly detection subsystem to be shipped to the central indexer.

Assuming:

CyFORT-Wazuh and ADBox deployed
a use case, including training settings available.

Build ADBox container
Run ADBox training with the shipping flag enabled
When using the created detector, turn the shipping on.

Rationale

Centralization and integration of information

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-018 Data Management Subsystem

Child links: LARC-020 SONAR detection pipeline sequence, TST-018 ADBox Create detector data stream, LARC-014 ADBox Shipper, LARC-013 ADBox RequestResponseHandler

Attribute	Value
importance	2
urgency	2
risk	2
type	F
version	0.1

1.15 AD Data Visualization SRS-043

As a user, I want a graphic visualization of the data produced by the anomaly detection subsystem.

Assuming:

CyFORT-Wazuh and ADBox deployed and integrated
At least a detector data stream available in CyFORT-Wazuh Indexer

Open CyFORT-Wazuh
Add the detector's pattern to Dashboard pattern list.
(Optional) Create an ad hoc visualization and a Dashboard.

Rationale

Accessibility of AD data for the end-users and centralise forensics

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-017 Monitoring Frontend

Child links: TST-033 ADBox Wazuh integration Dashboard

Attribute	Value
importance	2
urgency	2
risk	2
type	F
version	0.1

1.16 Cross-platform SONAR deployment SRS-046

As a user, I want to deploy ADBox as a platform independent solution.

Assuming:

CyFORT-Wazuh deployed

Deploy SONAR via Docker and shell scripts.

Rationale

Ensure cross-platform compatibility and portability for usage.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-020 Platform Independence

Child links: TST-001 Deploy ADBox via Docker and shell scripts

Attribute	Value
importance	5
urgency	5
risk	2
type	F
version	0.1

1.17 Interactive Use Case Builder SRS-047

As a user, I want to interactively compile a use case, to create an anomaly detector and run predictions.

Access C&C server
Access ADBox
Run interactive shell.

Rationale

To simplify the process of preparing use-case files.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-030 Deep Learning Technique

Child links: TST-004 Run ADBox console

Attribute	Value
urgency	2
type	F
version	0.1

1.18 Default Detector Training SRS-048

As a user, I want to train a base detector using default parameters.

Access C&C server
Access ADBox
ADBox with default option.

Rationale

To obtain a detector without use case specification.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-030 Deep Learning Technique

Child links: LARC-019 SONAR training pipeline sequence, TST-005 Run ADBox in default mode with a Wazuh connection, TST-006 Run ADBox in default mode without a Wazuh connection, TST-050 Linux resource usage monitoring scenario

Attribute	Value
importance	2
urgency	2
risk	1
type	F
version	0.1

1.19 Anomaly Shipping to Indexer SRS-049

As a user, I want to enable the shipping of anomaly detection outcomes to the central indexer to centralize data anaysis and threat hunting.

Access Command and Control server.
Access ADBox.
Run shipping installation script.

Rationale

To ensure consisten integration of AD outcomes with SIEM

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-021 IaC Deployment

Child links: TST-017 ADBox shipping install

Attribute	Value
importance	3
urgency	3
risk	2
type	F
version	0.1

2.0 RADAR System Requirements

System-level requirements for RADAR (Real-time Alert Detection and Automated Response) automated response subsystem.

2.1 RADAR scenario: ransomware SRS-057

As a security engineer, I want RADAR to detect ransomware attacks on Windows endpoints through multiple detection layers (pre-execution scanning, behavior-based rules, and file system anomalies), and then execute automated responses including file recovery and containment.

Scope

Endpoint coverage: This requirement applies to Windows endpoints monitored by Wazuh agents with Sysmon installed, FIM configured with real-time monitoring on critical user directories (Downloads, Documents, Desktop), and VirusTotal integration enabled.

Detection layers: Three complementary layers are employed across different attack phases:

Pre-execution — VirusTotal scanning of newly created or modified files via Wazuh FIM integration (known-malware coverage via threat intelligence)
Execution-time — Sysmon event monitoring and custom Wazuh rules detecting ransomware behavioral patterns (defense evasion, persistence, backup deletion)
Encryption-phase — FIM frequency-based correlation rules detecting rapid bulk file modifications or creations (catches novel/zero-day variants)

Rule series: Custom ransomware detection rules 100600–100629, supplemented by VirusTotal rule 87105.

Recovery mechanism: Volume Shadow Copy snapshots created proactively by the Wazuh Command module, disabled between operations to prevent ransomware deletion.

Alert delivery: Detection rule trigger → Wazuh alert → Active Response execution → audit log.

Requirements

Pre-execution detection: RADAR shall integrate Wazuh FIM with VirusTotal to scan files upon creation or modification in monitored directories (Downloads, Documents, Desktop folders). When VirusTotal identifies a file as malicious, RADAR shall trigger an Active Response to remove the threat before execution.
Execution detection: RADAR shall detect ransomware behaviors through Sysmon-monitored events and custom rules that identify:

Volume shadow copy deletion attempts (vssadmin delete shadows, wmic shadowcopy delete, wbadmin delete catalog)
System recovery inhibition (bcdedit modifications disabling recovery)
Windows Defender tampering (service disablement, registry modifications)
Windows firewall disabling
Boot configuration data modifications
Persistence mechanisms (registry run keys, startup folder additions)
Windows event log clearing
Suspicious file operations (executable copying to AppData, WerFault DLL sideloading)

File system anomaly detection: RADAR shall detect abnormal file system activity patterns using FIM frequency-based correlation rules:

Multiple file modifications in user directories within a short time window (≥10 modifications within 30 seconds)
Multiple file creations across different directories within a short time window (indicating ransom note distribution)
Unusual file extension patterns appearing across monitored directories

Alert generation: RADAR shall emit a “Ransomware attack detected” alert when any of the following conditions are met:

VirusTotal identifies ransomware (rule 87105)
System recovery inhibition behaviors detected (rules 100615–100621)
Multiple ransomware indicators detected within correlation window (rule 100628)
Rapid file system changes detected (rules 100626–100627)

Alert content: Ransomware alerts shall include:

Endpoint identity (agent.name) and detection method (VirusTotal/behavioral/file-system)
Specific rule ID and description, and MITRE ATT&CK technique IDs
Timestamp and affected file paths (when applicable)
Command lines executed (when applicable)

Automated response: Upon ransomware detection, RADAR shall execute the following Active Response actions:

Email notification to SOC team with alert details
Case creation in integrated SOAR platforms (e.g., FlowIntel) for high-risk alerts
Automatic file recovery from Volume Shadow Copy snapshots (when recovery AR is triggered by rule 100628)
Context collection and forensic logging
All active response executions shall be logged with success/failure status

Preventive protection: RADAR shall configure the Wazuh Command module on Windows endpoints to:

Periodically create Volume Shadow Copy snapshots (configurable interval, default 12 hours)
Disable VSS service between snapshot operations to prevent ransomware from deleting backups
Enable snapshots to be used for post-attack file recovery

Configuration requirements: RADAR shall provide deployment automation for:

Wazuh FIM configuration with real-time monitoring (realtime="yes") on critical directories
Sysmon installation and configuration with ransomware-relevant event logging
VirusTotal integration with API key configuration
Custom ransomware detection rules (100600–100629 series)
Active Response scripts for threat removal and file recovery
Volume Shadow Copy protection via Command module

Rationale

Ransomware can cause complete operational disruption within minutes, requiring detection across all attack phases. Pre-execution VirusTotal scanning covers known families; Sysmon behavioral rules catch zero-day variants via universal TTPs (backup deletion, defense tampering — MITRE ATT&CK T1486, T1490); FIM frequency rules serve as a last line of defense during rapid bulk encryption. Proactive VSS snapshot creation with VSS service disablement between operations ensures recovery capability even if the Wazuh agent itself is compromised.

Acceptance criteria

Successful validation according to the corresponding test specification, including:

Detection of ransomware file drops via VirusTotal integration
Detection of at least 8 different ransomware behavioral patterns
Successful Active Response execution for threat removal
Successful file recovery from VSS snapshots
Alert generation within 60 seconds of detection
Complete forensic logging of all detection and response actions

Parent links: MRS-007 Intrusion Prevention

Child links: LARC-021 RADAR risk engine calculation flow, LARC-026 RADAR active response decision pipeline

Attribute	Value
importance	5
urgency	4
risk	3
type	F
version	1.0

2.2 RADAR: Tiered active response logic SRS-061

As a security engineer, I want RADAR to apply a consistent, risk-scored tiered response framework across all detection scenarios, with integrated DECIPHER case creation, so that the SOC receives proportionate, auditable, and actionable responses for every alert.

Scope

Risk score input: The tier classification is driven by the unified risk score $R \in [0, 1]$ computed by the RADAR risk engine per the formula $R = w_{ad} \times A + w_{sig} \times S + w_{cti} \times T$. The mathematical specification of the risk engine is defined in radar-risk-math.md.

Tier boundaries: Default boundaries are defined globally and are configurable in ar.yaml. Per-scenario overrides are permitted where operationally justified.

DECIPHER integration: Case creation is performed via the DECIPHER subsystem of SATRAP-DL, which creates and manages cases in FlowIntel. Availability of DECIPHER is checked at runtime; its unavailability does not interrupt risk calculation or other response actions.

Requirements

RADAR shall classify every active response execution into exactly one response tier based on the computed risk score R:

(i) Tier 0 - Logging only (risk score below the configured Tier 1 minimum, where applicable): RADAR logs the event and risk computation to the audit log. No email notification is performed. Tier 0 is implemented as a minimum value of Tier 1. To explicitly enable Tier 0 suppression of Tier 1 actions, the tier1_min parameter must be set to a value greater than 0 in ar.yaml.
(ii) Tier 1 - Low risk (0.0 ≤ R < tier1_max, default tier1_max = 0.33): RADAR sends an email notification to the configured SOC recipient and records the decision in the audit log.
(iii) Tier 2 - Medium risk (tier1_max ≤ R < tier2_max, default range 0.33–0.66): RADAR executes all Tier 1 actions. Optional scenario-specific mitigations may be executed if allow_mitigation = true is set in ar.yaml.
(iv) Tier 3 - High risk (R ≥ tier2_max, default tier2_max = 0.66): RADAR executes all Tier 2 actions. Mitigation actions configured for the scenario (e.g., firewall_drop, lock_user_linux, terminate_service) shall be executed when allow_mitigation = true is set, subject to the mitigation safety gates defined in the active response specification.

Tier boundaries shall be configurable in ar.yaml without code changes:

(i) Global tier boundaries are defined under the tiers: key:

tiers:
    tier1_min: 0.0    # Lower bound for Tier 1; set > 0 to enable Tier 0 suppression
    tier1_max: 0.33   # Upper bound of Tier 1 (low risk)
    tier2_max: 0.66   # Upper bound of Tier 2 (medium risk)

(ii) Tier boundaries must satisfy 0.0 ≤ tier1_min ≤ tier1_max ≤ tier2_max ≤ 1.0. Violation of this constraint shall cause the active response script to log a CRITICAL error and exit without executing any actions.

RADAR shall match incoming Wazuh alerts to active response scenarios using the rule mapping declared in radar/scenarios/active_responses/ar.yaml:

(i) Each scenario may define rule_ids for exact alert.rule.id matching and rule_groups for membership overlap against alert.rule.groups.
(ii) Exact rule_ids shall take precedence over rule_groups when an alert matches both.
(iii) If an alert matches multiple scenarios by rule_groups only, the first matching scenario listed in ar.yaml shall be selected and the ambiguity shall be logged for audit.
(iv) If no scenario matches by rule_ids or rule_groups, the active response execution shall log a warning and exit without taking further action.

RADAR shall integrate with the DECIPHER subsystem of SATRAP-DL:

(i): Before making use of DECIPHER endpoints (e.g. to obtain a CTI score or create an incident case), RADAR shall first query the DECIPHER health endpoint. If DECIPHER is unavailable (connection refused, timeout, or non-2xx response), RADAR shall log a WARNING and proceed with all other risk-aware tiered response actions (email, mitigations, audit logging) without interruption. DECIPHER API invocation shall not be retried within the same active response execution.
(ii): When DECIPHER is available, RADAR shall submit a CTI analysis request to DECIPHER.
(iii): A successful DECIPHER response will return a CTI score $T$.
(iv): The call to the analysis endpoint of the DECIPHER API shall provide a dictionary of specific fields, specified per scenario.
(v): If DECIPHER returns an error response (4xx or 5xx), RADAR shall log the error with full response detail and continue with the remaining response actions. The execution result record shall reflect the DECIPHER execution status.

For Tier 1 and above, RADAR shall send an email notification to the configured SOC recipient and create a Flowintel case via the incident endpoint of the DECIPHER API:

(i) RADAR invokes the incident endpoint of the DECIPHER API to create a case. The case is populated by DECIPHER with CTI analysis results and assigned a priority tag. The priority tag reflects the tier determined by RADAR (based on its computed risk score) and it is intended for use by security analysts for triage within the FlowIntel interface.
(ii) The case submitted to DECIPHER shall include at minimum: RADAR scenario name, triggering agent name and ID, alert timestamp, risk score, tier classification, decision ID, title of case origin and the list of extracted IOCs.
(iii) The email body content shall include: alert summary, scenario name, risk score and tier classification, risk component breakdown (anomaly, signature, CTI components), affected agent and user identity, extracted IOCs, decision ID, and recommended manual verification steps. Moreover, the email body shall include the FlowIntel case ID and URL link returned by DECIPHER in response to the incident API call, enabling the analyst to navigate directly to the case. Both the case ID and the link shall be: - Included in the email body sent to the SOC - Recorded in the structured audit log entry for the active response execution
(iv) If DECIPHER returns an error response (4xx or 5xx), RADAR shall log the error with full response detail and continue with the remaining response actions. The execution result record shall reflect the DECIPHER execution status.
(v) If the SMTP configuration is incomplete or the email send fails, the failure shall be logged as ERROR and the remaining response actions shall continue unaffected.

RADAR shall generate a unique decision ID for every active response execution and maintain a complete audit record:

(i) The decision ID is computed as SHA256(JSON.dumps({alert_id, timestamp, rule_id, agent_id, scenario, detection, window, effective_agent}, sort_keys=True)), ensuring idempotency and deduplication.
(ii) The audit record shall capture: decision ID, tier classification, risk score and all components, planned and executed actions, DECIPHER case ID and link (if created), mitigation outcomes, and any errors encountered.
(iii) Audit records shall be written to the structured JSON log at /var/ossec/logs/active-responses.log.

Rationale

Automated response to security events must be proportionate to the assessed risk: acting aggressively on low-confidence signals wastes analyst time, disrupts legitimate users, and erodes trust in the system; acting conservatively on high-confidence signals leaves threats uncontained.

A tiered framework directly addresses this by mapping the continuous risk score R onto a discrete set of escalating response actions, each calibrated to the level of certainty and urgency warranted. Tier 0 preserves observability for events that are detected but do not yet meet the confidence threshold for operational action. Tier 1 ensures that no qualifying event goes unnoticed by the SOC. Tier 2 allows medium containment actions. Tier 3 authorizes automated containment actions (account lock, firewall block, service termination) only when the risk score provides sufficient confidence to justify the operational impact of those actions.

The use of a configurable risk score threshold, adjustable tier boundaries, and a per-scenario allow_mitigation flag means the framework can be tuned conservatively during initial deployment and progressively hardened as operational baselines and false-positive rates are understood. This avoids the binary choice between fully manual and fully automated response, instead providing a graduated path toward automation that the SOC can control and audit at each step.

Acceptance criteria

Successful validation according to test case specification, which shall verify:

Tier classification correctness: For each tier boundary, inject a synthetic alert with a risk score at and around the boundary value and verify that the correct tier is assigned and the correct actions are executed.
Tier 0 / Tier 1 minimum behavior: With default configuration (tier1_min = 0), verify that no event is suppressed to Tier 0 - all events receive at minimum Tier 1 (email) treatment. With tier1_min > 0, verify that events below the minimum receive logging-only treatment.
DECIPHER health check - available: With DECIPHER running, trigger a Tier 2 alert and verify: health check passes, case is created, a FlowIntel case ID and link are returned, the link appears in the email body, and both are recorded in the audit log.
DECIPHER health check - unavailable: With DECIPHER unreachable, continue with risk calculation: health check fails with WARNING log, email notification is still sent, mitigations (if configured) are still executed, and the active response exits with success code.
Audit log completeness: For every tier test, verify that the audit log entry contains the decision ID, tier, risk score and all components, action outcomes, DECIPHER case ID/link (where applicable), and any errors.

Parent links: MRS-007 Intrusion Prevention

Child links: TST-042 Build suspicious login, TST-043 Build non-whitelist GeoIP detection, TST-044 Build log volume abnormal growth, TST-045 Run RADAR for log volume abnormal growth, TST-055 GUI: Build & validate suspicious_login scenario, TST-056 GUI: Build & validate geoip_detection scenario, TST-057 GUI: Build & validate scanning_detection scenario, TST-058 GUI: Build & validate log_volume scenario

Attribute	Value
importance	5
urgency	4
risk	3
type	F
version	0.8

2.3 RADAR scenario: DLP1 - insider data exfiltration SRS-050

As a security engineer, I want RADAR to detect high-volume file read/copy behavior on endpoints and automatically trigger host active response mitigations with a clear audit trail.

Scope

Monitored activity: This requirement applies to file access events on monitored endpoints, specifically read and copy operations captured via Sysmon file events (e.g., Event ID 11 FileCreate, Event ID 23 FileDelete used as proxy for moves/copies) or equivalent host telemetry ingested as Wazuh alerts.

Detection method: Per-user behavioral baseline using an RRCF (Robust Random Cut Forest) model. Each user learns their own normal file-access rate and copy indicator profile over time, enabling detection relative to individual behavior rather than a population average.

User coverage: All users with activity recorded in Wazuh-indexed host telemetry. Each user maintains an independent model instance, identified by the user.name field in the alert.

Time granularity: Configurable aggregation window over which read and copy volumes are computed and compared against the learned baseline.

Alert delivery: Anomaly detection results → Wazuh Monitor → webhook → active response trigger.

Requirements

Anomaly detection: RADAR shall emit an "Insider Threat" alert when the per-user RRCF model classifies current file-access activity as abnormal:

Abnormality criteria: observed read volume or copy indicators exceed the user’s learned RRCF baseline score above a configured anomaly threshold.
Per-user model: each user shall have an independent behavioral baseline to detect deviations relative to that user’s own historical activity.
Feature inputs: the model shall consume at minimum read operation count, copy operation count, and unique file paths accessed within the aggregation window.

Alert content: The alert shall include sufficient context for triage and response:

User identity (user.name) and host identity (agent.name)
Detector name/ID, anomaly score, and confidence value from the RRCF model
Timestamp and time window covering the anomalous activity period
Observed metric values (read count, copy count) and their deviation from baseline

Risk-threshold evaluation: The Wazuh Monitor shall send the alert to the configured webhook when the computed risk score exceeds the threshold defined in the RADAR Technical Specification:

Risk scoring shall follow the Risk = Likelihood × Impact formulation, integrating the RRCF anomaly score (likelihood) with the scenario-configured severity weight (impact).
Threshold configuration shall reside in the scenario configuration file and be adjustable without code changes.

Automated response: When the risk threshold is passed, RADAR shall execute the configured agent active responses:

Event logging: full logging of file-access events covering the anomalous period to the Wazuh indexer.
User lock: the identified user account shall be locked on the affected host for the duration of the investigation period.
Below-threshold handling: if the computed risk score is below the threshold, the alert shall be logged to the index without triggering host-level containment actions.

Audit trail: All detection events, alerts, active responses, and their outcomes shall be logged to the Wazuh indexer with complete audit trails for compliance and forensic analysis.

Rationale

Bulk file read/copy activity is a reliable pre-exfiltration signal (MITRE ATT&CK T1005), covering threats staged locally for removal via media or out-of-band channels that network-based detection (SRS-058) cannot observe. Per-user RRCF modeling avoids false positives from power users while risk-weighted scoring enables proportionate automated containment.

Acceptance criteria

Successful validation according to the corresponding test case specification. Integration with Wazuh Sysmon event collection and RADAR active response framework must be demonstrable in a test environment simulating insider data collection scenarios (bulk file reads, mass copy operations).

Parent links: MRS-007 Intrusion Prevention

Attribute	Value
importance	5
urgency	3
risk	2
type	F
version	0.8

2.4 RADAR scenario: suspicious login SRS-051

As a security engineer, I want RADAR to detect suspicious login activity (failed-login bursts and impossible travel) and apply the existing risk policy to contain the attack.

Scope

Protocol coverage: This requirement applies to SSH authentication events only (Wazuh rule ID series 5710-5760). Future iterations may extend to RDP (rule ID 60XXX series), web-based authentication, and database logins.

Authentication sources: SSH authentication events from Linux/Unix systems via syslog (PAM, sshd logs), specifically:

Failed authentication: Wazuh upstream rule ID 5760 (base event detection)
Successful authentication: Wazuh upstream rule ID 5715 (base event detection)
Agents configured to monitor /var/log/auth.log or equivalent system authentication logs

Note: Rule IDs 5715 and 5760 are standard Wazuh SSH authentication rules (part of the default ruleset), not custom RADAR rules. They serve as prerequisite detection events that trigger RADAR's correlation rules (210012-210022).

GeoIP enrichment: Requires the manager-side RADAR enrichment integration (SRS-068) to provide the radar_country_change_i and radar_geo_velocity_kmh custom fields on the authentication path. These fields are produced by the same enrichment mechanism that SRS-055 uses for its radar_country field.

Requirements

RADAR shall emit a Suspicious Login alert when rule-based conditions classify the current SSH authentication pattern as abnormal. The system shall implement three detection mechanisms:

(i) Failed-login burst: Rule IDs 210012 and 210013 shall trigger when $\ge 5$ failed SSH authentication attempts (rule 5760) occur for the same user within 60 seconds, using Wazuh's timeframe and frequency correlation with <same_srcuser> or <same_user> matching.
(ii) Impossible travel: Rule IDs 210020 (authentication_failed) and 210021 (authentication_success) shall trigger when an SSH login exhibits both:
- Country change: radar_country_change_i field equals 1
- High geo-velocity: radar_geo_velocity_kmh field ≥ 900 (detected via PCRE2 regex matching values ≥900)
(iii) Composite correlation: Rule ID 210022 shall trigger when both a failed-login burst (210012) and an impossible travel success (210021) occur for the same user within a 300-second window, using Wazuh's <if_matched_sid> correlation with timeframe="300" and <same_user /> matching. This detects credential compromise scenarios where attackers first attempt brute-force from one location, then successfully authenticate from a geographically impossible location.

These rules operate alongside the AD pipeline (OpenSearch anomaly detector) but provide deterministic, immediate detection without requiring baseline training.

The alert shall carry contextual metadata appropriate to the detection type:

For signature-based detection (rules 210012, 210013, 210020, 210021, 210022):
- Rule metadata: rule.id, rule.level, rule.description, rule.groups
- User/host context: srcuser/dstuser, srcip, agent.name, agent.id
- GeoIP context: radar_country_change_i, radar_geo_velocity_kmh, country, region, city
- Temporal context: timestamp, timeframe window
For AD-based detection (OpenSearch anomaly detector results):
- Anomaly metrics: anomaly_grade, anomaly_confidence, entity (categorical field value)
- Detection period: period_start, period_end
- Feature contributions: per-feature anomaly scores
Risk scoring (computed by active response script):
- risk_score: Weighted combination $R = w_{ad} \times A + w_{sig} \times S + w_{cti} \times T$ (range $[0,1]$)
- tier: Classification (1=low, 2=medium, 3=high) based on configurable thresholds
- components: Breakdown of anomaly_component, signature_component, cti_component

Alert routing shall follow this workflow:

(a) Wazuh detects authentication pattern → Fires rule 210012/210013/210020/210021/210022
(b) Rule configured with <active-response> invokes the radar_ar.py script
(c) Active response script:
- Collects context events from OpenSearch (time window: signature=1min, AD=10min)
- Extracts IOCs (IPs, users, domains, hashes)
- Queries CTI analysis (SATRAP-DL DECIPHER if configured)
- Computes risk score using configured weights (w_ad, w_sig, w_cti)
- Determines tier based on risk_threshold boundaries
(d) If $R \ge \text{tier1}_{min}$: Execute tier-appropriate containment actions (see requirement 4). Otherwise, log alert to OpenSearch index only, no containment.

Note: For AD-based detections, the OpenSearch monitor sends webhook notifications independently, which are logged to /var/log/suspicious_login.log and ingested by Wazuh for correlation.

RADAR shall execute tiered response (SRS-061) actions based on the computed risk score:
- Tier 0 (R below configured tier1_min, when Tier 0 suppression is enabled): Logging only. The event and full risk computation are recorded in the audit log. To enable Tier 0 suppression, tier1_min must be set to a value greater than 0 in ar.yaml.
- Tier 1 (0.0 ≤ R < 0.33, or tier1_min ≤ R < tier1_max): An email notification and an incident case are created and sent to the configured SOC recipient and DECIPHER endpoint, respectively. Response actions are initiated: the decision is recorded in the audit log with full risk component detail.
- Tier 2 (tier1_max ≤ risk_score < tier2_max, default 0.66): Active containment - IP blocking
  - All Tier 1 actions, plus:
  - Block source IP address via iptables/nftables for 3600 seconds (1 hour)
  - Execute Wazuh's firewall-drop active response with timeout
  - Log firewall rule addition/removal to active response audit trail
- Tier 3 (risk_score ≥ tier2_max, default 0.66): Aggressive containment - user and host isolation
  - All Tier 2 actions, plus:
  - Disable SSH access for the target user account via PAM/passwd modifications (lock_user_linux active response)
  - Place affected host in isolated VLAN (requires SDN controller integration - planned for future release)
  - Trigger immediate SOC escalation via high-priority email/webhook

Logging requirements: All containment actions (firewall rules, user lockouts, network changes) shall be logged to:
- OpenSearch anomaly response index with full context
- Wazuh active response log (/var/ossec/logs/active-responses.log)
- System audit logs (/var/log/radar_ar.log)
Deferred capabilities (planned for future releases):
- SSO account lockout (requires Keycloak/LDAP integration - planned for SRS-052)
- Automated ticket creation in ITSM systems
- Dynamic threat intel submission to MISP/OpenCTI

The system shall maintain comprehensive audit logs of all active response executions:

(a) Each active response invocation shall generate a unique decision_id (SHA256 hash of scenario+timestamp+alert)
(b) Audit records shall capture:
- Decision metadata: decision_id, timestamp, scenario_name, detection_type
- Input data: alert content, context events, IOCs extracted
- Risk computation: all component scores (A, S, T), weights, final risk_score, tier
- Actions taken: List of executed commands/API calls with timestamps
- Outcomes: Success/failure status for each action, error messages if any
(c) Audit logs shall be queryable in OpenSearch for compliance reporting and forensic analysis
(d) Log retention shall follow the organization's compliance requirements (minimum 90 days recommended)

Rationale

Failed-login bursts indicate brute-force or credential stuffing (MITRE ATT&CK T1110); impossible travel indicates stolen credentials used from unauthorized locations. Deterministic signature-based detection complements the OpenSearch AD pipeline, providing sub-minute response without requiring a training period.

Dependencies

SRS-068: Manager-Side Log Enrichment (produces the radar_country_change_i, radar_geo_velocity_kmh custom fields consumed here)
HARC-015: Active response framework (provides script execution infrastructure)
MRS-007: Intrusion Prevention (parent mission requirement)

Related requirements

SRS-052 (future): SSO integration for centralized account lockout
SRS-055: Geo-based access control (shares the same manager-side enrichment integration and its radar_country field, though the two fields this requirement consumes are specific to the authentication path)
SRS-056: Log volume detection (shares similar behavioral baseline and risk scoring approaches)
SRS-058: Data exfiltration detection (shares IOC extraction and CTI enrichment patterns)

Acceptance criteria

Successful validation according to test case specification TST-051, which shall verify:

Failed-login burst detection: Generate 5 failed SSH attempts within 60 seconds for a test user; verify rules 210012/210013 fire
Impossible travel detection: Simulate SSH logins from Poland → USA → Australia with computed geo-velocity ≥ 900 km/h; verify rules 210020/210021 fire
Correlation rule: Execute failed-login burst followed by impossible travel within 5 minutes; verify rule 210022 fires
Risk scoring accuracy: For known test cases, verify risk_score computation matches expected values (±0.05 tolerance)
Tier-based actions: Test scenarios at each tier boundary; verify correct containment actions execute (iptables rules added, user disabled, logs generated)
Alert context completeness: Verify all required fields present in OpenSearch anomaly response index
Audit log integrity: Verify all active response executions logged with complete decision context and action outcomes
No false positives: Legitimate user behavior (normal login patterns, expected country changes with low velocity) shall not trigger alerts

Parent links: MRS-007 Intrusion Prevention

Child links: LARC-015 RADAR scenario setup flow, LARC-016 RADAR active response flow, LARC-017 RADAR integration with Opensearch modules, LARC-018 RADAR logical flow, LARC-021 RADAR risk engine calculation flow, LARC-022 RADAR detector creation workflow, LARC-023 RADAR monitor and webhook workflow, LARC-025 RADAR helper enrichment pipeline, LARC-026 RADAR active response decision pipeline, LARC-027 RADAR data ingestion pipeline, TST-042 Build suspicious login, TST-049 RADAR deployment integrity verification, TST-055 GUI: Build & validate suspicious_login scenario

Attribute	Value
importance	4
urgency	3
risk	2
type	F
version	0.5

2.5 RADAR scenario: DDoS detection SRS-052

As a security engineer, I want RADAR to detect inbound traffic surges consistent with DDoS against protected services and trigger the configured mitigation with auditable evidence.

Scope

Monitored traffic: This requirement applies to inbound network traffic directed at protected service endpoints, measured by connection rate and/or packet/byte volume per endpoint over a configurable time window.

Detection method: Per-endpoint behavioral baseline model that learns each service’s normal inbound traffic profile. Detection fires when the observed traffic volume or connection rate deviates significantly from the endpoint’s own learned baseline, rather than relying on a fixed global threshold.

Endpoint coverage: All Wazuh-monitored hosts and services configured for DDoS detection in the scenario. Each endpoint maintains an independent baseline instance, identified by agent.name or equivalent service identifier.

Time granularity: Configurable aggregation window over which inbound connection counts and byte volumes are accumulated and compared against the learned baseline.

Alert delivery: Anomaly detection results → Wazuh Monitor → webhook → active response trigger.

Requirements

Anomaly detection: RADAR shall emit a "DDoS" alert when the per-endpoint model flags the current inbound traffic profile as anomalous:

Abnormality criteria: observed inbound traffic volume or connection rate exceeds the endpoint’s learned baseline score above a configured anomaly threshold.
Per-endpoint model: each protected service shall have an independent behavioral baseline to detect deviations relative to its own normal traffic pattern.
Feature inputs: the model shall consume at minimum inbound connection count, inbound byte volume, and unique source IP count within the aggregation window.

Alert content: The alert shall include sufficient context for triage and response:

Host/service identity (agent.name) and source context where available
Detector name/ID, anomaly score, and confidence value
Timestamp and time window covering the anomalous traffic period
Observed metric values (connection rate, byte volume) and their deviation from baseline

Risk-threshold evaluation: The Wazuh Monitor shall send the alert to the configured webhook when the computed risk score exceeds the threshold defined in the RADAR Technical Specification:

Risk scoring shall follow the Risk = Likelihood × Impact formulation, integrating the anomaly score (likelihood) with the scenario-configured severity weight (impact).
Threshold configuration shall reside in the scenario configuration file and be adjustable without code changes.

Automated response: When the risk threshold is passed, RADAR shall execute the configured active responses:

Firewall block: inbound connections from flagged source ranges shall be blocked via Wazuh active response.
Rate-limiting: connection rate limits shall be enforced on the affected host to protect service availability.
Below-threshold handling: if the computed risk score is below the threshold, the alert shall be logged to the index without triggering network-level mitigation.

Audit trail: All detection events, alerts, active responses, and their outcomes shall be logged to the Wazuh indexer with complete audit trails for compliance and forensic analysis.

Rationale

Volumetric DDoS attacks are identified by inbound traffic surges far exceeding a service's normal load. Per-endpoint behavioral modeling distinguishes genuine attacks from legitimate spikes, avoiding the false positives of fixed global thresholds, and wires the scored result directly to firewall and rate-limiting responses for rapid automated mitigation.

Acceptance criteria

Successful validation according to the corresponding test case specification. DDoS traffic simulation and firewall/rate-limit active response execution must be demonstrable in a test environment with inbound traffic telemetry collected by Wazuh.

Parent links: MRS-007 Intrusion Prevention

Attribute	Value
importance	2
urgency	1
risk	2
type	F
version	0.5

2.6 RADAR scenario: malware C2 beaconing SRS-053

As a security engineer, I want RADAR to detect malware command-and-control communication through beaconing patterns and contain the attack using the configured active response flow.

Scope

Monitored activity: This requirement applies to outbound network connection events on monitored endpoints. Beaconing is identified by repeated outbound connections to the same external destination at near-regular intervals within a configurable analysis window.

Detection method: Per-host baseline detector that learns normal outbound connection behavior for each endpoint. A connection sequence is flagged as a beacon when its timing regularity and destination repetition exceed a configured threshold relative to the host’s historical outbound pattern.

Host coverage: All Wazuh-monitored endpoints configured for C2 beaconing detection in the scenario. Each host maintains an independent baseline instance, identified by agent.name.

Time granularity: Configurable analysis window within which connection timestamps to a single destination are evaluated for interval regularity.

Alert delivery: Anomaly detection results → Wazuh Monitor → webhook → active response trigger.

Requirements

Beaconing detection: RADAR shall emit a "C2 Beaconing" alert when the per-host detector identifies beacon-like outbound connection behavior:

Abnormality criteria: repeated connections to the same external destination at near-regular intervals, where interval regularity and frequency exceed the host’s learned baseline and the anomaly score is above a configured threshold.
Per-host model: each endpoint shall have an independent behavioral baseline to distinguish beaconing from legitimate scheduled outbound activity (e.g., NTP, telemetry agents).
Feature inputs: the model shall consume at minimum destination IP/domain, inter-connection interval regularity (jitter), connection count within the analysis window, and data volume per connection.

Alert content: The alert shall include sufficient context for triage and response:

Host identity (agent.name) and user context where available
Detector name/ID, anomaly score, and confidence value
Timestamp and analysis window covering the beaconing activity
Destination IP/domain, observed interval regularity, and connection count

Risk-threshold evaluation: The Wazuh Monitor shall send the alert to the configured webhook when the computed risk score exceeds the threshold defined in the RADAR Technical Specification:

Risk scoring shall follow the Risk = Likelihood × Impact formulation, integrating the anomaly score (likelihood) with the scenario-configured severity weight (impact).
Threshold configuration shall reside in the scenario configuration file and be adjustable without code changes.

Automated response: When the risk threshold is passed, RADAR shall execute the configured containment active responses:

Firewall block: outbound connections to the identified destination IP/range shall be blocked via Wazuh active response.
Service termination: the process responsible for the beaconing connection shall be terminated on the affected host where process attribution is available.
Host quarantine: the affected host shall be network-isolated to prevent further C2 communication and lateral movement.
Below-threshold handling: if the computed risk score is below the threshold, the alert shall be logged to the index without triggering containment actions.

Audit trail: All detection events, alerts, active responses, and their outcomes shall be logged to the Wazuh indexer with complete audit trails for compliance and forensic analysis.

Rationale

Periodic outbound connections to a fixed external destination at regular intervals are a hallmark of C2 implant check-in (MITRE ATT&CK T1071). Per-host behavioral modeling distinguishes beacons from legitimate scheduled processes (NTP, telemetry) without relying on static IP blocklists that malleable C2 frameworks easily evade.

Acceptance criteria

Successful validation according to the corresponding test case specification. C2 beaconing simulation and firewall block, service termination, and host quarantine active response execution must be demonstrable in a test environment with outbound connection telemetry collected by Wazuh.

Parent links: MRS-007 Intrusion Prevention

Attribute	Value
importance	4
urgency	2
risk	2
type	F
version	0.5

2.7 RADAR automated test framework SRS-054

As a security engineer, I want the RADAR test workflow to be automated end-to-end for reproducibility, to bring up the stack, feed scenario data, exercise active responses, and collect results without manual steps.

Scope

Framework coverage: This requirement applies to the automated test pipeline for all RADAR detection scenarios. The framework shall support the full test lifecycle: environment provisioning, dataset ingestion, threat simulation, active response exercise, and result evaluation.

Execution environment: Tests shall run in an isolated containerised environment that mirrors the production RADAR stack (OpenSearch, Wazuh, webhook, active response agents) to ensure fidelity between test and production behaviour.

Repeatability target: Any test run shall be fully reproducible from a clean state given the same input datasets and scenario configuration, with no dependency on pre-existing state in the environment.

Integration scope: The framework shall cover all scenario types defined in the SRS (anomaly detection scenarios, GeoIP-based access control, volume spike detection, and active response flows).

Requirements

Automated data ingest: The framework shall automatically prepare and load all required test data without manual intervention:

Ingest scenario-specific alert datasets into OpenSearch indices in the format expected by the relevant RADAR detectors.
Create and configure required users, hosts, and test entities in scenario-specific systems (e.g., Wazuh agent registration, OpenSearch user accounts).
Validate successful ingestion before proceeding to subsequent test phases.

Automated environment setup: The framework shall provision and configure the full RADAR stack from a defined baseline:

Deploy all RADAR components and their dependencies using the project’s standard tooling (Docker Compose / Ansible).
Apply scenario-specific configuration (detector parameters, thresholds, active response definitions) programmatically from the scenario configuration file.
Verify component health and readiness before executing test cases.

Automated threat simulation: The framework shall reproducibly exercise the attack scenarios that RADAR is designed to detect:

Generate and inject synthetic or replay-based threat traffic/events that correspond to each scenario’s detection target (e.g., beaconing connections, traffic surges, file read spikes).
Parameterise simulations so that both below-threshold and above-threshold cases can be exercised in a single run.
Record simulation inputs and timing for traceability between injected events and observed detection results.

Automated evaluation: The framework shall assess test outcomes and produce structured, machine-readable results:

Evaluate detection results against expected outcomes (true positive, false positive, false negative, true negative) for each scenario test case.
Compute evaluation metrics including detection rate, false positive rate, response latency, and active response success rate.
Produce a structured test report (artifacts + metrics) that can be archived and compared across test runs to track regressions.

Audit trail: All test execution steps, ingested datasets, simulation parameters, detection results, and evaluation metrics shall be persisted as test artifacts for post-run analysis and compliance evidence.

Rationale

Manual test execution of multi-component security systems is error-prone and difficult to reproduce. A fully automated framework guarantees identical environment state, data flow, and result collection across runs, providing a reliable regression baseline and enabling objective comparison of detection performance over time.

Acceptance criteria

Successful validation according to the corresponding test case specification. A complete automated test run covering at minimum one detection scenario must be demonstrable: from clean environment provisioning through dataset ingest, threat simulation, active response execution, and structured result report generation, without any manual intervention.

Parent links: MRS-007 Intrusion Prevention

Child links: LARC-017 RADAR integration with Opensearch modules, LARC-021 RADAR risk engine calculation flow, LARC-026 RADAR active response decision pipeline, LARC-029 RADAR log volume detection scenario flow

Attribute	Value
importance	4
urgency	3
risk	2
type	F
version	0.5

2.8 RADAR scenario: Geo-IP AC via whitelisting SRS-055

As a security engineer, I want RADAR to enforce access control by detecting access attempts from non-whitelisted countries and applying the existing active response, so that connections from not approved geographies are detected.

Scope

Authentication protocol coverage: This requirement applies to any authentication event classified under Wazuh group authentication_success, including but not limited to: SSH (rule series 5715), web authentication (rule series 311XX), VPN authentication, and database logins.

Web server access logs: This requirement additionally applies to HTTP/HTTPS access logs from Apache and Nginx web servers, classified under Wazuh group accesslog. Detection monitors all incoming web requests regardless of HTTP status code.

GeoIP data source: Requires the manager-side RADAR enrichment integration (see SRS-068), utilizing MaxMind GeoLite2 databases for IP-to-country resolution.

Whitelist management: Country whitelist maintained as Wazuh CDB list at etc/lists/whitelist_countries using country names matching GeoLite2 country name format (e.g., "Luxembourg", "France", "Germany", "Belgium").

Private/internal IP handling: Detection logic explicitly excludes RFC1918 private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local addresses to prevent false positives from internal network access. Private IP addresses do not trigger GeoIP enrichment or whitelist checking.

Requirements

RADAR shall maintain a country whitelist as a machine-readable configuration that can be updated without code changes:

(i) Whitelist format: Wazuh CDB (constant database) list stored at etc/lists/whitelist_countries with entries in format country_name: (one per line, colon-terminated)
(ii) Country names shall match MaxMind GeoLite2 country name format (e.g., "Luxembourg", "France", "Germany", "Belgium")
(iii) Whitelist updates: Modifications to the CDB list file shall be applied via Wazuh manager configuration reload (ossec-control restart or systemctl restart wazuh-manager) without requiring code changes
(iv) List declaration: The whitelist shall be declared in ossec.conf within <ruleset><list> section, with appropriate file permissions (read access for wazuh user)

For each relevant security event, the manager-side RADAR enrichment integration shall augment Wazuh events with GeoIP metadata:

(i) Triggering events, each handled by its own integration script on the Wazuh manager:
- custom-radar-enrich: any parsed SSH authentication line (sshd success or failure) with a valid source IP, once the alert reaches the manager.
- custom-radar-web-enrich: any Apache/Nginx access log line containing an HTTP request and a resolvable, non-private source IP.
(ii) Enrichment fields added, appended as a RADAR ... tail to the original log line and re-ingested through a RADAR-aware child decoder:
- Authentication path (custom-radar-enrich, decoded by the *-with-radar decoders in scenarios/decoders/geoip_detection/0310-ssh.xml and scenarios/decoders/suspicious_login/0310-ssh.xml): radar_outcome, radar_asn, radar_asn_placeholder_flag, radar_country, radar_region, radar_city, radar_geo_velocity_kmh, radar_country_change_i, radar_asn_novelty_i.
- Web-access-log path (custom-radar-web-enrich, decoded by the *-radar decoders in scenarios/decoders/geoip_detection/0375-web-accesslog.xml): radar_country, radar_region, radar_city only — this path does not add radar_asn, geo-velocity, or novelty fields.
(iii) Enrichment pipeline: each integration script is invoked by the Wazuh manager's own integrator process once per matching alert (the standard Wazuh <integration> mechanism), reads the alert JSON, computes the enrichment fields, and appends the result to a manager-local enriched log file (/var/ossec/logs/radar/enriched_auth.log or /var/ossec/logs/radar/enriched_web_access.log), which Wazuh then re-ingests via localfile and decodes with the RADAR-aware decoders above. There is no separate long-running enrichment service or daemon.
(iv) Database updates: MaxMind GeoLite2 databases shall be updated at least monthly to maintain geolocation accuracy

RADAR shall emit a "Non-whitelisted Country Access" alert when the enriched country value does not match any entry in the configured whitelist:

(i) List-based detection for authentication events (Rule 100900, level 10):
- Matches events in group authentication_success
- Requires radar_country field to be populated (PCRE2 regex .+ check)
- Uses Wazuh list lookup: <list field="radar_country" lookup="not_match_key">etc/lists/whitelist_countries</list>
- Fires when radar_country value NOT found in whitelist
- Rule description: "Connection from non-whitelist country"
(ii) List-based detection for web access log events (Rule 100902, level 10):
- Matches events in group accesslog
- Requires radar_country field to be populated (PCRE2 regex .+ check)
- Uses same Wazuh list lookup as Rule 100900: <list field="radar_country" lookup="not_match_key">etc/lists/whitelist_countries</list>
- Fires when radar_country value NOT found in whitelist
- Rule description: "Connection from non-whitelist country (access log)"
- Decoded by web-accesslog-domainport-radar, web-accesslog-ip-ip-radar, web-accesslog-domain-radar, or web-accesslog-ip-radar child decoders (each a RADAR-aware variant of the corresponding stock web-accesslog-* decoder, matching a RADAR country="..." tail appended by custom-radar-web-enrich and extracting radar_country, radar_region, radar_city)
(iii) Fallback hardcoded detection (Rule 100901, level 10):
- Matches events in group authentication_success
- Uses inline country check: <srcgeoip negate="yes">Luxembourg|France|Germany|Belgium</srcgeoip>
- Serves as backup detection only
- Rule description: "Connection from non-whitelist country"
- Limitation: The <srcgeoip> rule option requires Wazuh to be compiled from source with USE_GEOIP=yes flag and the legacy GeoIP.dat database.
(iv) Private IP exclusion: Rules shall NOT fire when source IP is in private address ranges (Wazuh's <srcip> matching with negation ensures this)
(v) Alert metadata includes:
- Rule metadata: rule.id (100900, 100901, 100902), rule.level (10), rule.description, rule.groups
- User/host context: dstuser, srcip, agent.name, agent.id
- GeoIP context: radar_country, radar_city, radar_region, radar_asn (authentication events only)
- Temporal context: timestamp

RADAR shall execute risk-based active response (SRS-061) when non-whitelisted country access is detected:

(i) Active response invocation: Rules 100900 and 100901 configured with <active-response> block in ossec.conf, invoking radar_ar.py script with scenario geoip_detection
(ii) Risk scoring: Active response script computes risk score using formula R = w_ad × A + w_sig × S + w_cti × T where:
- w_ad = 0.0 (no anomaly detection component for this signature-based scenario)
- w_sig = 0.6 (signature/rule-based component weight)
- w_cti = 0.4 (cyber threat intelligence component weight)
- A = 0 (no OpenSearch anomaly detector for this scenario)
- S = likelihood × impact = 0.8 × 0.6 = 0.48 (signature component)
- T = CTI enrichment score (1 if IOCs found in threat intel, 0 otherwise)
(iii) Tiered response actions:
- Tier 0 (risk_score < tier1_min): Logging only
- Tier 1 (tier1_min ≤ risk_score < tier1_max, default 0.33): Email notification to SOC, FlowIntel case creation via DECIPHER incident endpoint, log to active response audit log
- Tier 2 (tier1_max ≤ risk_score < tier2_max, default 0.66): Tier 1 actions + block source IP via firewall-drop active response command (iptables/nftables rule with timeout)
- Tier 3 (risk_score ≥ tier2_max, default 0.66): Tier 2 actions + high-priority SOC escalation
(v) Email format: Notification shall include alert summary, risk score breakdown, affected user/host, source country, and recommended manual verification steps

The system shall maintain comprehensive audit logs of all active response executions:

(i) Each active response invocation generates unique decision_id (SHA256 hash of scenario+timestamp+alert)
(ii) Audit records shall capture:
- Decision metadata: decision_id, timestamp, scenario_name="geoip_detection", detection_type="signature"
- Input data: alert content (rule ID, level, description), source IP, country, user
- Risk computation: signature_component (S), cti_component (T), final risk_score, tier classification
- Actions taken: List of executed actions (email, firewall-drop, case creation) with timestamps
- Outcomes: Success/failure status for each action, error messages if any
(iii) Audit log destinations:
- OpenSearch anomaly response index: wazuh-ar-geoip-detection-* (structured JSON, queryable)
- Wazuh active response log: /var/ossec/logs/active-responses.log (syslog format)
- RADAR audit log: /var/log/radar_ar.log (detailed execution trace)
(iv) Log retention: Audit logs shall be retained for minimum 90 days (configurable per compliance requirements)

Rationale

Country-based access control reduces exposure to high-risk regions and supports GDPR/export-control compliance. The deterministic signature-based approach (rules 100900/100901) provides immediate detection without a training period, complementing behavioral anomaly detection for credential compromise scenarios (SRS-051).

Dependencies

Manager-side RADAR enrichment integration (custom-radar-enrich, custom-radar-web-enrich, and the shared radar_enrichment/ module — see SRS-068): GeoIP enrichment providing the radar_country field via MaxMind GeoLite2 database lookup. Runs entirely on the Wazuh manager as Wazuh integration hooks.
MaxMind GeoLite2 Database: Country and City databases for IP geolocation. Requires periodic updates (monthly recommended) for accuracy.
Wazuh CDB Lists: List-based detection (rule 100900) requires Wazuh support for CDB lists (<list> tag in rules, list declaration in ossec.conf).
HARC-015: Active response framework (provides script execution infrastructure, radar_ar.py implementation).
SRS-068: Manager-Side Log Enrichment. Defines the enrichment architecture that this requirement's GeoIP fields rely on.
MRS-007: Intrusion Prevention (parent mission requirement).

Related requirements

SRS-051: Suspicious login detection (consumes radar_country_change_i and radar_geo_velocity_kmh fields)
SRS-056: Log volume detection (shares risk scoring engine and active response framework)
SRS-058: Data exfiltration detection (shares CTI enrichment patterns)

Acceptance criteria

Successful validation according to test case specification TST-055, which shall verify:

Whitelisted country access (SSH): SSH login from whitelisted country (e.g., Luxembourg) → No alert fired
Non-whitelisted country detection (list-based, SSH): SSH login from non-whitelisted country (e.g., USA) with radar_country enrichment → Rule 100900 fires with level 10
Non-whitelisted country detection (fallback): SSH login from non-whitelisted country without CDB list → Rule 100901 fires with level 10
Whitelist update: Add USA to etc/lists/whitelist_countries, reload Wazuh manager, repeat login from USA → No alert fired
Private IP exclusion: SSH login from private IP (192.168.1.10) regardless of geolocation → No alert fired
Web access log detection: HTTP request to Apache/Nginx from non-whitelisted country IP (e.g., Brazil) → custom-radar-web-enrich appends a RADAR country="Brazil" ... tail to the log line, the RADAR-aware child decoder extracts radar_country="Brazil", Rule 100902 fires with level 10
Web access log - whitelisted country: HTTP request from whitelisted country → Rule 100902 does not fire
Web access log - private IP: HTTP request from RFC1918 address → custom-radar-web-enrich skips enrichment (its private-IP check in web_enrichment.py short-circuits before any GeoIP lookup), no RADAR country= tail is appended, no rule fires
Web decoder format support: Verify radar_country field correctly extracted for all supported log formats (single IP, domain+IP, hostname:port+IP) via wazuh-logtest
Risk score computation: For rule 100900 alert, verify R = 0.6 × (0.8 × 0.6) + 0.4 × T = 0.288 + 0.4T, tier assignment based on threshold
Tier 2 firewall action: Generate alert with risk_score ≥ 0.51 → Verify firewall-drop active response executes, source IP blocked in iptables, audit log entry created
Email notification: Verify SOC email sent with correct alert metadata, risk score breakdown, and source country information
Audit log completeness: Verify all response actions logged to OpenSearch, /var/log/radar_ar.log, and /var/ossec/logs/active-responses.log with decision_id, risk components, and outcomes
Manager-side enrichment dependency: Disable the custom-radar-enrich integration on the manager, generate an authentication event → Verify enrichment fields absent, rule 100900 does not fire (rule 100901 fallback may fire if srcgeoip available from other source)

Parent links: MRS-007 Intrusion Prevention

Child links: LARC-021 RADAR risk engine calculation flow, LARC-025 RADAR helper enrichment pipeline, LARC-026 RADAR active response decision pipeline, LARC-028 RADAR GeoIP detection scenario flow, TST-043 Build non-whitelist GeoIP detection, TST-049 RADAR deployment integrity verification, TST-056 GUI: Build & validate geoip_detection scenario

Attribute	Value
importance	5
urgency	4
risk	2
type	F
version	0.5

2.9 RADAR scenario: log size change SRS-056

As a security engineer, I want RADAR to detect unusual log volume spikes for each endpoint based on its own normal behavior, and then apply the existing risk policy to decide how to react.

Scope

Monitored directories: This requirement applies to the total disk usage of /var/log directory on each monitored endpoint, measured in bytes. Individual log files or log types are not separately analyzed in the current implementation.

Endpoint coverage: All Wazuh agents configured with log volume monitoring via local command execution (alias log_volume_metric). Agents must have read access to /var/log directory and permission to execute the du command.

Detection method: Per-endpoint behavioral baseline using OpenSearch Anomaly Detection High-Cardinality Detector (HCAD) with categorical field agent.name.keyword. Each endpoint learns its own "normal" log growth rate over the detector training period (default: 8 shingle intervals × 5 minutes = 40 minutes minimum baseline).

Time granularity: Detector interval 5 minutes, aggregation uses max function on data.log_bytes field to capture peak log volume within each window.

Alert delivery: Anomaly detection results → OpenSearch monitor → webhook → Wazuh log ingestion → rule-based active response trigger.

Requirements

RADAR shall emit a "Log volume spike" alert when OpenSearch Anomaly Detection identifies behavior significantly exceeding the learned baseline for a specific endpoint:

(i) OpenSearch detector configuration (defined in config.yaml under scenarios.log_volume):
- Detector name: "log_volume"
- Index pattern: wazuh-ad-log-volume-* (date-based indexing for time-series data)
- Result index: opensearch-ad-plugin-result-log-volume (stores anomaly grades and metadata)
- Categorical field: agent.name (enables per-endpoint baselines using HCAD multi-entity detection)
- Feature definition: log_volume_max using max aggregation on data.log_bytes field
- Shingle size: 8 (combines 8 consecutive intervals for pattern recognition)
- Detector interval: 5 minutes (measurement frequency)
- Window delay: 1 minute (allows for indexing lag before analysis)
(ii) Anomaly threshold criteria (both must be met to trigger alert):
- Anomaly grade: anomaly_grade ≥ 0.3 (configurable via anomaly_grade_threshold)
- Confidence: confidence ≥ 0.3 (configurable via confidence_threshold)
(iii) Baseline learning requirements:
- Minimum data points: 32 intervals (8 shingles × 4 intervals per shingle = ~2.7 hours at 5-minute intervals)
- Training period: Detector learns "normal" log volume distribution for each agent independently
- Adaptation: Model continuously updates to track gradual baseline drift (e.g., application upgrades increasing normal log verbosity)
(iv) Spike quantification: Anomaly grade > 0.3 typically indicates log volume deviation > 2σ (two standard deviations) above the learned mean for that specific endpoint. Grade > 0.7 indicates extreme deviation (> 3σ).

The "Log volume spike" alert shall carry comprehensive metadata through the detection and response pipeline:

(i) OpenSearch monitor message (webhook payload structure):
- Monitor metadata: monitor_name="LogVolume-Monitor", trigger_name="LogVolume-Growth-Detected"
- Anomaly metrics: anomaly_grade (severity score [0,1]), confidence (model certainty [0,1])
- Entity identification: entity field contains agent name (e.g., "agent.insider", "webserver-prod-01")
- Feature data: feature_data.log_volume_max.data (actual measured log bytes value)
- Time window: period_start, period_end (ISO8601 timestamps defining the detection interval)
- Detector context: detector_id, detector_name for traceability
(ii) Wazuh event fields (after webhook writes to log file and Wazuh ingests):
- Alert decoder: opensearch_ad (custom decoder in 0001-log-volume.xml)
- Extracted fields: data.anomaly_grade, data.confidence, data.trigger_name, data.entity_keyword
- Trigger matching: Rule 100300 (generic AD alert) → Rule 100309 (specific to "LogVolume-Growth-Detected")
(iii) Active response augmentation (radar_ar.py LogVolume class processing):
- Agent resolution: Parses data.entity_keyword to extract agent name/ID
- Time window computation: Converts period_start/period_end to datetime for context collection
- Detector metadata: Adds detector_name="log_volume", scenario_id="log_volume" to audit records
- Context enrichment: Queries OpenSearch for events from affected agent within time window

Each monitored endpoint shall execute a local command to measure /var/log directory size and report results to Wazuh manager:

(i) Agent configuration (localfile command in radar-log-volume-agent-snippet.xml): xml <localfile> <log_format>full_command</log_format> <command>du -sb /var/log | awk '{print "log_bytes: "$1}'</command> <alias>log_volume_metric</alias> <frequency>300</frequency> </localfile>
(ii) Command behavior:
- du -sb /var/log: Disk usage in bytes, summarize (single total for directory tree)
- awk '{print "log_bytes: "$1}': Formats output as structured key-value pair
- Output example: log_bytes: 524288000 (500 MB in bytes)
(iii) Execution frequency: 300 seconds (5 minutes), aligned with OpenSearch detector interval to ensure one measurement per detection window
(iv) Permissions and requirements:
- Command runs as wazuh user (agent process owner)
- Requires read access to /var/log and subdirectories
- Requires du and awk commands available in agent's PATH
- Works on Linux/Unix systems (not applicable to Windows agents without modification)

Wazuh agents shall send log volume measurements to the manager, where a decoder extracts the metric and forwards it to OpenSearch for indexing:

(i) Wazuh decoder (defined in 0001-log-volume.xml):
- Decoder name: log_volume_metric
- Matches alias: log_volume_metric (tags output from localfile command)
- Field extraction: Parses log_bytes: <value> pattern, stores in data.log_bytes
(ii) Index pattern: wazuh-ad-log-volume-YYYY.MM.DD (date math enabled via index template or pipeline)
- Date-based indexing facilitates time-series queries and retention policies
- Index template defines mappings: @timestamp (date), agent.name (keyword), data.log_bytes (long)
(iii) Document structure (example): json { "@timestamp": "2026-02-17T14:35:00.000Z", "agent": { "name": "webserver-prod-01", "id": "001" }, "data": { "log_bytes": 524288000 }, "decoder": { "name": "log_volume_metric" } }
(iv) Index refresh interval: 5 seconds (balances near-real-time detection with indexing overhead). OpenSearch detector query runs every 5 minutes, querying data from previous interval.

OpenSearch monitor shall evaluate detector results and deliver alerts via webhook when thresholds are exceeded:

(i) Monitor configuration (automated via radar/anomaly_detector/monitor.py):
- Monitor type: Per-query monitor (queries anomaly detector result index)
- Schedule: Runs every detector interval (5 minutes)
- Query: anomaly_grade >= 0.3 AND confidence >= 0.3 against opensearch-ad-plugin-result-log-volume
(ii) Trigger conditions: When query returns results (threshold exceeded for any entity)
- Trigger name: "LogVolume-Growth-Detected" (matched by Wazuh rule 100309)
- Severity: High (configurable)
(iii) Webhook action: HTTP POST to RADAR webhook service endpoint
- Webhook URL: http://<webhook-service>:5000/webhook (configurable)
- Payload: JSON containing monitor metadata, anomaly metrics, entity, time window
- Retry logic: 3 attempts with exponential backoff (OpenSearch default)
(iv) Webhook processing (RADAR webhook service):
- Receives JSON POST request
- Formats message as syslog-compatible text
- Writes to /var/log/ad_alerts.log with timestamp and structured fields
- Example log line: Feb 17 14:40:01 radar-webhook: LogVolume-Growth-Detected entity=webserver-prod-01 anomaly_grade=0.75 confidence=0.82
(v) Wazuh ingestion:
- Wazuh manager monitors /var/log/ad_alerts.log (configured in ossec.conf)
- Decoder opensearch_ad parses structured fields
- Rule 100300 fires (generic AD alert), then rule 100309 fires (specific trigger match)
- Rule 100309 invokes active response via <active-response> block

RADAR shall execute risk-based active response when log volume anomalies exceed the configured risk threshold:

(i) Risk scoring: Active response script (radar_ar.py) computes risk score using formula R = w_ad × A + w_sig × S + w_cti × T where:
- w_ad = 0.9 (anomaly detection component weight - heavily favored for this AD-based scenario)
- w_sig = 0.0 (signature component weight - not applicable, no signature rules)
- w_cti = 0.1 (cyber threat intelligence component weight)
- A = anomaly_grade × confidence (both from detector output, range [0,1])
- S = 0 (no signature component for this scenario)
- T = CTI enrichment score (queries threat intel for affected agent IP if configured; typically 0 for log volume unless correlated with known malicious activity)
(ii) Example risk calculation:
- Anomaly: grade=0.75, confidence=0.82
- A = 0.75 × 0.82 = 0.615
- R = 0.9 × 0.615 + 0.0 × 0 + 0.1 × 0 = 0.554
- Result: risk_score = 0.554 → Tier 2 (0.33 ≤ 0.554 < 0.66)
(iii) Risk threshold: Alerts with risk_score ≥ 0.51 (configurable in ar.yaml) trigger containment actions; below threshold alerts are logged only
(iv) Tiered response actions:
- Tier 0 (risk_score < tier1_min): Logging only
- Tier 1 (tier1_min ≤ risk_score < tier1_max): Passive monitoring
  - Log alert to OpenSearch anomaly response index
  - Send email notification to SOC (if SMTP configured)
  - Record decision in audit log with tier=1
- Tier 2 (tier1_max ≤ risk_score < tier2_max): Active investigation
  - All Tier 1 actions, plus:
  - Enhanced logging with context collection (recent events from affected agent)
  - SOC dashboard alert escalation
- Tier 3 (risk_score ≥ tier2_max): Automated mitigation
  - All Tier 2 actions, plus:
  - Execute terminate_service mitigation (requires manual playbook implementation - typically stops log-generating service or rotates logs)
  - Create incident case in Flowintel (if configured)
  - Immediate SOC escalation via high-priority notification
(v) Email notification format: Alert summary, anomaly metrics (grade, confidence), affected agent, log volume value, time window, risk score breakdown, recommended investigation steps

The system shall maintain comprehensive audit logs of all active response executions:

(i) Each active response invocation generates unique decision_id (SHA256 hash of scenario+timestamp+alert)
(ii) Audit records shall capture:
- Decision metadata: decision_id, timestamp, scenario_name="log_volume", detection_type="ad"
- Input data: alert content (trigger name, anomaly_grade, confidence), entity (agent name), time window
- Risk computation: anomaly_component (A), cti_component (T), final risk_score, tier classification
- Context: Log bytes value, detector name, period_start/period_end
- Actions taken: List of executed actions (email, mitigation commands, case creation) with timestamps
- Outcomes: Success/failure status for each action, error messages if any
(iii) Audit log destinations:
- OpenSearch anomaly response index: wazuh-ar-log-volume-* (structured JSON, queryable for analytics)
- Wazuh active response log: /var/ossec/logs/active-responses.log (syslog format for Wazuh integration)
- RADAR audit log: /var/log/radar_ar.log (detailed execution trace for debugging)
(iv) Log retention: Audit logs shall be retained for minimum 90 days (configurable per organizational compliance requirements)

Rationale

Log volume spikes can signal log flooding attacks, verbose malware error loops, or log injection for DLP evasion. Per-endpoint HCAD baselines accommodate the wide variance in normal log rates across heterogeneous infrastructure and adapt automatically to legitimate baseline drift, complementing content-based signature detection by identifying anomalous volume regardless of log content.

Dependencies

OpenSearch Anomaly Detection Plugin: Provides HCAD (High-Cardinality Anomaly Detection) engine for per-endpoint baseline learning. Requires OpenSearch 2.x with AD plugin installed.
RADAR Webhook Service: Relays OpenSearch monitor alerts to Wazuh ingestion. Deployed as standalone service (Flask/Python) or integrated into RADAR core.
RADAR Anomaly Detector Module (radar/anomaly_detector/): Python automation for detector/monitor provisioning via OpenSearch API. Includes detector.py, monitor.py, webhook.py scripts.
Wazuh Agent Dependencies: Agents must have du and awk commands available (standard on most Linux distributions). Windows agents require PowerShell equivalent commands.
HARC-015: Active response framework (provides script execution infrastructure, radar_ar.py implementation).
MRS-007: Intrusion Prevention (parent mission requirement).

Related requirements

SRS-051: Suspicious login detection (shares risk scoring engine and active response framework patterns)
SRS-055: Geo-based access control (shares CTI enrichment and audit logging approaches)
SRS-058: Data exfiltration detection (similar behavioral baseline approach for network volume anomalies)

Acceptance criteria

Successful validation according to test case specification TST-056, which shall verify:

Baseline establishment: Deploy an agent with stable log volume for a sufficient training period. Verify the detector learns a baseline and does not flag normal behavior as anomalous.
Anomaly trigger - moderate spike: Grow the monitored directory to a moderate multiple of its baseline. Verify an anomaly is flagged within a small number of detection intervals, with moderate confidence.
Anomaly trigger - severe spike: Grow the monitored directory to a much larger multiple of its baseline. Verify the anomaly is flagged with high confidence.
Webhook delivery: Verify the anomaly detector fires when its threshold is exceeded and delivers the alert to the webhook with the expected fields (anomaly grade, confidence, affected entity, time window).
Wazuh ingestion: Verify the delivered alert is ingested by Wazuh and matched by both the generic anomaly-detection rule and the log-volume-specific rule.
Risk score computation: For a known anomaly grade and confidence, verify the computed risk score and resulting tier match the documented formula.
Tier 3 response - high confidence: Generate a high-confidence anomaly that resolves to Tier 3. Verify an email notification is sent, the alert is recorded in the anomaly response index, the audit trail shows Tier 3 with the expected actions, and any configured mitigation is logged.
Alert metadata completeness: For any triggered alert, verify the anomaly response index record contains a decision ID, scenario and detection-type identifiers, the anomaly metrics, the affected entity, the time window, the risk score and tier, the actions taken, and a timestamp.

Parent links: MRS-007 Intrusion Prevention

Child links: LARC-021 RADAR risk engine calculation flow, LARC-022 RADAR detector creation workflow, LARC-023 RADAR monitor and webhook workflow, LARC-026 RADAR active response decision pipeline, LARC-027 RADAR data ingestion pipeline, LARC-029 RADAR log volume detection scenario flow, TST-044 Build log volume abnormal growth, TST-045 Run RADAR for log volume abnormal growth, TST-049 RADAR deployment integrity verification, TST-058 GUI: Build & validate log_volume scenario

Attribute	Value
importance	5
urgency	4
risk	2
type	F
version	0.5

2.11 RADAR scenario: DLP2 - network data exfiltration SRS-058

As a security engineer, I want RADAR to detect data exfiltration attempts through monitoring outbound network traffic volume per user/host combined with GeoIP analysis, and then apply automated response mechanisms to contain the threat.

Scope

Monitored traffic: This requirement applies to outbound network connections from monitored hosts, tracking data volume (bytes transferred) to external destinations. Internal/private IP ranges (RFC 1918) are excluded from volume accounting and destination analysis.

Detection method: Two complementary detection mechanisms are combined:

Volume anomaly — per-user and per-host behavioral baseline (dynamic, adapts over time) detecting significant deviations in outbound data volume, following the same architecture as SRS-056.
Destination intelligence — GeoIP enrichment correlating high-volume transfers with destination country against an organization-managed approved-destination list, referencing the GeoIP infrastructure defined in SRS-055.

LOTL coverage: Detection additionally monitors for Living Off the Land tool abuse (PowerShell, bitsadmin, curl, certreq) used to blend exfiltration with legitimate traffic.

Host and user coverage: All Wazuh-monitored hosts and user accounts with outbound network telemetry. Each user and host maintains an independent behavioral baseline.

Alert delivery: Anomaly/rule trigger → composite risk score → Wazuh Monitor → webhook → active response trigger.

Requirements

Outbound traffic monitoring: RADAR shall monitor outbound network data volume per user and per host over configurable time windows:

Track cumulative bytes sent to external destinations within each time window.
Exclude internal/private IP ranges (RFC 1918) from volume accounting.
Identify destination count (number of distinct external IPs contacted) per window.

Baseline establishment: RADAR shall learn a behavioral baseline for each user and host, establishing their normal outbound data transfer patterns:

The baseline shall be dynamic and adapt over time to legitimate changes in user/host behavior, following the log volume detection architecture in SRS-056.
Each user and host shall maintain an independent baseline instance to enable per-entity anomaly detection.

Volume anomaly detection: RADAR shall emit a “Data Exfiltration — Volume Spike” alert when outbound data volume significantly exceeds the learned baseline:

Trigger condition: anomaly score from the detector exceeds the configured anomaly threshold.
Alert content: user/host identity, detector name/ID, time window, bytes transferred, anomaly score, and destination count.

GeoIP enrichment: The Wazuh pipeline shall enrich each outbound connection event with GeoIP metadata before RADAR analysis:

Fields enriched: destination IP address (dstip), destination GeoIP data (dstgeoip including country/region), protocol, bytes transferred, and timestamp.
RADAR shall correlate high-volume transfers with destination geography using the enriched fields.

Unusual destination detection: RADAR shall emit a “Data Exfiltration — Unusual Destination” alert when large data transfers occur to unexpected destinations:

Trigger condition: bytes transferred exceed the configured byte threshold and the destination country is not in the organisation’s approved-destination list, or the destination is historically unusual for that user/host.
Alert content: user/host identity, destination IP, destination country, bytes transferred, and historical transfer count to that destination.

Living Off the Land (LOTL) tool detection: RADAR shall detect data exfiltration attempts using legitimate system tools commonly abused by attackers. Detection shall include monitoring for:

PowerShell Invoke-WebRequest with POST/upload parameters and large payloads
bitsadmin commands with /transfer, /upload, or /addfile parameters
curl commands with -T (upload) parameter targeting external destinations
certreq commands with -Post parameter to non-PKI destinations
Unusual usage patterns of these tools outside normal administrative contexts

Correlation and scoring: RADAR shall correlate multiple indicators to produce a composite risk score:

Volume anomaly score from behavioral model
Destination geography risk (unusual or non-whitelisted countries)
LOTL tool usage detection
Transfer frequency and pattern (e.g., multiple small transfers vs. single large transfer)
Time of day and user context

Alert generation: RADAR shall emit a “Data Exfiltration Detected” alert when the composite risk score exceeds the configured risk threshold defined in the RADAR Technical Specification:

The alert shall include all relevant context: user/host identity, anomaly details, destination information, transfer volume, tools detected, and risk score.

Automated response: When the risk threshold is passed, RADAR shall trigger configured active responses which may include:

Immediate logging and alerting to security team
Email notification to security engineer and system administrator
Firewall rules to block destination IP/range (via Wazuh active response)
User session termination on the source host
Network isolation of the source host for high-risk scenarios
Creating forensic snapshots for investigation

Audit trail: All detection events, alerts, active responses, and their outcomes shall be logged to the Wazuh indexer with complete audit trails for compliance and forensic analysis.

Rationale

Attackers and malicious insiders commonly use Living Off the Land techniques to blend exfiltration with normal traffic, rendering signature-only detection insufficient (MITRE ATT&CK T1048). Combining per-entity volume behavioral baselines (SRS-056 architecture), GeoIP destination intelligence (SRS-055), and LOTL tool monitoring provides overlapping detection layers that reduce false positives while enabling automated containment before significant data loss.

Acceptance criteria

Successful validation according to the corresponding test case specification. Integration with Wazuh Sysmon event collection, GeoIP enrichment pipeline, and RADAR active response framework must be demonstrable in a test environment simulating data exfiltration scenarios using common tools (PowerShell, bitsadmin, curl, certreq).

Parent links: MRS-007 Intrusion Prevention

Child links: LARC-021 RADAR risk engine calculation flow, LARC-026 RADAR active response decision pipeline

Attribute	Value
importance	5
urgency	4
risk	3
type	F
version	0.8

2.12 RADAR Scenario Simulation Framework SRS-059

As a security engineer, I want a structured and automated scenario simulation framework that generates realistic attack artefacts on agent endpoints and validates detection logic end-to-end, so that RADAR detection scenarios can be exercised reproducibly without manual log injection or synthetic alert manipulation.

Scope

Framework coverage: This requirement applies to the automated simulation pipeline for all current production RADAR detection scenarios: suspicious_login, geoip_detection, and log_volume. The framework shall support the full simulation lifecycle: agent-level artefact generation, pipeline traversal, and detection triggering.

Execution environment: Simulations shall execute on real or containerised agent endpoints that are connected to a running RADAR stack. All artefacts shall be introduced at the agent level and processed through the standard Wazuh ingestion pipeline.

Repeatability target: Any simulation run shall be fully reproducible from a clean baseline given the same scenario configuration, with no dependency on pre-existing artefacts, synthetic documents, or manually prepared state in the environment.

Integration scope: The framework shall cover all three production scenario types — credential-based attack simulation (suspicious_login), geographic access policy violation (geoip_detection), and filesystem growth anomaly simulation (log_volume) — as well as the active response and alerting flows triggered downstream.

Requirements

Unified simulation entry point: The framework shall provide a single executable interface for dispatching scenario simulations:

Expose a top-level script (simulate-radar.sh) that accepts a scenario identifier and an agent execution mode (local container or remote SSH).
Dispatch execution to the appropriate agent endpoint based on the selected mode.
Return a non-zero exit code if simulation execution fails, enabling integration with CI pipelines and regression testing workflows.

Agent-realistic artefact generation: All simulation artefacts shall be generated at the agent level and processed through the native Wazuh pipeline:

For suspicious_login and geoip_detection: write real SSH log entries into the configured authentication log file on the agent, adapting automatically to the endpoint's native timestamp format (ISO 8601 or syslog).
For log_volume: execute directly on the agent endpoint, measure the current monitored directory size dynamically, and generate real filesystem growth calibrated to a configurable spike ratio above the observed baseline.
All events shall be timed within the detection window required by the relevant rule logic.

Configurable simulation behaviour: All simulation parameters shall be externalised and environment-specific behaviour shall be tunable without code changes:

Maintain a scenario configuration file (config.yaml) defining target directories, spike ratio thresholds, growth parameters, cleanup timing, container-to-scenario mappings, and agent name filters.
Support parameterisation of both below-threshold and above-threshold simulation cases to exercise true negative and true positive paths within a single run.
Resolve agent target mappings dynamically from configuration for both docker_local and remote SSH deployment modes.

4. Controlled cleanup for log_volume simulation: The framework shall restore the agent filesystem after a log_volume simulation run without requiring manual intervention:

Remove the spike file (target_dir / spike_filename) automatically after a configurable delay (cleanup_minutes).
Execute cleanup asynchronously via a background shell process so it does not block simulation execution.
Apply safety caps on per-step and total disk consumption to prevent uncontrolled filesystem growth on production-adjacent endpoints (max_step_bytes, max_total_bytes).
Set cleanup_minutes: 0 to disable automatic cleanup, in which case the spike file must be removed manually.
Note: suspicious_login and geoip_detection simulations write entries to the system auth log (/var/log/auth.log); these entries are not removed by the framework and persist in the log file after simulation completes.

Local and remote agent support: The framework shall support both containerised and remote production-like agent endpoints:

Execute simulation logic on local container agents via docker exec.
Execute simulation logic on remote SSH agents via Ansible playbooks.
Resolve the execution path dynamically based on the agent mode provided at invocation, with no manual reconfiguration required between modes.

Rationale

Direct log injection and synthetic OpenSearch document generation bypass critical stages of the RADAR pipeline — decoders, rules, the webhook bridge, and the active response chain — making it impossible to validate the full detection stack. A simulation framework that operates at the agent level ensures that every component exercised in production is also exercised during testing. Externalising simulation parameters in a configuration file, combining this with automated script and support for both local and remote endpoints, produces a reproducible, safe, and operationally realistic validation mechanism that can serve as a regression baseline across RADAR releases.

Acceptance criteria

A complete simulation run covering all three production scenarios (suspicious_login, geoip_detection, log_volume) must be demonstrable end-to-end without manual intervention: from clean agent state through artefact generation and full pipeline traversal, using only the simulate-radar.sh entry point with the appropriate flags.

For suspicious_login: the framework shall generate SSH authentication events satisfying the configured frequency threshold within the required timeframe, such that rule 210012 or 210013 (brute force) or 210020/210021 (impossible travel) is eligible to trigger.
For geoip_detection: the framework shall generate an authentication success event carrying a non-whitelisted country field, such that rule 100900 or 100901 is eligible to trigger.
For log_volume: the framework shall grow the monitored directory beyond the configured spike ratio so that the log volume metric collector observes real filesystem growth and the anomaly detector is exercised under realistic conditions. In all cases, artefacts shall be removed within the configured cleanup window and no residual files shall remain on the agent after cleanup completes.

Parent links: MRS-007 Intrusion Prevention, SWD-039 RADAR simulation framework software design

Child links: TST-046 DECIPHER-RADAR detection validation for Suspicious login, TST-047 Detection validation for GeoIP detection, TST-048 Detection validation for Log volume abnormal growth

Attribute	Value
importance	4
urgency	2
risk	2
type	F
version	0.8

2.13 RADAR Deployment Health Check SRS-060

As a security engineer or operator, I want a single-command tool that verifies the completeness and operational readiness of a RADAR deployment, so that misconfiguration, missing artifacts, or broken connectivity can be identified quickly after deployment or after infrastructure changes, without manually inspecting each component.

Scope

Tool coverage: This requirement applies to RADAR deployments where the Wazuh manager runs in a Docker container, across all production scenarios. It covers the Wazuh manager node and, when named agents are supplied, those agents' status as reported by the Wazuh management API.

Invocation: The health check shall be executable through a single entry-point script that runs a manager-side check (container and file presence), a manager-side API check (Wazuh management API, OpenSearch, and the alert webhook, all over HTTP), and — only if named agents are supplied — an agent check via the Wazuh management API.

Output: Check results shall be printed as each section completes: manager checks, then manager API checks, then (if requested) named-agent checks. Each check line is marked OK, WARN, or FAIL.

Scope exclusions: The health check is a read-only validation tool. It shall not make any changes to the target environment, restart services, or remediate detected issues.

Requirements

Single entry point: A single script shall be the sole invocation interface:
- Accept a --scenario <name|all> argument and an optional --agent-name <name1,name2,...> argument. The manager is always addressed through its container and the Wazuh management API, never over SSH.
- Run the manager checks, then the manager API checks, and — only if agent names are supplied — the named-agent checks.
- Return a non-zero exit code if any underlying check fails to run.
Manager checks: Executed against the manager's container, these shall verify:
- Container health: the Wazuh manager and alert-webhook containers are running.
- Key file presence and ownership: the active-response script, its configuration, and its environment file are present with the correct group ownership, along with the manager's core configuration files (a missing agent-group configuration file is reported as a warning, not a failure). Scenario-specific checks shall be verified as well:
  - The manager's Python runtime and GeoIP library are available, the manager-side enrichment files and GeoIP reference databases are present, the per-user enrichment state store exists and is writable, and the enrichment error log is empty or absent.
  - The log-ingestion pipeline has the routing update it needs for log-volume metrics.
Separately, a check against the Wazuh management API shall verify: - Core daemon status: the manager's core processes are reported active. - Active-response wiring and scenario group configuration: for each target scenario, the corresponding active-response wiring and agent-group configuration are present. - Ruleset files: the decoder and rule files each target scenario depends on are present; for geoip_detection, the country whitelist is additionally checked. - Scenario agent state: agents assigned to each target scenario's group(s) are reported. - Connectivity: OpenSearch is reachable and its cluster health status is reported; for log_volume, the OpenSearch index template is additionally checked; the configured webhook endpoint responds.
Agent checks: When agent names are supplied, a check against the Wazuh management API shall verify, with no direct connection made to the agent endpoint itself:
- The named agent is registered and its connection status is active (a status of "never connected" is reported as a failure).
- The agent's group membership includes the baseline group and, unless all scenarios were requested, the named scenario's group.
Non-destructive execution: All checks shall be read-only. No check defined by this requirement shall write to or modify any file, service state, or configuration on the manager or on any agent.
Consolidated end-of-run summary: The tool shall print the manager section, then the manager API section, then (if requested) the agent section, each clearly labelled, so the full result is visible as a single, ordered output.
Scenario filtering: When a specific scenario is named, scenario-specific checks (ruleset file presence, log_volume pipeline/index-template checks, geoip_detection whitelist check, expected agent group membership) shall be scoped to that scenario only. When all scenarios are requested, checks shall cover every production scenario.

Rationale

Manual post-deployment verification of a RADAR stack requires inspecting container state, file presence and permissions, Python environments, and scenario-specific artifacts across multiple nodes. Without automation this is error-prone and time-consuming, and failures are typically discovered only when an alert fails to trigger rather than at deployment time. A single-command health check that surfaces all misconfiguration after deployment reduces mean time to operational readiness and provides a repeatable baseline for regression testing after infrastructure changes.

Acceptance criteria

A complete health check run against a correctly deployed RADAR stack must complete without any fails, covering manager checks, manager API/OpenSearch/webhook checks, and (when requested) agent checks, using only the health check tool's --scenario and --agent-name options.

The manager section, the manager API section, and (if requested) the agent section shall each print in full and in order; no section shall be silently skipped or interleaved with another.

Parent links: SWD-040 RADAR health check software design

Attribute	Value
importance	4
urgency	2
risk	2
type	F
version	0.8

2.14 RADAR scenario: off-hour login detection SRS-062

As a security engineer, I want RADAR to detect authentication activity occurring outside of normal business hours using per-user behavioral baselines, and then apply the existing risk policy to contain potential account compromise.

Scope

Protocol coverage: This requirement applies to all authentication events including VPN, SSH, LDAP, RDP, web-based authentication, and database logins. The system is protocol-agnostic and detects off-hour access based on temporal patterns regardless of authentication mechanism.

Authentication sources: Authentication events from multiple sources via syslog integration, forwarded to Wazuh manager and indexed in OpenSearch.

Required event fields (must be present in all authentication sources):

- User identification: data.user or equivalent field (username from authentication event)
- Temporal context: timestamp field (ISO8601 format with millisecond precision)
- Authentication outcome (optional for filtering events): Success/failure indicator (e.g., rule.id, data.status)

Detection method: Per-user behavioral baseline using OpenSearch RCF Anomaly Detection algorithm with categorical field data.user.keyword. Each user learns their own "normal" work schedule over the detector training period.

Business hours definition: The system trains exclusively on authentication events occurring during business hours (Monday-Friday, 07:00-20:00 local time). Events outside this window (weekends, nights, early mornings) are considered off-hours and flagged as anomalous when detected.

Alert delivery: Anomaly detection results → OpenSearch monitor → webhook → Wazuh log ingestion → rule-based active response trigger.

Requirements

RADAR shall emit an "Off-hour login detected" alert when OpenSearch Anomaly Detection identifies authentication activity occurring outside a user's learned work schedule:

(i) OpenSearch detector configuration (defined in config.yaml under scenarios.suspicious_login):
- Detector name: "off_hour_login"
- Index pattern: wazuh-alerts-* (date-based indexing for time-series data)
- Result index: opensearch-ad-plugin-result-off-hour (stores anomaly grades and metadata)
- Categorical field: data.user.keyword (enables per-user baselines using multi-entity detection)
- Feature definitions:
  - login_hour: Hour extraction from timestamp (0-23) using Painless script doc['timestamp'].value.getHour(), aggregation: avg
  - login_day_of_week: Day of week extraction (1=Monday, 7=Sunday) using Painless script doc['timestamp'].value.getDayOfWeek(), aggregation: avg
- Shingle size: 8
- Detector interval: 60 minutes (hourly detection windows)
- Window delay: 1 minute (allows for indexing lag before analysis)
- Filter query: authentication groups or successful logins
(ii) Anomaly threshold criteria (both must be met to trigger alert):
- Anomaly grade: anomaly_grade ≥ 0.3 (configurable via anomaly_grade_threshold)
- Confidence: confidence ≥ 0.3 (configurable via confidence_threshold)
(iii) Baseline learning requirements:
- Minimum data points: 8 intervals (8 * 60 minutes = 8 hours)
- Training period: Detector learns each user's "normal" authentication pattern independently
  - Training data filtered to business hours only (Mon-Fri, 07:00-20:00)
  - Zero weekend data in training set (weekends = off-hours by definition)
  - Zero night/early morning data in training set (nights = off-hours by definition)
(iv) Anomaly quantification:
- Anomaly grade > 0.3 typically indicates authentication time/day deviation > 2σ (two standard deviations) from the user's learned schedule
- Grade > 0.7 indicates extreme deviation (> 3σ), such as weekend login for strictly Monday-Friday user, or 2 AM login for user who normally works 9 AM - 5 PM
(v) Temporal feature rationale:
- login_hour: Direct mapping to 24-hour cycle captures business hours (7-20) vs off-hours patterns. Hourly patterns are critical for User Behavior Analytics (UEBA) temporal anomaly detection.
- login_day_of_week: Captures weekly work patterns (Mon-Fri vs weekends). Temporal behavior modeling analyzing daily routines is fundamental to authentication anomaly detection.

The "Off-hour login detected" alert shall carry comprehensive metadata through the detection and response pipeline:

(i) OpenSearch monitor message (webhook payload structure):
- Monitor metadata: monitor_name="OffHourLogin-Monitor", trigger_name="OffHourLogin-Detected"
- Anomaly metrics: anomaly_grade (severity score [0,1]), confidence (model certainty [0,1])
- Entity identification: entity field contains username
- Feature data:
  - feature_data.login_hour.data (actual login hour value)
  - feature_data.login_day_of_week.data (actual day of week value)
- Time window: period_start, period_end (ISO8601 timestamps defining the detection interval)
- Detector context: detector_name for traceability
(ii) Wazuh event fields (after webhook writes to log file and Wazuh ingests):
- Alert decoder: opensearch_ad (custom decoder)
- Extracted fields: data.anomaly_grade, data.confidence, data.trigger_name, data.entity_keyword
- Trigger matching: Rule 100300 (generic AD alert) → Rule 100310 (specific to "OffHourLogin-Detected")
(iii) Active response augmentation (radar_ar.py):
- User resolution: Parses data.entity_keyword to extract username
- Time window computation: Converts period_start/period_end to datetime for context collection
- Detector metadata: Adds detector_name="off_hour_login", scenario_id="off_hour_login" to audit records
- Context enrichment: Queries OpenSearch for authentication events from affected user within time window
- IOC extraction: Collects source IPs, countries, user agents from context events

Training data preparation shall ensure clean baseline establishment by filtering authentication logs to business hours only:

(i) Data filtering requirements:
- Training index: wazuh-alerts-*
- Temporal filter: Monday-Friday, 07:00-20:00 local time
- Include both successful AND failed logins during business hours (failed attempts are legitimate security events to track during normal operations)
- Exclude all weekend events (Saturday-Sunday)
- Exclude all off-hour events (20:00-07:00, Mon-Fri)
- Date mapping: Historical authentication data (e.g., CSV import from RBA dataset) dynamically mapped to recent dates via configurable days_before_start parameter
(ii) Data ingestion pipeline (Python script: wazuh_ingest.py):
- Configuration: Reads from config.yaml under suspicious_login.ingest section
- CSV input: RBA dataset or equivalent authentication logs
- Dynamic date shift: Maps CSV timestamps to N days before script execution (days_before_start: 7)
- Weekend skipping: Automatically filters weekends during import (skip_weekends: true)
- Rule configuration: Injects rule IDs, severity levels, and group tags from config
- OpenSearch indexing: Bulk ingestion with chunk size optimization (default 1000 docs/batch)
- Index pattern: wazuh-alerts-YYYY.MM.DD (date-based for retention management)
(iii) Baseline establishment verification:
- Minimum training duration: 7 days of business hours = 168 hourly data points
- User coverage: Baseline only established for users with ≥100 authentication events during training period
- Anomaly grade verification: During training period, anomaly_grade should remain < 0.3 for all business-hour events (validates clean baseline)

OpenSearch monitor shall evaluate detector results and deliver alerts via webhook when off-hour activity is detected:

(i) Monitor configuration (automated via radar/anomaly_detector/monitor.py):
- Monitor type: Per-query monitor (queries anomaly detector result index)
- Schedule: Runs every detector interval
- Query: anomaly_grade >= 0.3 AND confidence >= 0.3 against opensearch-ad-plugin-result-off-hour
(ii) Trigger conditions: When query returns results (off-hour authentication detected for any user)
- Trigger name: "OffHourLogin-Detected" (matched by Wazuh rule 100310)
- Severity: High (off-hour access indicates potential account compromise)
(iii) Webhook action: HTTP POST to RADAR webhook service endpoint
- Webhook URL: http://<webhook-service>:8080/notify (configurable)
- Payload: JSON containing monitor metadata, anomaly metrics, entity (username), time window, feature values
(iv) Webhook processing (RADAR webhook service):
- Receives JSON POST request
- Formats message as syslog-compatible text with structured fields
- Writes to /var/log/ad_alerts.log with timestamp
(v) Wazuh ingestion:
- Wazuh manager monitors /var/log/ad_alerts.log (configured in ossec.conf)
- Decoder opensearch_ad parses structured fields
- Rule 100300 fires (generic AD alert), then rule 100310 fires (specific OffHourLogin trigger match)
- Rule 100310 invokes active response via <active-response> block

RADAR shall execute risk-based active response when off-hour authentication anomalies exceed the configured risk threshold:

(i) Risk scoring: Active response script (radar_ar.py) computes risk score using formula $R = w_{ad} \times A + w_{sig} \times S + w_{cti} \times T$ where:
- $w_{ad}$ = 0.7 (anomaly detection component weight - primary detection mechanism)
- $w_{sig}$ = 0.0 (signature component weight - reserved for future rule-based augmentation)
- $w_{cti}$ = 0.3 (cyber threat intelligence component weight)
- $A$ = anomaly_grade × confidence (both from detector output, range [0,1])
- $S$ = signature score (currently 0; future: correlation with failed-login bursts, impossible travel)
- $T$ = CTI enrichment score (queries threat intel for source IP; typically 0 unless IP has known malicious history)
(ii) Example risk calculation:
- Off-hour login: Sunday 2 AM, anomaly_grade=0.85, confidence=0.88
- $A$ = 0.85 × 0.88 = 0.748
- $T$ = 0 (no CTI hits for source IP)
- $R$ = 0.7 × 0.748 + 0.0 × 0 + 0.3 × 0 = 0.524
- Result: risk_score = 0.524 → Tier 2 (0.33 ≤ 0.524 < 0.66)
(iii) Risk threshold: Alerts with risk_score ≥ 0.2 (configurable in ar.yaml) trigger containment actions; below threshold alerts are logged only
(iv) Tiered response actions:
- Tier 0 (risk_score < tier1_min): Logging only
  - Record alert in OpenSearch anomaly response index
  - No notifications, no containment actions
  - Used for low-confidence detections or whitelisted users
- Tier 1 (tier1_min ≤ risk_score < tier1_max, default 0.33): Passive monitoring
  - Log alert to OpenSearch anomaly response index
  - Send email notification to SOC with alert details:
    - Username, login time (hour, day), anomaly grade, confidence
    - Source IP, geolocation, user agent
    - Expected schedule summary (e.g., "User typically logs in Mon-Fri 8:00-18:00")
    - Risk score breakdown
  - Record decision in audit log with tier=1
  - No active containment (user retains access)
- Tier 2 (tier1_max ≤ risk_score < tier2_max, default 0.66): Active containment
  - All Tier 1 actions, plus:
  - Session tracking: Monitor user activity for anomalous behavior (file access, privilege escalation)
- Tier 3 (risk_score ≥ tier2_max, default 0.66): Aggressive containment
  - All Tier 2 actions, plus:
  - Terminate active session
  - Disable user account temporarily
  - Block source IP via firewall
(v) Email notification format:
- Subject: [RADAR Alert] Off-Hour Login Detected - {username} - Risk Tier {tier}
- Body sections:
  - Alert summary (username, login time, day of week)
  - Anomaly metrics (grade, confidence)
  - Source context (IP address, country, city, ISP)
  - Temporal context (actual login hour vs expected schedule)
  - Risk score computation breakdown (A, S, T components)
  - Tier classification and actions taken
  - Direct link to FlowIntel case for context exploration

The system shall maintain comprehensive audit logs of all active response executions:

(i) Each active response invocation generates unique decision_id (SHA256 hash of scenario+timestamp+alert+entity)
(ii) Audit records shall capture:
- Decision metadata:
  - decision_id (unique identifier)
  - timestamp (ISO8601 execution time)
  - scenario_name="off_hour_login"
  - detection_type="ad" (anomaly detection)
- Input data:
  - Alert content: trigger_name, anomaly_grade, confidence
  - Entity: username (data.user)
  - Time window: period_start, period_end
  - Feature values: login_hour, login_day_of_week, hour_deviation
- Risk computation:
  - anomaly_component (A): anomaly_grade × confidence
  - signature_component (S): currently 0
  - cti_component (T): threat intel enrichment score
  - final_risk_score (R): weighted sum
  - tier: classification (0, 1, 2, 3)
- Context:
  - Source IP, geolocation, user agent
  - Expected user schedule summary
  - Previous authentication events (last 24 hours)
- Actions taken:
  - List of executed actions (email, session_termination, account_disable, firewall_block)
  - Timestamp for each action
  - Command/API call details
- Outcomes:
  - Success/failure status for each action
  - Error messages if any
(iii) Log retention: Audit logs shall be retained for minimum 90 days (configurable per organizational compliance requirements). For regulated industries (PCI-DSS, HIPAA), retention may extend to 1+ years.

The system shall provide testing and evaluation capabilities to measure detector performance:

(i) Test data generation:
- Test index: wazuh-alerts-*
- Test scenarios:
  - Normal business hours logins (Mon-Fri 9:00-17:00) → Expected: no alert
  - Off-hours logins (Mon-Fri 21:00, 23:00, 02:00, 05:00) → Expected: alert
  - Weekend logins (Saturday 10:00, Sunday 14:00) → Expected: alert
  - Edge cases: Exactly 07:00 (boundary), exactly 20:00 (boundary)
(ii) Evaluation metrics:
- Precision: TP / (TP + FP) - measures false positive rate
- Recall: TP / (TP + FN) - measures detection coverage
- F1 Score: 2 × (Precision × Recall) / (Precision + Recall) - harmonic mean
- False Positive Rate: FP / (FP + TN) - critical for operational acceptance
- Detection latency: Time from event ingestion to alert generation
- Target thresholds: Precision ≥ 0.90, Recall ≥ 0.85, FPR ≤ 0.05
(iii) Visualization and reporting:
- Confusion matrix: True positives, false positives, true negatives, false negatives
- ROC curve: TPR vs FPR at different anomaly_grade thresholds
- Precision-Recall curve: Tradeoff analysis for threshold tuning
- Time series plot: Anomaly grades over time, colored by ground truth
- Export formats: PNG charts, CSV metrics, JSON detailed results

Rationale

Off-hour authentication is an indicator of account compromise. Attackers often use stolen credentials outside the victim's normal work schedule to avoid detection. Per-user behavioral baselines accommodate diverse work patterns (9-to-5 employees, shift workers, remote workers in different time zones) while identifying suspicious deviations. Unlike signature-based detection, temporal anomaly detection adapts to legitimate schedule changes (e.g., user switches to night shift) without manual rule updates.

Dependencies

OpenSearch Anomaly Detection Plugin: Provides HCAD (High-Cardinality Anomaly Detection) engine for per-user baseline learning. Requires OpenSearch 2.x with AD plugin installed.
RADAR Webhook Service: Relays OpenSearch monitor alerts to Wazuh ingestion. Deployed as standalone service (Flask/Python) or integrated into RADAR core.
RADAR Anomaly Detector Module (radar/anomaly_detector/): Python automation for detector/monitor provisioning via OpenSearch API. Includes detector.py, monitor.py, webhook.py scripts.
Data Ingestion Pipeline: Python script wazuh_ingest.py with supporting config files (.env, config.yaml) for training data import.
LARC-016: Active response framework (provides script execution infrastructure, radar_ar.py implementation).
MRS-007: Intrusion Prevention (parent mission requirement).

Related requirements

SRS-051: Suspicious login detection (shares risk scoring engine, active response framework, and alert correlation patterns)
SRS-055: Geo-based access control (shares CTI enrichment, audit logging approaches, and GeoIP metadata)
SRS-056: Log volume detection (shares HCAD methodology, webhook pipeline, and tiered response actions)
SRS-058: Data exfiltration detection (similar behavioral baseline approach for network volume anomalies)

Acceptance criteria

Successful validation according to test case specification:

Baseline establishment: Import 7 days (168 hours) of business-hour authentication data for test users. Verify: - OpenSearch detector processes all 168 intervals - Anomaly_grade < 0.3 for all business-hour events during training period - Detector status: "Running" with 0 initialization errors - Result index contains entries for each categorical field (user)
Off-hour detection - weeknight: Simulate a user logging in Monday 23:00 (11 PM). Verify: - Anomaly_grade > 0.3 within 2 detection intervals (2 hours max) - Confidence > 0.3 - Feature values: login_hour=23, login_day_of_week=1 (Monday)
Off-hour detection - weekend: Simulate a user logging in Saturday 14:00. Verify: - Anomaly_grade > 0.5 (higher confidence for weekend anomaly) - Feature values: login_day_of_week=6 (Saturday) - Demonstrates weekend detection even during "business hours" (14:00)
Off-hour detection - early morning: Simulate a user logging in Tuesday 05:30 AM. Verify: - Anomaly_grade > 0.3 - Feature values: login_hour=5
Normal hour non-detection: Simulate multiple users logging in during business hours (Mon-Fri, 09:00-17:00). Verify: - Anomaly_grade < 0.3 for all events - No alerts generated - Demonstrates clean baseline, no false positives
Webhook delivery: When off-hour anomaly detected, verify: - OpenSearch monitor fires within 1 detection interval (60 minutes) - HTTP POST sent to webhook endpoint - Webhook log (/var/log/ad_alerts.log) contains entry with correct structure - JSON payload includes: trigger_name="OffHourLogin-Detected", anomaly_grade, confidence, entity, period_start, period_end
Wazuh ingestion and rule matching: Verify: - Wazuh ingests webhook log entry - Rule 100300 fires (generic OpenSearch AD alert) - Rule 100310 fires (specific OffHourLogin-Detected trigger match) - Active response invoked (check /var/ossec/logs/active-responses.log)
Risk score computation - Tier 1: Given anomaly_grade=0.45, confidence=0.70, no CTI hits: - $A$ = 0.45 × 0.70 = 0.315 - $R$ = 0.8 × 0.315 + 0.1 × 0 + 0.1 × 0 = 0.252 - Verify: risk_score = 0.252, tier = 1 (assuming tier1_min=0.0, tier1_max=0.33) - Actions: Email sent, OpenSearch index updated, no containment
Risk score computation - Tier 2: Given anomaly_grade=0.75, confidence=0.80, no CTI hits: - $A$ = 0.75 × 0.80 = 0.60 - $R$ = 0.8 × 0.60 = 0.48 - Verify: risk_score = 0.48, tier = 2 (0.33 ≤ 0.48 < 0.66) - Actions: Email sent, session monitoring activated
Risk score computation - Tier 3: Given anomaly_grade=0.90, confidence=0.95, CTI score=0.3:
- $A$ = 0.90 × 0.95 = 0.855
- $T$ = 0.3 (source IP has known malicious history)
- $R$ = 0.8 × 0.855 + 0.1 × 0 + 0.1 × 0.3 = 0.684 + 0.03 = 0.714
- Verify: risk_score = 0.714, tier = 3 (≥ 0.66)
- Actions: Session terminated, account disabled, IP blocked, incident case created
Per-user independence: Import training data for two users with different schedules:
- User A: Mon-Fri 09:00-17:00 (typical office hours)
- User B: Mon-Fri 14:00-22:00 (afternoon/evening shift)
Test scenarios: - User A logs in at 20:00 → Anomaly detected (outside A's schedule) - User B logs in at 20:00 → No anomaly (within B's schedule) - Demonstrates categorical field isolation (independent baselines)
Alert metadata completeness: For any triggered alert, verify all required fields present:
- decision_id (SHA256 hash)
- scenario_name="off_hour_login"
- detection_type="ad"
- anomaly_grade, confidence (from detector)
- entity (username)
- period_start, period_end (time window)
- feature_values: login_hour, login_day_of_week, hour_deviation_from_mean
- risk_score, tier
- actions_taken (array of executed actions)
- timestamp (alert processing time)
- source_ip, country, city (geolocation context)
Audit log integrity: For each active response execution, verify:
- Entry in Wazuh AR log (/var/ossec/logs/active-responses.log)
- Entry in RADAR audit log (/var/log/radar_ar.log)
- All three logs contain matching decision_id for correlation
- Audit record includes full risk computation breakdown
- Action outcomes (success/failure) logged for each executed command

Parent links: MRS-007 Intrusion Prevention

Attribute	Value
importance	3
urgency	3
risk	3
type	F
version	0.8

2.15 RADAR SOAR Web Interface - REST API SRS-063

As a security engineer, I want a REST API that exposes RADAR's scenario and active-response configuration, connector settings, and deployment actions as structured HTTP resources, so that the RADAR web interface can read and write configuration and trigger operational actions without directly editing files or invoking scripts on the Wazuh manager.

Scope

API coverage: This requirement defines the REST API that backs the RADAR web interface. It covers four groups of endpoints: scenario configuration (list, detail, active-response settings, bind/unbind), connector configuration (external service settings and connection tests), credential-session management, and deployment actions (scenario deploy/undeploy, agent onboarding and lifecycle, health checks, teardown).

Relationship to SRS-070: The deployment action endpoints exist to back the interface described in SRS-070. This requirement defines their existence, request/response shape, and streaming behavior; SRS-070 defines what each action does operationally and how it is presented to the user. Where the two would otherwise overlap, this requirement covers the HTTP contract and SRS-070 covers the user-facing behavior.

Persistence backend: Scenario and active-response configuration is stored in a single configuration file read and written directly by the API process; connector configuration is stored in a single environment file in the same way. Neither is a database, and neither is presented to the frontend as one.

Requirements

Scenario endpoints

A scenario list endpoint shall return every scenario the interface is allowed to show, each with an identifier, display name, description, status, detection type, and its associated rule IDs, plus whether it is currently bound and whether it is a shared scenario. For each bound scenario, its active-response configuration shall be included inline.
A scenario detail endpoint shall return the same record for a single named scenario, or a not-found error if the scenario does not exist.
An active-response configuration endpoint shall support reading a scenario's active-response configuration on its own, and separately updating it. An update shall accept a partial set of fields and merge them into the existing configuration; it shall not require the caller to resend the full configuration.

Connector endpoints

A connector list endpoint shall return the current value of every connector field except password-bearing fields, plus, for each password-bearing field, whether a value is currently set.
A per-connector save endpoint shall accept and persist a connector's fields.
A reveal endpoint shall return the current value of a single password-bearing field, restricted to the fixed set of fields the interface allows revealing.
A per-connector test endpoint shall attempt a live connection check for the named connector using its currently saved fields, and report whether it succeeded.

Credential-session endpoints

Sudo password credential shall be associated with the caller's session via a single shared session cookie, and none shall be persisted beyond that session.

Error handling

Every endpoint's error responses shall indicate failure and include a human-readable message. Endpoints shall use standard HTTP status codes to distinguish a missing resource from an invalid request from a server-side failure.

Rationale

RADAR's configuration and operational actions are otherwise only reachable by editing files or running scripts directly on the Wazuh manager host. A REST API layer gives the web interface (and any future tooling) a stable way to read and change that configuration and to trigger deployment actions, without requiring direct host access or knowledge of the underlying file formats and scripts.

Dependencies

SRS-051: Suspicious login scenario - contributes rule IDs and active-response configuration exposed through the scenario endpoints.
SRS-055: GeoIP detection scenario - contributes rule IDs and active-response configuration exposed through the scenario endpoints.
SRS-056: Log volume monitoring scenario - contributes rule IDs and active-response configuration exposed through the scenario endpoints.
SRS-070: GUI Deployment interface - defines the operational behavior behind the deployment action endpoints; this requirement defines their HTTP contract.
SRS-069, SRS-067, SRS-060: the scenario deployment, agent onboarding, and health-check mechanisms invoked by the deployment action endpoints.

Related requirements

SRS-064: RADAR Web Interface - Frontend. The primary consumer of this API.

Acceptance criteria

Successful validation according to test case specification TST-063, which shall verify:

Scenario list: Verify the scenario list endpoint returns every visible scenario with its identifier, name, description, status, detection type, rule IDs, bound state, and shared state, and that bound scenarios additionally include their active-response configuration.
Scenario detail: Verify the detail endpoint returns the same information for a single scenario and returns a not-found error for an unknown one.
Active-response read and update: Verify a scenario's active-response configuration can be read on its own, and that a partial update changes only the supplied fields while leaving the rest intact.
Connector list, save, and reveal: Verify the connector list endpoint omits password values while indicating which are set, that a connector's fields can be saved, and that a password value can be retrieved through the reveal endpoint but only for an allowed field.
Connector test: Verify the test endpoint reports success or failure for each connector type based on its currently saved fields.
Credential sessions: Verify that udo credential share a single session.
Deployment action streaming: Verify a long-running deployment action streams its output progressively rather than only on completion.
Preview: Verify the preview endpoint returns the command a deployment action would run without executing it.
Error handling consistency: Verify that every endpoint's failure responses are distinguishable from success, carry a human-readable message, and use an HTTP status code appropriate to the failure type.

Parent links: MRS-017 Monitoring Frontend

Attribute	Value
importance	4
urgency	3
risk	2
type	F
version	0.8

2.16 RADAR SOAR Web Interface - Frontend SRS-064

As a security engineer, I want a browser-based interface for RADAR that lets me configure active-response behavior for bound scenarios, manage the external services RADAR connects to, and drive deployment and agent lifecycle actions, so that I can operate RADAR without shell access to the Wazuh manager host.

Scope

Interface coverage: This requirement applies to a web-based interface with three pages: a Scenarios page for configuring active-response behavior, a Connectors page for external service configuration, and a Deployment page for scenario and agent lifecycle actions. The Deployment page's behavior is specified separately in SRS-070.

Deployment model: The interface is served as a set of server-rendered pages with accompanying stylesheets and scripts; no separate build step is required to serve or modify a page.

User persona: Primary users are security engineers and SOC operators who understand RADAR concepts (scenarios, risk tiers, active-response weights).

Integration boundary: The frontend integrates exclusively through the REST API defined in SRS-063. It shall not communicate directly with Wazuh, OpenSearch, or any RADAR subsystem.

Requirements

Shared navigation

Every page shall render an identical navigation bar with exactly three entries: Scenarios, Connectors, and Deployment. The entry for the currently viewed page shall be visually distinguished from the other two.
The application's default landing page shall be the Scenarios page.

Scenarios page

The interface shall present the set of currently bound scenarios as a list the user can select from, and shall show, for the selected scenario, its name, description, and its active-response configuration, editable in place:
- Its three risk weights, together with a live-updating total so the user can see whether they sum to 1.0 before saving; saving shall be blocked if they do not.
- Scoring inputs appropriate to the scenario's detection type: signature-based scoring inputs when the scenario is signature-driven, an indication that scoring inputs are supplied at runtime by the anomaly detector when it is anomaly-driven, and both when it is a hybrid of the two.
- The look-back windows used when correlating an alert against anomaly-detection and signature-based context.
- The four response tiers, with the boundary between the no-action tier and the first active tier, and between the first and second active tiers, editable; the interface shall block saving if the tier boundaries are not in strictly increasing order.
- Per-tier mitigation actions for the two tiers where mitigations apply, added and removed from a list of known available actions.
- A single control for allowing automatic mitigation execution, separate from configuring which mitigations would run.
- The scenario's associated rule IDs, shown for reference only.
Saving a scenario's active-response configuration shall update it in place without a full page reload, and shall show the user whether the save succeeded or failed.

Connectors page

The interface shall present one configuration card per external connector RADAR uses: the search/analytics backend, the Wazuh management API, the analytics dashboard, outbound email, the incident-case system, the GeoIP database provider, and the inbound alert webhook. Each card shall show that connector's fields, with any password-bearing field masked by default and revealable on demand only for fields the API allows revealing.
Each card shall provide a way to save its fields independently of the others, and a way to test that connector's current configuration and show whether the test succeeded.
The interface shall provide a single action that tests every configured connector at once, in addition to the per-card test action.

Deployment page

The interface shall provide a Deployment page covering the scenario and agent lifecycle actions specified in SRS-070, organized into distinct sections for scenario management, anomaly-detector setup, agent management, group management, status/health checking, and teardown. The behavior of each section is defined in SRS-070; this requirement only establishes that the page exists and is reachable from the shared navigation.

Visual and UX requirements

The interface shall follow a consistent color convention across all three pages: a consistent color for active/enabled/low-risk states, a distinct color for demo/warning states, and a distinct color for critical/high-risk/mitigation-enabled states.

Rationale

RADAR's active-response behavior and connector configuration are otherwise only reachable by editing files directly on the Wazuh manager host. A focused interface — one page for tuning how a scenario responds, one for configuring the services RADAR talks to, and one for the deployment actions covered by SRS-070 — lowers the skill and access barrier for routine operational tasks without requiring the operator to understand the underlying file formats.

Dependencies

SRS-063: RADAR SOAR Web Interface - REST API. All data displayed and all mutations performed by the frontend are mediated through the API contract defined there.
SRS-070: GUI Deployment interface. Defines the behavior of the Deployment page referenced in requirement 9.
SRS-051: Suspicious login scenario - contributes rule IDs and active-response configuration shown on the Scenarios page.
SRS-055: GeoIP detection scenario - contributes rule IDs and active-response configuration shown on the Scenarios page.
SRS-056: Log volume monitoring scenario - contributes rule IDs and active-response configuration shown on the Scenarios page.

Acceptance criteria

Successful validation according to test case specification, which shall verify:

Navigation: Verify all three pages are reachable from the shared navigation, that the active page is visually indicated, and that the default landing page is the Scenarios page.
Scenario selection and display: Verify selecting a bound scenario shows its active-response configuration, correctly reflecting its detection type in which scoring inputs are shown, and that switching between scenarios updates the displayed configuration accordingly.
No scenarios bound: Verify that when no scenario is bound, the page communicates this clearly instead of showing a broken or empty configuration view.
Weight validation: Verify the interface blocks saving when the three risk weights do not sum to 1.0, and that the running total updates as the user edits them.
Tier validation: Verify the interface blocks saving when the tier boundaries are not strictly increasing.
Mitigation configuration: Verify a mitigation action can be added to and removed from a tier's list, and that automatic mitigation execution can be toggled independently of which mitigations are configured.
Save behavior: Verify saving a scenario's configuration updates it without a full page reload and clearly indicates success or failure.
Connector configuration: Verify each connector's fields can be saved independently, that password fields are masked by default and revealable only where permitted, and that a per-connector test and the test-all action both report success or failure accurately.
Deployment page presence: Verify the Deployment page is reachable and organized into the sections defined in SRS-070.

Parent links: MRS-017 Monitoring Frontend

Attribute	Value
importance	3
urgency	2
risk	1
type	F
version	0.8

2.17 RADAR Ruleset-as-Code SRS-065

As a security engineer, I want to develop, review, and deploy Wazuh detection rules and decoders through a Git-based CI/CD workflow, so that ruleset changes are version-controlled, peer-reviewed, and automatically applied to the Wazuh manager without requiring direct server access.

Scope

Deployment mode: This requirement defines a second, parallel deployment mode for RADAR detection logic, complementing the existing Ansible-powered approach. It does not replace Ansible; Ansible remains the mechanism for full scenario rollouts, initial bring-up, and infrastructure-level configuration. RaC covers day-to-day rule and decoder iteration only.

Covered artefacts: The RaC pipeline governs all XML rule files under radar/scenarios/rules/<scenario>/ and all XML decoder files under radar/scenarios/decoders/<scenario>/.

CI/CD platform: The reference implementation uses GitHub Actions. The server-side apply script is platform-agnostic and may be reused with other CI/CD systems without modification.

Target environment: The Wazuh manager is assumed to run inside a Docker container on the deployment host. The pipeline interacts with the manager via the host's Docker daemon.

Requirements

The repository shall provide a GitHub Actions workflow that automatically validates rule files on every pull request targeting main:

(i) The workflow shall trigger on pull_request events where the target branch is main.
(ii) Validation shall be performed by ci/check_rule_ids.py, which shall be the sole validation entry point invoked by the workflow.
(iii) The workflow shall fail the pull request check if any of the following conditions are detected:
- Two or more rules share the same id attribute within a single changed file.
- A rule id introduced in a new file already exists in any file on main.
- A rule id introduced in a modified file is new (not present in the main version of that file) and already exists in a different file on main.
(iv) The workflow shall pass without error if no rule files are changed in the pull request.

The server-side deploy script (ci/deploy_rulesets.sh) shall apply the uploaded payload to the Wazuh manager:

(i) The script shall copy rule XMLs from the staging payload into RAC_HOST_RULES_DIR and decoder XMLs into RAC_HOST_DECODERS_DIR, where both variables correspond to the host-side bind-mount paths of /var/ossec/etc/rules and /var/ossec/etc/decoders inside the container.
(ii) After copying, the script shall set ownership root:wazuh and mode 0640 on all deployed XML files inside the container, consistent with the existing RADAR Ansible convention.
(iii) The script shall restart the Wazuh manager using /var/ossec/bin/wazuh-control restart executed inside the container via docker exec.
(iv) The script shall emit a clear success or failure message after the restart attempt and shall exit with a non-zero status code on failure, causing the CI job to fail.
(v) The script shall abort with a non-zero exit code and a diagnostic message if the target container is not running at the time of invocation.

The following GitHub repository secrets shall be required for the deploy workflow to function:

(i) RAC_SSH_HOST: IP address or DNS name of the Wazuh manager host.
(ii) RAC_SSH_USER: SSH username on the manager host; the user must have passwordless sudo.
(iii) RAC_SSH_PORT: SSH port on the manager host.
(iv) RAC_SSH_KEY: PEM-encoded private key for SSH authentication, without passphrase.
(v) RAC_MGR_CONTAINER: Name of the Docker container running the Wazuh manager.
(vi) RAC_HOST_RULES_DIR: Absolute path on the host that is bind-mounted to /var/ossec/etc/rules inside the container.
(vii) RAC_HOST_DECODERS_DIR: Absolute path on the host that is bind-mounted to /var/ossec/etc/decoders inside the container.

The repository shall enforce branch protection on main such that:

(i) Direct pushes to main are disallowed; all changes must arrive via pull request.
(ii) The check_rule_ids status check is required to pass before a pull request may be merged.

Rationale

RADAR's detection logic currently changes only through the Ansible-powered deployment path, which requires a full playbook run for any rule edit. Applying version control, peer review via pull requests, automated conflict detection, and CI/CD deployment reduces operational risk, shortens the feedback loop for detection engineers, and produces a complete audit trail of every ruleset change through git history, without requiring direct access to the Wazuh manager.

Acceptance criteria

Successful validation according to test case specification, which shall verify:

Open a pull request containing a new rule file with a unique rule ID in the valid custom range - check_rule_ids passes.
Open a pull request containing a rule file with two rules sharing the same ID - check_rule_ids fails and the pull request is blocked from merging.
Merge a pull request that modifies a rule XML - integrate_rulesets workflow triggers automatically.
Merge a pull request that modifies only non-XML files - integrate_rulesets workflow does not trigger.
After a successful deploy run, verify the deployed XML files are present in RAC_HOST_RULES_DIR and RAC_HOST_DECODERS_DIR on the manager host.
Verify deployed XML files inside the container have ownership root:wazuh and mode 0640.
Verify wazuh-control status reports the manager as running after the deploy completes.

Parent links: MRS-043 Detection as Code

Attribute	Value
importance	2
urgency	3
risk	2
type	F
version	1.0

2.18 RADAR scenario: web scanning detection SRS-066

As a security engineer, I want RADAR to detect web-layer scanning by combining three indicators that are each individually evadable but not all at once — scanner tool signatures, failed-request rate, and HTTP method abuse — and to apply automated response only where two or more agree on the same source.

Scope

This requirement applies to detection of automated web-layer scanning against monitored HTTP servers, via three indicators: a known scanner signature in the User-Agent, an abnormal rate of failed requests, and use of HTTP methods a normal client would not send. Automated response is scoped to fire only when two or more indicators agree on the same source within a short window; a single-indicator match remains a detection-only alert and is out of scope for automated response.

Payload-level detection (SQLi, XSS, path traversal in request parameters) is out of scope for this scenario — that is a WAF function, handled separately.

Requirements

RADAR shall provide a non-alerting base rule (100800, level 0) matching HTTP access log entries from the monitored source, to which all child rules bind by SID.
RADAR shall fire Indicator 1 — tool signature (100810, level 3) when a request's User-Agent matches a known scanning tool: sqlmap, nikto, nmap, masscan, nuclei, gobuster, dirb/dirbuster, ffuf, feroxbuster, wfuzz, wpscan, joomscan, openvas, nessus, acunetix, burp, w3af, whatweb, arachni, skipfish, zgrab.
RADAR shall fire Indicator 2 — failed-request rate: rule 100815 (level 2, non-alerting) records each 404/401/403 response; rule 100825 (level 10) fires when 100815 matches 20 times from the same source IP within 60 seconds.
RADAR shall fire Indicator 3 — method abuse (100820, level 6) on TRACE, TRACK, CONNECT, plus a per-application, toggleable WebDAV set (PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, SEARCH). OPTIONS is excluded (CORS preflight is legitimate high-volume traffic); PUT, DELETE, and PATCH are excluded (normal REST semantics). The WebDAV subset must be disabled for applications that serve WebDAV natively (SharePoint, Nextcloud, CalDAV, SVN-over-HTTP, macOS Finder mounts).
RADAR shall fire Scan confirmation (100830, level 12) when two or more of Indicators 1–3 match the same source IP within 300 seconds. This is the sole trigger for notification and active response.
RADAR shall deduplicate each indicator to at most one contributing event per confirmation window: 100810, 100820, and 100825 each carry a 300-second same-source-IP ignore. Without this, repeated matches of a single indicator alone could satisfy the confirmation rule.
RADAR shall enforce an allowlist only at the active-response handler, not in the detection rules, so an allowlisted source still raises alerts. A matching source's active response shall be declined and recorded in an audit entry (decision_id, rule_id, source_ip, action, tier, result, reason), with reason: allowlist.
RADAR shall raise operational alert 100835 (level 12, no attacker source IP or ATT&CK technique) and decline the active response if the allowlist cannot be read, rather than fail open. A declined block is recoverable; an executed block against unverified infrastructure is not, within its timeout.

Rationale

Automated web scanning is the reconnaissance phase that typically precedes web application exploitation (ATT&CK T1595.002/T1595.003, OWASP OAT-014): before committing to an actual exploit, an attacker's tooling systematically probes an application to map its attack surface — which paths exist, which methods are accepted, which technologies are running. Detecting this phase gives defenders a chance to respond before exploitation begins, rather than only after a breach.

Since there are sophisticated detection evasion techniques, two indicators raises precision:

Evasion applied	I1 tool signature	I2 failed-request rate	I3 method abuse
Spoof/randomize User-Agent	defeated	fires	fires
Mask request rate (`--delay`)	fires	defeated	fires
Distribute across many source IPs	fires	defeated	fires
Restrict to GET/POST only	fires	fires	defeated

Acceptance criteria

Successful validation according to the corresponding test case specification, which shall verify:

Detection:

Indicator 1 fires — one request carrying a scanner User-Agent fires 100810 at level 3, and the alert carries the matched User-Agent value.
Indicator 1 does not escalate — 100810 from one source, at any repetition count, produces no notification and no active response.
Indicator 2 above threshold — the calibrated count of failed responses from one source within the window fires 100825 at level 10.
Indicator 2 below threshold — one event fewer in the same window fires 100815 and does not fire 100825.
Indicator 2 does not escalate — 100825, at any repetition count, produces no notification and no active response. Confirms that notification and response bind by rule ID rather than by alert level.
Indicator 2 source isolation — the threshold count distributed across distinct sources fires 100825 for none of them.
Indicator 3 fires — one TRACE request and one PROPFIND request, each carrying a common browser User-Agent, each fire 100820 at level 6. Establishes that detection does not depend on the User-Agent value.
Indicator 3 exclusions — sustained OPTIONS traffic and routine PUT, DELETE, and PATCH requests fire nothing. Where the WebDAV subset is disabled for an application, PROPFIND fires nothing.
Two-indicator confirmation — two distinct indicators matching the same source within 300 s fire 100830 at level 12, carrying source IP, agent name, and ATT&CK technique. All three pairings verified.
Single-indicator non-escalation — one indicator alone, at any volume, does not fire 100830. Includes a sustained failed-request case spanning more than one Indicator 2 window, confirming that each indicator contributes at most once per confirmation window.
Confirmation source isolation — two distinct indicators matching two different sources within 300 s do not fire 100830.
Legitimate traffic — a representative normal session, sustained CORS preflight traffic, and uptime-monitor and CI smoke-test traffic each produce no alert above level 3. A verified search-engine crawl including failed requests produces no alert above level 3 where the calibrated threshold exceeds its failure rate; where it does not, the crawl may fire 100825 at level 10 but shall not fire 100830 and shall not notify.

Response:

Response binding — 100830 is the only rule bound to active response; any indicator rule present in the binding fails this criterion.
Mitigation executed — a tier 2 risk score with allow_mitigation enabled blocks the source at the enforcement point (verified by inspecting enforcement state, not the handler's exit status), audited as executed/tier 2, and the block is gone after its configured timeout (verified the same way).
Mitigation withheld — an out-of-tier-2 risk score, or allow_mitigation disabled, alerts at level 12 with no change to enforcement state, recorded in the audit log.
Allowlist guard — an allowlisted target still alerts at 100830, but the handler declines before acting, enforcement state is unchanged, and the audit entry records declined/allowlist.
Allowlist unreadable — the handler declines, raises 100835 at level 12 naming the failure, enforcement state is unchanged, and the audit entry records declined/allowlist_unreadable.

Parent links: MRS-007 Intrusion Prevention

Attribute	Value
importance	3
urgency	3
risk	3
type	F
version	1.1

2.19 Secure agent enrollment and automated onboarding SRS-067

As a security engineer, I want agent enrollment to require a credential, endpoint onboarding to be a single verifiable command, and a clean Linux endpoint to become a fully monitored one without manual configuration steps, so that no unauthenticated host can register as a RADAR-monitored endpoint and onboarding a legitimate endpoint requires no hand-editing of Wazuh configuration.

Scope

This requirement covers, for Linux endpoints:

The manager-side credential requirement for Wazuh agent enrollment, rejection of duplicate-name enrollment attempts, cluster-key handling, and the time-limited restriction of network access to the enrollment port.
The one-shot installer script that takes a clean Linux endpoint to a fully monitored one, the short-lived token that authorizes it, and the corresponding removal script.

Windows endpoints and Docker-based agent deployment are out of scope for the installer and removal script; the manager-side enrollment controls (requirements 1-6) apply regardless of the endpoint's operating system.

Requirements

The manager shall refuse an agent-auth enrollment attempt that does not present the current, valid enrollment credential. An unauthenticated enrollment attempt shall not receive an agent key.
An enrollment attempt using the name of an agent already registered on the manager shall fail with an explicit error, rather than silently overwriting the existing agent's registration.
The manager's cluster authentication key shall be generated randomly at first setup, or read from an environment variable (WAZUH_CLUSTER_KEY). A randomly generated key shall be persisted to the manager's environment file so that it survives a restart.
Network access to the manager's agent enrollment port (1515) shall be blocked by a host-level firewall rule by default. It shall be reachable only during an explicitly opened, time-limited window.
An engineer shall be able to open the enrollment window for a specified duration, close it before that duration elapses, and query its current state (open or closed), independently of minting a token. An opened window shall close automatically once its duration elapses, without requiring a manual close action.
An enrollment token shall become invalid once its configured expiry elapses. Minting a new token shall immediately invalidate any previously minted token.
A single script shall, given a manager address, a valid token, and one or more target groups:
- Install a pinned version of the Wazuh agent package from the official repository.
- Write the manager address into the agent's configuration.
- Enroll the agent using the supplied token.
- Assign the agent to the specified group(s) if agent was not enrolled before.
- Install the currently allow-listed active-response scripts into the agent's active-response directory with correct ownership and permissions.
- Enable and start the agent service.
- Print a clear success or failure message, including a next step on failure.
Running the installer again on an endpoint that is already enrolled (i.e., a non-empty local agent key file already exists, or the manager reports "Duplicate agent name") shall not create a duplicate registration or fail; it shall detect the existing enrollment and proceed directly to verifying the service is running correctly.
The installer shall not require Docker or any container runtime on the target endpoint.
The installer shall be published as a versioned release artifact accompanied by a checksum. The documented onboarding procedure shall be download, verify the checksum, then execute.
A separate script, run on the endpoint, shall stop and disable the agent service and uninstall the agent package. An option (--purge-data) shall additionally and irreversibly remove all local agent state (logs, enrollment data, installed active-response scripts) when explicitly requested.

Rationale

RADAR trains an anomaly detection model on incoming data; a host that can enroll without authentication can inject events that teach the model that attack behavior is normal (training data poisoning), which is a materially worse consequence than the equivalent gap in a signature-only system. Closing this gap with a shared credential, immediately, was prioritized over a higher-assurance certificate-based scheme that would take materially longer to stand up correctly — the risk reduction from "no authentication" to "some authentication" is large and urgent, and is layered with additional mitigations (short-lived tokens rather than one long-lived secret, rejection of duplicate-name enrollment, and a normally-closed enrollment port) that narrow the residual exposure of a shared-credential scheme to a bounded, operator-controlled window.

Many organizations already manage endpoints with configuration/fleet management tooling (Ansible, Puppet, Intune, SCCM). A single, parameterized installer script that does nothing beyond initial onboarding means each of these can wrap the same artifact rather than RADAR maintaining a separate integration per tool.

Dependencies

SRS-069: Scenario-Scoped Agent Group Configuration Delivery. The installer's group assignment step, and all configuration an onboarded agent receives afterward, are delivered through the mechanism this requirement defines.

Acceptance criteria

Successful validation according to the corresponding test case specification, which shall verify:

An agent-auth attempt without a credential is refused by the manager.
An agent-auth attempt with the correct, currently valid credential succeeds.
A second enrollment attempt using an existing agent's name is rejected rather than silently replacing that agent's registration.
The enrollment port is unreachable from a general network outside of an explicitly opened window, and an opened window closes on its own once its duration elapses.
A freshly minted token successfully authorizes exactly one onboarding, and an expired or superseded token is refused.
A clean, supported Linux endpoint becomes a fully enrolled, correctly grouped, running monitored endpoint by running the installer once with a valid manager address, token, and group.
Running the installer a second time on the same, already-enrolled endpoint completes without error and creates no duplicate agent.
The installer fails clearly and promptly when the manager is unreachable or the supplied token is invalid.
The published installer artifact's checksum matches the artifact itself.
Running the removal script on an onboarded endpoint stops and uninstalls the agent, and the --purge-data option additionally removes all local agent state.

Parent links: SRS-069 Scenario-scoped Agent Group Configuration Delivery

Attribute	Value
importance	5
urgency	4
risk	3
type	F
version	2.0

2.20 Manager-side enrichment SRS-068

As a security engineer, I want GeoIP, ASN, and login-velocity enrichment for authentication and web-access events computed entirely on the Wazuh manager, so that a user's behavioral history stays consistent no matter which endpoint they authenticate from, and monitored endpoints carry no RADAR-specific runtime dependency beyond the standard Wazuh agent.

Scope

This requirement applies to the two production scenarios whose detection logic depends on GeoIP/ASN/velocity context: suspicious_login and geoip_detection. It defines where and how that enrichment is computed and where the resulting state is kept.

Requirements

GeoIP, ASN, and geo-velocity enrichment for suspicious_login and geoip_detection shall be computed by a component running on the Wazuh manager, triggered by the manager's own alert pipeline recognizing a relevant authentication or web-access event.
The manager-side enrichment shall produce, at minimum: source country, region/ASN, geo-velocity between consecutive logins, country-change indication, and ASN novelty.
The history used to compute geo-velocity and ASN novelty for a given user shall be maintained centrally on the manager, keyed by user identity, not per endpoint. A user authenticating from two different endpoints in sequence shall be evaluated against one consistent history, not two independent ones.
The agent-side configuration for these scenarios shall do nothing beyond forwarding the endpoint's own raw log data (the system authentication log for suspicious_login; the web server's own access log for geoip_detection) to the manager, unmodified.
The GeoIP reference databases required for enrichment shall be obtained by the manager itself during deployment, using a license key supplied via an environment variable. The databases shall not be committed to the project's version control repository.
A failure of the manager-side enrichment component (for example, it is not running, or fails to produce enriched output) shall be detectable by the deployment health check (SRS-060) rather than failing silently.

Rationale

Centralizing the computation on the manager, where relevant events from every endpoint already arrive, provides a comprehensive view of user activity and enables a single, correct per-user history for geo-velocity and ASN-novelty comparisons.

Dependencies

SRS-051: Suspicious login scenario. Consumes the enriched fields this requirement defines (country, ASN, geo-velocity, country change) in its detection rules.
SRS-055: GeoIP detection scenario. Consumes the enriched country field this requirement defines in its detection rules.
SRS-060: RADAR Deployment Health Check. Surfaces a failure of the enrichment component defined here.

Acceptance criteria

Successful validation according to the corresponding test case specification, which shall verify:

For a given raw authentication or web-access event, manager-side enrichment produces the same enriched fields (country, ASN, geo-velocity, country change, ASN novelty, as applicable) that the scenario's detection rules require.
A user authenticating from one endpoint and then a different endpoint produces a geo-velocity/ASN-novelty result computed against that user's combined history across both endpoints, not two separate histories.
The suspicious_login and geoip_detection scenarios produce alerts equivalent to their expected detection behavior using manager-side enrichment.
The manager obtains its GeoIP reference databases during deployment using a configured license key, and no such database file is present in the version-controlled repository.
Deliberately disabling or breaking the manager-side enrichment component causes the deployment health check to report a failure for it.

Parent links: MRS-007 Intrusion Prevention

Attribute	Value
importance	4
urgency	3
risk	2
type	F
version	2.0

2.21 Scenario-scoped Agent Group Configuration Delivery SRS-069

As a security engineer, I want each RADAR scenario's agent-side configuration delivered exclusively through its own Wazuh agent group, so that deploying, changing, or removing a scenario's configuration is a manager-side operation that never requires direct contact with any individual endpoint.

Scope

This requirement defines how RADAR's scenario-specific agent configuration (log collection paths and related agent-side settings) reaches an enrolled agent, and how it is withdrawn. It covers the group structure used, and the manager-side operations that apply a scenario's configuration.

The configurations and files that are dependent on more than one scenario (a shared agent group, or a decoder/rule file used by more than one scenario) should be handled safely, so that an operation scoped to one scenario cannot break another scenario currently relying on the same shared resource.

Requirements

Each production scenario shall have its own dedicated Wazuh agent group, distinct from any other scenario's group and from the baseline group every agent belongs to regardless of scenario.
Configuration needed by more than one scenario shall be delivered through a single shared group used by exactly those scenarios, rather than duplicated into each scenario's own group.
Applying, updating, or removing a scenario's agent-side configuration shall be accomplished entirely by updating the relevant group's configuration through the Wazuh REST API. No script or operation defined by this requirement shall connect to, or require credentials for, an individual agent endpoint in order to change its configuration.
Deploying a scenario shall ensure its own group exists and shall push that scenario's agent-config snippet to it; if the scenario depends on the shared group, deploying it shall also ensure the shared group exists and carries the shared snippet.
Removing a scenario's deployment shall reset its own group's configuration to empty and shall remove any agent's membership in that group. It shall not modify the baseline group every agent belongs to.
An operation that removes one scenario's configuration shall not modify or remove the shared group's configuration, or any file used by more than one scenario, while another scenario that depends on that shared group or file is still currently deployed. Such shared resources shall only be removed once no remaining deployed scenario depends on them.
Deploying an already-deployed scenario, or removing an already-removed (or never-deployed) scenario's configuration, shall complete without error and without unintended side effects.

Rationale

Wazuh's own group mechanism already distributes configuration to every agent in a group without requiring the manager to individually contact each one; using it as the sole configuration-delivery path for RADAR scenarios means adding, changing, or removing a scenario never requires direct access to any endpoint, and an agent picks up a group's configuration through Wazuh's own existing synchronization rather than a RADAR-specific mechanism that would have to replicate it. Because some configuration is legitimately needed by more than one scenario, that sharing has to be handled explicitly and conservatively during removal.

Dependencies

SRS-067: Secure agent enrollment and automated onboarding. The group assignment step of the onboarding installer, and any later re-assignment of an already-enrolled agent, both use the mechanism this requirement defines.

Acceptance criteria

Successful validation according to the corresponding test case specification, which shall verify:

Deploying a scenario updates only that scenario's own group, and the shared group if the scenario depends on it — no other scenario's group is modified.
An agent assigned to a scenario's group receives that scenario's configuration without any direct connection having been made to the agent itself.
Removing one scenario's configuration, while a different scenario that depends on the same shared group or file is still deployed, leaves that shared group and file unchanged and the other scenario's detection unaffected.
Removing one scenario's configuration, once no other deployed scenario depends on the same shared group or file, removes that shared resource too.
Removing a scenario's configuration resets its own group and clears agent membership in it, without altering the baseline group any agent retains regardless of scenario.
Repeating a deploy or a remove operation for the same scenario a second time completes without error and produces no change beyond the first operation's effect.

Parent links: MRS-015 Software Configuration Management

Attribute	Value
importance	4
urgency	3
risk	2
type	F
version	2.0

2.22 RADAR GUI Deployment interface SRS-070

As a security engineer or operator, I want a single browser-based interface to deploy, undeploy, onboard, unenroll, deregister, and health-check RADAR scenarios and agents, so that the full operational lifecycle of a RADAR deployment can be managed without direct shell or SSH access to the manager.

Scope

This requirement covers the RADAR web interface's deployment-lifecycle page: scenario deployment and its reversal, agent onboarding and its reversal, agent group assignment and its reversal, agent enrollment window control, anomaly detector creation, deployment health checking, and stack teardown. It also covers the credential handling shared across the actions on this page that require elevated host privileges.

Requirements

The interface shall allow deploying a named scenario, or bringing up the underlying stack with no scenario applied, and shall stream the operation's output to the user as it is produced.
The interface shall allow reversing a previously deployed scenario's configuration, streaming its output as it is produced, safe to invoke whether or not the scenario is currently deployed.
The interface shall allow minting a short-lived enrollment token scoped to one or more groups, automatically opening the agent enrollment window for the token's duration, and shall present the resulting onboarding command as a distinct element the user can copy directly, separate from the general streamed log output.
The interface shall allow removing an agent's registration from the manager entirely, with an option to keep its name and address reserved rather than freeing them immediately for reuse.
The interface shall allow assigning an already-enrolled agent to a scenario's group(s), and separately allow unenrolling it from them, without requiring direct access to the agent endpoint for either action.
The interface shall allow opening, closing, and checking the status of the agent enrollment window independently of minting a token.
The interface shall allow creating and starting the anomaly detector and monitor for a scenario that uses one, with an option to first ingest a training dataset.
The interface shall allow running the deployment health check scoped to a single scenario or to all deployed scenarios, optionally including specific named agents, and shall stream the result.
The interface shall allow stopping the locally managed stack, with an explicit, separately presented option to also permanently delete its data; the default action shall not delete data.
Actions that require elevated host privileges (scenario deployment, agent onboarding, enrollment window control, and teardown) shall share a single credential prompt per browser session. The credential shall be held only in memory for the duration of that session, never written to persistent storage, and shall be requested again if the interface's own server process restarts.
Every action defined above that runs for longer than an immediate response shall stream its output to the user progressively as it is produced, rather than presenting a result only after the action completes, and shall allow the user to stop following that output before the action itself finishes.

Rationale

A single interface surfacing all the mentioned actions, with low-friction credential prompt for the ones that need elevated privileges lowers the skill and access barrier for routine operational tasks without changing what those tasks actually do underneath.

Dependencies

SRS-069: Scenario-scoped agent group configuration delivery. Backs the scenario deploy/undeploy and group assign/unenroll actions this interface exposes.
SRS-067: Secure agent enrollment and automated onboarding. Backs the token-minting action and produces the installer command this interface presents.
SRS-060: RADAR Deployment Health Check. Backs the health check action this interface exposes.

Acceptance criteria

Successful validation according to the corresponding test case specification, which shall verify:

A scenario can be deployed, and separately undeployed, entirely from the interface, with streamed output visible for each.
An agent can be onboarded by minting a token in the interface and running the resulting, separately presented command on the target endpoint, with no manual construction of that command by the operator.
An agent can be deregistered from the interface, and no longer appears as a registered agent afterward.
An agent's group membership can be assigned and separately unenrolled from the interface, with the change visible in the agent's group membership afterward.
The enrollment window can be opened, closed, and its status checked from the interface independently of minting a token.
The anomaly detector for a scenario can be created and started from the interface, including the training-dataset-ingestion option.
A health check can be run from the interface scoped to one scenario, to all scenarios, and to named agents, with the result streamed to the user.
The stack can be torn down from the interface with data preserved by default, and permanently deleted only when the explicit data-deletion option is selected.
A privileged action prompts for a credential once per session; a second privileged action in the same session does not prompt again; restarting the interface's server process requires the credential to be entered again.
A long-running action's output is visible to the user progressively while the action is still in progress, and the user can stop following it before the action completes.

Parent links: MRS-014 Data Extraction API, MRS-016 Agent (De)Registration, MRS-017 Monitoring Frontend

Attribute	Value
importance	4
urgency	3
risk	2
type	F
version	2.0

System-level requirements for ADBox v1 (MTAD-GAT legacy system) - maintenance mode only.

4.0 Infrastructure & Integration System Requirements

System-level requirements for deployment, integration, platform support, and cross-cutting capabilities.

4.1 Centralized C&C Deployment SRS-001

As a system admin user, I want to deploy and maintain a central subsystem, called command-and-control (C&C), so that I can update user-exposed settings of subsystems tackling data collection, intrusion detection and prevention.

Set up host for C&C server.
Access as root.
Deploy C&C components following:

IDPS-ESCAPE decision diagram C&C deployment

Configure components via respective software configuration management (SCM) mechanism.

Rationale

To centralize and simplify IDPS components configuration management.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-002 Command & Control

Child links: TST-020 Wazuh installation in a containerized environment

Attribute	Value
importance	5
urgency	5
risk	1
type	F
version	0.1

4.2 Endpoint Status Monitoring SRS-002

As a system admin user, I want to access the end-point monitored system via IDPS-ESCAPE C&C server/unit, so that I can check the status of end-point monitoring solutions deployed, if any.

Access C&C server as root.
Via CyFORT-Wazuh manager, list the enrolled agents and their status.
If deployed, check C-CyFORT-Suricata and mirroring status
If any deployed, remote connect to endpoint and check local CyFORT-Suricata status.

Rationale

To centralize and simplify agent/sensor configuration management.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-002 Command & Control

Attribute	Value
importance	5
urgency	5
risk	2
type	F
version	0.1

4.2 Default Use Case Update SRS-021

As a user, I want to update the default use case of ADBox.

Access C&C server
Access ADBox
Modify ../siem_mtad_gat/assets/default_configs/default_detector_input_config.json

Rationale

To adapt ADBox default behavior

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-015 Software Configuration Management

Child links: LARC-012 ADBox ConfigManager

Attribute	Value
importance	3
urgency	3
risk	1
type	F
version	0.1

4.3 HIDS Agent Deployment SRS-003

As a sys admin user, I want deploy HIDS agents on the hosts monitored system so that I can enable the IDPS-ESCAPE HIDS capabilities.

Access host to be monitored
Install Wazuh Agent
Enroll Wazuh Agent in CyFORT-Wazuh manager.
Configure Wazuh Agent.

Rationale

To enable a multi-node deployment of monitoring endpoints host.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-005 Host-based Intrusion Detection

Child links: TST-021 Wazuh agent installation and enrollment: the local machine

Attribute	Value
importance	5
urgency	5
risk	1
type	F
version	0.1

4.4 HIDS Agent Management SRS-004

As a sys admin user, I want to enabled/disabled HIDS agents deployed on the host monitored system.

Access C&C server
Enroll/unenroll Wazuh Agent from CyFORT-Wazuh manager
Possibly, remove logs and config files.

Rationale

To enable system hosts security posture monitoring

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-005 Host-based Intrusion Detection

Child links: TST-023 Wazuh agent deletion and uninstallation, TST-024 Wazuh agent unenrollment

Attribute	Value
importance	5
urgency	5
risk	2
type	F
version	0.1

4.5 Network Monitoring Control SRS-005

As a sys admin user, I want to enable/disable network monitoring within IDPS-ESCAPE subsystem boundaries.

Access C&C server
Deploy C-CyFORT-Suricata
Set up channel to be connections to be monitored
Possibly, add custom rules.

Rationale

To enable traffic monitoring

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-006 NIDS Support

Attribute	Value
importance	5
urgency	4
risk	2
type	F
version	0.1

4.6 Centralized NIDPS Prevention SRS-006

As a sys admin user, I want a centralized NIDPS in the C&C server.

Access C&C server
Deploy C-CyFORT-Suricata
Activate prevention in the config and set up actions behavior.

Rationale

To be able to take reactive corrective measures and mitigate intrusions

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-007 Intrusion Prevention

Attribute	Value
importance	2
urgency	1
risk	4
type	F
version	0.1

4.7 Raw Traffic Capture SRS-007

As a sys admin user, I want to capture and forward raw network traffic to the C&C server, to run NIDS on such a traffic.

Access C&C server.
Deploy C-CyFORT-Suricata.
Identify host capture interface (CI), C&C CI and IP.
Run port mirroring activation script with above arguments.

Rationale

To collect events for threat hunting and CTI operations, reducing the NIDS overhead and to do customized AD.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-008 Network Capture Forwarding

Child links: TST-026 Port mirroring for remote machines

Attribute	Value
importance	5
urgency	5
risk	2
type	F
version	0.1

4.8 Dockerized NIDS Deployment SRS-008

As a sys admin user, I want to deploy NIDS components as a Docker container on a system end-points hosts, to monitor traffic and store logs locally.

Access end-point (EP) host,
Deploy using custom script.
Update the configs file (.yml) with local configuration.

Rationale

To ensure the following properties: consistent and reproducible environments, isolation, resource efficiency, scalability, portability, fast spawning and shutdown, improved CI/CD, support of micro services architecture, improved dependency management.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-009 Docker Deployment Option

Child links: TST-019 Suricata installation in a containerized environment

Attribute	Value
importance	3
urgency	2
risk	2
type	F
version	0.1

4.9 Signature-Based HIDS SRS-009

As a sys admin user, I want to enable host intrusion detection via pattern matching with known/expected threats (signature-based HIDS).

Access host to be monitored.
Deploy Wazuh Agent (using C&C manager ip).
Enroll Agent agent.
Set up local configs and logs.
Possibly, define custom rules.

Rationale

To build on the mature and existing rule-based detection and CTI body of knowledge and to mitigate low AD detection risk.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-011 Signature-based Host IDS

Attribute	Value
importance	5
urgency	5
risk	1
type	F
version	0.1

4.10 Centralized Threat Management SRS-010

As SOC member user, I want to manage the HIDP and NIDS results and information jointly, to have a centralized overview of the system for threat detection, investigation, and response.

Access C&C server
Deploy CyFORT-Wazuh and HIDS agents
Deploy (C-)CyFORT-Suricata
Integrate CyFORT-Suricata and CyFORT-Wazuh using custom script and procedure

Rationale

None

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-012 XDR & SIEM Integration

Child links: TST-025 Suricata and Wazuh Integration

Attribute	Value
importance	5
urgency	4
risk	1
type	F
version	0.1

4.11 Network Event Visualization SRS-011

As SOC member, I want a graphic visualization of the network events detected in my system.

Assuming: CyFORT-Suricata integrated in CyFORT-Wazuh

Access CyFORT-Wazuh Dashboard
Filter security events generate by NIDS group rules

Rationale

To improve accessibility and easy-of-use for IDPS-ESCAPE end-users

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-013 Visual Dashboard

Child links: TST-027 Traffic monitoring on Wazuh (local), TST-028 Traffic monitoring on Wazuh (remote), TST-032 Wazuh filters using the Wazuh Dashboard

Attribute	Value
importance	3
urgency	3
risk	1
type	F
version	0.1

4.12 Host Event Visualization SRS-012

As SOC member, I want a graphic visualization of the host events detected in my system.

Assuming: CyFORT-Wazuh and HIDS agents deployed

Access CyFORT-Wazuh Dashboard
Filter security events generate by HIDS group rules

Rationale

To improve accessibility and easy-of-use for IDPS-ESCAPE end-users

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-013 Visual Dashboard

Attribute	Value
importance	3
urgency	3
risk	1
type	F
version	0.1

4.13 HIDS Agent Status Panel SRS-013

As SOC member, I want to check the status of HIDS agents.

Assuming: CyFORT-Wazuh and HIDS agents deployed and enrolled to C&C Manager

Access CyFORT-Wazuh Dashboard.
Look dedicated panel and click to the agent ID for additional info.

Rationale

To improve IDPS-ESCAPE status management for the end-users

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-013 Visual Dashboard

Attribute	Value
importance	3
urgency	2
risk	1
type	F
version	0.1

4.14 Event Decoding & Transformation SRS-014

As SOC member, I want the detected event to be correctly decoded and transformed before usage and storage.

Access C&C server
Access CyFORT-Wazuh manager
Run testing and verification of rules and decoders via CyFORT-Wazuh server API

Rationale

To ensure avoid errors and inaccuracy

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-014 Data Extraction API

Attribute	Value
importance	3
urgency	1
risk	1
type	F
version	0.1

4.15 Custom Rule Support SRS-015

As a user, I want my SIEM to interpret a new type of data forwarded by agents/sensors.

Access C&C server
Access CyFORT-Wazuh manager
Add custom rules and custom decoders.

Rationale

To extend the detection capability of IDPS-ESCAPE and tailor the detection to my system

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-014 Data Extraction API

Attribute	Value
importance	2
urgency	1
risk	3
type	F
version	0.1

4.16 Indexer Credential Management SRS-016

As an admin user, I want to modify the credentials of data indexer for a user, to improve the security level of the admin password.

Access C&C server
Access CyFORT-Wazuh manager
Update config/wazuh_indexer/internal_users.yml file.

Rationale

Maintain/improve the security of IDPS-ESCAPE

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-015 Software Configuration Management

Child links: TST-029 Changing password for Wazuh indexer users, TST-030 Changing password for Wazuh API users

Attribute	Value
importance	3
urgency	1
risk	2
type	F/S
version	0.1

4.17 Custom Data Source SRS-017

As a user, I want to define a ADBox to fetch data from an indexer at specific host address.

Access C&C server
Access ADBox
Modify IP address in ../siem_mtad_gat/assets/secrets/wazuh_credentials.json

Rationale

To connect ADBox to a specific data source containing data of interest, possibly different from the default one

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-015 Software Configuration Management

Child links: TST-034 ADBox set up indexer host address

Attribute	Value
importance	5
urgency	4
risk	4
type	F
version	0.1

4.18 Datatype Transformation Map SRS-019

As a user, I want to modify the datatype transformation map operated by ADBox on fetched.

Access C&C server
Access ADBox
Modify key values ../siem_mtad_gat/assets/wazuh/wazuh_columns.json

Rationale

To maintain the consistency with SIEM solution

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-015 Software Configuration Management

Attribute	Value
urgency	1
type	F
version	0.1

4.19 Ingestion Field Update SRS-020

As a user, I want to update the default fields fetched at ingestion phase by ADBox.

Access C&C server
Access ADBox
Update key and values in ../siem_mtad_gat/assets/wazuh/wazuh_columns.json

Rationale

To maintain the consistency with SIEM solution, add custom feature

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-015 Software Configuration Management

Attribute	Value
urgency	1
type	F
version	0.1

4.21 Indexer Credentials Update SRS-022

As a user, I want to update indexer credentials in ADBox.

Access C&C server
Access ADBox
Update CyFORT-Wazuh indexer credentials in ../siem_mtad_gat/assets/secrets/wazuh_credentials.json

Rationale

To adapt to local configuration

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-015 Software Configuration Management

Child links: TST-035 ADBox change indexer credentials

Attribute	Value
importance	3
urgency	3
risk	2
type	F
version	0.1

4.22 Agent Registration Process SRS-023

As a user, I want to register a new agent in the central SIEM&XDR.

Assuming the CyFORT-Wazuh Manager is running on C&C and an agent is running on the selected host, either:

a. Add the manager IP as an environment variable during the agent installation process.

b. Set the manager IP in the agent configuration file.

c. Requests the key from the manager API and manually imports it into the agent.

Rationale

To enable a non-static configuration of monitored nodes.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-016 Agent (De)Registration

Child links: TST-022 Wazuh agent installation and enrollment: remote machine

Attribute	Value
importance	3
urgency	3
risk	1
type	F
version	0.1

4.23 Event Querying Capability SRS-024

As a user, I want to run queries on data such as events, alerts and statistics.

Assuming: CyFORT-Wazuh running and established connection to indexer

Formulate query as Wazuh Query Language
Query to indexer via Wazuh API

Rationale

To achieve a programmatic access to security alert and event data.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-018 Data Management Subsystem

Child links: TST-031 Wazuh filters using the RESTful API

Attribute	Value
importance	2
urgency	4
risk	1
type	F
version	0.1

4.24 Remote Endpoint Deployment SRS-033

As a system admin user, I want to deploy IDPS end-point monitoring solutions on a remote end-point by choosing from multiple configuration options so that I can monitor events on my system's edge/endpoints.

Access end-point as root.
Deploy end-point components following:

IDPS-ESCAPE decision diagram EP deployment

Connect local solution to C&C sub-system.

Rationale

To adapt and improve performance

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-037 Multiple Deployment Models

Child links: LARC-004 IDPS-ESCAPE end-point integrated arch., LARC-005 IDPS-ESCAPE end-point hybrid arch., LARC-006 IDPS-ESCAPE end-point host-only IDS arch., LARC-007 IDPS-ESCAPE end-point capture-only arch.

Attribute	Value
importance	5
urgency	4
risk	3
type	F
version	0.1

4.26 Custom NIDS Rules SRS-036

As user, I want to add a new custom rule set signature to a specific network related event type.

Access C&C server
Add the file with custom rules local.rules
Open /etc/suricata/suricata.yaml and update:

rule-files: - suricata.rules - /path/to/local.rules

Rationale

To extend the detection capability of IDPS-ESCAPE and tailor the detection to my system

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-040 Signature-Based NIDS

Attribute	Value
importance	3
urgency	1
risk	3
type	F
version	0.1

4.27 Platform-Independent Deployment SRS-044

As a user, I want to deploy ADBox using a platform-independent solution, and to further develop it.

Assuming:

CyFORT-Wazuh deployed

Deploy ADBox using dev container.

Rationale

Ensure cross-platform compatibility and portability both for usage and develpment.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-020 Platform Independence

Child links: TST-003 Install ADBox as dev container

Attribute	Value
importance	4
urgency	4
risk	2
type	F/A
version	0.1

4.28 High-Level Architecture Overview SRS-045

As a user, I want to understand IDPS-ESCAPE high level architecture.

Assuming:

access to idps-escape docs repository

Open the docs\specs project folder.
Open HARC

Rationale

To follow a consistent and well-defined process, while improving development security.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-026 C5-DEC Development Model

Child links: TST-040 Visualize IDPS-ESCAPE high level architecture

Attribute	Value
urgency	3
risk	1
type	S
version	0.1

4.29 TIP Data Export SRS-026

As a user, I want to export data from IDPS-ESCAPE to a TIP.

Rationale

To enable programmatic access, which would also in turn support integration with SATRAP-DL.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-025 Threat Detection API

Attribute	Value
urgency	1
type	F
version	0.1

4.30 MITRE ATT&CK Mapping SRS-025

As a user, I want to map a detected event to the MITRE ATT&CK framework.

Assuming: CyFORT-Wazuh running

Open the document corresponding to the event (e.g. via index query, or using the dashboard)
Check if the following keys exist in the attributes rule.mitre.id , rule.mitre.tactic , rule.mitre.technique

Rationale

To improve and speed up threat detection and classification, thereby facilitating CTI analysis.

Acceptance criteria

Successful validation according to the corresponding test case specification

Parent links: MRS-023 MITRE ATT&CK Mapping

Child links: TST-036 Map a detected event to MITRE ATT&CKS

Attribute	Value
importance	2
urgency	2
risk	1
type	F
version	0.1