Do I need a SIEM for a small environment?

Not always a full SIEM, but you do need central, protected logs and alerts on the important events. A lightweight open-source stack such as Wazuh is a good fit for small teams and labs.

Why do SOC teams worry so much about false positives?

Too many noisy alerts cause alert fatigue and real attacks get missed. Good detection engineering tunes rules with context, thresholds, and allow-lists for known-good activity.

Security Logging and SIEM Basics with Wazuh and Sigma

Introduction

You cannot detect or investigate what you did not log. Lack of logging and alerting is its own category in the OWASP Top 10:2025. A security information and event management system, or SIEM, collects logs from many sources, so analysts can search them and receive alerts. This lesson covers what to log, a hands-on Python example, Wazuh, and the vendor-neutral Sigma rule format.

Prerequisites

Basic Python
A Linux VM with SSH, from the hardening lesson

Step-by-Step Guide

Step 1: Decide what is worth logging

Start with events that signal attacks or misuse: successful and failed logins, privilege changes, new accounts, process creation, access control failures, configuration changes, firewall and IDS alerts, and administrative actions. Keep accurate time with NTP, because correlating events across systems depends on synchronized clocks. Never log passwords, tokens, or full card numbers, and protect logs from tampering by sending copies to a separate system.

Windows Security events that matter early:
  4624  successful logon
  4625  failed logon
  4672  special privileges assigned at logon
  4688  a new process was created (needs auditing enabled)
  1102  the audit log was cleared

Linux:  /var/log/auth.log on Debian and Ubuntu, or  journalctl -u ssh

Step 2: Write a small detector in Python

A quick script shows what a SIEM rule does at heart: parse events, count by source, and alert on a threshold. This one reads an SSH log and reports addresses with many failed logins. It is a teaching example, since real systems stream logs continuously and handle many formats.

import re
from collections import Counter

FAILED = re.compile(r"Failed password for (?:invalid user )?(\S+) from (\S+) port")
THRESHOLD = 5

failures = Counter()
with open("/var/log/auth.log", encoding="utf-8", errors="replace") as log:
    for line in log:
        match = FAILED.search(line)
        if match:
            user, ip = match.groups()
            failures[ip] += 1

for ip, count in failures.most_common():
    if count >= THRESHOLD:
        print(f"ALERT: {count} failed SSH logins from {ip}")

Step 3: Understand what Wazuh provides

Wazuh is a free, open-source security platform that combines SIEM and XDR features. Lightweight agents on your endpoints collect logs, check file integrity, inventory software, detect vulnerabilities, and assess configuration against benchmarks. A central server analyzes events with decoders and rules, and an indexer and dashboard let you search and visualize alerts. It is well suited to a home lab SOC.

Step 4: Install Wazuh in your lab

The Wazuh quickstart installs the server, indexer, and dashboard on one machine with an installer script, and it needs a machine with a few gigabytes of RAM. Check the official quickstart documentation for the current script URL and system requirements, because the version number in the address changes. Then add an agent to your Linux VM using the deployment command that the dashboard generates for you.

# Wazuh server VM: follow the current Quickstart at documentation.wazuh.com
curl -sO https://packages.wazuh.com/<version>/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

# The dashboard then gives you a ready-made command to install an agent
# on each endpoint. Run that command on the endpoint VM.

Step 5: Generate events and watch the alerts

From your attacker VM, fail a few SSH logins against the monitored VM, and run an Nmap scan, both inside your lab. Open the Wazuh dashboard and find the authentication failure alerts and their rule IDs. Practice answering questions: which host, which user, from where, and how many times. This is the daily loop of a SOC analyst, and tuning rules to reduce noise is a big part of the job.

Step 6: Learn Sigma, a shared rule format

Sigma is an open, vendor-neutral format for writing detection rules in YAML, so one rule can be converted to the query language of many SIEMs. A rule has metadata, a logsource saying where the events come from, a detection section with selections and a condition, and a level. This example flags a cleared Windows Security log, which attackers do to hide their tracks. Generate your own unique id for each rule.

title: Windows Security Event Log Cleared
id: 00000000-0000-0000-0000-000000000000   # replace with a generated UUID
status: experimental
description: Detects clearing of the Windows Security audit log.
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 1102
    condition: selection
falsepositives:
    - Authorized administrative log maintenance
level: high

FAQs

Do I need a SIEM for a small environment?: Not always a full SIEM, but you do need central, protected logs and alerts on the important events. A lightweight open-source stack such as Wazuh is a good fit for small teams and labs.
Why do SOC teams worry so much about false positives?: Too many noisy alerts cause alert fatigue and real attacks get missed. Good detection engineering tunes rules with context, thresholds, and allow-lists for known-good activity.

Summary

Log the events that matter, keep clocks synced and logs protected, understand detection by writing a threshold script, use Wazuh to collect and alert in your lab, and write portable detections in Sigma.