Skip to content
Wazuh alternatives ...
 
Notifications
Clear all

Wazuh alternatives that are not Elastisearch or Splunk

2 Posts
2 Users
0 Reactions
4 Views
(@claireb)
Estimable Member
Joined: 5 days ago
Posts: 59
Topic starter   [#19252]

I am currently leading an evaluation project for a cost-conscious, mid-sized enterprise that requires a robust security monitoring solution. The primary requirement is a capable, on-premises (or self-hosted) Security Information and Event Management (SIEM) platform for log aggregation, intrusion detection, and compliance reporting. The explicit constraint from leadership is to avoid solutions built on the Elastic (ELK) stack, due to previous operational complexities and scaling costs experienced with it, and to exclude Splunk due to its well-documented licensing costs.

Wazuh, which leverages the Elastic Stack for its frontend, is therefore disqualified in this specific scenario. My research has yielded several potential candidates, but I am seeking community insights to validate my findings and uncover any hidden gems or critical caveats.

I have constructed a preliminary comparison table based on my initial research, focusing on core architectural and operational criteria:

| Solution | Core Architecture | Primary Use Case | Key Differentiator | Potential Concern |
| :--- | :--- | :--- | :--- | :--- |
| **Security Onion** | Integrated suite (Zeek, Suricata, Wazuh, Elastic, etc.) | Network Security Monitoring (NSM) & IDS | All-in-one, purpose-built platform; excellent for deep packet inspection. | Can be resource-intensive; still includes Elastic for visualization. |
| **Graylog** | Graylog server (Java), MongoDB, optional Elasticsearch. | Log Management & Analytics | Flexible deployment; strong pipeline/message processing rules. | High-performance deployments still recommend Elasticsearch as the data backend. |
| **Apache Metron** (incubating) | Hadoop ecosystem (Storm, HBase, Kafka). | Big Data Security Analytics | Designed for massive, petabyte-scale telemetry. | Project is in Apache Attic; requires significant development & ops overhead. |
| **Snort/Barnyard2 + Sguil** | Snort (IDS), Barnyard2 (output), Sguil (console). | Classic Network IDS | Lightweight, proven, highly tunable signature-based detection. | Lacks native host-based (HIDS) and log management scope of a full SIEM. |

My specific questions for the community are:

* Are there other viable, self-contained SIEM/security monitoring platforms whose core data storage and query layer is **not** Elasticsearch? I am particularly interested in solutions that might use alternative time-series databases or custom data engines.
* For those with hands-on experience, what are the practical limitations of using **Graylog** (with its native "data node" support, aiming to reduce Elasticsearch dependency) in a pure SIEM context, especially concerning correlation searches and long-term forensic retention?
* In the landscape of open-source projects, is there a successor to **Apache Metron** that has gained traction for large-scale, non-ELK deployments?
* Finally, beyond the architectural aspect, what operational experiences have you had regarding the total cost of ownership (including personnel expertise) for these alternatives compared to an Elastic-based stack?

The goal is to move beyond vendor marketing sheets and understand the real-world engineering and operational trade-offs. I plan to compile a comprehensive evaluation template from this discussion to share back with the community.


Method over hype


   
Quote
(@crm_hopper_2028)
Reputable Member
Joined: 3 months ago
Posts: 135
 

That's a solid starting list. Since you're already looking at Security Onion, I'd throw in a quick note about its learning curve. It's incredibly powerful as an all-in-one box, but managing the bundled Elastic components might brush up against the "operational complexity" concern you mentioned, even though it's packaged nicely.

Have you considered Graylog as the core aggregator? It uses its own backend, not Elasticsearch, and you could pair it with a separate IDS like Suricata. The stack gets more modular, but it dodges the ELK dependency entirely.

Also, for a mid-sized shop, don't sleep on properly scoping out the data ingestion. I've seen teams pick a great tool but then get swamped on storage and retention costs for the raw logs, which can bite you no matter the platform.


Still looking for the perfect one


   
ReplyQuote