1.1 TCER: install ADBox shipping TRB-001

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.2 TCER: ADBox deployment TRB-002

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: 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

1.3 TCER: ADBox in dev container TRB-003

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: 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

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

1.4 TCER: ADBox console TRB-004

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: 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

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

1.5 TCER: ADBox in default mode with Wazuh TRB-005

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: 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

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

1.6 TCER: ADBox UC scenario 2 with Wazuh TRB-006

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: 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

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-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

1.7 TCER: ADBox UC scenario 3 with Wazuh TRB-007

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: 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

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-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

2.0 RADAR test case execution results

2.1 TCER: Setup RADAR foundation TRB-008

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 director 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/TSL certificates

0 = flawless: certificates created and stored successfully

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

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	2025-12-03
tester	AAT
defect-category	0 = flawless
passed-steps	4
failed-steps	0
not-executed-steps	0
release-version	0.5
verification-method	T

2.2 TCER: RADAR build suspicious login TRB-009

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 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: Default 0310 decoder is excluded in ossec.conf:

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

Test case step 2.3: RADAR decoders for suspicious_login are in local_decoder.xml:

0 = flawless: a 0310-ssh_decoders.xml line appears (at least once) within the enclosures.

Test case step 2.4: RADAR rules for suspicious_login are in local_rules.xml:

0 = flawless: local_rules.xml contains a  block with rules for suspicious SSH logins.

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

0 = flawless: suspicious login rule ID(s) references the intended <group>, <options> or <active-response> that trigger ad_context_* and email_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: 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.8: 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.9: radar-helper.service systemd unit is installed, enabled, and running:

0 = flawless: the service is active.

Test case step 2.10: Agent ossec.conf on SSH agent includes the suspicious_login RADAR snippet:

1 = insignificant defect: /var/ossec/etc/ossec.conf exists with owner root:wazuh, mode 0640, and contains a  block inserted before </ossec_config>; the verdict is 1 = insignificant defect because the markers are not replaced, i.e. {_marker} found instead of RADAR, but this does not hamper functionality or usability.

Test case step 2.11: Active response scripts for suspicious_login are present on SSH agents:

0 = flawless: files from radar/scenarios/active_responses/* are present under /var/ossec/active-response/bin/ with owner root:wazuh and mode 0750.

Test case step 2.12: Wazuh agent service is running on SSH agents after restart:

0 = flawless: the status output indicates the agent 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 OR 1 = insignificant defect OR 2 = minor defect OR 3 = major defect OR 4 = critical defect

Defect summary description

Almost defect-free test execution, i.e., defect category: 1 = insignificant defect

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 RADAR: build suspicious login

Attribute	Value
test-date	2025-12-09
tester	AAT
defect-category	1 = insignificant defect
passed-steps	13
failed-steps	0
not-executed-steps	0
release-version	0.5.1
verification-method	T

2.3 TCER: RADAR build non-whitelist GeoIP TRB-010

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 --manager local --manager_exists 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 0644.

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: local_rules.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>.

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.

Test case step 2.9: Agent ossec.conf on SSH agent includes the geoip_detection RADAR snippet.

1 = insignificant defect: /var/ossec/etc/ossec.conf exists with owner root:wazuh, mode 0640, and contains a  block inserted before </ossec_config>; the verdict is 1 = insignificant defect because the markers are not replaced, i.e. {_marker} found instead of RADAR, but this does not hamper functionality or usability.

Test case step 2.10: Wazuh agent service is running on SSH agents after restart.

0 = flawless: status output indicates the agent 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: command output empty.

Defect summary description

Almost defect-free test execution, i.e., defect category: 1 = insignificant defect

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 RADAR: build non-whitelist GeoIP detection

Attribute	Value
test-date	2025-12-09
tester	AAT
defect-category	1 = insignificant defect
passed-steps	11
failed-steps	0
not-executed-steps	0
release-version	0.5.1
verification-method	T

2.4 TCER: RADAR build log volume growth TRB-011

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 --manager local --manager_exists 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: local_decoder.xml contains a RADAR_DECODERS: log_volume block defining decoders that produce a log_bytes field.

Test case step 2.3: RADAR rules for log_volume exist

0 = flawless: local_rules.xml contains a RADAR_RULES: log_volume block with rules using log_bytes for anomaly detection.

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 email_ar.py as intended.

In endpoints running agents

Test case step 2.6: RADAR helper directory and script 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.7: radar-helper.service systemd unit is installed, enabled, and running.

0 = flawless: the service is active.

Test case step 2.8: Agent ossec.conf on agent includes the log_volume RADAR snippet.

1 = insignificant defect: /var/ossec/etc/ossec.conf exists with owner root:wazuh, mode 0640, and contains a {_marker}: log_volume BEGIN/END block inserted before </ossec_config>; the verdict is 1 = insignificant defect because the markers are not replaced, i.e. {_marker} found instead of RADAR, but this does not hamper functionality or usability.

Test case step 2.9: Wazuh agent service is running on SSH agents after restart

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

Post-test cleanup

3 Check the cleanup after successful validations, the command output should be empty:
0 = flawless: command output empty.

Defect summary description

Almost defect-free test execution, i.e., defect category: 1 = insignificant defect

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 RADAR: build log volume abnormal growth

Attribute	Value
test-date	2025-12-09
tester	AAT
defect-category	1 = insignificant defect
passed-steps	10
failed-steps	0
not-executed-steps	0
release-version	0.5.1
verification-method	T

2.5 TCER: Add log volume growth anomaly detector TRB-012

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

Defect-free test execution, i.e., defect category: 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	2025-12-18
tester	AAT
defect-category	0 = flawless
passed-steps	2
failed-steps	0
not-executed-steps	0
release-version	0.6
verification-method	T

2.6 TCER: RADAR suspicious login detection TRB-013

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: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 210*** listed.

0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

0 = flawless: email received.

Defect summary description

Successful test execution, i.e., defect category: 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-046 Suspicious login detection validation

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

2.7 TCER: RADAR non-whitelist GeoIP detection TRB-014

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: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 100309 listed.

0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

0 = flawless: Email received.

Defect summary description

Successful test execution, i.e., defect category: 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 Non-whitelist GeoIP detection validation

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

2.8 TCER: RADAR log volume growth anomaly detector TRB-015

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.

In Wazuh Dashboard

Test case step 1: In rule trigger verification in the Wazuh Dashboard Discovery page

0 = flawless: an entry for rule ID 100309 is registered and an email capturing the alert (EMAIL_TO from .env of TST-041) is received at the specified address.

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

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 Log volume abnormal growth validation

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

2.9 TCER: Setup RADAR foundation TRB-016

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 director 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/TSL certificates

0 = flawless: certificates created and stored successfully

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

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 Setup RADAR foundation v0.7

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

2.10 TCER: RADAR build suspicious login TRB-017

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: Default 0310 decoder is excluded in ossec.conf:

0 = flawless: 0310 SSH 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 0310-ssh_decoders.xml line appears (at least once) within the enclosures.

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) references the intended <group>, <options> or <active-response> that trigger 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 exists 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 OR 1 = insignificant defect OR 2 = minor defect OR 3 = major defect OR 4 = critical defect

Defect summary description

Almost defect-free test execution, i.e., defect category: 1 = insignificant defect

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-050 RADAR: build suspicious login

Attribute	Value
test-date	2026-01-14
tester	DMA
defect-category	1 = insignificant defect
passed-steps	13
failed-steps	0
not-executed-steps	0
release-version	0.7
verification-method	T

2.11 TCER: RADAR build non-whitelist GeoIP TRB-018

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 (if manager is local then the command should be run with sudo):

./build-radar.sh geoip_detection --agent remote --manager local --manager_exists 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 0644.

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: Agent configurations are in place.

0 = flawless: Agent configurations for geoip detection exists.

In endpoints running agents

Test case step 2.8: 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.9: 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: command output empty.

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

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 RADAR: build non-whitelist GeoIP detection

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

2.12 TCER: RADAR build log volume growth TRB-019

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 log_volume --agent remote --manager local --manager_exists 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: The file 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: The agent configurations for log volume exists.

In endpoints running agents

Test case step 2.7: RADAR helper directory and script 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

3 Check the cleanup after successful validations, the command output should be empty:
0 = flawless: command output empty.

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

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 RADAR: build log volume abnormal growth

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

2.13 TCER: Add log volume growth anomaly detector TRB-020

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

Defect-free test execution, i.e., defect category: 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 Run RADAR for log volume abnormal growth

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

2.14 TCER: RADAR suspicious login detection TRB-021

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: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 210*** listed.

0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

0 = flawless: email received.

Defect summary description

Successful test execution, i.e., defect category: 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 Suspicious login detection validation

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

2.15 TCER: RADAR non-whitelist GeoIP detection TRB-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: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 10090* listed.

0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

0 = flawless: Email received.

Defect summary description

Successful test execution, i.e., defect category: 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-055 Non-whitelist GeoIP detection validation

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

2.16 TCER: RADAR log volume growth anomaly detector TRB-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

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: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 100309 listed.

0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

0 = flawless: Email received.

Defect summary description

Successful test execution, i.e., defect category: 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-056 Log volume abnormal growth validation

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

2.17 TCER: RADAR Flowintel case creation via Active Response TRB-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

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 director availability

0 = flawless: radar directory available.

Test case step 2: Verify configuration of .env file with FlowIntel configs

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/TSL certificates

0 = flawless: certificates created and stored successfully

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

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-057 RADAR FlowIntel case creation via Active Response

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

2.18 TCER: RADAR build non-whitelist GeoIP detection with case creation TRB-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

sudo ./build-radar.sh geoip_detection --agent remote --manager local --manager_exists 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 0644.

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: The active response directory /var/ossec/active-response/bin/ has files ar.yaml and pyflowintel.

Test case step 2.8: Agent configurations are in place.

0 = flawless: Agent configurations for geoip detection exists.

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: command output empty.

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

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-058 RADAR: build non-whitelist GeoIP detection with case creation

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

2.19 TCER: RADAR non-whitelist GeoIP detection + Flowintel TRB-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

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: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 10090* listed.

0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

0 = flawless: Email received.

Test case step 3: The FlowIntel case is created in the Cases menu in FlowIntel defined in FLOWINTEL_BASE_URL address.

0 = flawless: FlowIntel case created.

Defect summary description

Successful test execution, i.e., defect category: 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-059 Non-whitelist GeoIP detection validation

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

1.0 ADBox test execution results

1.1 TCER: install ADBox shipping TRB-001

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

1.2 TCER: ADBox deployment TRB-002

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

1.3 TCER: ADBox in dev container TRB-003

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

1.4 TCER: ADBox console TRB-004

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

1.5 TCER: ADBox in default mode with Wazuh TRB-005

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

1.6 TCER: ADBox UC scenario 2 with Wazuh TRB-006

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

1.7 TCER: ADBox UC scenario 3 with Wazuh TRB-007

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

2.0 RADAR test case execution results

2.1 TCER: Setup RADAR foundation TRB-008

Relevant test environment and configuration details

Test execution results

Defect summary description

Text execution evidence

Comments

Guide

2.2 TCER: RADAR build suspicious login TRB-009

Relevant test environment and configuration details

Test execution results

In Wazuh Manager

In endpoints running agents

Post-test cleanup

Defect summary description

Text execution evidence

Comments

Guide

2.3 TCER: RADAR build non-whitelist GeoIP TRB-010

Relevant test environment and configuration details

Test execution results

In Wazuh Manager

In endpoints running agents

Post-test cleanup

Defect summary description

Text execution evidence

Comments

Guide

2.4 TCER: RADAR build log volume growth TRB-011

Relevant test environment and configuration details