Wazuh infrastructure for large deployments

[Essa Sannat]

Hi All,

In my company, we support ~7000 devices. We use tripwire enterprise mainly for real time policy compliance monitoring. We are considering to replace it with an open source alternative. I start evaluating Wazuh for the past week and need to clarify some points:
- What are the hardware , storage and network requirements for large deployments?
- What is the average cost for an enterprise subscription?

Best Regards,
Essa

[Kat]

I've done that at a couple of companies -the most prominent saved $1M in the first year. Not to mention the load difference on heavily loaded servers - TW killed them and ossec/WAZUH dropped to almost nothing. And with clustering in the Wazuh implementation, this gives you lots of control. I just ran larger servers - since disk I/Os ere the big problem, and database size - so the faster the disks, the better. And something else I found to help greatly - bonded NICs to handle single IP but failover sine they were on different switches. 

Original OSSEC was single threaded and that was a bottleneck, but with clustering in Wazuh, it is no longer the case. 

I had servers than could handle 20,000 agents, but I would suggest load balancing and failover by configuring a cluster of 2-4 masters to handle 7000 agents and then you don't have to spend the money on bigger servers like I did.

-Kat

[Santiago Bassett]

Thank you Kat for the feedback. I can confirm, as a Wazuh engineer, that quite a few of our users have replaced Tripwire with our solution. 

One of the main gaps with Tripwire, was the ability to capture the who-data (who changes a file and how), as opposed to just alert that a file has been changed. Tripwire, afaik, can do this by installing a kernel module to monitor file system calls. 

Wazuh has recently implemented this capability using Linux audit subsystem and Windows SACL natively, the agent itself takes care of configuring audit policies, so no additional configuration needs to be done. No kernel modules are installed either. This feature is already available in our Github repository for 3.4, which will be released as the stable version next week. I believe it adds a ton of value to FIM capabilities (remember that, in addition to FIM, Wazuh also provides SIEM, IDS and Incident response capabilities).

Regarding average cost for the enterprise subscription. There is no such a thing. All software is completely free open source so once the solution is deployed (in enterprise environments or not), the users completely own it (no vendor lock-in, and flexibility to adapt it to your needs). Wazuh just offers services such as professional support, training courses, assistance with deployments, etc. 

I hope it helps,

Santiago.

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/45fc5bd7-f535-4cf7-85b5-051978cda0c7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Essa Sannat]

Thank you guys for your detailed answers. As a matter of fact, we also would save ~1M when we get rid of tripwire. I’m looking forward to test the new features in the next release.

Regards,
Essa

[Louis Bernardo]

I can confirm that Wazuh is the best option for large enterprises and as Kat stated it is simply a case of having the right hardware in place and thinking about the design before hand. If you are however going to deal with a significant amount of alerting volumes I would additionally spend some time planning your ELK stack/cluster. Getting this right from the start will make life much simpler in the future. Invest in the time to review it properly. I am currently running a 3 node cluster with failover configured on the end points (not even using a load balancer at this point) and I am processing close somewhere between 300 and 500 million events per week depending on maintenance work being performed.