Log correlation
A detector that never fires looks exactly like a network that is safe
Small SIEM deployments rarely fail loudly. They fail by running, processing, reporting healthy, and concluding nothing. This page covers why that happens, what the free options actually are, and where a single-binary alternative fits.
Three ways a small deployment dies
1. The ingest bill
Priced-per-GB platforms create an incentive that runs against security: the cheapest configuration is the one that collects least. So verbose sources get dropped, retention gets trimmed to weeks, and the log you need during an incident is the one that aged out. A team ends up paying for a SIEM and not having the data.
2. Alert fatigue
A hundred single-line alerts per day, each ambiguous on its own, is not a detection capability. It is a queue nobody reads. The failure is not the volume — it is that each alert lacks the context needed to decide anything, so deciding gets deferred, and then permanently.
3. The silent detector
This is the one worth dwelling on, because it is invisible from every dashboard you have.
I hit it in my own code. One field was never filled: the timestamp on each parsed line. "Five failures in two minutes" quietly became "five failures, ever, since the beginning of time." The cooldown logic inverted. The chain that should have escalated never reached its window.
Nothing errored. It ran. It processed. It reported healthy. It simply never concluded anything — and a detector that has never fired is indistinguishable from a network where nothing has happened.
Two habits that catch this, whatever tool you run.
Reject log lines whose timestamp you could not parse — never silently default them to "now" or to zero. And replay a known-bad sequence on a schedule, then assert the alert appeared. A detector you have never seen fire is a detector you have never tested.
The free options, honestly
These are all good projects run by people who know what they are doing. Pick by shape, not by marketing.
| Project | Shape | Best when | Cost of entry |
|---|---|---|---|
| Wazuh | Agent-based host security platform with a management server and indexer | You want endpoint visibility, FIM and compliance reporting as well as log analysis | Agents to deploy; an indexer to run and size |
| Graylog | Log management and search, with alerting on top | Search and retention are the primary need | Requires supporting datastores; open-source edition trails the enterprise one on some features |
| Security Onion | A whole distribution for network security monitoring | You want IDS, full packet capture and analyst tooling together | It is an appliance-scale commitment, not a service you add |
| Elastic / ELK | Build-your-own — the pieces are excellent, the assembly is yours | You have the time and want full control | Highest operational overhead of the four |
| Loglight this project |
One Go binary with SQLite. Ingest, detect, correlate | One person is responsible and there is no budget for a cluster | Deliberately small — and correspondingly limited, see below |
If you have a team and an infrastructure budget, several of the options above will take you further than Loglight will. The case for something smaller is narrow and specific: a SIEM nobody has time to operate detects nothing at all, and a one-person shop that keeps deferring the Elastic cluster has zero detection in the meantime.
Correlation is the part that matters
Three separate alerts:
10:02 port scan from 203.0.113.44
10:19 47 failed SSH logins from 203.0.113.44
10:26 successful SSH login from 203.0.113.44Read individually, the first two are internet background noise and the third is a normal event. Read together, they are one intrusion with a timeline, and the third line is the one that ends the argument.
That is the whole job: not producing more alerts, but joining the ones you already have so a human sees a story instead of three shrugs.
Loglight
Ingests syslog, plain files, journald, Docker and Windows events. Detects brute force, scanning, exfiltration patterns and new-admin events, and correlates them into kill-chain incidents. One binary, SQLite storage, embedded UI. No telemetry, no outbound connections.
Every other Hexward tool can emit findings as RFC 3164 syslog, so a Decoy trip from an address Loglight already saw scanning becomes one critical incident with the timeline attached, rather than two alerts you have to join up yourself. There is nothing Hexward-specific about the format — any collector works.
Run it
Grab the tarball and SHA256SUMS from the releases page, then:
sha256sum -c SHA256SUMS
tar -xzf loglight-free-0.2.0-linux-amd64.tar.gz
cd loglight-0.2.0
./loglight
# dashboard on http://127.0.0.1:8427 — point one source at itHonest limits
- SQLite on one host. This is not a clustered platform and will not pretend to be — there is a volume above which you need a real indexer.
- No endpoint agent, no file integrity monitoring, no packet capture. If you need those, Wazuh or Security Onion are the better answer.
- Detection content is a starting set, not a maintained threat-intel feed.
- Compliance reporting is not a feature. If an auditor needs a specific report format, check before you commit.
Related: self-hosted deception — the highest-signal input you can feed a correlation engine, because a touched decoy is almost never a false alarm.