1.1 Deploy ADBox via Docker and shell scripts TST-001

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
26 GB storage on the machine
git version 2.44.0

Test steps

Clone the ADBox repository. git clone https://github.com/AbstractionsLab/idps-escape.git
Change the working directory to the cloned folder containing all the files along with the Dockerfile.

cd siem-mtad-gat

Build the image.

3a. Make the script executable: chmod +x build-adbox.sh

3b. And execute it as follows

./build-adbox.sh

Run the container by executing the bash file containing the run commands.

4a. Make it executable: chmod +x adbox.sh

4b. And execute it as follows

./adbox.sh -h

Expected outcome

Step 1. A copy of siem-mtad-gat folder in local folder

Step 3. In the list of docker images (docker images), the following should be present

REPOSITORY                      TAG       IMAGE ID       CREATED         SIZE
siem-mtad-gat                   v0.1.4    ...   ...            ...

Step 4b. Display ADBox help message

usage: driver.py [-h] [-i] [-u USECASE] [-c] [-s]

IDPS-ESCAPE ADBox, an open-source anomaly detection toolbox, developed in project CyFORT.

options:
  -h, --help            show this help message and exit
  -i, --interactive     run the interactive console for training and prediction
  -u USECASE, --usecase USECASE
                        specify a configuration scenario/use-case file for training and prediction
  -c, --connection      check connection with Wazuh
  -s, --shipping        enable data shipping to Wazuh

Parent links: SRS-046 Cross-platform SONAR deployment

Child links: TRP-001 TCER: Deploy ADBox via Docker and shell scripts, TRP-023 TCER: ADBox deployment

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	1
test_data	see referenced files
version	0.2

1.3 Install ADBox as dev container TST-003

Preconditions and setup actions

Docker engine version 26.1.3
Docker desktop version 1.0.35
Visual Studio Code version 1.83.1 (system setup)
Dev Containers extension for VS Code by Microsoft version v0.315.1
at least 26 GB of persistent/disk storage

Test steps

Clone this repository: git clone https://github.com/AbstractionsLab/idps-escape.git
Start Docker Desktop if not already running.
Open the project folder in VS Code.
Select the "Reopen in Container" option in the notification that pops up in VS Code or run it via the command palette.
Open a terminal in VS Code and run poetry install in the container to install all dependencies.
Run ADBox using its entrypoint.

  poetry run adbox

Expected outcome

Step 1. Repository creation

Step 4. Container created and terminal open.

Step 5. Poetry install terminated with Installing the current project: siem-mtad-gat (0.1.4).

Step 6. Run ADBox default mode:

  IDPS-ESCAPE ADBox running in default mode
Are you sure you wish to run the default ADBox in default mode? (y/n):

Parent links: SRS-044 Platform-Independent Deployment

Child links: TRP-003 TCER: Install ADBox as dev container, TRP-004 TCER: Install ADBox as dev container, TRP-020 TCER: Install ADBox as dev container, TRP-024 TCER: ADBox in dev container

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.4 Run ADBox console TST-004

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.

Test steps

Run the container “siem-mtad-gat-container” by executing the adbox script without any parameters. ./adbox.sh -i

Expected outcome

ADBox starts with

IDPS-ESCAPE ADBox driver running in interactive console mode.

Enter a number and press enter to select an ADBox action to perform:
1. Train an anomaly detector.
2. Predict anomalies using one of the available detectors.
3. Select an existing anomaly detector for prediction.
4. Exit
Enter a number (1-4):

Parent links: SRS-047 Interactive Use Case Builder

Child links: TRP-005 TCER: Run ADBox console, TRP-025 TCER: ADBox console

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.5 Run ADBox in default mode with a Wazuh connection TST-005

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.
Wazuh indexer RESTful API should be listening on port 9200.
TST-034 and TST-035 should succeed

Test steps

Run the container “siem-mtad-gat-container” by executing the adbox script without any parameters. ./adbox.sh
Input y after Are you sure you wish to run the default ADBox in default mode? (y/n):

Expected outcome

ADBox starts with

IDPS-ESCAPE ADBox running in default mode
Are you sure you wish to run the default ADBox in default mode? (y/n): y
No input use-case: a detection with default config will be created.
Start training pipeline.
Init Data managers.
JSON file 'detector_input_parameters.json' saved at /home/alab/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/input/detector_input_parameters.json.
Data ingestion.
...

A detector {detector_id} is trained according to the default parameters specified in siem_mtad_gat/assets/default_configs/default_detector_input_config.json.
Training response should be seen in the console.
Training outputs and artifacts should be available in the following folder: /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}.

Parent links: SRS-048 Default Detector Training

Child links: TRP-006 TCER: Run ADBox in default mode with a Wazuh connection, TRP-026 TCER: ADBox in default mode with Wazuh

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	3
test_data	see referenced files
version	0.2

1.6 Run ADBox in default mode without a Wazuh connection TST-006

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.0
No existing container named “siem-mtad-gat-container” should be running.
No instance of Wazuh distribution running.

Test steps

Run the container “siem-mtad-gat-container” by executing the adbox script without any parameters. ./adbox.sh
Input y after Are you sure you wish to run the default ADBox in default mode? (y/n):

Expected outcome

ADBox starts with

IDPS-ESCAPE ADBox running in default mode
Are you sure you wish to run the default ADBox in default mode? (y/n): y
No input use-case: a detection with default config will be created.
Start training pipeline.
Init Data managers.
JSON file 'detector_input_parameters.json' saved at /home/alab/siem-mtad-gat/siem_mtad_gat/assets/detector_models/fb5faf1c-7913-4e90-880f-51f3a178a053/input/detector_input_parameters.json.
Data ingestion.
Wazuh data ingestor establishing connection to Wazuh...
Could not establish a connection with OpenSearch.
More details see logs.
...

A detector {detector_id} is trained according to the default parameters specified in siem_mtad_gat/assets/default_configs/default_detector_input_config.json and using default stored data

...
The file '/home/alab/siem-mtad-gat/siem_mtad_gat/assets/data/train/sample-alerts-train-2024-11.json' does not exist, returning all default data.
...

Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.

Parent links: SRS-048 Default Detector Training

Child links: TRP-007 TCER: Run ADBox in default mode without a Wazuh connection, TRP-019 TCER: Run ADBox in default mode without a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.7 ADBox use case 1 with a Wazuh connection TST-007

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.
Wazuh indexer RESTful API should be listening on port 9200.
Wazuh configured to monitor linux resource utilization. (Monitoring Linux resource usage with Wazuh)
2024-07-* index not empty.
TST-034 and TST-035 should succeed

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 1 parameters. ./adbox.sh -u 1

Expected outcome

ADBox starts with IDPS-ESCAPE ADBox driver running use-case scenario configuration uc_1.yaml.
The training should run for 10 epochs.
Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with the message Predicting in real-time mode with interval 1 (min).
A prediction response should be seen in the output console after every 1 minute.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-027 ML-Based Anomaly Detection

Child links: TRP-008 TCER: ADBox use case 1 with a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.8 ADBox use case 1 without a Wazuh connection TST-008

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
No instance of Wazuh distribution running.

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 1 parameters.

  ./adbox.sh -u 1

Expected outcome

ADBox starts with Running AD driver with user configuration uc_1.yaml.
Output screen should show the message Could not establish a connection with OpenSearch.
And collect training data from the default file with message Returning data from file /home/root/siem-mtad-gat/siem_mtad_gat/assets/data/train/sample-alerts-train-2024-07.json.
The training should run for 10 epochs.
Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in real-time mode with interval 1 (min).
Output screen should show the following messages:
Could not establish a connection with OpenSearch.
Prediction in run_mode.REALTIME requires a connection with OpenSearch.
No data found for given input.
And the application should exit.

Parent links: SRS-027 ML-Based Anomaly Detection

Child links: TRP-009 TCER: ADBox use case 1 without a Wazuh connection, TRP-018 TCER: ADBox use case 1 without a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.1

1.9 ADBox use case 2 with a Wazuh connection TST-009

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.
Wazuh indexer RESTful API should be listening on port 9200.
2024-07-* index not empty.
TST-034 and TST-035 should succeed

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 2 parameters. ./adbox.sh -u 2

Expected outcome

ADBox starts with Running AD driver with user configuration uc_2.yaml.
The training should run for 10 epochs.
Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in historical mode.
Prediction response should be seen in the output console.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-035 Offline Anomaly Detection

Child links: TRP-010 TCER: ADBox use case 2 with a Wazuh connection, TRP-027 TCER: ADBox UC scenario 2 with Wazuh

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.10 ADBox use case 2 without a Wazuh connection TST-010

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
No instance of Wazuh distribution running.

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 2 parameters. ./adbox.sh -u 2

Expected outcome

ADBox starts with Running AD driver with user configuration uc_2.yaml.
Output screen should show the message Could not establish a connection with OpenSearch.
And collect training data from the default file with message Returning data from file /home/root/siem-mtad-gat/siem_mtad_gat/assets/data/train/sample-alerts-train-2024-07.
The training should run for 10 epochs.
Training response should be seen on the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in historical mode.
Output screen should show message Could not establish a connection with OpenSearch.
And collect training data from default file with message The file '/home/root/siem-mtad-gat/siem_mtad_gat/assets/data/predict/sample-alerts-predict-2024-07-26' does not exist, returning all default data., depending upon the date it was run.
Prediction response should be seen in the output console.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-035 Offline Anomaly Detection

Child links: TRP-017 TCER: ADBox use case 2 without a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.11 ADBox use case 3 with a Wazuh connection TST-011

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.
Wazuh indexer RESTful API should be listening on port 9200.
2024-07-* index not empty.
TST-034 and TST-035 should succeed

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 3 parameters.

  ./adbox.sh -u 3

Expected outcome

ADBox starts with Running AD driver with user configuration uc_3.yaml.
The training should run for 10 epochs.
Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in batch mode with batch interval 5 (min).
Prediction response should be seen on the output console after every 5 minutes.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-027 ML-Based Anomaly Detection

Child links: TRP-011 TCER: ADBox use case 3 with a Wazuh connection, TRP-028 TCER: ADBox UC scenario 3 with Wazuh

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.12 ADBox use case 3 without a Wazuh connection TST-012

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
No instance of Wazuh distribution running.

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 3 parameters.

  ./adbox.sh -u 3

Expected outcome

ADBox starts with Running AD driver with user configuration uc_3.yaml.
Output screen should show the message Could not establish a connection with OpenSearch.
And collect training data from the default file with the message Returning data from file /home/root/siem-mtad-gat/siem_mtad_gat/assets/data/train/sample-alerts-train-2024-07.json.
The training should run for 10 epochs.
Train response should be seen on the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in batch mode with batch interval 5 (min).
Output screen should show the following messages:
- Could not establish a connection with OpenSearch.
- Prediction in run_mode.BATCH requires a connection with OpenSearch.
- No data found for given input.
- And the application should exit.

Parent links: SRS-027 ML-Based Anomaly Detection

Child links: TRP-016 TCER: ADBox use case 3 without a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.1

1.13 ADBox use case 4 with a Wazuh connection TST-013

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.0
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.
Wazuh indexer RESTful API should be listening on port 9200.
Wazuh agent configured to read Suricata logs.
"2024-03-*" not empty.
TST-034 and TST-035 should succeed

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 4 parameters.

./adbox.sh -u 4

Expected outcome

ADBox starts with Running AD driver with user configuration uc_4.yaml.
The training should run for 10 epochs.
Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in historical mode.
Prediction response should be seen in the output console.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-038 Joint Host-Network Training

Child links: TRP-012 TCER: ADBox use case 4 with a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.14 ADBox use case 4 without a Wazuh connection TST-014

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
No instance of Wazuh distribution running.

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 4 parameters.

./adbox.sh -u 4

Expected outcome

ADBox starts with Running AD driver with user configuration uc_4.yaml.
Output screen should show message Could not establish a connection with OpenSearch.
And collect training data from default file with message Returning data from file /home/root/siem-mtad-gat/siem_mtad_gat/assets/data/train/sample-alerts-train-2024-03.json.
The training should run for 10 epochs.
Training response should be seen on the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in historical mode.
Output screen should show message Could not establish a connection with OpenSearch.
And collect training data from default file with message The file '/home/root/siem-mtad-gat/siem_mtad_gat/assets/data/predict/wazuh-alerts-*.*-2024.07.22.json' does not exist, returning all default data., depending upon the date it was run.
Prediction response should be seen on the output console.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-038 Joint Host-Network Training

Child links: TRP-015 TCER: ADBox use case 4 without a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.15 ADBox use case 5 with a Wazuh connection TST-015

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.
Wazuh indexer RESTful API should be listening on port 9200.
Wazuh agent configured to read Suricata logs.
TST-034 and TST-035 should succeed

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 5 parameters. ./adbox.sh -u 5

Expected outcome

ADBox starts with Running AD driver with user configuration uc_5.yaml.
The training should run for 10 epochs.
Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in historical mode.
Prediction response should be seen on the output console.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-037 Anomaly-Based NIDS

Child links: TRP-013 TCER: ADBox use case 5 with a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.16 ADBox use case 5 without a Wazuh connection TST-016

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
No instance of Wazuh distribution running.

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with use case 5 parameters.

./adbox.sh -u 5

Expected outcome

ADBox starts with Running AD driver with user configuration uc_5.yaml.
Output screen should show message Could not establish a connection with OpenSearch.
And collect training data from default file with message Returning data from file /home/root/siem-mtad-gat/siem_mtad_gat/assets/data/train/sample-alerts-train-2024-03.json.
The training should run for 10 epochs.
Training response should be seen in the console.
Training outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.
Prediction starts after training with message Predicting in historical mode.
Output screen should show message Could not establish a connection with OpenSearch.
And collect training data from default file with message The file '/home/root/siem-mtad-gat/siem_mtad_gat/assets/data/predict/wazuh-alerts-*.*-2024.07.22.json' does not exist, returning all default data., depending upon the date it was run.
Prediction response should be seen in the output console.
Prediction outputs and artifacts should be available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id}/prediction folder.

Parent links: SRS-037 Anomaly-Based NIDS

Child links: TRP-014 TCER: ADBox use case 5 without a Wazuh connection

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.17 ADBox shipping install TST-017

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.

Test steps

Run the container siem-mtad-gat-container by executing the adbox script with shipping flag.

  ./adbox.sh -s

Expected outcome

CLI:

IDPS-ESCAPE ADBox shipping on
ADBox Shipper establishing connection to Wazuh...
ADBox shipper connected to Wazuh
Template for mtad_gat initialized
Exit shipper installation. Check ADBox templates and policy correct installation from Wazuh Dashboard!

Wazuh Dashboard* :

Indexer Management>Index Management>Templates check for presence of base templatesadbox_stream_template,adbox_stream_template_mtad_gat;
Indexer Management>Index Management>Templates>Component templates check for presence of base templatescomponent_template_mtad_gat;
Indexer Management>Index Management>State management policies check for presence of the policy adbox_detectors_rollover.

Parent links: SRS-049 Anomaly Shipping to Indexer

Child links: TRP-022 TCER: ADBox shipping install

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.18 ADBox Create detector data stream TST-018

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.
An instance of a Wazuh distribution should be running.

Test steps

Run the container siem-mtad-gat-container by executing the adbox use case 12 with shipping flag.

  ./adbox.sh -u 12 -s

Expected outcome

CLI:

Training model for 2 epochs

  IDPS-ESCAPE ADBox shipping on
  ADBox Shipper establishing connection to Wazuh...
  IDPS-ESCAPE ADBox driver running use case scenario configuration uc_12.yaml.
  Start training pipeline.
  Init Data managers.
  JSON file 'detector_input_parameters.json' saved at /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/1bda6dd3-0947-43e3-9ca2-bd3c711ae69f/input/detector_input_parameters.json.
  Data ingestion.
  Wazuh data ingestor establishing connection to Wazuh...

Historical prediction: the start time shall be the present day at '00:06:00Z' (notice window size is 6 and granularity 1min) and the end time/present timestamp rounded to the closest unit timestamp.

Start prediction pipeline. Detector: 1bda6dd3-0947-43e3-9ca2-bd3c711ae69f
Init Data managers.
Spot object 0 loaded.
Spot object 1 loaded.
...
Prediction response:
{'run_mode': 'HISTORICAL', 'detector_id': '1bda6dd3-0947-43e3-9ca2-bd3c711ae69f', 'start_time': '2024-11-25T00:06:00Z', 'end_time': '2024-11-25T16:58:00Z', 'results': []}
Prediction ended

Local storage:

Training outputs and artifacts available in the /home/root/siem-mtad-gat/siem_mtad_gat/assets/detector_models/{detector_id} folder.

Wazuh Dashboard:

When verifying the output using the dashboard vizualisations, remember that time shift due to TimeZone may apply.
Indexer Management>Index Management>Templates check if the template adbox_detector_mtad_gat_{detector_id} is there;
Indexer Management>Index Management>Templates> Component templates check if the templates component_template_{detector_id} is there;
Indexer Management>Data streams check if adbox_detector_mtad_gat_{detector_id} is there and contains at least a document. TST-18-detector-stream.png" width="80%" />

Parent links: SRS-042 Prediction Shipping Feature

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.19 ADBox Wazuh integration Dashboard TST-033

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
An instance of CyFORT-Wazuh distribution should be running.
A detector data stream adbox_detector_mtad_gat_{detector_id} available in Wazuh indexer

Test steps

A detailed description of the integration procedure can be found at docs/manual/dashboard_tutorial.md

Open Dashboard Management.
Select Dashboard Management>Index patterns and create a new index.
Add the data stream pattern using the.
Select timestamp as time field.
Finally, the pattern is created. The field names correspond to the prediction outcome fields.

Expected outcome

The pattern is created. The field names correspond to the prediction outcome fields.
The data can be navigated using Discover dashboard.

Parent links: SRS-043 AD Data Visualization

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	4
test_data	see referenced files
version	0.2

1.20 ADBox set up indexer host address TST-034

Preconditions and setup actions

ADBox repository https://github.com/AbstractionsLab/idps-escape.git cloned on the host.
Wazuh central component deployed.
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.

Test steps

Open the cloned ADBox repository
Open the /siem_mtad_gat/assets/secrets/wazuh_credentials.json
Set "host" as indexer's host address
Set "port" as indexer's port
Run

./adbox.sh -c

Expected outcome

Succesful connection

IDPS-ESCAPE ADBox checking connection with Wazuh/OpenSearch...
Wazuh data ingestor establishing connection to Wazuh...
Connection with Wazuh established successfully!

Parent links: SRS-017 Custom Data Source

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.21 ADBox change indexer credentials TST-035

Preconditions and setup actions

ADBox repository https://github.com/AbstractionsLab/idps-escape.git cloned on the host.
Wazuh central component deployed.
User with root privileges
Built image siem-mtad-gat:v0.1.4
No existing container named siem-mtad-gat-container should be running.

Test steps

Open the cloned ADBox repository
Open the /siem_mtad_gat/assets/secrets/wazuh_credentials.json
Update "username" as indexer's username
Update "password" as indexer's password
Run

./adbox.sh -c

Expected outcome

Succesful connection

IDPS-ESCAPE ADBox checking connection with Wazuh/OpenSearch...
Wazuh data ingestor establishing connection to Wazuh...
Connection with Wazuh established successfully!

Parent links: SRS-022 Indexer Credentials Update

Attribute	Value
platform	MacOS, Windows, GNU/Linux
execution_type	M
verification_method	T
complexity	2
test_data	see referenced files
version	0.2

1.22 Open prediction file of training data TST-037

Preconditions and setup actions

ADBox dev container running.
Wazuh central component deployed.
User with root privileges
At lease a trained detector.

Test steps

Open the cloned ADBox repository
Choose one of the detectors avaliable in siem_mtad_gat/assets/detector_models. E.g, siem_mtad_gat/assets/detector_models/9a447100-39d1-4e00-83fc-8c618444edf7.
Open siem_mtad_gat/frontend/viznotebook/result_visualizer.ipynb within dev container
Insert dector id in Variables and path to be modified
Run Notebook
Go to Running ADBox with a use-case>Training>Training output table

Expected outcome

Table showing prediction aver train data

Parent links: SRS-030 AD Results Visualization

Attribute	Value
platform	MacOS, Windows, GNU/Linux
execution_type	M
verification_method	I
release	alpha
complexity	2
test_data	see referenced files
version	0.2

1.23 Visualize train losses TST-038

Preconditions and setup actions

Wazuh central component deployed.
ADBox deployed
User with root privileges
At lease a trained detector.

Test steps

Open the cloned ADBox repository
Choose one of the detectors avaliable in siem_mtad_gat/assets/detector_models.
Open siem_mtad_gat/assets/detector_models/uuid/training/train_losses.png using system default software.

Expected outcome

Graph displaying train_losses.png

Parent links: SRS-031 Training Loss Visualization

Attribute	Value
platform	MacOS, Windows, GNU/Linux
execution_type	M
verification_method	I
release	alpha
complexity	1
test_data	see referenced files
version	0.2

1.24 Open prediction raw outcome TST-039

Preconditions and setup actions

Wazuh central component deployed.
ADBox deployed
User with root privileges
At lease a trained detector used for running prediction at least once (i.e., stored prediction data).

Test steps

Open the cloned ADBox repository
Choose one of the detectors avaliable in siem_mtad_gat/assets/detector_models.
Open siem_mtad_gat/assets/detector_models/uuid/prediction
Open a prediction file of the uc-x_predicted_anomalies_data-*.json using system default software.

Expected outcome

Prediction info store using json format. E.g.

{ "run_mode": "REALTIME", "detector_id": "563394be-5079-424d-b2ba-cfda0812cf88", "start_time": "2024-10-25T08:51:00Z", "end_time": "2024-10-25T08:52:00Z", "results": [ { "timestamp": "2024-10-25T08:51:00Z", "is_anomaly": false, "anomaly_score": 0.029846280813217163, "threshold": 0.12186630221790373, "Forecast_data.5mins_loadAverage_average": 0.1334819793701172, "Recon_data.5mins_loadAverage_average": 0.11187170445919037, "True_data.5mins_loadAverage_average": 0.1077537015080452, "A_Score_data.5mins_loadAverage_average": 0.029846280813217163, "Thresh_data.5mins_loadAverage_average": 0.12186630221790373, "A_Pred_data.5mins_loadAverage_average": 0.0 } ] }

Parent links: SRS-032 Predicted Anomalies Visualization

Attribute	Value
platform	MacOS, Windows, GNU/Linux
execution_type	Automated/Manual
verification_method	I
release	alpha
test_data	see referenced files
version	0.2

2.0 IDPS-ESCAPE foundation test cases

2.1 Suricata installation in a containerized environment TST-019

Preconditions and setup actions

Docker version 26.0.0
User with root privileges

Test steps

Create a new directory for suricata docker deployment.
In the directory download the suricata.yaml configuration file deployment/suricata/suricata.yaml.
Make the required changes in the configuration file as per the network settings of the respective system as explained deployment/suricata/suricata_installation.md#suricata-configuration-file.
In the directory download the Dockerfile deployment/suricata/Dockerfile.
Pull the ubuntu docker base image. sudo docker pull ubuntu
Build the docker image.

sudo docker build -t suricata-container .

Run the docker container.

sudo docker run --network=host --hostname=suricata-instance --name=suricatainstance
-it suricata-container

Expected outcome

Container named suricata-instance is running. Verify it by checking the running docker container with this command. sudo docker ps -a
Upon running the ps aux command inside the running container's bash, Suricata services can be seen as a running process. The container bash can be accessed by the following command. sudo docker exec -it suricata-instance bash
In the container's bash run the following command to read Suricata log files. tail /var/log/suricata/suricata.log

Parent links: SRS-008 Dockerized NIDS Deployment

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	3
test_data	see referenced files
version	0.2

2.2 Wazuh installation in a containerized environment TST-020

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0

Test steps

Clone the Wazuh docker repository in the system as mentioned in section

git clone https://github.com/wazuh/wazuh-docker.git -b v4.8.1

Navigate to the directory since it is a single node deployment.

cd wazuh-docker/single-node

Provide the group of certificates for secure communication. sudo docker-compose -f generate-indexer-certs.yml run --rm generator
Deploy Wazuh as single-node using docker-compose. sudo docker-compose up -d This could take some time since it would pull all the images.

Expected outcome

The following output should be visible on the screen after deployment in the background (with -d option)

✔ Container single-node-wazuh.indexer-1 Started
0.1s
✔ Container single-node-wazuh.manager-1 Started
0.1s
✔ Container single-node-wazuh.dashboard-1 Started

Run the following command and you should see 3 containers running. By sudo docker ps -a you shall see wazuh/wazuh-dashboard:4.8.1,wazuh/wazuh-manager:4.8.1,wazuh-indexer:4.8.1 .
The Wazuh dashboard is accessible through any browser, on the IP address of the system that it is deployed on.

Parent links: SRS-001 Centralized C&C Deployment

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	3
test_data	see referenced files
version	0.2

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

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0
Deployment of Wazuh Dashboard version 4.8.1 on the local monitoring machine inside a container
Deployment of Wazuh Indexer version 4.8.1 on the local monitoring machine inside a container
Deployment of Wazuh Manager version 4.8.1 on the local monitoring machine inside a container
GNU bash, version 5.1.16
No prior agent should already be running on the local monitoring machine

Test steps

On the Wazuh Dashboard, go to Endpoint Summary, and click on Deploy new agent.
Select the package to download and install on the respective system i.e., Linux DEB amd64.
Provide a server address and an optional name for the agent. The server address should be the IP address of the docker host address in the case of docker installation on the local monitoring machine. - The docker host address can be found by:

sudo docker network inspect bridge | grep Gateway

Install the agent by running the command that should be provided on the dashboard after entering the above information. For example, - download

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.8.1-1_arm64.deb && sudo WAZUH_MANAGER='172.17.0.1' WAZUH_AGENT_GROUP='default' WAZUH_AGENT_NAME='idps-escape-1' dpkg -i ./wazuh-agent_4.8.1-1_arm64.deb

Start the agent by running the three commands that should also be provided on the dashboard, i.e.,

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Expected outcome

The status of the agent should be “Started Wazuh agent.” Which is seen by running the command: sudo systemctl status wazuh-agent.
On the Wazuh Dashboard the Agent should appear as active in the summary page.

Parent links: SRS-003 HIDS Agent Deployment

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	3
test_data	see referenced files
version	0.2

2.4 Wazuh agent installation and enrollment: remote machine TST-022

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0
Deployment of Wazuh Dashboard version 4.8.1 on the local monitoring machine inside a container
Deployment of Wazuh Indexer version 4.8.1 on the local monitoring machine inside a container
Deployment of Wazuh Manager version 4.8.1 on the local monitoring machine inside a container
GNU bash, version 5.1.16
No prior agent should already be running on a REMOTE monitoring machine

Test steps

On the Wazuh Dashboard, go to Endpoint Summary, and click on Deploy new agent.
Select the package to download and install on the REMOTE MACHINE system i.e., Linux DEB amd64.
Provide a server address (this should be the machine hosting the manager) and an optional name for the agent. - The docker host address can be found by:

sudo docker network inspect bridge | grep Gateway

Install the agent by running the command in the REMOTE HOST that should be provided on the dashboard after entering the above information. For example, - download

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.8.1-1_arm64.deb && sudo WAZUH_MANAGER='172.17.0.1' WAZUH_AGENT_GROUP='default' WAZUH_AGENT_NAME='idps-escape-1' dpkg -i ./wazuh-agent_4.8.1-1_arm64.deb

Start the agent by running the three commands in the REMOTE HOST that should also be provided on the dashboard, i.e.,

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Expected outcome

The status of the agent should be “Started Wazuh agent.” Which is seen by running the command: sudo systemctl status wazuh-agent.
On the Wazuh Dashboard the Agent should appear as active in the summary page.

Parent links: SRS-023 Agent Registration Process

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	3
test_data	see referenced files
version	0.2

2.5 Wazuh agent deletion and uninstallation TST-023

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager
Wazuh API Token
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)

Test steps

Using the Wazuh API Token, send a DELETE request through the Wazuh API to the Wazuh manager. The request should also contain the IDs of the agents to be deleted.

curl -k -X DELETE "https://[Wazuh Server Address]:55000/agents?pretty=true&older_than=0s&agents_list=[Comma separated agent IDs]&status=all"
-H "Authorization: Bearer $TOKEN"

Uninstall the agent by running the following commands.

sudo apt-get remove --purge wazuh-agent
sudo systemctl disable wazuh-agent
sudo systemctl daemon-reload

Expected outcome

After deleting the agent, the agent should not be visible in the list of agents on the Wazuh Dashboard.
The agent should also not be present in the list of available agents on the machine, which can be checked by the following command. sudo /var/ossec/bin/manage_agents -l
After uninstalling the agent, no command regarding the agent should work.
The agent removal can also be verified from the Wazuh manager.

Access the bash of the container which is running the Wazuh Manager. sudo docker exec -it [Container name or ID of Wazuh Manager] bash
Run the command to access the Agent Manager. /var/ossec/bin/manage_agents
The removal can be confirmed by entering L and pressing ENTER to verify its absence from the Available Agents listing.

Parent links: SRS-004 HIDS Agent Management

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	3
test_data	see referenced files
version	0.2

2.6 Wazuh agent unenrollment TST-024

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)

Test steps

Access the bash of the container which is running the Wazuh Manager.

sudo docker exec -it [Container name or ID of
Wazuh Manager] bash

Run the command to access the Agent Manager. /var/ossec/bin/manage_agents
Press <R> which is the option for removing and agent and press enter.
Enter the ID of the agent to be removed and unenroll from the manager. e. Confirm the removal action by pressing <Y> and enter.

Expected outcome

After confirming the output should be a confirmation message, "Agent ID removed".
After deleting the agent, the agent should not be visible in the list of agents on the Wazuh Dashboard.
The agent should also not be present in the list of available agents on the machine, which can be checked by the following command. sudo /var/ossec/bin/manage_agents -l

Parent links: SRS-004 HIDS Agent Management

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	2
test_data	see referenced files
version	0.2

2.7 Suricata and Wazuh Integration TST-025

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)
Deployment of Suricata version 7.0.3 on the local monitoring machine inside a container
GNU nano, version 6.2
curl version 7.81.0

Test steps

Edit the configuration file of the Wazuh agent to make it able to read Suricata logs. sudo nano /var/ossec/etc/ossec.conf
Add the suricata eve logs the end of the file, before the last </ossec_config> closing tag.

<ossec_config>
...
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>

Remove the Suricata container. sudo docker rm suricata-instance
Run the Suricata container again with adding arguments to create docker volumes.

sudo docker run -v
/var/log/suricata:/var/log/suricata --network=host
--hostname=suricata-instance --name=suricatainstance
-d suricata-container

Restart the Wazuh agent

sudo systemctl restart wazuh-agent

Generate some malicious network traffic by sending a curl request to the following tool.

curl -sSL
https://raw.githubusercontent.com/3CORESec/testmynids.org/master/tmNIDS -o /tmp/tmNIDS && chmod +x /tmp/tmNIDS && /tmp/tmNIDS

Enter any number from 1 to 11 to generate the respective traffic.
On the Wazuh dashboard, filter the alerts to see the events particularly generated by Suricata. This is done by Threat Hunting > Add Filter. And to create the filter, in the Field dropdown, select rule.groups, in the operator dropdown, select is and in the Value, write suricata.

Expected outcome

-The alert generated by Suricata for the malicious traffic should be seen on the Wazuh Dashboard Threat Hunting. - After filter application, all alerts generated by suricata should be visible.

Parent links: SRS-010 Centralized Threat Management

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	3
test_data	see referenced files
version	0.2

2.8 Port mirroring for remote machines TST-026

Preconditions and setup actions

Ubuntu 22.04.4 LTS (Machine 1, central monitoring host)
Ubuntu 22.04.4 LTS (Machine 2, target host or the remote machine)
Prerequisites for Machine 1:
- tcpdump version 4.99.1
- User with root privileges
Prerequisites for Machine 2:
- User with root privileges
- ping from iputils 20211215
- GNU bash, version 5.1.16
- No existing tunnel is configured from machine 2 to machine 1
Test steps
1. Create a GRE tunnel from machine 2 to machine 1 and mirror all the ingress and egress (incoming and outgoing) network traffic generated on machine 2 to machine 1. Using the procedure describe in deployment/remote_monitoring/remote_monitoring.md.

From machine 2, send some ICMP echo request packets to machine 1.

ping -c3 [IP of the capture interface of machine
1]

On machine 1, use tcpdump to capture network traffic on the default interface.

sudo tcpdump -n -i [Capture interface of machine
1]

Expected outcome

tcpdump output should show that machine 1 receives both the ingress and egress ICMP packets from machine 2, encapsulated within GRE packets

Parent links: SRS-007 Raw Traffic Capture

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	A
release	alpha
complexity	4
test_data	see referenced files
version	0.2

2.9 Traffic monitoring on Wazuh (local) TST-027

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)
Deployment of Suricata version 7.0.3 on the local monitoring machine inside a container
GNU nano, version 6.2
curl version 7.81.0
Wazuh agent configured to integrate with Suricata

Test steps

Generate some malicious network traffic on the monitored machine by sending a curl request to the following tool.

curl -sSL
https://raw.githubusercontent.com/3CORESec/testmynids.org/master/tmNIDS -o /tmp/tmNIDS && chmod +x /tmp/tmNIDS && /tmp/tmNIDS

Enter any number from 1 to 11 to generate the respective traffic on the console.

Expected outcome

The alert generated by Suricata for the malicious traffic should be seen on the Wazuh Dashboard.

Parent links: SRS-011 Network Event Visualization

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	4
test_data	see referenced files
version	0.2

2.10 Traffic monitoring on Wazuh (remote) TST-028

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager in remote machine
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)
Deployment of Suricata version 7.0.3 on the remote monitoring machine inside a container
GNU nano, version 6.2
curl version 7.81.0
Wazuh agent configured to integrate with Suricata
GRE tunnel created from the remote machine to the local monitoring machine which mirrors all the ingress and egress network traffic from the remote machine to the local monitoring machine

Test steps

Generate some malicious network traffic on the remote monitored machine by sending a curl request to the following tool. curl -sSL https://raw.githubusercontent.com/3CORESec/testmynids.org/master/tmNIDS -o /tmp/tmNIDS && chmod +x /tmp/tmNIDS && /tmp/tmNIDS
Enter any number from 1 to 11 to generate the respective traffic on the console.
On the Wazuh dashboard, filter the alerts to see the events particularly related to the remote machine. This is done bya adding a filter. And to create the filter, in the Field dropdown, select data.tunnel.src_ip, in the operator dropdown, select is and in the Value, write the IP of the capture interface of the remote machine where the GRE tunnel was created.

Note that after creating the tunnel there could be a possible delay of some minutes between the creation of the tunnel and the display of the events on the Wazuh dashboard.

Expected outcome

Step 2.

The alert generated by Suricata for the malicious traffic should be seen on the Wazuh Dashboard.

Step 3.

The alert generated by Suricata for the malicious traffic should be seen on the Wazuh Dashboard.
The filter application should show the Suricata alert for the test traffic that was run.

Parent links: SRS-011 Network Event Visualization

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	4
test_data	see referenced files
version	0.2

2.11 Changing password for Wazuh indexer users TST-029

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)
Deployment of Suricata version 7.0.3 on the local monitoring machine inside a container
GNU nano, version 6.2

Test steps

The change password procedure is more detailed in deployment/wazuh/change_passwords.md.

Part 1: Genereate Hash

Stop the deployment stack if it's running. From wazuh repository:

sudo docker-compose down

Run the following command to generate the hash of the new password. Once the container launches, input the new password and press Enter.

sudo docker run --rm -ti wazuh/wazuhindexer:4.8.1 bash /usr/share/wazuhindexer/plugins/opensearchsecurity/tools/hash.sh

Copy the generated hash.
Open the config/wazuh_indexer/internal_users.yml file. Locate the block for the user for whom the password is being changed for.

Part 2: Set the new password.

In the docker-compose.yml file, replace all instances of the old password with the new one.

Part 3: Apply changes

Start the deployment stack.

sudo docker-compose up -d

Enter the container bash.

sudo docker exec -it [Name or ID of the Wazuh Indexer container] bash

Set the following variables:

export INSTALLATION_DIR=/usr/share/wazuhindexer
CACERT=$INSTALLATION_DIR/certs/root-ca.pem
KEY=$INSTALLATION_DIR/certs/admin-key.pem
CERT=$INSTALLATION_DIR/certs/admin.pem
export JAVA_HOME=/usr/share/wazuhindexer/jdk

Wait for the Wazuh indexer to initialize properly. The waiting time can vary from two to five minutes. It depends on the size of the cluster, the assigned resources, and the speed of the network. Then, run the securityadmin.sh script to apply all changes.

bash /usr/share/wazuhindexer/plugins/opensearchsecurity/tools/securityadmin.sh -cd /usr/share/wazuh-indexer/opensearchsecurity/ -nhnv -cacert $CACERT -cert $CERT -key $KEY -p 9200 -icl

Exit the Wazuh indexer container and login with the new credentials on the Wazuh dashboard.
Enter any number from 1 to 11 to generate the respective traffic on the console.

Expected outcome

-The Wazuh dashboard should show "Invalid username or password. Please try again." error while trying to login with the old password. - The Wazuh dashboard should be accessible through the new password.

Parent links: SRS-016 Indexer Credential Management

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	Automated/Manual
verification_method	I
release	alpha
complexity	4
test_data	see referenced files
version	0.2

2.12 Changing password for Wazuh API users TST-030

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)
Deployment of Suricata version 7.0.3 on the local monitoring machine inside a container
GNU nano, version 6.2

Test steps

The change password procedure is more detailed in deployment/wazuh/change_passwords.md.

Part 1: Genereate Hash

Stop the deployment stack if it's running. From wazuh repository:

sudo docker-compose down

Run the following command to generate the hash of the new password. Once the container launches, input the new password and press Enter.

sudo docker run --rm -ti wazuh/wazuhindexer:4.8.1 bash /usr/share/wazuhindexer/plugins/opensearchsecurity/tools/hash.sh

Copy the generated hash.
Open the config/wazuh_indexer/internal_users.yml file. Locate the block for the user for whom the password is being changed for.

Part 2: Set the new password.

In the docker-compose.yml file, replace all instances of the old password with the new one at API_PASSWORD occurrence.

Part 3: Apply changes

Start the deployment stack.

sudo docker-compose up -d

Expected outcome

Trying to obtain Wazuh API token using the old password, which can be done in the following way (make sure that the password is within inverted quotes). TOKEN=$(curl -u wazuh-wui:"MyS3cr37P450r.*-" -k -X POST "https://172.17.0.1:55000 /security/user/authenticate?raw=true"); echo $TOKEN This hould return the following error. {"title": "Unauthorized", "detail": "Invalid credentials"}
The token can be successfully obtained using the new password.

Parent links: SRS-016 Indexer Credential Management

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I/T
release	alpha
complexity	4
test_data	see referenced files
version	0.2

2.13 Wazuh filters using the RESTful API TST-031

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager in remote machine
Wazuh agent installed and enrolled with the manager in local machine
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)
Deployment of Suricata version 7.0.3 on the remote monitoring machine inside a container
GNU nano, version 6.2
curl version 7.81.0
Wazuh agent configured to integrate with Suricata
GRE tunnel created from the remote machine to the local monitoring machine which mirrors all the ingress and egress network traffic from the remote machine to the local monitoring machine

Test steps

Get the Wazuh API Token.
Run the following query to apply the filter: curl -G "q=data.tunnel.src_ip=[IP of the tunnel source interface]" -k -X GET "https://[Wazuh Manager IP address]:55000/manager/logs?limit=500&pretty=true" -H "Authorization: Bearer $TOKEN"

Expected outcome

The output of the query should show JSON decoded logs and in the last there should be a success message. "message: Logs were successfully read, error: 0"

Parent links: SRS-024 Event Querying Capability

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	4
test_data	see referenced files
version	0.2

2.14 Wazuh filters using the Wazuh Dashboard TST-032

Preconditions and setup actions

Docker version 26.0.0
User with root privileges
Docker Compose version v2.25.0 curl version 7.81.0
Wazuh agent installed and enrolled with the manager in remote machine
Wazuh agent installed and enrolled with the manager in local machine
Deployment of Wazuh Dashboard on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Indexer on the local monitoring machine inside a container (4.8.1)
Deployment of Wazuh Manager on the local monitoring machine inside a container (4.8.1)
Wazuh agent configured to integrate with Suricata
GRE tunnel created from the remote machine to the local monitoring machine which mirrors all the ingress and egress network traffic from the remote machine to the local monitoring machine

Test steps

On the Wazuh dashboard navigate to Threat Hunting and filter by data.tunnel.src_ip:[IP remote machine].

Expected outcome

The output of the query should show JSON decoded logs and in the last there should be a success message. "message: Logs were successfully read, error: 0"

Parent links: SRS-011 Network Event Visualization

Attribute	Value
platform	Ubuntu 22.04.4 LTS
execution_type	M
verification_method	I
release	alpha
complexity	2
test_data	see referenced files
version	0.2

2.15 Map a detected event to MITRE ATT&CKS TST-036

Preconditions and setup actions

Wazuh central component deployed.
Presence of alerts collected in Wazuh indexer.

Test steps

Open Wazuh Dashboard
Go to Threat Hunting > Events> Add Filter and choose rule.mitre.id exists.
Inspect filtered output (possibly extend time interval for more results).

Expected outcome

In json rule.mitre.id key should include the matching MITRE ID. E.g. T1078, T1021

"mitre": {
      "technique": [
        "Valid Accounts",
        "Remote Services"
      ],
      "id": [
        "T1078",
        "T1021"
      ],
      "tactic": [
        "Defense Evasion",
        "Persistence",
        "Privilege Escalation",
        "Initial Access",
        "Lateral Movement"
      ]
    },
    "id": "5715",
    "gpg13": [
      "7.1",
      "7.2"
    ]
  }

Parent links: SRS-025 MITRE ATT&CK Mapping

Attribute	Value
platform	MacOS, Windows, GNU/Linux
execution_type	Automated/Manual
verification_method	I
release	alpha
complexity	2
test_data	see referenced files
version	0.2

2.16 Visualize IDPS-ESCAPE high level architecture TST-040

Preconditions and setup actions

A copy of ADBox project repository

Test steps

Open the docs/traceability/HARC.html file using the browser

Expected outcome

Wab page displaying IDPS architecture diagrams

Parent links: SRS-045 High-Level Architecture Overview

Attribute	Value
platform	MacOS, Windows, GNU/Linux
execution_type	M
verification_method	I
release	alpha
complexity	1
test_data	see referenced files
version	0.2

3.0 RADAR test case specifications

3.1 Setup RADAR foundation TST-041

Preconditions and setup actions

A test controller host/node is available:
- A Linux machine/VM (the Ansible control node) is available to the tester.
- OS: recent GNU/Linux distribution, preferably an Ubuntu distribution (22.04+).
A second test node (accessible via the controller node) is available: GNU/Linux distro e.g. Debian GNU/Linux 13 (trixie)
Ansible is installed on the controller host under the root account:
- Location: install Ansible only on the controller node.
- Installation reference:
  - if pipx is available, follow the instruction` in Ansible Installation Documentation using pipx.
  - otherwise, follow the official instructions for Linux distributions.
  - Minimum version: Ansible 2.15+.
Targeted Wazuh manager and agent versions: 4.14.1
Environment values such as OS_URL, OS_USER, OS_PASS, DASHBOARD_URL, DASHBOARD_USER, DASHBOARD_PASS and SMTP credentials are available to the tester. The tester has network access (SSH) from the test controller node to controlled endpoints.
If either the Wazuh agent (aka agent) or the Wazuh manager (aka manager) is chosen to be remote:
- the remote agent/manager needs to have Docker and Docker Compose installed following the official documentations for Docker and Docker Compose.
- an available user in remote agent or manager with sudo access, and tester needs to have SSH access to the user from test controller host.
If the agents are to be deployed on remote nodes, the Wazuh agents must be installed in the monitored endpoints using the official documentation.
The agent must be registered with the Wazuh manager following the official documentation.
The DECIPHER Stack (DECIPHER, FlowIntel and MISP) is deployed and reachable from the Wazuh manager. The validated version is available in the DECIPHER folder of the SATRAP-DL repository, tested against v0.4 of SATRAP-DL. Once deployed, configure the DECIPHER_BASE_URL variable in .env to point to the running DECIPHER instance.

Test steps

In the controller host, the working directory is required to be radar:

cd radar

Set .env file with required variables:

# =======================
# OpenSearch Configuration
# =======================
OS_URL=https://192.168.5.4:9200  # Change accordingly
OS_USER=admin
OS_PASS=SecretPassword
OS_VERIFY_SSL="/app/config/wazuh_indexer_ssl_certs/root-ca.pem"

DASHBOARD_URL=https://192.168.5.4  # Change accordingly
DASHBOARD_USER=admin
DASHBOARD_PASS=SecretPassword
DASHBOARD_VERIFY_SSL="/app/config/wazuh_indexer_ssl_certs/root-ca.pem"

WAZUH_API_URL=https://192.168.5.4:55000  # Change accordingly
WAZUH_AUTH_USER=wazuh-wui
WAZUH_AUTH_PASS=MyS3cr37P450r.*-

WAZUH_AGENT_VERSION=4.14.1-1
WAZUH_MANAGER_ADDRESS=192.168.5.4  # Change accordingly

WEBHOOK_NAME="RADAR_Webhook"
WEBHOOK_URL=http://192.168.5.4:8080/notify  # Change accordingly

# =======================
# Logging
# =======================

AR_LOG_FILE=/var/ossec/logs/active-responses.log
AR_RISK_CONFIG=/var/ossec/active-response/bin/ar.yaml

# =======================
# SMTP
# =======================

SMTP_HOST=SMTP_HOST # Change accordingly
SMTP_PORT=SMTP_PORT # Change accordingly
SMTP_USER=SMTP_USER # Change accordingly
SMTP_PASS=SMTP_PASS # Change accordingly
EMAIL_TO=RECEIVER_EMAIL@example.com # Change accordingly
SMTP_STARTTLS=yes

# =======================
# DECIPHER
# =======================

DECIPHER_BASE_URL=http://localhost:8000  # Change IP accordingly
DECIPHER_VERIFY_SSL=VERIFY_SSL           # Change IP accordingly
DECIPHER_TIMEOUT_SEC=30                  # Change IP accordingly

In case either the agent or the manager is remote:

3.1. Change inventory.yaml based on remote agent/manager data, user credentials and docker container names. Change is needed:
- for remote agents, the endpoint part wazuh_agents_ssh must be configured.
- for a remote manager, the endpoint part wazuh_manager_ssh must be configured.
- in each of the above two, you may need to define a ansible_ssh_private_key_file: <path-to-ssh-key> attribute (to enable access from the control node to the controlled node)
3.2. Create a vault for each host in inventory.yaml (IMPORTANT: the vault name and host name must match):
- for remote agents: ansible-vault create host_vars/edge.vm.yml
- for remote manager: ansible-vault create host_vars/mgr.remote.yml
3.3. Assign a vault password and set sudo password: ansible_become_password: <selected-user-sudo-password>
Existence of Wazuh manager on targeted endpoint (local/remote) (signaled via manager_exists flag used by build-radar.sh):

4.1. In case the manager does not exist, certificates must be issued matching the MANAGER_IP and INDEXER_IP according to the documentation in config/wazuh_indexer_ssl_certs/README.md; in short, once you have adapted config/certs.yml according to your endpoints (IP address and container name), from within the config folder, run

docker run --rm -it -v "PWD/certs.yml:/config/certs.yml:ro"−v"PWD/certs.yml:/config/certs.yml:ro" -v "PWD/certs.yml:/config/certs.yml:ro"−v"PWD/wazuh_indexer_ssl_certs:/certificates" wazuh/wazuh-certs-generator:0.0.2

4.2. If the manager is already in place, certificates must be copied into config/wazuh_indexer_ssl_certs.

Expected outcome

In the controller host, the vaults are created and SSH access is set correctly:
- if the agent is chosen to be remote:
3.1 The vault is created and exists in host_vars/: ansible-vault view host_vars/edge.vm.yml

3.2 Ansible reaches the SSH group: ansible -i inventory.yaml wazuh_agents_ssh -m ping --ask-vault-pass
- if the manager is chosen to be remote:
3.1 The vault is created and exists in host_vars/: ansible-vault view host_vars/mgr.remote.yml

3.2 Ansible reaches the SSH group: ansible -i inventory.yaml wazuh_manager_ssh -m ping --ask-vault-pass
The certificates are available under config/wazuh_indexer_ssl_certs/:

ls config/wazuh_indexer_ssl_certs/

Child links: TRP-030 TCER: Setup RADAR foundation

Attribute	Value
platform	GNU/Linux (Ubuntu+Debian)
execution_type	Manual
verification_method	T
release	alpha
complexity	3
test_data	see referenced files
version	0.8

3.2 Build suspicious login TST-042

Preconditions and setup actions

RADAR is setup according to TST-041

Test steps

In the controller host, the working directory is required to be radar:

cd radar

Build RADAR with SCENARIO_NAME suspicious_login, if manager is local then the command should be run with sudo:

./build-radar.sh suspicious_login --agent remote/local --manager remote/local --manager_exists true/false

In this step, please choose options according to your setup:

--agent Where agents live: local (docker-compose.agents.yml) | remote (SSH endpoints)
--manager Where manager lives: local (docker-compose.core.yml) | remote (SSH host)
--manager_exists Whether the manager already exists at that location:
- true : do not bootstrap a manager
- false : bootstrap a manager
--ssh-key Optional: path to the SSH private key used for remote manager/agent access. If not provided, defaults to: $HOME/.ssh/id_ed25519

To clean up the test environment only after a successful test execution AND a successful execution of TST-046:

In case the manager is chosen to be local, in the controller node/host, run these commands:

./stop-radar.sh --manager local

In case the manager is chosen to be remote and bootstrapped, in the controller node/host, run these commands:

./stop-radar.sh --manager remote

In case the agent is chosen to be local, in the controller node/host, run this command:

./stop-radar.sh --agent local

In case the agent is chosen to be remote, in the controller node/host, run this command:

./stop-radar.sh --agent remote

Expected outcome

2. Check the setup

In Wazuh Manager

Connect to the Wazuh manager to be able to perform the following verifications:

docker exec -it wazuh.manager bash

2.1 Custom 0310 SSH decoder deployed; verify this by running

ls -l /var/ossec/etc/decoders/0310-ssh.xml

to ensure that 0310-ssh.xml exists, and is owned by root:wazuh, mode 0640.

2.2 Custom 0310 SSH decoder should contain the decoders sshd-*-with-radar (e.g., including RADAR fields like ASN, country, geo_velocity)

tail -n20 /var/ossec/etc/decoders/0310-ssh.xml

to ensure that RADAR enrichment fields will be parsed.

2.3 Default 0310 decoder is excluded in ossec.conf; verify via

grep '<decoder_exclude>0310-ssh_decoders.xml</decoder_exclude>' /var/ossec/etc/ossec.conf

to ensure that a <decoder_exclude>0310-ssh_decoders.xml</decoder_exclude> line appears (ideally once) under <ruleset>.

2.4 RADAR rules for suspicious_login are in /var/ossec/etc/rules/; verify via

ls -al /var/ossec/etc/rules/ | grep "suspicious-login"

to ensure rules for suspicious login exists.

2.5 Suspicious login rules are bound to active responses; verify via

grep -A5 'radar_ar' /var/ossec/etc/ossec.conf

to ensure that suspicious login rule ID(s) references the intended <group>, <options> or <active-response> that trigger radar_ar.py.

2.6 Agent is registered with the manager; verify via

/var/ossec/bin/agent_control -l

to ensure that an entry exists for each agent.

2.7 Agent configurations are in place; verify via

cat /var/ossec/etc/shared/default/agent.conf | grep "suspicious_login"

to ensure that agent configurations for suspicious login exists.

2.8 Wazuh Manager is running after restart; verify via

/var/ossec/bin/wazuh-control status

to ensure that status output indicates the manager is running with no error messages.

In endpoints running agents

2.9 RADAR helper directory and script are installed on the SSH agent host; verify via

ls -ld /opt/radar
ls -l /opt/radar/radar-helper.py

to ensure /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

2.10 radar-helper.service systemd unit is installed, enabled, and running; verify via

systemctl status radar-helper.service

to ensure the service is active.

Post-test cleanup

3 Check the cleanup after successful validations, the command output should be empty:

docker ps

Parent links: SRS-051 RADAR scenario: suspicious login, SRS-061 RADAR: Tiered active response logic

Child links: TRP-031 TCER: Build suspicious login

Attribute	Value
platform	GNU/Linux (Ubuntu+Debian)
execution_type	Manual
verification_method	T
release	alpha
complexity	3
test_data	see referenced files
version	0.8

3.3 Build non-whitelist GeoIP detection TST-043

Preconditions and setup actions

RADAR is setup according to TST-041

Test steps

In the controller host, the working directory is required to be radar:

cd radar

Build RADAR with SCENARIO_NAME geoip_detection, if manager is local then the command should be run with sudo:

sudo ./build-radar.sh geoip_detection --agent remote/local --manager remote/local --manager_exists true/false

In this step, please choose options according to your setup:

--agent Where agents live: local (docker-compose.agents.yml) | remote (SSH endpoints)
--manager Where manager lives: local (docker-compose.core.yml) | remote (SSH host)
--manager_exists Whether the manager already exists at that location:
- true : do not bootstrap a manager
- false : bootstrap a manager
--ssh-key Optional: path to the SSH private key used for remote manager/agent access. If not provided, defaults to: $HOME/.ssh/id_ed25519

To clean up the test environment only after a successful test execution AND a successful execution of TST-047:

In case the manager is chosen to be local, in the controller node/host, run these commands:

./stop-radar.sh --manager local

In case the manager is chosen to be remote and bootstrapped, in the controller node/host, run these commands:

./stop-radar.sh --manager remote

In case the agent is chosen to be local, in the controller node/host, run this command:

./stop-radar.sh --agent local

In case the agent is chosen to be remote, in the controller node/host, run this command:

./stop-radar.sh --agent remote

Expected outcome

2. Check the setup

In Wazuh Manager

Connect to the Wazuh manager to be able to perform the following verifications:

docker exec -it wazuh.manager bash

2.1 Whitelist file exists

ls -l /var/ossec/etc/lists/whitelist_countries

to ensure that /var/ossec/etc/lists/whitelist_countries exists, its contents match the scenario’s whitelist_countries, and its owner is root:wazuh, with mode 0664.

2.2 ossec.conf has <list> entry for whitelist_countries

grep -n 'whitelist_countries' /var/ossec/etc/ossec.conf

to ensure under <ruleset>, there is a <list>...whitelist_countries</list> entry with the RADAR marker for geoip_detection.

2.3 Custom 0310 SSH decoder deployed; verify this by running

ls -l /var/ossec/etc/decoders/0310-ssh.xml

to ensure that 0310-ssh.xml exists, and is owned by root:wazuh, mode 0640.

2.4 Default 0310 decoder is excluded in ossec.conf; verify via

grep '<decoder_exclude>0310-ssh_decoders.xml</decoder_exclude>' /var/ossec/etc/ossec.conf

to ensure that a <decoder_exclude>0310-ssh_decoders.xml</decoder_exclude> line appears (ideally once) under <ruleset>.

2.5 RADAR rules for geoip_detection exist

ls -al /var/ossec/etc/rules/ | grep "geoip-detection"

to ensure rules for geoip detection exists.

2.6 GeoIP non-whitelist rules are bound to active responses

grep -A10 'radar_ar' /var/ossec/etc/ossec.conf

to check GeoIP non-whitelist rule ID(s) reference the correct <active-response>.

2.7 Active response config files are in place

ls -al /var/ossec/active-response/bin/ | grep "ar.yaml"
ls -al /var/ossec/active-response/bin/ | grep "pyflowintel"

to check active response config files are copied.

2.8 Agent configurations are in place; verify via

cat /var/ossec/etc/shared/default/agent.conf | grep "suspicious_login"

to ensure that agent configurations for geoip detection exists.

In endpoints running agents

2.9 RADAR helper directory and script are installed on the SSH agent host.

ls -ld /opt/radar
ls -l /opt/radar/radar-helper.py

to check /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

2.10 radar-helper.service systemd unit is installed, enabled, and running.

systemctl status radar-helper.service

to check that the service is active.

Post-test cleanup

3 Check the cleanup after successful validations, the command output should be empty:

docker ps

Parent links: SRS-055 RADAR scenario: Geo-IP AC via whitelisting, SRS-061 RADAR: Tiered active response logic

Child links: TRP-032 TCER: Build non-whitelist GeoIP detection

Attribute	Value
platform	GNU/Linux (Ubuntu+Debian)
execution_type	Manual
verification_method	T
release	alpha
complexity	3
test_data	see referenced files
version	0.8

3.4 Build log volume abnormal growth TST-044

Preconditions and setup actions

RADAR is setup according to TST-041

Test steps

The working directory is required to be radar:

cd radar

Build RADAR with SCENARIO_NAME log_volume, if manager is local then the command should be run with sudo:

./build-radar.sh log_volume --agent remote/local --manager remote/local --manager_exists true/false

In this step, please choose options according to your setup:

--agent Where agents live: local (docker-compose.agents.yml) | remote (SSH endpoints)
--manager Where manager lives: local (docker-compose.core.yml) | remote (SSH host)
--manager_exists Whether the manager already exists at that location:
- true : do not bootstrap a manager
- false : bootstrap a manager
--ssh-key Optional: path to the SSH private key used for remote manager/agent access. If not provided, defaults to: $HOME/.ssh/id_ed25519

To clean up the test environment only after a successful test execution AND a successful execution of TST-048:

In case the manager is chosen to be local, in the controller node/host, run these commands:

./stop-radar.sh --manager local

In case the manager is chosen to be remote and bootstrapped, in the controller node/host, run these commands:

./stop-radar.sh --manager remote

In case the agent is chosen to be local, in the controller node/host, run this command:

./stop-radar.sh --agent local

In case the agent is chosen to be remote, in the controller node/host, run this command:

./stop-radar.sh --agent remote

Expected outcome

Check the setup:

2. Check the setup

In Wazuh Manager

Connect to the Wazuh manager to be able to perform the following verifications:

docker exec -it wazuh.manager bash

2.1 RADAR snippet for log_volume is present in ossec.conf

grep -n 'RADAR: log_volume' /var/ossec/etc/ossec.conf

to check ossec.conf contains a RADAR: log_volume BEGIN/END block with the log_volume-related settings.

2.2 RADAR decoders for log_volume exist

ls -al /var/ossec/etc/decoders/ | grep "log-volume"

to check decoders for log volume are in place.

2.3 RADAR rules for log_volume exist

ls -al /var/ossec/etc/rules/ | grep "log-volume"

to check rules for log volume are in place.

2.4 OpenSearch template radar-log-volume is present

curl -u "$OS_USER:$OS_PASS" -k "$OS_URL/_index_template/radar-log-volume?pretty"

to ensure HTTP status is 200 and the template JSON exists with mappings for log_bytes as a numeric type.

2.5 log_volume rules are bound to active responses

grep -A5 'radar_ar' /var/ossec/etc/ossec.conf

to check Log volume anomaly rule ID(s) reference radar_ar.py as intended.

2.6 Agent configurations are in place; verify via

cat /var/ossec/etc/shared/default/agent.conf | grep "log_volume_metric"

to ensure that agent configurations for log volume exists.

In endpoints running agents

2.7 RADAR helper directory and script are installed on the SSH agent host.

ls -ld /opt/radar
ls -l /opt/radar/radar-helper.py

to check /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

2.8 radar-helper.service systemd unit is installed, enabled, and running.

systemctl status radar-helper.service

to check that the service is active.

Post-test cleanup

3 Check the cleanup after successful validations, the command output should be empty:

docker ps

Parent links: SRS-056 RADAR scenario: log size change, SRS-061 RADAR: Tiered active response logic

Child links: TRP-033 TCER: Build log volume abnormal growth

Attribute	Value
platform	GNU/Linux (Ubuntu+Debian)
execution_type	Manual
verification_method	T
release	alpha
complexity	2
test_data	see referenced files
version	0.8

3.5 Run RADAR for log volume abnormal growth TST-045

Preconditions and setup actions

RADAR is built according to the scenario TST-044.

Test steps

The working directory is required to be radar:

cd radar

After building the scenario, wait about 3 minutes for index creation and correct mapping. Then, run RADAR with SCENARIO_NAME log_volume

./run-radar.sh log_volume

Expected outcome

In Wazuh Dashboard:

2.1. The detector LOG_VOLUME_DETECTOR is created in Wazuh Dashboard with the correct configurations. In Anomaly Detection menu the created detector should be visible. The correct configurations can be found in config.yaml under log_volume key.

2.2. The monitor is created in Wazuh Dashboard with the trigger to the webhook. In Alerting menu created Monitor should be listed under Monitors tab.

Parent links: SRS-056 RADAR scenario: log size change, SRS-061 RADAR: Tiered active response logic

Child links: TRP-034 TCER: Run RADAR for log volume abnormal growth

Attribute	Value
platform	GNU/Linux (Ubuntu+Debian)
execution_type	Manual
verification_method	T
release	alpha
complexity	3
test_data	see referenced files
version	0.8

3.6 DECIPHER-RADAR detection validation for Suspicious login TST-046

Preconditions and setup actions

RADAR is setup according to TST-042

Test steps

Configure common and suspicious_login parts in /radar/radar-test-framework/simulate/scenarios/config.yaml.
From the radar/, run: bash ./simulate-radar.sh suspicious_login --agent remote

Expected outcome

2.1. The ansible playbook executes successfully.

2.2. In the Wazuh Dashboard Discovery page, at least one of rule IDs 210012, 210013, 210020, or 210021 is triggered for the remote agent.

2.3. In Wazuh manager check alert tier:

grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Expected risk_score range is between 0.0 and 1.0.
If tier is:
- Tier 0:
  - No email is received at EMAIL_TO.
  - No FlowIntel case is created.
  - No mitigation command appears in /var/ossec/logs/active-responses.log.
- Tier 1:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier, and FlowIntel case URL.
  - A FlowIntel case is created and can be accessed at the Flowintel URL included in the email notification.
  - The FlowIntel case contains relevant information about the suspicious login event, related events found in MISP, and a breakdown of the risk score including the assigned tier.
  - Open the FlowIntel case at the URL in the email. Verify that misp_available: true appears in the case description, confirming that DECIPHER's analysis was enriched with MISP data.
  - The Flowintel case is tagged with low priority.
  - No mitigation command appears in /var/ossec/logs/active-responses.log.
- Tier 2:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier, and FlowIntel case URL.
  - A FlowIntel case is created and can be accessed at the Flowintel URL included in the email notification.
  - The FlowIntel case contains relevant information about the suspicious login event, related events found in MISP, and a breakdown of the risk score including the assigned tier.
  - Open the FlowIntel case at the URL in the email. Verify that misp_available: true appears in the case description, confirming that DECIPHER's analysis was enriched with MISP data.
  - The Flowintel case is tagged with medium priority.
  - Mitigation commands appear in /var/ossec/logs/active-responses.log (check mitigation commands in ar.yaml field mitigations_tier2 for suspicious_login).
- Tier 3:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier, and FlowIntel case URL.
  - A FlowIntel case is created and can be accessed at the Flowintel URL included in the email notification.
  - The FlowIntel case contains relevant information about the suspicious login event, related events found in MISP, and a breakdown of the risk score including the assigned tier.
  - Open the FlowIntel case at the URL in the email. Verify that misp_available: true appears in the case description, confirming that DECIPHER's analysis was enriched with MISP data.
  - The FlowIntel case is tagged with high priority.
  - Mitigation commands appear in /var/ossec/logs/active-responses.log (check mitigation commands in ar.yaml field mitigations_tier3 for suspicious_login). Considering the mitigation check:
    - firewall-drop: check the IP addresses are blocked in the agent
    - lock_user_linux.sh: check the user is locked in the agent
    - terminate_service.sh: check the service is terminated in the agent

Parent links: SRS-059 RADAR Scenario Simulation Framework

Child links: TRP-035 TCER: DECIPHER-RADAR detection validation for suspicious login

Attribute	Value
platform	GNU/Linux (Dockerized C5-DEC deployment environment)
execution_type	Automated
verification_method	T
release	alpha
complexity	1
test_data	see referenced files
version	0.8

3.7 Detection validation for GeoIP detection TST-047

Preconditions and setup actions

RADAR is setup according to TST-043

Test steps

Configure common and geoip_detection parts in /radar/radar-test-framework/simulate/scenarios/config.yaml.
From the radar/, run: bash ./simulate-radar.sh geoip_detection --agent remote

Expected outcome

2.1. The ansible playbook executes successfully.

2.2. In the Wazuh Dashboard Discovery page, a rule with ID matching 10090* is triggered for the remote agent.

2.3. In Wazuh manager check alert tier:

grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Expected risk_score range is between 0.0 and 1.0.
If tier is:
- Tier 0:
  - No email is received at EMAIL_TO.
  - No mitigation command appears in /var/ossec/logs/active-responses.log.
- Tier 1:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier.
  - No mitigation command appears in /var/ossec/logs/active-responses.log.
- Tier 2:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier.
  - Mitigation commands appear in /var/ossec/logs/active-responses.log (check mitigation commands in ar.yaml field mitigations_tier2 for geoip_detection).
- Tier 3:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier.
  - Mitigation commands appear in /var/ossec/logs/active-responses.log (check mitigation commands in ar.yaml field mitigations_tier3 for geoip_detection). Considering the mitigation check:
    - firewall-drop: check the IP addresses are blocked in the agent
    - lock_user_linux.sh: check the user is locked in the agent
    - terminate_service.sh: check the service is terminated in the agent

Parent links: SRS-059 RADAR Scenario Simulation Framework

Child links: TRP-036 TCER: Detection validation for GeoIP detection

Attribute	Value
platform	GNU/Linux (Dockerized C5-DEC deployment environment)
execution_type	Automated
verification_method	T
release	alpha
complexity	1
test_data	see referenced files
version	0.8

3.8 Detection validation for Log volume abnormal growth TST-048

Preconditions and setup actions

RADAR is setup according to TST-045

Test steps

Configure common and log_volume parts in /radar/radar-test-framework/simulate/scenarios/config.yaml. The values for abnormal growth should be adapted to detector configurations, if the suppression rules are 10%, the values should be calculated to pass the rules.
From the radar/, run:

./simulate-radar.sh log_volume --agent remote

Expected outcome

2.1. The ansible playbook executes successfully.

2.2. In the Wazuh Dashboard Discovery page, rule ID 100309 is triggered for the remote agent.

2.3. Verify that spike has happened in the agent:

echo /var/log $(du -sb /var/log 2>/dev/null | awk '{print $1}')

2.4. In Wazuh manager check alert tier:

grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Expected risk_score range is between 0.0 and 1.0.
If tier is:
- Tier 0:
  - No email is received at EMAIL_TO.
  - No mitigation command appears in /var/ossec/logs/active-responses.log.
- Tier 1:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier.
  - No mitigation command appears in /var/ossec/logs/active-responses.log.
- Tier 2:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier.
  - Mitigation commands appear in /var/ossec/logs/active-responses.log (check mitigation commands in ar.yaml field mitigations_tier2 for log_volume).
- Tier 3:
  - The email address specified in EMAIL_TO (from .env) receives a RADAR alert notification, containing the risk score, tier.
  - Mitigation commands appear in /var/ossec/logs/active-responses.log (check mitigation commands in ar.yaml field mitigations_tier3 for log_volume). Considering the mitigation check:
    - firewall-drop: check the IP addresses are blocked in the agent
    - lock_user_linux.sh: check the user is locked in the agent
    - terminate_service.sh: check the service is terminated in the agent 2.5. Verify that the spike file (log_volume.target_dir / log_volume.spike_filename) is removed after cleanup_minutes have elapsed (if cleanup_minutes > 0), or remove it manually if cleanup_minutes is set to 0.

Parent links: SRS-059 RADAR Scenario Simulation Framework

Child links: TRP-037 TCER: Detection validation for log volume abnormal growth

Attribute	Value
platform	GNU/Linux (Dockerized C5-DEC deployment environment)
execution_type	Automated
verification_method	T
release	alpha
complexity	1
test_data	see referenced files
version	0.8

1.0 ADBox test case specifications

1.1 Deploy ADBox via Docker and shell scripts TST-001

Preconditions and setup actions

Test steps

Expected outcome

1.3 Install ADBox as dev container TST-003

Preconditions and setup actions

Test steps

Expected outcome

1.4 Run ADBox console TST-004

Preconditions and setup actions

Test steps

Expected outcome

1.5 Run ADBox in default mode with a Wazuh connection TST-005

Preconditions and setup actions

Test steps

Expected outcome

1.6 Run ADBox in default mode without a Wazuh connection TST-006

Preconditions and setup actions

Test steps

Expected outcome

1.7 ADBox use case 1 with a Wazuh connection TST-007

Preconditions and setup actions

Test steps

Expected outcome

1.8 ADBox use case 1 without a Wazuh connection TST-008

Preconditions and setup actions

Test steps

Expected outcome

1.9 ADBox use case 2 with a Wazuh connection TST-009

Preconditions and setup actions

Test steps

Expected outcome

1.10 ADBox use case 2 without a Wazuh connection TST-010

Preconditions and setup actions

Test steps

Expected outcome

1.11 ADBox use case 3 with a Wazuh connection TST-011

Preconditions and setup actions

Test steps

Expected outcome

1.12 ADBox use case 3 without a Wazuh connection TST-012

Preconditions and setup actions

Test steps

Expected outcome

1.13 ADBox use case 4 with a Wazuh connection TST-013

Preconditions and setup actions

Test steps

Expected outcome

1.14 ADBox use case 4 without a Wazuh connection TST-014

Preconditions and setup actions

Test steps

Expected outcome

1.15 ADBox use case 5 with a Wazuh connection TST-015

Preconditions and setup actions

Test steps

Expected outcome

1.16 ADBox use case 5 without a Wazuh connection TST-016

Preconditions and setup actions

Test steps

Expected outcome

1.17 ADBox shipping install TST-017

Preconditions and setup actions

Test steps

Expected outcome

CLI:

Wazuh Dashboard* :

1.18 ADBox Create detector data stream TST-018

Preconditions and setup actions

Test steps

Expected outcome

CLI:

Local storage:

Wazuh Dashboard:

1.19 ADBox Wazuh integration Dashboard TST-033

Preconditions and setup actions

Test steps

Expected outcome

1.20 ADBox set up indexer host address TST-034

Preconditions and setup actions