I'd been reading about SIEM tools for months before I actually touched one.
SIEM — Security Information and Event Management — shows up in almost every SOC job description. It's the platform analysts live in. The place where logs flow in, alerts fire, and investigations begin. I knew what it was conceptually. But knowing what something is and actually deploying one are two completely different things.
Lab 11 was the day I stopped reading about it and started building.
What I Was Setting Up
The goal was straightforward on paper: deploy Elastic Cloud Serverless SIEM, enroll an Elastic Agent on my Kali Linux host, and confirm that logs were actually flowing into the platform.
Three steps. One outcome — a working SIEM pipeline.
What nobody tells you before you start is that "straightforward on paper" and "smooth in practice" rarely mean the same thing in a lab environment.
Step 1: Standing Up Elastic Cloud Serverless
Elastic offers a free cloud trial that's more than enough to get a functional SIEM environment running. The Serverless option is the right choice for a home lab — no infrastructure to manage, no Elasticsearch cluster to babysit. You spin up a Security project, and Elastic handles the backend.
The setup process itself is guided. You create an account, start a new Security project, and land in Kibana — Elastic's web interface where everything lives. The dashboard is clean and purpose-built for security work. Integrations, detection rules, alerts, and the Discover interface for raw log querying are all right there.
First impression: this is a real tool. Not a toy, not a simplified student version. The same platform security teams use in production environments.
Step 2: Enrolling Elastic Agent on Kali Linux
Elastic Agent is the component that actually collects logs from your host and ships them to the SIEM. Getting it enrolled on my Kali Linux machine was the most technically involved part of the lab.
The process runs through Kibana's Fleet interface — Elastic's agent management console. You create an agent policy, download the agent package for Linux, and run an enrollment command that registers the agent with your cloud instance.
The enrollment command looks something like this:
sudo ./elastic-agent install \
--url=<your-fleet-server-url> \
--enrollment-token=<your-token>
Once that runs successfully, the agent shows up as enrolled in Fleet. Green status. Connected.
That moment — watching the agent appear as active in the console — is one of those small wins that feels bigger than it probably should. Because it means the pipeline is alive. Data is moving.
Step 3: Confirming Log Ingestion
The final step was verifying that logs from the Kali host were actually arriving in Elastic. This is where a lot of first-time setups fall apart — the agent enrolls, but the data doesn't flow the way you expect.
In Kibana's Discover interface, I queried for events from the enrolled host and confirmed that system logs were coming through. The timestamps were current. The host name matched. The data was real.
Pipeline confirmed.
What This Lab Actually Taught Me
Setting up a SIEM from scratch teaches you something that reading about SIEM never does: you learn where the data actually comes from.
It's easy to think of a SIEM as a magic box that knows everything happening on your network. It's not. It only knows what you tell it. Every log source has to be explicitly configured. Every agent has to be enrolled. Every data stream has to be verified.
The intelligence of a SIEM is only as good as the instrumentation behind it. And the analyst who understands that — who knows not just how to query the data but where the data comes from and why it might be missing — is going to be more effective than one who just knows how to run searches.
That lesson was worth more than the lab itself.
What's Next
Lab 11 got the pipeline running. Lab 12 is where things get interesting — that's where I started building detection rules. Taking a live SIEM with real log data and teaching it to recognize an attack.
That's the post coming next.
If you want to follow along with the actual lab work, the full documented report is on my GitHub: github.com/RouteToRoot
Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io
