Blocks-lab: Introduction
This write-up summarizes the purpose of the lab and the scope of the implementation.
“A SIEM (Security Information and Event Management) is a cybersecurity solution that centrally collects, analyzes, and evaluates security logs and events originating from networks and systems”
Google Gemini
Problem definition
My experience in the field is manual deployment of Wazuh, and these experiences show that getting such a system up and running requires a lot of time and resources. Starting with data collection: installing servers and agents and then configuring them is the initial challenge (a quick look at Wazuh’s documentation reveals its complexity), followed by data processing and the creation of visualizations, tables, diagrams, and reports.
Approach
Although SIEM systems can vary depending on the user’s needs, a SIEM system built around the following evaluation criteria and supported by clear, structured visualizations already provides a solid foundation — whether for longer-term use or for more customization:
| Category | Metrics/Visualizations |
|---|---|
| File Integrity | Recent file changes, change trends |
| Policy Changes | Important config changes |
| Authentication | Logon/logoff attempts, failed logins, geolocation |
| User Monitoring | New/deleted users, privilege changes |
| Threat Detection | Detected malware/threats, severity charts |
What is the solution?
Make installation, configuration, and presentation automatable. The goal is to start using the SIEM system as soon as possible. I created this lab with the aim of minimizing the time and effort required to build the infrastructure.
The lab’s two technological pillars are Terraform and Ansible. This is represented in the figure above by the automation blocks: infrastructure on the left (built with Terraform) and service on the right (built with Ansible). Both automation blocks must be highly configurable. Without aiming for completeness: the network, security groups, Linux versions, IP addresses, and the directories to be scanned should all be configurable — even before starting the automatic deployment.
Infrastructure
The components and connections of the lab’s infrastructure — whether cloud or on‑prem — are described by Terraform code. Its other task is to prepare the server for using Ansible (see jumpstart.sh).
Service
Environment, Config, Assets: these three words define the server-side framework of the solution, and they also make up the larger part of the implementation. The Ansible role responsible for server deployment has three main tasks:
- installing the software environment and dependencies (environment),
- configuring the SIEM system (config),
- installing the reports and visualizations (assets).
An Ansible role is also prepared for configuring the clients, which, in the case of Wazuh, includes only installing the agents and their basic configuration. Monitoring fine-tuning is performed in the server-side configuration.