My First SIEM Deployment: Logs, Lessons, and a Little Bit of Chaos
If you’ve ever wondered what it feels like to stand up your very first SIEM, let me tell you: it’s a mix of excitement, confusion, triumph, and the occasional “why is this port closed again?” moment. This week, I finally dove into deploying a SIEM inside my CloudShare lab environment—and I’m here to tell the tale.
Spoiler: nothing exploded. But a few things definitely caught fire metaphorically.
Setting the Stage: My CloudShare Playground & Modifications
I’ve been using CloudShare as my personal cybersecurity sandbox—a controlled multi-VM topology containing a Windows Server target, an Ubuntu Linux workstation, and our SIEM stack. Before deploying and ingesting telemetry into the SIEM, I made several specific environment modifications to ensure logs were generated and forwarded properly:
- Windows Server Audit Policies & Sysmon Deployment Advanced Audit Policy: Enabled detailed auditing on the Windows Target via Group Policy (gpedit.msc -> Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration). Specifically enabled Audit Logon (Success/Failure) and Audit Process Creation.
Sysmon Installation: Installed System Monitor (Sysmon v14) with a custom configuration file (sysmonconfig-export.xml) to log process creation, network connections, and PowerShell activity into Microsoft-Windows-Sysmon/Operational.
Command-Line Logging: Enabled Include command line in process creation events via Administrative Templates (System > Audit Process Creation) to capture complete execution strings.
- Linux Syslog Forwarding (rsyslog) To forward Linux system and authentication events to the SIEM over UDP port 514:
Modified /etc/rsyslog.conf on the Ubuntu VM to include the remote logging directive:
. @192.168.1.50:514 (using standard RFC 3164 syslog format).
Restarted the rsyslog service: sudo systemctl restart rsyslog.
- Network & Firewall Adjustments Windows Defender Firewall: Added inbound rules to allow UDP port 514 (Syslog) and TCP port 5985/5986 (WinRM for event collection).
CloudShare Network Rules: Adjusted internal security groups to permit communication across port 514 (Syslog) and 1514/1515 (Agent-to-Manager communication).
🛠️ Deploying the SIEM: The Moment of Truth
I chose an approachable, lightweight open-source SIEM stack for this first run. The deployment process involved:
Spinning up the SIEM Manager VM: Deployed the instance hosting the SIEM stack on CloudShare and updated system repositories.
Agent Installation & Pairing: Installed agent software on both the Windows and Linux endpoints, connecting them securely to the manager IP over TCP port 1514.
Log Source Configuration: Configured the manager to parse incoming Windows Event Logs (Security, System, Application, and Sysmon), alongside Linux /var/log/auth.log and /var/log/syslog.
Validation: Verified log ingestion through the SIEM dashboard, confirming events were populating in real time.
🔬 Running Experiments: AKA "Let's See What Breaks"
Once everything was connected, I executed targeted simulations to see how the SIEM parsed, correlated, and alerted on raw telemetry.
🧪 Experiment 1: RDP Brute Force Simulation
Command/Tool Used: Executed Hydra from an attacker host to perform an automated dictionary attack against the Windows Server via RDP:
hydra -l Administrator -P /usr/share/wordlists/rockyou.txt rdp://192.168.1.10
Generated Logs & Alerts:
Event ID 4625 (An account failed to log in) fired repeatedly in the Windows Security event log.
Key log fields captured: TargetUserName: Administrator, WorkstationName, and IpAddress: 192.168.1.100.
The SIEM correlated multiple threshold breaches into a High Severity Alert: Multiple Failed RDP Logon Attempts (Possible Brute Force).
What I Learned: Threshold-based alerting is critical. Single failed logons happen all the time (typos!), but tracking event velocity (>10 failures in 60s) helps filter out noise from actual attack attempts.
🧪 Experiment 2: Suspicious PowerShell Execution
Command Used: Ran an encoded PowerShell payload on the Windows target to simulate obfuscated malicious execution:
powershell.exe -e aT33eCAtRW5jb2RlZENvbW1hbmQ... (base64 encoded string)
Generated Logs & Alerts:
Sysmon Event ID 1 (Process Creation) logged the parent process (cmd.exe), child process (powershell.exe), and full command-line parameters.
Windows Event ID 4104 (Script Block Logging) captured the decoded execution block.
The SIEM generated a Medium-High Alert: Obfuscated PowerShell Execution Detected.
What I Learned: Standard process logging isn't enough; command-line parameters and Sysmon Event ID 1 are vital for identifying attacker techniques like obfuscation and living-off-the-land binaries (LOLBins).
🧪 Experiment 3: Linux Unauthorized SSH Access Attempt
Command Used: Attempted invalid SSH logins against the Linux VM while monitoring local auth logs:
ssh invalid_user@192.168.1.20
Generated Logs & Alerts:
Captured directly in /var/log/auth.log:
Failed password for invalid user invalid_user from 192.168.1.100 port 54321 ssh2
Forwarded via rsyslog to the SIEM on UDP 514 and mapped to rule ID 5710 (Attempt to login using non-existent user).
What I Learned: Syslog parsing rules rely heavily on regular expressions. Standardizing timestamps across Linux and Windows hosts (using UTC) is essential for proper event correlation.
📊 What I Learned (Besides "Check Your Ports")
Deploying a SIEM for the first time taught me a few important lessons:
Log sources are everything. A SIEM without structured, detailed logs is like a detective without clues. Enabling Sysmon and Advanced Audit Policies made all the difference.
Normalization matters. Windows Event IDs and Linux Syslog use completely different schema formats; the SIEM acts as the central translator that makes cross-platform correlation possible.
Noise is real. Even a tiny 3-node lab generates thousands of events per hour. Fine-tuning baseline rules is necessary to prevent alert fatigue.
Experimentation is the best teacher. Generating actual attacks in a controlled environment gives you direct insight into what SOC analysts see on the monitor during an incident.
🚀 Final Thoughts: Would I Do It Again? Absolutely.
Standing up my first SIEM felt like leveling up in my cybersecurity journey. It wasn’t perfect, and I definitely made my share of syntax and port mistakes, but that’s the beauty of a lab environment—it’s a safe place to learn, break things, and build confidence.
Next up: tuning detections, writing custom rules, and suppressing false positives. But for now, I’m enjoying watching real-time logs stream across the dashboard!
📚 References
Microsoft Learn: Advanced Security Audit Policy Settings
Microsoft Sysinternals: Sysmon v14.1 Documentation & Downloads
RSYSLOG Documentation: Rsyslog Documentation & Configuration Reference
MITRE ATT&CK: Technique T1110: Brute Force
TripleTen Cybersecurity Program: Sprint 11 SIEM Deployment Lab Instructions
