Building a Cybersecurity Lab for Detection, Simulation, and Analysis

When learning cybersecurity, one of the biggest gaps is the difference between theory and real system behavior. Reading about attacks, logs, or detection logic is useful, but it does not fully show how these elements interact in a real environment.

The objective of this project was to close that gap by creating a self-contained lab where I could safely simulate activity, collect logs, analyze behavior, and validate detections without relying on external systems or assumptions.

Instead of focusing on a single tool or concept, the goal was to build an environment that supports continuous learning — a place where multiple scenarios can be tested, observed, and improved over time.

I approached this project by treating the lab as a small network rather than a single machine. This made it possible to simulate interactions between systems, which is critical for understanding real-world security events.

The lab was built using VirtualBox and configured as an isolated internal network. This allowed multiple systems to communicate with each other while keeping all activity contained and safe from external exposure.

At the center of the environment is a Wazuh SIEM server, responsible for collecting logs, processing events, and generating alerts. Around that, I deployed systems that serve different roles in the lab, including a Linux server, a Windows endpoint, and a Kali Linux machine used to simulate attacker behavior.

The environment was designed to represent a simplified but realistic network. Each system plays a role in generating or monitoring activity, which allows me to observe how events move through the environment and how they are captured by the SIEM.

The Linux server is used for authentication testing, service interaction, and log generation. The Windows endpoint is included to support future work involving endpoint telemetry, logging, and detection using tools like Sysmon.

The Kali Linux machine acts as a controlled attacker system. It is used to generate activity such as brute-force attempts and other test scenarios, which can then be analyzed through logs and alerts in Wazuh.

By combining these systems, the lab creates a closed environment where both normal and suspicious behavior can be observed and understood in a practical way.

After setting up the systems, the next step was validating that logs were being generated, collected, and processed correctly. This involved configuring Wazuh agents, confirming connectivity between systems, and verifying that activity appeared in the SIEM dashboard.

I tested different types of system activity to ensure that logs were captured consistently. This included authentication events, service interactions, and simulated attack behavior generated from the Kali system.

During this phase, troubleshooting played a major role. Not all configurations worked as expected on the first attempt, which required reviewing logs, adjusting configurations, and validating results until the system behaved as intended.

This process was important because it reinforced the idea that security work is not just about setup, but about validation and understanding how systems behave under different conditions.

This lab is the foundation for all future projects in my portfolio. It provides a consistent environment where scenarios can be tested, detections can be validated, and findings can be documented in a way that reflects real security workflows.

More importantly, it allows me to move beyond theoretical knowledge and develop a practical understanding of how systems behave, how events are captured, and how detection logic can be applied in real-world situations.

Every future project builds on this foundation, which helps show progression over time rather than isolated exercises.