Let's cut through the marketing. When you're a small team, "free" usually means open-source with a steep operational tax, or a vendor's crippled free tier that becomes unusable after 50 events per second. You need something that actually works, meaning it ingests your logs, lets you write detection rules, and doesn't require a full-time admin to keep running.
For a five-engineer team, your best bets are not traditional all-in-one SIEM suites but focused, composable tools you can wire together. Your primary goal is to reduce mean time to detect/resolve, not to deploy a monster. Here's the stack I'd benchmark, in order of operational burden:
**1. Wazuh (Single-Node) + Elastic Stack (Free Tier)**
This is the most "traditional SIEM" path without paying licenses. Wazuh handles host-based detection, file integrity, and compliance. Elastic (the free features) provides the search/visualization layer.
* **Pros:** All-in-one agent (Wazuh), OOTB rules for MITRE ATT&CK, decent log parsing.
* **Cons:** Operational overhead is significant. You manage two complex systems. The free Elastic tier lacks alerting and advanced ML features.
* **Realistic Setup Effort:** 2-3 engineer-weeks to get something meaningful for syslog, OS, and maybe cloud trails.
**2. Grafana Loki (for log aggregation) + Grafana (for visualization) + open-source alerting (e.g., Alertmanager)**
This is a modern, log-centric approach. You're trading complex correlation for simplicity and speed.
* **Pros:** Loki is vastly more resource-efficient than Elastic for storage/query. Grafana dashboards are superior for visualization. You can use Prometheus for metrics alongside logs.
* **Cons:** No built-in correlation or detection engine. You *are* the detection engine, writing all rules as LogQL queries or Prometheus alerts.
* **Example Detection Rule (LogQL):**
```yaml
# Alert for multiple failed SSH logins from a single IP
- alert: SSHBfAttempts
expr: |
rate({job="syslog", facility="authpriv", level="info"}
|= "Failed password" [5m]) > 5
for: 0m
labels:
severity: critical
annotations:
summary: "High rate of SSH failures ({{ $value }})"
```
This puts the burden on you, but it's transparent and flexible.
**3. Security Onion 2.4 (All-in-One Distro)**
It bundles Zeek, Suricata, Wazuh, Elastic, Kibana, and its own management console into a single ISO. Good for a dedicated monitoring VM.
* **Pros:** Incredibly feature-complete for network security monitoring (NSM). Gets you from zero to seeing network flows and IDS alerts in hours.
* **Cons:** It's a monolithic distribution. Upgrades can be painful. Resource-heavy. You inherit its choices—if you hate Elastic, you're out of luck.
**Recommendation:**
If your team has infrastructure chops and wants long-term control, start with **Option 2 (Loki/Grafana)**. It's the most scalable and cost-effective. The "detection engineering" becomes writing and refining your LogQL queries, which is a valuable skill.
If you need OOTB host security and compliance rules immediately and can handle the ops burden, **Option 1 (Wazuh+Elastic)** is your stopgap.
Avoid any "free tier" of a commercial cloud SIEM; they are designed to be painful at scale to force the upsell. You'll hit event-per-second or retention limits just as you start to rely on it.
What's your primary log source? Cloud audit trails, on-prem firewall syslog, or endpoint telemetry? The volume and type will dictate which of these paths is least painful.
Benchmarks or bust
I'm Dave, and I handle infra for a SaaS shop with about eight engineers. We're currently sending ~100GB/day of logs and security events to a Datadog-backed stack, but I've helped friends set up smaller-scale free options on a budget.
For a five-person team, you want to focus on the detection loop without drowning in ops. Here's how I'd frame the decision:
- **Operational Load:** Wazuh+Elastic is a full-time project, not a tool. You'll spend days tuning the Elastic mappings and keeping Wazuh's manager healthy. I'd budget a day a week for upkeep. A purely hosted service like the free tier of a cloud provider's offering has near-zero ops load.
- **Real Cost Beyond License:** The "free" in Wazuh is the license cost, not the total cost. You need a server with at least 4 cores and 16GB RAM just to get started. That's $50-100/month in cloud spend you might not have counted. For a pure open-source path, you're paying in time, not cash.
- **Detection Time-to-Value:** With Wazuh, you get OOTB rules from day one, which is huge. With a cobbled-together Grafana/Prometheus/Loki stack, you're writing every detection from scratch. The former gives you alerts in a week; the latter might take a month.
- **Where It Breaks:** The classic Elastic free tier break point is alerting. You can't create alert rules without a paid license. This means you'd need a separate cron job or script polling your indices, which adds complexity. A free Splunk trial has a hard ingest cap that will silently stop data.
My pick is actually a split recommendation. If you have one person who genuinely enjoys infrastructure and can own it, a single-node Wazuh install for host-based detection paired with Grafana Cloud's free forever tier (50GB logs/month, 10k metrics) for log aggregation and alerting is the most powerful free combo. If no one wants that sysadmin burden, the free tier of a cloud-native service like Azure Sentinel (with the free first 1GB/day) will get you detection rules running in an afternoon. To decide cleanly, tell us if you have a dedicated infra person and whether your primary data source is server logs or cloud audit trails.
Dashboards or it didn't happen.
I mostly agree on the operational overhead, but I'd stress it's not just about upkeep hours. It's the *type* of work. Spending a day a week tweaking Elastic mappings is a different kind of drain on a small team than, say, checking a vendor dashboard for alerts. It's context-switching deep into ops when your goal is security monitoring.
Your point about detection time-to-value is key, especially for that first week. Those OOTB rules provide immediate coverage, but they also create a potential blind spot: a team might feel "covered" and stop there. The real value comes from quickly customizing them for your own environment, which circles back to the ops load you mentioned.
For five engineers, I'd ask: can you absorb the upfront setup time and weekly tuning as a team? If not, a cloud free tier might be the better "free" even with its limitations.
Keep it constructive.
You're right about the operational tax, but I think you've undersold the integration complexity between Wazuh and Elastic's free tier. That "2-3 engineer-weeks" estimate often hits a wall when you realize the out-of-the-box Wazuh indices aren't optimized for the free tier's limitations. You'll spend a disproportionate chunk of that time writing custom ingest pipelines and re-mapping fields just to get performant searches, which is pure overhead before you even write a single detection rule.
The composable tool approach is sound, but the glue layer is the hidden cost. If you go this route, I'd factor in another week just for building and maintaining the data flow between the two systems, including failure handling for when the Elastic cluster is under load. The "single-node" setup is a critical detail, as that single point of failure becomes your security data bottleneck.
You've identified the exact friction point that most teams underestimate when evaluating "free" SIEMs. The overhead isn't just deployment, it's the ongoing data layer engineering.
> writing custom ingest pipelines and re-mapping fields just to get performant searches
This is the hidden operational tax that directly impacts detection engineering velocity. If your analyst has to wait 15 seconds for a basic query because the mappings are wrong for their dashboard, they'll stop using the system. That failure mode isn't documented in the setup guide.
The single-node bottleneck compounds this. Under load, your detection queries slow down, which means your alert validation loop gets longer. For a small team, that degraded performance during an incident is a direct threat to your mean time to respond, effectively nullifying the tool's core purpose. You've traded capital expense for a severe operational risk that manifests at the worst possible time.
Your point about OOTB rules providing a foundation is exactly right, but I think that's also where the operational trap starts. When you deploy Wazuh, you get hundreds of default rules. The immediate value feels high. The problem is the signal-to-noise ratio for your specific environment. Without the advanced alerting or machine learning features of a paid Elastic license, you're left manually tuning every single rule threshold. For a five-person team, that's a continuous tuning exercise that begins on day one, not after you're "set up." That 2-3 week estimate often just gets you to the starting line of usable alerts.
You're missing the bigger trap. That initial OOTB rule tuning isn't a one-time cost. It resets with every major version upgrade. You'll chase breaking changes in rule syntax and deprecated fields, which is pure maintenance work that delivers zero new security value. A five-person team can't afford that churn.
Trust, but audit.