1.0 ADBox test execution results

1.1 TCER: Deploy ADBox via Docker and shell scripts TRP-001

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape

Test execution results

Test case step 1: Clone the ADBox repository — 0 = flawless

Test case step 2: Change the working directory — 0 = flawless

Test case step 3: Build the image — 0 = flawless

Test case step 4: Run the container via shell script — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

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

Attribute	Value
test-date	2024-07-23
tester	AGI
defect-category	0 = flawless
passed-steps	4
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.2 TCER: Install ADBox as dev container TRP-003

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape

Test execution results

The docker build command fails. See reference. Test repeated.

Test case step 4: Open project in dev container in VS Code — 4 = critical defect: dev container build failure — not enough memory

All other steps: 0 = flawless

Defect summary description

Defect category: 4 = critical defect

Dev container build failure — not enough memory (step 4). See referenced screenshot.

Text execution evidence

See tra-003_Dev_container_error.png in assets.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

docs/specs/trp/assets/tra-003_Dev_container_error.png

Parent links: TST-003 Install ADBox as dev container

Attribute	Value
test-date	2024-07-24
tester	AGI
defect-category	4 = critical defect
passed-steps	5
failed-steps	1
not-executed-steps	0
release-version	0.1
verification-method	T

1.3 TCER: Install ADBox as dev container TRP-004

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape

Test execution results

Container size ~26 GB.

Test case step 6: Run ADBox via its entrypoint — 1 = insignificant defect: entrypoint specification unclear (poetry run adbox required)

All other steps: 0 = flawless

Defect summary description

Defect category: 1 = insignificant defect

Entrypoint specification unclear (change last step: entrypoint poetry run adbox).

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-003 Install ADBox as dev container

Attribute	Value
test-date	2024-07-24
tester	AGI
defect-category	1 = insignificant defect
passed-steps	5
failed-steps	1
not-executed-steps	0
release-version	0.1
verification-method	T

1.4 TCER: Run ADBox console TRP-005

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape

Test execution results

Test case step 1: Run the siem-mtad-gat-container container in interactive mode — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-004 Run ADBox console

Attribute	Value
test-date	2024-07-24
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.5 TCER: Run ADBox in default mode with a Wazuh connection TRP-006

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run the adbox container without any parameters — 0 = flawless

Test case step 2: Input y after the choice prompt for running in default mode — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Suggestion: decrease the number of default epochs.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-005 Run ADBox in default mode with a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	0 = flawless
passed-steps	2
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.6 TCER: Run ADBox in default mode without a Wazuh connection TRP-007

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape

Test execution results

Test case step 1: Run the AD driver in default mode — 0 = flawless

Test case step 2: Verify offline data loading — 2 = minor defect: offline data not available due to filename mismatch

Output observed:

Running AD driver in default mode.
JSON file 'detector_input_parameters.json' saved at .../detector_models/.../input/detector_input_parameters.json.
Could not establish a connection with OpenSearch.
The file '.../assets/data/train/wazuh-alerts-*.*-2024.07.*.json' does not exist, returning all default data.

Problem with file names:

wazuh-alerts-.-2024.03..json  wazuh-alerts-.-2024.05..json  wazuh-alerts-.-2024.07..json
wazuh-alerts-.-2024.04..json  wazuh-alerts-.-2024.06..json

Defect summary description

Defect category: 2 = minor defect

Offline data not available (filename mismatch).

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-006 Run ADBox in default mode without a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	2 = minor defect
passed-steps	1
failed-steps	1
not-executed-steps	0
release-version	0.1
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 1 — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-007 ADBox use case 1 with a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.8 TCER: ADBox use case 1 without a Wazuh connection TRP-009

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape

Test execution results

Test case step 1: Run adbox with use case scenario 1 (no Wazuh connection) — 2 = minor defect: offline data not available due to filename mismatch

Output observed:

Running AD driver in default mode.
JSON file 'detector_input_parameters.json' saved at .../detector_models/.../input/detector_input_parameters.json.
Could not establish a connection with OpenSearch.
The file '.../assets/data/train/wazuh-alerts-*.*-2024.07.*.json' does not exist, returning all default data.

Problem with file names:

wazuh-alerts-.-2024.03..json  wazuh-alerts-.-2024.05..json  wazuh-alerts-.-2024.07..json
wazuh-alerts-.-2024.04..json  wazuh-alerts-.-2024.06..json

Defect summary description

Defect category: 2 = minor defect

Offline data not available (filename mismatch).

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-008 ADBox use case 1 without a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	2 = minor defect
passed-steps	0
failed-steps	1
not-executed-steps	0
release-version	0.1
verification-method	T

1.9 TCER: ADBox use case 2 with a Wazuh connection TRP-010

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 2 — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-009 ADBox use case 2 with a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.10 TCER: ADBox use case 3 with a Wazuh connection TRP-011

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 3 — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-011 ADBox use case 3 with a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 4 — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-013 ADBox use case 4 with a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 5 — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-015 ADBox use case 5 with a Wazuh connection

Attribute	Value
test-date	2024-07-25
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 5 (no Wazuh connection) — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Suggestions

For prediction the response should be null if the data are not available.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-016 ADBox use case 5 without a Wazuh connection

Attribute	Value
test-date	2024-07-26
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 4 (no Wazuh connection) — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Suggestions

For prediction the response should be null if the data are not available.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-014 ADBox use case 4 without a Wazuh connection

Attribute	Value
test-date	2024-07-26
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 3 (no Wazuh connection) — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-012 ADBox use case 3 without a Wazuh connection

Attribute	Value
test-date	2024-07-26
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 2 (no Wazuh connection) — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Suggestions

For prediction the response should be null if the data are not available.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-010 ADBox use case 2 without a Wazuh connection

Attribute	Value
test-date	2024-07-26
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.17 TCER: ADBox use case 1 without a Wazuh connection TRP-018

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run adbox with use case scenario 1 (no Wazuh connection) — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-008 ADBox use case 1 without a Wazuh connection

Attribute	Value
test-date	2024-07-26
tester	AGI
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.18 TCER: Run ADBox in default mode without a Wazuh connection TRP-019

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape
Wazuh host: 192.168.5.5

Test execution results

Test case step 1: Run the adbox container without any parameters — 0 = flawless

Test case step 2: Input y after the choice prompt for running in default mode — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-006 Run ADBox in default mode without a Wazuh connection

Attribute	Value
test-date	2024-07-26
tester	AGI
defect-category	0 = flawless
passed-steps	2
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.19 TCER: Install ADBox as dev container TRP-020

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: vm-cyfort-idps-escape

Test execution results

Test case step 1: Clone the repo — 0 = flawless

Test case step 2: Start Docker Desktop — 0 = flawless

Test case step 3: Open project folder in VS Code — 0 = flawless

Test case step 4: Open project in dev container in VS Code — 0 = flawless

Test case step 5: Run poetry install in the container — 0 = flawless

Test case step 6: Run ADBox via its entrypoint — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

None

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-003 Install ADBox as dev container

Attribute	Value
test-date	2024-07-29
tester	AGI
defect-category	0 = flawless
passed-steps	6
failed-steps	0
not-executed-steps	0
release-version	0.1
verification-method	T

1.20 TCER: ADBox shipping install TRP-022

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: Running the container with the -s flag

0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-017 ADBox shipping install

Attribute	Value
test-date	2024-12-10
tester	AAT
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.3
verification-method	T

1.21 TCER: ADBox deployment TRP-023

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Test case step 1: Clone the repo — 0 = flawless

Test case step 2: Change directory — 0 = flawless

Test case step 3: Build the image — 0 = flawless

Test case step 4: Make the container executable and run it — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

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

Attribute	Value
test-date	2025-01-17
tester	AAT
defect-category	0 = flawless
passed-steps	4
failed-steps	0
not-executed-steps	0
release-version	0.3
verification-method	T

1.22 TCER: ADBox in dev container TRP-024

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Test case step 1: Clone the repo — 0 = flawless

Test case step 2: Start Docker Desktop — 0 = flawless

Test case step 3: Open project folder in VS Code — 0 = flawless

Test case step 4: Open project in dev container in VS Code — 0 = flawless

Test case step 5: Run poetry install in the container — 0 = flawless

Test case step 6: Run ADBox via its entrypoint — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence / Comments — N/A

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-003 Install ADBox as dev container

Attribute	Value
test-date	2025-01-17
tester	AAT
defect-category	0 = flawless
passed-steps	6
failed-steps	0
not-executed-steps	0
release-version	0.3
verification-method	T

1.23 TCER: ADBox console TRP-025

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Test case step 1: Run the siem-mtad-gat-container container in interactive mode — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence / Comments — N/A

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-004 Run ADBox console

Attribute	Value
test-date	2025-01-17
tester	AAT
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.3
verification-method	T

1.24 TCER: ADBox in default mode with Wazuh TRP-026

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Test case step 1: Run the adbox container without any parameters — 0 = flawless

Test case step 2: Input y after the choice prompt for running in default mode — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence / Comments — N/A

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-005 Run ADBox in default mode with a Wazuh connection

Attribute	Value
test-date	2025-01-22
tester	AAT
defect-category	0 = flawless
passed-steps	2
failed-steps	0
not-executed-steps	0
release-version	0.3
verification-method	T

1.25 TCER: ADBox UC scenario 2 with Wazuh TRP-027

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Test case step 1: Run adbox with use case scenario number 2 — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence / Comments — N/A

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-009 ADBox use case 2 with a Wazuh connection

Attribute	Value
test-date	2025-01-23
tester	AAT
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.3
verification-method	T

1.26 TCER: ADBox UC scenario 3 with Wazuh TRP-028

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Test case step 1: Run adbox with use case scenario number 3 — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence / Comments — N/A

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-011 ADBox use case 3 with a Wazuh connection

Attribute	Value
test-date	2025-01-23
tester	AAT
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	0.3
verification-method	T

2.0 RADAR test case execution results

2.1 TCER: Setup RADAR foundation TRP-030

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: Verify working directory availability

0 = flawless: radar directory available.

Test case step 2: Verify configuration of .env file

0 = flawless: available as indicated in the test case specification.

Test case step 3: Verify Ansible configuration, setup and reachability

0 = flawless: remote agent configuration successful
0 = flawless: remote manager configuration successful
0 = flawless: vault creation and setup for agent and manager successful
0 = flawless: sudo setup for access to controlled node successful
0 = flawless: Ansible reaching nodes in the SSH group successful

Test case step 4: Verify creation and setup of SSL/TLS certificates

0 = flawless: certificates created and stored under config/wazuh_indexer_ssl_certs/

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-041 Setup RADAR foundation

Attribute	Value
test-date	2026-03-10
tester	DMA
defect-category	0 = flawless
passed-steps	4
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

2.2 TCER: Build suspicious login TRP-031

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

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

In Wazuh Manager

Test case step 2.1: Custom 0310 SSH decoder deployed

0 = flawless: 0310-ssh.xml exists, and is owned by root:wazuh, with mode 0640.

Test case step 2.2: Custom 0310 SSH decoder contains RADAR fields

0 = flawless: decoder contains the decoders sshd-*-with-radar (e.g., including RADAR fields like ASN, country, geo_velocity).

Test case step 2.3: Default 0310 decoder is excluded in ossec.conf

0 = flawless: a <decoder_exclude>0310-ssh_decoders.xml</decoder_exclude> line appears (ideally once) under <ruleset>.

Test case step 2.4: RADAR rules for suspicious_login are in /var/ossec/etc/rules/

0 = flawless: a3-suspicious-login.xml exists with owner root:wazuh, mode 0640.

Test case step 2.5: Suspicious login rules are bound to active responses

0 = flawless: suspicious login rule ID(s) reference the intended <active-response> triggering radar_ar.py.

Test case step 2.6: Agent is registered with the manager

0 = flawless: an entry exists for each agent.

Test case step 2.7: Agent configurations are in place

0 = flawless: agent configurations for suspicious login exist in the  block.

Test case step 2.8: Wazuh Manager is running after restart

0 = flawless: the status output indicates the manager is running with no error messages.

In endpoints running agents

Test case step 2.9: RADAR helper directory and script are installed on the SSH agent host

0 = flawless: /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

Test case step 2.10: radar-helper.service systemd unit is installed, enabled, and running

0 = flawless: the service is active.

Post-test cleanup

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

0 = flawless: The command output is empty.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-042 Build suspicious login

Attribute	Value
test-date	2026-03-10
tester	DMA
defect-category	0 = flawless
passed-steps	11
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

2.3 TCER: Build non-whitelist GeoIP detection TRP-032

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

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

In Wazuh Manager

Test case step 2.1: Whitelist file exists

0 = flawless: /var/ossec/etc/lists/whitelist_countries exists, its contents match the scenario's whitelist_countries, and its owner is root:wazuh, with mode 0664.

Test case step 2.2: ossec.conf has <list> entry for whitelist_countries

0 = flawless: under <ruleset>, there is a <list>...whitelist_countries</list> entry with the RADAR marker for geoip_detection.

Test case step 2.3: Custom 0310 SSH decoder deployed

0 = flawless: 0310-ssh.xml exists, and is owned by root:wazuh, mode 0640.

Test case step 2.4: Default 0310 decoder is excluded in ossec.conf

0 = flawless: a <decoder_exclude>0310-ssh_decoders.xml</decoder_exclude> line appears (ideally once) under <ruleset>.

Test case step 2.5: RADAR rules for geoip_detection exist

0 = flawless: a2-geoip-detection.xml contains a RADAR_RULES: geoip_detection block; rules use whitelist_countries to detect non-whitelisted countries.

Test case step 2.6: GeoIP non-whitelist rules are bound to active responses

0 = flawless: GeoIP non-whitelist rule ID(s) reference the correct <active-response>.

Test case step 2.7: Active response config files are in place

0 = flawless: ar.yaml and radar_ar.py present in /var/ossec/active-response/bin/.

Test case step 2.8: Agent configurations are in place

0 = flawless: agent configurations for geoip detection exist.

In endpoints running agents

Test case step 2.9: RADAR helper directory and script are installed on the SSH agent host

0 = flawless: /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

Test case step 2.10: radar-helper.service systemd unit is installed, enabled, and running

0 = flawless: the service is active.

Post-test cleanup

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

0 = flawless: The command output is empty.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-043 Build non-whitelist GeoIP detection

Attribute	Value
test-date	2026-03-10
tester	DMA
defect-category	0 = flawless
passed-steps	11
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

2.4 TCER: Build log volume abnormal growth TRP-033

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

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

In Wazuh Manager

Test case step 2.1: RADAR snippet for log_volume is present in ossec.conf

0 = flawless: ossec.conf contains a RADAR: log_volume BEGIN/END block with the log volume-related settings.

Test case step 2.2: RADAR decoders for log_volume exist

0 = flawless: 0001-log-volume.xml contains a block defining decoders that produce a log_bytes field.

Test case step 2.3: RADAR rules for log_volume exist

0 = flawless: a1-log-volume.xml exists in /var/ossec/etc/rules.

Test case step 2.4: OpenSearch template radar-log-volume is present

0 = flawless: HTTP status is 200 and the template JSON exists with mappings for log_bytes as a numeric type.

Test case step 2.5: log_volume rules are bound to active responses

0 = flawless: log volume anomaly rule ID(s) reference radar_ar.py as intended.

Test case step 2.6: Agent configurations are in place

0 = flawless: agent configurations for log volume exist.

In endpoints running agents

Test case step 2.7: RADAR helper directory and script are installed on the SSH agent host

0 = flawless: /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

Test case step 2.8: radar-helper.service systemd unit is installed, enabled, and running

0 = flawless: the service is active.

Post-test cleanup

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

0 = flawless: The command output is empty.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-044 Build log volume abnormal growth

Attribute	Value
test-date	2026-03-10
tester	DMA
defect-category	0 = flawless
passed-steps	9
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

./run-radar.sh log_volume

In Wazuh Dashboard

Test case step 2.1: The detector LOG_VOLUME_DETECTOR is created in the Wazuh Dashboard with the correct configurations

0 = flawless: In the Anomaly Detection menu, the created detector is visible. The expected configurations are found in config.yaml under the log_volume key.

Test case step 2.2: Monitor creation and trigger to webhook existence

0 = flawless: the monitor is created in the Wazuh Dashboard with a trigger to a RADAR webhook instance. In the Alerting menu, the created Monitor is listed under the Monitors tab.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-045 Run RADAR for log volume abnormal growth

Attribute	Value
test-date	2026-03-10
tester	DMA
defect-category	0 = flawless
passed-steps	2
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

sudo ./simulate-radar.sh suspicious_login --agent remote

Test case step 2.1: The ansible playbook executes successfully

0 = flawless: The simulation was successfully executed.

Test case step 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

0 = flawless: Alerts with one of the rule.id : [210012, 210013, 210020, or 210021] appear in the Wazuh Dashboard.

Test case step 2.3: In Wazuh manager, alert tier verified via grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Tier 0:
- 0 = flawless: no email received at EMAIL_TO.
- 0 = flawless: no FlowIntel case created.
- 0 = flawless: no mitigation command in /var/ossec/logs/active-responses.log.
Tier 1: (Same alerts were generated, but by putting one of the IPs present in the alert in MISP changed the tier from 0 to 1)
- 0 = flawless: email received at EMAIL_TO with risk score, tier, and FlowIntel case URL.
- 0 = flawless: FlowIntel case created and accessible at the URL included in the email.
- 0 = flawless: 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.
- 0 = flawless: misp_available: true appears in the FlowIntel case description, confirmed via "DECIPHER analyze completed" log entry matched by decision_id.
- 0 = flawless: FlowIntel case is tagged with low priority.
- 0 = flawless: no mitigation command in /var/ossec/logs/active-responses.log.

Defect summary description

0 = flawless

Text execution evidence

FlowIntel case:

Email:

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-046 DECIPHER-RADAR detection validation for Suspicious login

Attribute	Value
test-date	2026-03-10
tester	DMA
defect-category	0 = flawless
passed-steps	3
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

2.7 TCER: Detection validation for GeoIP detection TRP-036

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

sudo ./simulate-radar.sh geoip_detection --agent remote

Test case step 2.1: The ansible playbook executes successfully

0 = flawless: The ansible playbook executed successfully.

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

0 = flawless: A rule with rule.id '100900' was triggered and appeared in Wazuh Dashboard

Test case step 2.3: In Wazuh manager, alert tier verified via grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Tier 1:
- 0 = flawless: email received at EMAIL_TO with risk score, tier.
- 0 = flawless: no mitigation command in /var/ossec/logs/active-responses.log.
Tier 3:
- 0 = flawless: email received at EMAIL_TO with risk score, and tier.
- 0 = flawless: mitigation commands from mitigations_tier3 for geoip_detection appear in /var/ossec/logs/active-responses.log.
- 0 = flawless: firewall-drop: IP address blocked in the agent.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-047 Detection validation for GeoIP detection

Attribute	Value
test-date	2026-03-10
tester	DMA
defect-category	0 = flawless
passed-steps	3
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

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

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

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

Test case step 2.1: The ansible playbook executes successfully

0 = flawless: The ansible playbook executed successfully.

Test case step 2.2: In the Wazuh Dashboard Discovery page, rule ID 100309 is triggered for the remote agent

0 = flawless: An alert with rule.id 100309 has been triggered and appears in the Wazuh dashboard.

Test case step 2.3: Spike has happened in the agent

0 = flawless: /var/log size increase confirmed.

Test case step 2.4: In Wazuh manager, alert tier verified via grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Tier 2:
- 0 = flawless: email received at EMAIL_TO with risk score, tier, and FlowIntel case URL.
- 0 = flawless: mitigation commands from mitigations_tier2 for log_volume appear in /var/ossec/logs/active-responses.log.

Test case step 2.5: Spike file removed after cleanup_minutes elapsed (or manually if cleanup_minutes is 0)

0 = flawless: Spike file removed after cleanup_minutes elapsed

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-048 Detection validation for Log volume abnormal growth

Attribute	Value
test-date	2026-03-11
tester	DMA
defect-category	0 = flawless
passed-steps	5
failed-steps	0
not-executed-steps	0
release-version	0.8
verification-method	T

2.9 TCER: RADAR deployment integrity verification TRP-038

Relevant test environment and configuration details

Software deviations: none — aligned with test case specification
Controller host: vm-cyfort-1 — Ubuntu 22.04 LTS, RADAR v0.8.2 repository at ~/radar
Wazuh host (remote): vm-cyfort-radar — Ubuntu 22.04 LTS, 12 GB RAM, Wazuh multi-node Docker stack v4.14.4
Remote agent: vm-cyfort-testing-2
Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)
NFS snapshot source: vm-lan-nfs.itrust.lu:/nfs/wazuh-snapshots, snapshot: wazuh-20260312
Fingerprint cutoff used: 2026-03-26T12:00:00.000Z
Deployment mode: --manager remote --agent remote

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Step 2 — Pre-deployment snapshot

Pre-01: Wazuh configuration backup

0 = flawless: ossec.conf backed up for master (8.7K) and worker (8.7K).

Pre-02: Active response scripts backup

0 = flawless: 15 AR bin files hashed to baseline.

Pre-03: Wazuh index file hashes

0 = flawless: manager 68 files, worker 68 files.

Pre-04: File permissions snapshot

0 = flawless: 68 permission entries captured for manager.

Pre-05: Indexer document fingerprint

0 = flawless: Fingerprint file: 19273 lines. Hash: 4b78de52aa936ead05278aedb86b9fe366411d1f287c068b3b21d28c5bcbd909

Pre-06: Cluster health

0 = flawless: manager master <span style="color:green">**0 = flawless**</span>, worker01 worker <span style="color:green">**0 = flawless**</span>

Pre-07: Agent connectivity

0 = flawless: 000 wazuh.master active, 001 vm-cyfort-testing-2 active

Pre-08: Wazuh API health

0 = flawless: version: v4.14.4, uuid: 7794ccab-52c8-4505-aba0-bb25084b86ed, type: server

Pre-09: Existing detection test

Both master and worker tested with:

2026-03-26T13:43:53.668837+01:00 vm-cyfort-testing-2 sudo: pam_unix(sudo:session): session closed for user root

0 = flawless: master — decoder: pam, rule: 5502, level: 3, description: PAM: Login session closed., groups: pam, syslog
0 = flawless: worker — identical result

Pre-10: Filebeat pipeline state

0 = flawless: Pipeline filebeat-7.10.2-wazuh-archives-pipeline captured.

Pre-11: Wazuh manager service state

0 = flawless: All core daemons running: wazuh-clusterd, wazuh-modulesd, wazuh-monitord, wazuh-logcollector, wazuh-remoted, wazuh-syscheckd, wazuh-analysisd, wazuh-execd, wazuh-db, wazuh-authd, wazuh-apid. Not running (expected in Docker): wazuh-maild, wazuh-agentlessd, wazuh-integratord, wazuh-dbd, wazuh-csyslogd.

Step 3 — RADAR deployment

geoip_detection: - 0 = flawless: Ansible tasks completed. failed=0 for all hosts.

suspicious_login: - 0 = flawless: Ansible tasks completed. failed=0 for all hosts.

log_volume: - 0 = flawless: Ansible tasks completed. failed=0 for all hosts.

Step 4 — Post-deployment checks

Post-01: Wazuh index file hashes

0 = flawless: PASS - No unexpected file modifications (manager)
0 = flawless: PASS - No unexpected file modifications (worker)

New files added by RADAR (all within RADAR scope): client.keys, decoders/0001-ad-common.xml, decoders/0001-log-volume.xml, decoders/0310-ssh.xml, decoders/0375-web-accesslog.xml, lists/whitelist_countries, lists/whitelist_countries.cdb, ossec.conf, rules/a1-log-volume.xml, rules/a2-geoip-detection.xml, rules/a3-suspicious-login.xml, shared/ar.conf, shared/default/agent.conf, shared/default/agent.conf.*~, shared/default/merged.mg

Post-02: File permissions

0 = flawless: PASS - No unexpected permission changes

Post-03: Existing detection test

Same log line tested on both master and worker after deployment:

0 = flawless: master — decoder: pam, rule: 5502, level: 3, description: PAM: Login session closed., groups: pam, syslog — identical to pre-deployment baseline
0 = flawless: worker — identical result

Post-04: Agent connectivity

0 = flawless: CHECK - Agent changes (webhook enrollment expected): agent 002 3c59000272f3 active enrolled — expected. Agents 000 and 001 unchanged.

Post-05: Cluster health

0 = flawless: PASS - Cluster nodes unchanged — manager master, worker01 worker

Post-06: Indexer document fingerprint

0 = flawless: PASS - Index data fingerprint identical
Pre-RADAR: 4c4f86dc42b5286ace58e99ec4d08f7ae0bec8eae4c0fca71c064124a41aae9b
Post-RADAR: 4c4f86dc42b5286ace58e99ec4d08f7ae0bec8eae4c0fca71c064124a41aae9b

Post-07: Wazuh API

0 = flawless: API was confirmed reachable and returning valid responses (token refresh succeeded, version v4.14.4 confirmed).

Post-08: No new errors in ossec.log

0 = flawless: No error types introduced by RADAR.

Post-09: Webhook service

0 = flawless: Container status: running. HTTP endpoint on port 8080 returns 301 Moved Permanently (nginx proxy) — endpoint responding.

Post-10: Active response wiring

0 = flawless: radar_ar_geoip: 2 matches — PASS
0 = flawless: radar_ar_log_volume: 2 matches — PASS
0 = flawless: terminate_service/lock_user_linux: 4 matches — PASS

Post-11: Decoder and rule deployment

0 = flawless: 0310-ssh.xml — owner=root:wazuh mode=640 — PASS
0 = flawless: 0375-web-accesslog.xml — owner=root:wazuh mode=640 — PASS
0 = flawless: 0001-ad-common.xml — owner=root:wazuh mode=640 — PASS
0 = flawless: 0001-log-volume.xml — owner=root:wazuh mode=640 — PASS
0 = flawless: a2-geoip-detection.xml — owner=root:wazuh mode=640 — PASS
0 = flawless: a3-suspicious-login.xml — owner=root:wazuh mode=640 — PASS
0 = flawless: a1-log-volume.xml — owner=root:wazuh mode=640 — PASS

Post-12: Python dependencies

0 = flawless: PASS - pyyaml and requests importable

Post-13: GeoIP databases on agents

0 = flawless: GeoLite2-City.mmdb — 63,823,624 bytes — PASS
0 = flawless: GeoLite2-ASN.mmdb — 10,819,328 bytes — PASS

Post-14: Existing rules unmodified

0 = flawless: PASS - All pre-existing files byte-for-byte unmodified

Post-15: Filebeat pipeline integrity

0 = flawless: Container pipeline file /usr/share/filebeat/module/wazuh/archives/ingest/pipeline.json contains 2 matches of log_volume_metric - PASS.

Post-16: OpenSearch index mappings

0 = flawless: RADAR-specific template radar-log-volume present covering wazuh-ad-log-volume-* — PASS. Existing wazuh-alerts-* templates unchanged.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-049 RADAR deployment integrity verification

Attribute	Value
test-date	2026-03-26
tester	GDU
defect-category	0 = flawless
passed-steps	4
failed-steps	0
not-executed-steps	0
release-version	0.8.1
verification-method	T

2.10 TCER: Build scanning detection TRP-041

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Dockerized C5-DEC deployment environment)
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

sudo ./build-radar.sh scanning_detection --manager local --agent remote --manager_exists false --ssh-key /home/<USER>/.ssh/id_ed25519

In Wazuh Manager

Test case step 2.1: RADAR scanning detection rules are deployed

0 = flawless: a4-scanning-detection.xml exists, owned by root:wazuh, mode 0640.

Test case step 2.2: Scanning detection rules contain all expected rule IDs

0 = flawless: rules 100800 through 100805 are present in a4-scanning-detection.xml.

Test case step 2.3: Scanning detection rules are bound to active responses

0 = flawless: scanning rule IDs reference the radar_ar_scanning <active-response> block triggering radar_ar.py.

Test case step 2.4: Agent is registered with the manager

0 = flawless: an entry exists for each agent.

Test case step 2.5: Agent configurations for scanning detection are in place

0 = flawless: the  block exists and contains Apache and Nginx log source entries with log_format apache.

Test case step 2.6: Wazuh Manager is running after restart

0 = flawless: the status output indicates the manager is running with no error messages.

In endpoints running agents

Test case step 2.7: Wazuh agent is active and connected to the manager

0 = flawless: the agent service is active.

Test case step 2.8: Apache or Nginx is running and writing to the expected log path

0 = flawless: the log file(s) exist and contain recent access log entries in combined log format.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-051 Build scanning detection

Attribute	Value
test-date	2026-07-29
tester	GDU
defect-category	0 = flawless
passed-steps	3
failed-steps	0
not-executed-steps	0
release-version	1.1
verification-method	T

2.11 TCER: Detection validation for scanning detection TRP-042

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Dockerized C5-DEC deployment environment)
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

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

Test case step 2.1: The ansible playbook executes successfully

0 = flawless: the simulation was successfully executed.

Test case step 2.2: In the Wazuh Dashboard Discovery page, rule ID 1008* is triggered for the remote agent

0 = flawless: an alert matching rule ID 1008* appeared in the Wazuh Dashboard for the remote agent.

Test case step 2.3: In Wazuh manager, alert tier verified via grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Tier 2:
- 0 = flawless: email received at EMAIL_TO containing the risk score and tier, matching EmailNotifier._build_body()'s format.
- 0 = flawless: no mitigation command is triggered. The scenario is currently configured notify-only by design.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-052 Detection validation for scanning detection

Attribute	Value
test-date	2026-07-29
tester	GDU
defect-category	0 = flawless
passed-steps	2
failed-steps	0
not-executed-steps	0
release-version	1.1
verification-method	T

2.12 TCER: Validate default scenario rules detection TRP-043

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Dockerized C5-DEC deployment environment)
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

sudo ./build-radar.sh suspicious_login --manager local --agent remote --manager_exists false --ssh-key /home/<USER>/.ssh/id_ed25519

In Wazuh Manager

Test case step 2.1: RADAR rules for the default scenario are deployed

0 = flawless: rule IDs 100400-100405 are present in /var/ossec/etc/rules/.

Test case step 2.2: ar.yaml reflects the configured groups

0 = flawless: the default: block lists rule_ids: ["100401","100402","100404","100405","23503","23504","23505"] and rule_groups: ["authentication_failures"] as configured.

Test case step 2.3: The active-response binding in ossec.conf includes both the exact IDs and the two groups

0 = flawless: <rules_id> lists 100401,100402,100404,100405,23503,23504,23505 and <rules_group> lists authentication_failures,, bound to radar_ar_default.

Test case step 2.4: Wazuh Manager is running after restart

0 = flawless: the status output indicates the manager is running with no error messages.

Post-test cleanup

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

0 = flawless: docker ps output was empty.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-053 Validate default scenario rules detection

Attribute	Value
test-date	2026-07-29
tester	GDU
defect-category	0 = flawless
passed-steps	3
failed-steps	0
not-executed-steps	0
release-version	1.2
verification-method	T

2.13 TCER: DECIPHER-RADAR detection validation for Default rules TRP-044

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Dockerized C5-DEC deployment environment)
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case. The executed command was as follows:

sudo ./simulate-radar.sh default --agent remote --ssh-key /home/<USER>/.ssh/id_ed25519

Test case step 1.1: Based on syscollector frequency after 60 minutes, at least one alert of rule IDs 23503, 23504, or 23505 is triggered for the remote agent

0 = flawless: 3 emails with rule.id 23504, 2 emails with rule.id 23505, and 1 email with rule.id 23503 are received

Test case step 1.2: In Wazuh manager, alert tier verified via grep "Risk computed" /var/ossec/logs/active-responses.log | tail -1

Tier 1:
- 0 = flawless: email received at EMAIL_TO with risk score, tier, and FlowIntel case URL.
- 0 = flawless: FlowIntel case created and accessible at the URL included in the email.
- 0 = flawless: FlowIntel case contains relevant information about the vulnerability detection event and a breakdown of the risk score including the assigned tier.
- 0 = flawless: FlowIntel case is tagged with low priority.
- 0 = flawless: no mitigation command in /var/ossec/logs/active-responses.log.

Defect summary description

0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-054 DECIPHER-RADAR detection validation for Default rules

Attribute	Value
test-date	2026-07-29
tester	GDU
defect-category	0 = flawless
passed-steps	1
failed-steps	0
not-executed-steps	0
release-version	1.2
verification-method	T

2.14 TCER: GUI: Build & validate `suspicious_login` scenario TRP-045

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Ubuntu) and second test node running Debian GNU/Linux 13 (trixie); Wazuh manager/agent version 4.14.1; DECIPHER Stack (DECIPHER, FlowIntel, MISP) deployed per SATRAP-DL v1.0
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: .env prepared under radar with the required variables set, including MAXMIND_LICENSE_KEY — 0 = flawless

Test case step 2: GUI started via ./radar.sh gui; reachable in the browser at the printed host:port, with Build & deploy, Onboard Agent, and Group Enrollment tabs present; .venv created on first run — 0 = flawless

Test case step 3: Scenario suspicious_login built and deployed via Deploy → Build & deploy

(a) command completed with === SUCCESS in its output — 0 = flawless
(b) GeoLite2-City.mmdb and GeoLite2-ASN.mmdb confirmed present under /var/ossec/etc/radar/ on the manager — 0 = flawless

Test case step 4: Onboarding token minted for scenario suspicious_login; ready-to-run bootstrap-agent.sh command printed — 0 = flawless

Test case step 5: bootstrap-agent.sh executed on the agent host; command completed with === SUCCESS === in its output — 0 = flawless

Test case step 6: Agent enrolled via Group Enrollment; Wazuh Dashboard Agents management → Summary shows the agent assigned groups suspicious_login and radar_shared — 0 = flawless

Test case step 7: Health check run for the Suspicious Login scenario in the Status tab; no FAIL lines present — 0 = flawless

Test case step 8: suspicious_login.py simulation run directly on the agent host

(a) script completed without error, printing "suspicious_login simulation completed" — 0 = flawless
(b) enriched_auth.log on the manager showed authentication events enriched with RADAR columns within 1 minute — 0 = flawless
(c) Wazuh rule 210021 (RADAR SuspiciousLogin: impossible travel) appeared in Wazuh Dashboard Discovery — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

All steps completed successfully, matching the expected outcome in TST-055. Cleanup performed via the Teardown tab in the GUI and uninstall-agent.sh --purge-data on the agent host.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-055 GUI: Build & validate suspicious_login scenario

Attribute	Value
test-date	2026-08-18
tester	AAT
defect-category	0 = flawless
passed-steps	8
failed-steps	0
not-executed-steps	0
release-version	2.0
verification-method	T

2.15 TCER: GUI: Build & validate `geoip_detection` scenario TRP-046

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Ubuntu) and second test node running Debian GNU/Linux 13 (trixie); Wazuh manager/agent version 4.14.1; DECIPHER Stack (DECIPHER, FlowIntel, MISP) deployed per SATRAP-DL v1.0
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: .env prepared under radar with the required variables set, including MAXMIND_LICENSE_KEY — 0 = flawless

Test case step 3: Scenario geoip_detection built and deployed via Deploy → Build & deploy

(a) command completed with === SUCCESS in its output — 0 = flawless
(b) GeoLite2-City.mmdb and GeoLite2-ASN.mmdb confirmed present under /var/ossec/etc/radar/ on the manager — 0 = flawless

Test case step 4: Onboarding token minted for scenario geoip_detection; ready-to-run bootstrap-agent.sh command printed — 0 = flawless

Test case step 5: bootstrap-agent.sh executed on the agent host; command completed with === SUCCESS === in its output — 0 = flawless

Test case step 6: Agent enrolled via Group Enrollment; Wazuh Dashboard Agents management → Summary shows the agent assigned groups geoip_detection and radar_shared — 0 = flawless

Test case step 7: Health check run for the GeoIP Detection scenario in the Status tab; no FAIL lines present — 0 = flawless

Test case step 8: geoip_detection.py simulation run directly on the agent host

(a) script completed without error, printing "geoip_detection simulation completed" — 0 = flawless
(b) within 2 minutes, rule 100900 appeared in Wazuh Dashboard Discovery, radar_ar.py wrote an active-response entry to active-responses.log, an email notification was delivered, and enrichment_errors.log had no new entries — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

All steps completed successfully, matching the expected outcome in TST-056. Cleanup performed via the Teardown tab in the GUI and uninstall-agent.sh --purge-data on the agent host.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-056 GUI: Build & validate geoip_detection scenario

Attribute	Value
test-date	2026-08-18
tester	AAT
defect-category	0 = flawless
passed-steps	8
failed-steps	0
not-executed-steps	0
release-version	2.0
verification-method	T

2.16 TCER: GUI: Build & validate `scanning_detection` scenario TRP-047

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Ubuntu) and second test node running Debian GNU/Linux 13 (trixie); Wazuh manager/agent version 4.14.1; Apache/Nginx log sources configured on the targeted agent host
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: .env prepared under radar with the required variables set — 0 = flawless

Test case step 3: Scenario scanning_detection built and deployed via Deploy → Build & deploy

(a) command completed with === SUCCESS in its output — 0 = flawless
(b) ossec.conf on the manager confirmed to contain the marked RADAR: scanning_detection block — 0 = flawless

Test case step 4: Onboarding token minted for scenario scanning_detection; ready-to-run bootstrap-agent.sh command printed — 0 = flawless

Test case step 5: bootstrap-agent.sh executed on the agent host; command completed with === SUCCESS === in its output — 0 = flawless

Test case step 6: Agent enrolled via Group Enrollment; Wazuh Dashboard Agents management → Summary shows the agent assigned group scanning_detection — 0 = flawless

Test case step 7: Health check run for the Scanning Detection scenario in the Status tab; no FAIL lines present — 0 = flawless

Test case step 8: scanning_detection.py simulation run directly on the agent host

(a) script completed without error, printing "scanning_detection simulation completed" — 0 = flawless
(b) within 2 minutes, scanning rules per radar/scenarios/rules/scanning_detection/ (100800–100804) appeared in Wazuh Dashboard Discovery — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

All steps completed successfully, matching the expected outcome in TST-057. Cleanup performed via the Teardown tab in the GUI and uninstall-agent.sh --purge-data on the agent host.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-057 GUI: Build & validate scanning_detection scenario

Attribute	Value
test-date	2026-08-18
tester	AAT
defect-category	0 = flawless
passed-steps	8
failed-steps	0
not-executed-steps	0
release-version	2.0
verification-method	T

2.17 TCER: GUI: Build & validate `log_volume` scenario TRP-048

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Ubuntu) and second test node running Debian GNU/Linux 13 (trixie); Wazuh manager/agent version 4.14.1
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: .env prepared under radar with the required variables set — 0 = flawless

Test case step 2: GUI started via ./radar.sh gui; reachable in the browser at the printed host:port, with Build & deploy, Onboard Agent, Group Enrollment, and Run Anomaly Detector tabs present; .venv created on first run — 0 = flawless

Test case step 3: Scenario log_volume built and deployed via Deploy → Build & deploy

(a) command completed with === SUCCESS in its output — 0 = flawless
(b) the radar-log-volume index template was confirmed applied on the OpenSearch cluster — 0 = flawless

Test case step 4: Onboarding token minted for scenario log_volume; ready-to-run bootstrap-agent.sh command printed — 0 = flawless

Test case step 5: bootstrap-agent.sh executed on the agent host; command completed with === SUCCESS === in its output — 0 = flawless

Test case step 6: Agent enrolled via Group Enrollment; Wazuh Dashboard Agents management → Summary shows the agent assigned group log_volume — 0 = flawless

Test case step 7: Log Volume Growth detector run via Deploy → Run Anomaly Detector with the ingest option checked

(a) streamed output completed without an [ERROR] line, reporting the detector was created and started — 0 = flawless
(b) the wazuh-ad-log-volume-* index confirmed to contain more than 0 documents (docs.count) — 0 = flawless

Test case step 8: Health check run for the Log Volume Growth scenario in the Status tab; no FAIL lines present — 0 = flawless

Test case step 9: log_volume.py simulation run directly on the agent host

(a) script completed without error, printing "log_volume simulation completed" — 0 = flawless
(b) A spike or anomaly event is detected and visible on the log volume detector page of the Anomaly Detection dashboard of Wazuh. — 0 = flawless
(c) active-response mitigation commands logged in active-responses.log — 3 = major defect
(d) rule 100309 (LogVolume-Growth-Detected) fired in Wazuh Dashboard Discovery, and an email notification was received — 3 = major defect

Defect summary description

Defect-free test execution, i.e., defect category: 3 = major defect

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

See linked files (if any), e.g., screenshots, logs, etc.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-058 GUI: Build & validate log_volume scenario

Attribute	Value
test-date	2026-08-19
tester	AAT
defect-category	3 = major defect
passed-steps	9
failed-steps	0
not-executed-steps	0
release-version	2.0
verification-method	T

2.18 TCER: GUI: Unenroll, undeploy, and deregister the `log_volume` scenario TRP-049

Relevant test environment and configuration details

Software deviations: aligned with test case specification, with controller node running GNU/Linux (Ubuntu) and second test node running Debian GNU/Linux 13 (trixie); Wazuh manager/agent version 4.14.1
Hardware deviations: aligned with test case specification

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: GUI started (or already running) via ./radar.sh gui; reachable in the browser at the printed host:port, with Scenario Management, Agent Management, Group Management, and Status tabs present under Deploy — 0 = flawless

Test case step 2: Wazuh Dashboard Agents management → Summary checked before changes; agent shows both default and log_volume groups — 0 = flawless

Test case step 3: Agent unenrolled from scenario Log Volume Growth via Deploy → Group Management → Unenroll from groups; streamed output ended with === SUCCESS: group unassignment for 'log_volume' completed === — 0 = flawless

Test case step 4: Wazuh Dashboard Agents management → Summary checked again; agent now shows only the default group — 0 = flawless

Test case step 5: Agent re-enrolled via Deploy → Group Management → Assign group; streamed output ended with === SUCCESS: group assignment for 'log_volume' completed ===, and the agent is re-assigned to both default and log_volume — 0 = flawless

Test case step 6: Scenario Log Volume Growth undeployed via Deploy → Scenario Management → Undeploy scenario; streamed output ended with === SUCCESS: undo for 'log_volume' completed ===, with no error key present in either printed result — 0 = flawless

Test case step 7: Health check run for the Log Volume Growth scenario in the Status tab

(a) the four wazuh-* daemon checks and the OpenSearch/Webhook checks all still reported OK — 0 = flawless
(b) the five checks for active-response wiring, group config, and the three decoder/rule files reported FAIL — 0 = flawless

Test case step 8: On the manager host, docker exec wazuh.manager grep -c "RADAR: log_volume" /var/ossec/etc/ossec.conf returned 0 — 0 = flawless

Test case step 9: Wazuh Dashboard Agents management → Summary checked once more; agent shows only the default group — 0 = flawless

Test case step 10: Agent deregistered via Deploy → Agent Management → Deregister agent; streamed output ended with JSON result followed by === SUCCESS: deregistration for '<agent-name>' completed === — 0 = flawless

Test case step 11: Wazuh Dashboard Agents management → Summary checked; the agent no longer appears in the agents list — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

All steps completed successfully, matching the expected outcome in TST-059. Cleanup performed via the Teardown tab in the GUI and uninstall-agent.sh --purge-data on the agent host.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-059 GUI: Unenroll, undeploy, and deregister the log_volume scenario

Attribute	Value
test-date	2026-08-19
tester	AAT
defect-category	0 = flawless
passed-steps	11
failed-steps	0
not-executed-steps	0
release-version	2.0
verification-method	T

3.0 SONAR test case execution results

3.1 TCER: Linux resource usage monitoring scenario TRP-040

Relevant test environment and configuration details

Software deviations: aligned with test case specification, N/A
Hardware deviations: aligned with test case specification, N/A
Environment: dev container (Debian GNU/Linux 12, Dockerized C5-DEC development environment)
SONAR version: as checked out in current repository branch
Debug mode: enabled; no live Wazuh indexer connection required
Test data: sonar/test_data/resource_monitoring/resource_monitoring_training-2.json, sonar/test_data/resource_monitoring/resource_monitoring_detection.json

Test execution results

Test case step 1: Train the SONAR model using poetry run sonar train --scenario sonar/scenarios/linux_resource_monitoring.yaml --debug — 0 = flawless

Test case step 2: Verify model artefact linux_resource_monitoring_20260112_230114 persisted under sonar/models/ — 0 = flawless

Test case step 3: Run detection using poetry run sonar detect --scenario sonar/scenarios/linux_resource_monitoring.yaml --debug — 0 = flawless

Test case step 4: Verify at least one anomaly flagged in the detection output with score exceeding 0.75 — 0 = flawless

Test case step 5: Verify at least three consecutive anomalous 1-minute buckets reported, satisfying min_consecutive: 3 — 0 = flawless

Test case step 6: Verify derived feature Boolean values (is_cpu_high, is_memory_high, is_high_load) consistent with the raw metric thresholds in the detection data — 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Test executed in debug mode using pre-recorded resource monitoring data. No live Wazuh indexer connection required. All training and detection steps completed successfully within the expected runtime.

Guide

Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-050 Linux resource usage monitoring scenario

Attribute	Value
test-date	2026-05-04
tester	AAT
defect-category	0 = flawless
passed-steps	6
failed-steps	0
not-executed-steps	0
release-version	1.0
verification-method	T