Open source detection tools can give a security team real SIEM, IDS and endpoint visibility without licence fees, but only if the team understands what each project actually does, what its licence allows and what it costs to run. The landscape is crowded and confusing: some "open" platforms are source-available rather than open source, some are single-purpose sensors that need a back end, and some flagship projects have quietly moved to commercial editions. This guide maps the main open source SIEM, log analytics, network and endpoint detection projects, how they fit together, how to deploy them safely and how to measure whether they are working. It is written for SOC leads, detection engineers and security architects in small and mid-sized organisations, and for larger teams building a lab or a second detection layer.
Key takeaways
- A SIEM is a stack, not a product. Open source detection usually combines a collector or agent, a sensor layer (Zeek, Suricata, osquery), a search store (OpenSearch or Elasticsearch) and a rules layer (Sigma, Wazuh rules, Suricata signatures).
- Check the licence before you build. Wazuh core is GPLv2, Suricata GPL-2.0, Zeek BSD and Arkime Apache 2.0, while Graylog server is SSPL v1 and Elasticsearch offers a choice of SSPL, AGPLv3 or Elastic License 2.0.
- Sigma is the portable detection layer. Writing detections in Sigma (over 3,000 community rules under DRL 1.1) keeps them portable if you change back end later.
- The real cost is people and storage. Licence savings are consumed by index sizing, upgrades, parser maintenance and tuning; budget engineering time before you budget hardware.
- The detection stack is itself a target. Exposed search clusters, default credentials and over-privileged agents turn a monitoring tool into a breach path, so harden it like any other tier 0 system.
What the tool does
"Open source SIEM" covers several layers that commercial suites bundle together. The table below places the main projects by role, using the licence stated in each project's own repository or licensing page.
| Project | Layer | What it does | Licence (as published) |
|---|---|---|---|
| Wazuh | SIEM and XDR platform | Agent-based log collection, decoders and rules, file integrity monitoring, configuration assessment (SCA), vulnerability detection, active response; indexer, server and dashboard components | GPLv2 by default; the newer analysis engine is AGPLv3 |
| Security Onion | Network and host monitoring distribution | Bundles Suricata, Zeek, Stenographer, Elastic Agent, ElastAlert 2 and case management into one installable platform | Free and open platform (check each bundled component) |
| OpenSearch with Security Analytics | Search store and SIEM plugin | Document store and dashboards; Security Analytics adds detectors, findings and correlation for ingested logs | Apache 2.0 |
| Elasticsearch and Kibana | Search store and UI | Widely used log back end; many open tools write to it | Source under SSPL 1.0, AGPLv3 or ELv2 (choice); Elastic's own releases under the Elastic License |
| Graylog | Log management | Log ingestion, pipelines and search over OpenSearch or Elasticsearch storage | SSPL v1 (source-available, not OSI open source) |
| Suricata | Network IDS, IPS and NSM | Signature-based detection plus protocol logs in EVE JSON (alert, http, dns, tls, flow, files) | GPL-2.0 (OISF) |
| Zeek | Network security monitoring | Protocol analysis and scriptable policy, producing conn, dns, http, ssl, files, x509, notice and weird logs | BSD |
| Arkime | Full packet capture | Writes PCAP to sensor disk and indexes session metadata in OpenSearch or Elasticsearch | Apache 2.0 |
| osquery | Endpoint telemetry | Exposes the operating system as SQL tables (processes, connections, kernel modules, hashes) on Linux, macOS and Windows | Apache-2.0 and GPL-2.0 licence files |
| Sigma (SigmaHQ) | Detection rule format | Generic YAML signature format for log events, converted to back-end queries with sigma-cli or pySigma | Rules under Detection Rule License 1.1 |
The licence column matters commercially. AGPL and GPL obligations are triggered by distribution or network service, which is rarely an issue for internal use but matters for managed service providers. SSPL places obligations on anyone offering the software as a service, and it is not approved by the Open Source Initiative. Elastic re-added an open source option (AGPLv3) for Elasticsearch and Kibana source in 2024, around the 8.16 release. TheHive, once the default open source case manager, moved to a commercial distribution and its AGPL repository was archived in December 2025, which is a reminder to check a project's current status rather than its reputation.
Defender use cases
- Central log analysis for a small team: Wazuh is the most common single-install answer: agents on Windows, Linux and macOS (also Solaris, AIX and HP-UX), syslog from network devices, and built-in rules mapped to compliance requirements such as PCI DSS. See the Wazuh Guide.
- Network security monitoring: Security Onion packages Zeek and Suricata on sensor nodes fed from a TAP or SPAN port, with full packet capture kept on the sensor. See the Security Onion Guide, the Zeek Network Monitoring Guide and the Suricata IDS Guide.
- Portable detection content: write rules once in Sigma and convert them for OpenSearch, Elasticsearch, Splunk or Microsoft Sentinel. This protects detection investment if you later move to a commercial SIEM. See the Sigma Rules Guide.
- Endpoint visibility without an EDR budget: osquery scheduled queries (osqueryd) for process, listening port and persistence inventory, shipped into the SIEM; Wazuh FIM and SCA for integrity and hardening drift.
- Threat hunting and retro-hunting: Zeek conn and dns logs, Suricata flow records and Arkime sessions let hunters answer "did this indicator ever talk to us" months after the fact, within your retention window. See the Threat Hunting Guide.
- Second detection layer or lab: larger organisations run open tools beside a commercial SIEM to test new detections, ingest high-volume network logs cheaply, or give a red team a realistic target environment.
Deployment and safe use
A phased rollout keeps the scope honest and gives you a rollback point at each stage.
- Define use cases and log sources first. List the 10-20 detections you need (for example, Windows event log clearing, new local administrator, impossible travel, outbound connections from servers) and the sources they require. The joint ASD ACSC, CISA, NSA, FBI and NCSC-UK guidance on event logging and threat detection recommends an approved enterprise logging policy before tooling; NIST SP 800-92 Rev. 1 (initial public draft) frames the same work as log management planning.
- Size storage before installing. Estimate events per second and daily ingest per source, multiply by retention and replica count, and add headroom. Network logs and EVE JSON from busy links usually dominate.
- Build in a lab, then a pilot. Use Security Onion's Import or Evaluation mode, or a single-node Wazuh, against sample PCAP and EVTX files. Security Onion documents Standalone as suitable for labs and low throughput only, and Distributed (manager, search and sensor nodes) as the recommended production layout.
- Onboard sources in rings. Start with domain controllers, identity provider logs, internet-facing servers and firewalls; then servers; then workstations. Validate parsing for each source before adding the next.
- Enable rules in alert-only mode. Run Suricata as IDS rather than inline IPS, and keep Wazuh active response disabled, until you have two to four weeks of baseline and tuned false positives. Active blocking without tuning is the fastest way to lose operational trust.
- Test detections against known behaviour. Replay benign test cases (for example, clearing a test event log on a lab host) and confirm an alert fires end to end with the right fields.
- Plan rollback. Snapshot indices and configuration before upgrades, pin versions, and keep the previous agent package available. Upgrade the search tier and the agents in the order the project documents.
Hardening the stack
- Never expose the store: keep OpenSearch or Elasticsearch, dashboards and APIs off the internet, behind authentication and TLS. The DeepSeek database exposure shows what an unauthenticated log store leaks: a ClickHouse table of over a million log lines containing API keys and chat history. See the Elasticsearch and OpenSearch Security Guide.
- Change every default: default admin passwords, demo certificates and sample users in search clusters and dashboards.
- Secure agent enrolment: protect Wazuh agent registration (port 1515) with a password or certificates, and restrict agent traffic (port 1514) to known networks.
- Limit active response: a central server that can run commands on every agent is a privileged system; restrict who can author response scripts.
- Protect log integrity: forward logs off-host quickly, restrict delete rights on indices, and alert on log pipeline gaps.
Where identity fits
Open source stacks run on machine credentials: agent enrolment keys, ingestion API keys, cloud read-only roles for pulling AWS, Azure and Google Cloud logs, and service accounts that read Windows event logs. Give each its own least-privileged identity, store it in a secrets manager rather than configuration files, and rotate it. A stolen ingestion key lets an attacker read or poison your telemetry. See the Service Account Security Guide and the Secrets Management Guide.
Detection and hardening value
The value of an open detection stack is measured by which attacker behaviours it can see. The mapping below shows typical coverage by layer.
| Behaviour | Example reference | Best open source layer | Log source |
|---|---|---|---|
| Windows event logs cleared | ATT&CK T1685.005 Clear Windows Event Logs | Wazuh rules or Sigma rule in OpenSearch | Security log event 1102, System log event 104 |
| Event logging disabled or tampered | ATT&CK T1685.001 Disable or Modify Windows Event Log | Sigma plus "source went silent" pipeline alert | Windows events, ingestion heartbeat |
| Credential dumping from LSASS | ATT&CK T1003.001 LSASS Memory | Sigma rules on Sysmon process access | Sysmon event 10 |
| Command and control beaconing | Network anomaly | Zeek conn.log analysis, Suricata signatures | conn.log, eve.json flow and alert |
| Suspicious TLS clients | JA3/JA3S fingerprints | Zeek ssl.log | ssl.log |
| Unauthorised file change on servers | Integrity monitoring | Wazuh FIM | Agent FIM events |
| Hardening drift | CIS Benchmark checks | Wazuh SCA, osquery | Agent SCA results, osquery tables |
Metrics that show it is working:
- Source coverage: percentage of critical assets (domain controllers, identity provider, internet-facing servers) sending logs that parse correctly.
- Pipeline health: number of sources silent for more than one hour, and ingestion lag in minutes.
- Detection coverage: ATT&CK techniques with at least one tested, enabled detection, tracked per quarter.
- Alert quality: true positive rate per rule; rules above an agreed false positive threshold get tuned or retired.
- Time to detect: median time from a test event to an alert in the queue.
- Patch currency of the stack: days behind the latest supported release for indexer, server and agents.
Framework mapping
| Framework | Reference | How the stack supports it |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01, DE.CM-03, DE.CM-09 | Network (Zeek, Suricata), personnel activity and endpoint (agents, osquery) monitoring |
| NIST CSF 2.0 | DE.AE-02, DE.AE-03 | Rule analysis and correlation across sources in the SIEM |
| NIST SP 800-53 Rev. 5 | AU-6, AU-12, SI-4 | Audit record generation, review and system monitoring |
| NIST SP 800-53 Rev. 5 | AU-9, AU-11 | Protection and retention of audit information in the store |
| CIS Controls v8.1 | Control 8 Audit Log Management; Control 13 Network Monitoring and Defense | Centralised collection, retention, review and network IDS |
See the CIS Control 8 Audit Log Management Guide and the Log Management and Retention Guide.
Alternatives
| Option | Choose it when | Trade-off |
|---|---|---|
| Wazuh all-in-one | Small team, mixed endpoints, compliance reporting needed, one platform to learn | Network visibility is limited without adding Zeek or Suricata |
| Security Onion | Network monitoring is the priority, you control TAP or SPAN points, you want hunting tools bundled | Heavier hardware; production needs a distributed grid |
| Build your own (OpenSearch plus Sigma plus sensors) | Experienced engineers, need for custom pipelines or very high volumes | You own integration, upgrades and parser maintenance |
| Commercial SIEM with open sensors | Large estate, 24x7 SOC, need for vendor support and SLAs | Ingest-based licence cost; keep Sigma content to stay portable |
| Managed detection service | No capacity to run or staff a SOC | Less control over detections and data location |
Small versus large: under roughly 500 endpoints, a single Wazuh deployment with Sysmon and a handful of Sigma rules is realistic for one or two engineers. Larger estates usually keep open sensors (Zeek, Suricata, osquery) and the Sigma content, but move the store and case management to a supported platform as volume and on-call needs grow. For buying decisions see the SIEM Buyer's Guide; for the fundamentals see the SIEM Guide.
Common failure patterns
- Logs collected, nobody looking: thousands of default rules enabled with no triage owner, so real alerts drown. Start with a short, tested rule set.
- Exposed back end: search clusters or dashboards reachable from the internet with default or no authentication, the same class of failure as the DeepSeek database exposure.
- Silent sources: an agent breaks after an upgrade or an attacker disables logging, and no alert fires because absence of data is never monitored.
- Storage collapse: retention set without sizing, disks fill, indices go read-only and ingestion stops during the incident you needed it for.
- Licence surprise: a provider builds a managed service on an SSPL or AGPL component without legal review.
- Unmaintained projects: continuing to run an archived or end-of-life component (such as TheHive 3 or 4) with no security fixes.
Practitioner checklist
- Record the licence and maintenance status of every component in the stack and review it annually.
- Write the use case list and required log sources before installing anything.
- Size ingest, retention and replicas, then add at least 30 per cent headroom.
- Keep stores, dashboards and APIs private, with TLS, SSO or strong authentication and no default credentials.
- Give agents, ingestion keys and cloud log readers separate least-privileged identities stored in a secrets manager.
- Write detections in Sigma where possible and keep them in version control with test cases.
- Alert on silent sources and ingestion lag, not only on attacker behaviour.
- Run new rules and active response in alert-only mode for a tuning period before blocking.
- Track coverage, pipeline health, alert quality and time to detect monthly.
Standards and references
- NIST: SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide (initial public draft)
- CISA and partners: Best Practices for Event Logging and Threat Detection
- NIST: Cybersecurity Framework 2.0
- Wazuh: Central components documentation
- Security Onion: Architecture
- SigmaHQ: Sigma rule repository
- OISF: Suricata EVE JSON output
- Elastic: Licensing FAQ
Related NHI Mgmt Group resources: Detection Engineering Guide · Open Source DFIR Tools Landscape Guide · NDR Guide · Elastic Security Guide