# Improving Threat Detection in Wazuh Using Machine Learning Techniques
## 3 Materials and Methods
### Training Unsupervised ML Techniques
The algorithm relies on two key parameters:

* **eps** (epsilon): the maximum distance between two samples for them to be considered neighbors;
* **min_samples**: the minimum number of neighboring points required to form a dense region. In this study, the parameters were set to eps = 0.3 and min_samples = 3. This configuration means that any data point must have at least two other points within a 0.3-unit radius to be considered part of a cluster. Otherwise, it is labeled as noise. Once initialized, the DBSCAN algorithm was applied to the preprocessed dataset. It assigned cluster labels to each data point. Points that could not be assigned to any cluster were marked with the label \(-\mathbf{1}\), signifying that they were outliers or anomalies. To identify these anomalies, the assigned labels were analyzed, and all points labeled as \(-\mathbf{1}\) were extracted. These instances were flagged in a new column labeled _anomaly_ and isolated in a separate dataset for further inspection. ## 4 Results and Discussion

### Experimental Setup and Real-Time Performance Definition and Measurement

The experimental environment was designed to emulate a realistic Security Operations Center (SOC) deployment while ensuring controlled conditions for reproducible evaluation and upper-bound performance testing. The infrastructure comprised a server environment featuring two Dell PowerEdge R740 servers, each equipped with an Intel Xeon Gold 6248R processor (24 cores, 3.0 GHz), 128 GB of DDR4 RAM, and 2 TB of NVMe SSD storage configured in a RAID 10 setup for enhanced reliability and performance. These servers operated on Ubuntu Server 20.04 LTS, providing a stable foundation for the experiment. The client environment included 12 endpoint devices, consisting of 8 Windows machines,3 Linux systems, and 1 macOS device, with varied hardware configurations to reflect the heterogeneity typical of enterprise settings. These endpoints were interconnected via a 10 Gbps network infrastructure to simulate high-speed data exchange. The Wazuh deployment utilized Wazuh Server version 4.3.10 integrated with Elasticsearch version 7.17.0, with Wazuh agents installed across all 12 endpoints. The configuration incorporated default rule sets supplemented by custom rules tailored to specific attack scenarios alongside standard logging levels and real-time alerting capabilities to ensure comprehensive event monitoring. The development environment leveraged Python 3.9.7, equipped with scikit-learn 1.4.1, pandas 1.4.1, and numpy 1.22.2 for machine learning and data processing tasks, while Jupyter Notebook 7.4.0.facilitated interactive analysis and visualization. We categorize events into three temporal tiers:

* Critical Threat Response (hard real-time): Processing must completed within 100 ms to enable integration with automated response systems (e.g., DDoS mitigation, malware containment). This aligns with industry benchmarks requiring 50-200 ms response windows [2];
* Standard Alert Processing (soft real-time): 95% of events must be completed within 500 ms to balance thorough analysis with operational efficiency;
* Batch Processing: Events exceeding 1 s are queued for low-activity periods to prevent resource bottlenecks. Timing measurements use high-resolution performance counters with microsecond precision, capturing data across all stages: alert ingestion, feature extraction, model inference, result formatting, and output delivery. We conducted 1000+ iterations per test condition, calculating mean, median, standard deviation, and 95 th percentile metrics. Bootstrap sampling (1000 iterations) established 95% confidence intervals, with paired \(t\)-tests (\(p<0.001\)) and Cohen's d for effect size validation. For example, Random Forest inference averaged 45 ms [95% CI: 43-47 ms], DBSCAN 62 ms [95% CI: 59-65 ms], and SVM 48 ms [95% CI: 46-50 ms], all within the 100 ms hard real-time threshold.