FTT1 - Inventory collection system testing

[juliamagan]

Overview

This issue is dedicated to the comprehensive end-to-end functionality system testing of the Inventory feature. The aim is to ensure the correct operation of all interconnected components and processes involved in the Inventory feature, with a focus on its alerting and state management capabilities. The test coverage spans across multiple operating systems, simulating real-world use and ensuring the robustness of the system across various scenarios.

Feature Architecture and Components

To maintain a centralized system inventory, Wazuh agents collect system information from monitored endpoints and send it to the Wazuh server. The Wazuh Syscollector module is responsible for collecting such data from each agent. The data the Wazuh agent collects includes hardware and operating system information, installed software details, network interfaces, ports, and running processes.

Users can generate system inventory reports from the Wazuh dashboard, which can be valuable resources during threat hunting and IT hygiene exercises. The information contained in the report can be used to identify unwanted applications, processes, services, and malicious artifacts.

The architecture includes:

1. Syscollector module: This module is the core of the feature, which gathers relevant information from the monitored endpoint. Once the agent service starts on a monitored endpoint, the Syscollector module runs periodical scans and collects data on the system properties defined in your configuration.
2. Agent inventory database: The Syscollector module runs periodic scans and sends the updated data in JSON format to the Wazuh server. The Wazuh server analyzes and stores this data in a separate database for each endpoint. The databases contain tables that store each type of system information. You can query the database for specific information using the Wazuh API or the SQLite tool.
3. Alerts index: This manages alerts generated based on information stored in the databases by the Syscollector module.

Test Design

The test design ensures that all components work as intended in an integrated, real-world context. We aim to ensure that the Invenvtory feature behaves reliably, issuing appropriate alerts and maintaining accurate state information across various scenarios.

Chosen Families

• Windows
• MacOS
• Redhat based
• Debian based

Initial Coverage OS

• Windows 11
• Windows Server 2022
• MacOS Ventura or Sonoma (Latest available at tests delivery)
• CentOS 7
• Ubuntu 22.04

This list will be updated accordingly following the new compatibility matrix and tiers system.

Test Cases

Trigger/Condition	Preconditions	Expected Outcome	Type
First syscollector scan	TBD	Expected packages appear in the inventory	Time driven
First syscollector scan	TBD	Expected network interfaces appear in the inventory	Time driven
First syscollector scan	TBD	Expected ports appear in the inventory	Time driven
First syscollector scan	TBD	Expected processes appear in the inventory	Time driven
First syscollector scan	TBD	Expected hardware configuration appear in the inventory	Time driven
First syscollector scan	TBD	Expected operating system configuration appear in the inventory	Time driven
First syscollector scan	TBD	Expected Windows updates appear in the inventory	Time driven
Install package	TBD	New package appears in the inventory	Time driven
Update package	TBD	Package version is updated in the inventory	Time driven
Uninstall package	TBD	Package doesn't appear in the inventory	Time driven
Modify network configuration	TBD	Expected network configuration appear in the inventory	Time driven
Open ports	TBD	New ports appear in the inventory	Time driven
Close ports	TBD	Closed ports don't appear in the inventory	Time driven
Stop processes	TBD	Stopped proccess don't appear in the inventory	Time driven
Start processes	TBD	Expected processes appear in the inventory	Time driven
Update Windows endpoint	TBD	Windows hotfix is updated in the inventory	Time driven
Custom rules	TBD	Alerts are triggered when matching custom rules	Event driven

Test Execution

Security Implications:

• TBD

Performance Expectations:

• TBD

Edge Cases/Exception Cases:

• TBD

Regression Scenarios:

• TBD

Tasks

• Design test module structure
• Design test documentation structure
• Create module testing framework
• TBD

[davidjiglesias]

To be done as part of 5.0 when time comes.