Not another “top 10 SIEM tools” listicle — the actual debugging notes from building one.
So I built one. A real Flask application that ingests actual Windows and Linux telemetry, runs it through detection logic I wrote and tuned by hand, and responds to it roughly the way a production SOC tool would — SIEM, Sigma engine, SOAR automation, attack chain correlation, the whole pipeline.
This isn’t a feature list. It’s the actual story of building it, including the parts that didn’t work the first time — because those parts taught me more than the parts that did.
The part I’m most proud of
Individually, alerts are noise. Five failed logons is one brute-force attempt. A privilege escalation an hour later, from the same account, is a completely different situation — except most tools show you both as two disconnected rows in a table and expect you to notice the connection yourself.
So I built a correlation engine: if the same user or IP sets off three or more distinct rule types within an hour, it gets clustered into one incident automatically. Distinct types matter more than raw count on purpose — five failed logons is still one attempt, no matter how you count it, but a brute force followed by a privilege escalation followed by a credential dump is a different, much more serious story, even though it’s also technically three alerts either way.
I want to be upfront that this is a heuristic, not a certainty. A busy admin doing several unusual-but-legitimate things in one hour could, in theory, false-positive into a chain. That’s exactly why it queues for a human to review instead of automatically opening a case or taking any action — the tool notices the pattern, a person decides what it means.
Debugging the forwarder was more educational than building it
I wanted logs from a separate VM, not just the local machine. Straightforward in theory. In practice, it turned into a genuinely useful lesson in why “it should work” and “it works” are different sentences.
First problem: Windows doesn’t log the actual command line on a process-creation event by default. The event fires, but the field that would tell you what actually ran is just empty unless a specific audit policy is turned on. I only found this by staring at real Event Viewer output and noticing the command line field was missing — not a bug in my code, a Windows default nobody warns you about.
Second problem, once I’d wired up Sysmon to fix the first one: Sysmon uses a completely separate event numbering scheme from native Windows events. My forwarder sent Sysmon’s process-creation events under their raw Sysmon ID, but the detection rules that actually catch real attacks are written to check for Windows’ native process-creation ID specifically. Events arrived. The command line was right there in the message. The rule still never fired — because the ID check failed before the message content was ever read.
I found a real security bug in my own security tool
During a self-audit, I found that Sigma rule titles — user-uploaded YAML content — were being inserted into the page completely unescaped. I didn’t just read the code and assume it was fine. I uploaded a Sigma rule with an actual script payload in its title and watched it execute in my browser. That’s the only way to know a stored XSS is real instead of theoretical.
The fix had a subtlety worth knowing about if you ever build something similar: simple HTML escaping isn’t enough for values embedded inside an inline onclick handler, because the browser decodes the attribute before the JavaScript engine parses it as code — so an escaped quote can still reopen a string and break out. Needed a second, separate escaping function specifically for that case.
While auditing, I also noticed the tool that detects brute-force attacks had zero protection against brute force on its own login page. Fixed that too, and routed failed login attempts through the exact same detection pipeline as everything else — so an attack on the SIEM’s own front door now shows up as a real, MITRE-tagged alert instead of disappearing into a log nobody watches.
What it actually does now
35 detection rules spanning brute force, Kerberoasting, process injection, DNS tunneling, PowerShell obfuscation, AMSI bypass attempts — plus a Sigma rule engine that runs the same YAML format used by Splunk and Elastic. Every alert gets MITRE ATT&CK-tagged automatically. The correlation engine turns related alerts into real incidents. Case management, SOAR-style response with hard safety guardrails (it will refuse to block a private IP or disable a protected account no matter who approved it), and a full redesign toward something closer to actual enterprise SOC tooling instead of a “hacker terminal” aesthetic.
Every rule was validated against real Atomic Red Team test runs on an actual Windows Server VM — not synthetic demo data.
What’s still rough, said plainly
SQLite doesn’t handle concurrent writes at real production volume — fine for a lab, would need PostgreSQL for anything real. Everything runs over HTTP, not HTTPS. The Sigma parser covers common condition patterns, not the full specification. And there’s no automated test suite committed to the repo — everything above was tested extensively during development, but that testing lived in my process, not in re-runnable code. That’s the next thing I’d build.
If you want to look at it
Full code, documentation, and the complete rule catalog are on GitHub: github.com/sodik-tursunboev/SIEM
If you’re building something similar and hit a wall, or you just want to talk detection engineering, I’m on LinkedIn: linkedin.com/in/sodik-tursunboev
#Cybersecurity #SIEM #EthicalHacking #Python #Blue Team #SoftwareEngineering