Wazuh Integration
dmitry....@seznam.cz
I'm loving ELK so far. One question I do have is that would it be possible to integrate Wazuh into the Security Onion now that is also runs ELK? I feel like this would be an incredibly useful solution myself
Josh Silvestro
I personally don't have any experience with Wazuh, but it appears to just be OSSEC built up a bit. Have you considered looking at beats? I moved from OSSEC to all beats deployment and love the amount of data I'm getting.
I've also followed the following SOS Sysmon configuration to add additional data such processes data, file access, etc.
Wes Lambert
--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
dmitry....@seznam.cz
Interesting I will check it out
dmitry....@seznam.cz
> Wazuh is on the roadmap to replace our existing OSSEC component, however, as Josh has mentioned, Beats are another option.
>
>
> Thanks,
> Wes
>
>
> On Thu, May 3, 2018 at 4:13 PM, 'Josh Silvestro' via security-onion <securit...@googlegroups.com> wrote:
> Dmitry,
>
>
>
> I personally don't have any experience with Wazuh, but it appears to just be OSSEC built up a bit. Have you considered looking at beats? I moved from OSSEC to all beats deployment and love the amount of data I'm getting.
>
>
>
> I've also followed the following SOS Sysmon configuration to add additional data such processes data, file access, etc.
>
>
>
> https://github.com/SwiftOnSecurity/sysmon-config
>
>
>
>
>
> --
>
> Follow Security Onion on Twitter!
>
> https://twitter.com/securityonion
>
> ---
>
> You received this message because you are subscribed to the Google Groups "security-onion" group.
>
>
> To post to this group, send email to securit...@googlegroups.com.
>
> Visit this group at https://groups.google.com/group/security-onion.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
> --
>
>
> https://twitter.com/therealwlambert
>
> https://securityonion.net/
That is great you guys do great work thank you very much!
Kevin Branch
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
dmitry....@seznam.cz
> Hi Dmitry,
>
>
> I have used OSSEC in production starting around a decade ago, until several years back when I switched to Wazuh. Wazuh used to be a simple OSSEC fork with some cool extras like PCI-tagged rules, but especially in the last couple of years they have done extensive development that has taken what OSSEC does, to a dramatically new level. I have Security Onion and the Wazuh/Elasticstack installs at multiple customer sites where I provide MSSP services, and I consider both indispensable to my operations. In my opinion Wazuh really is the future of OSSEC, and it should be a piece of cake to integrate into stock Security Onion. I've done it manually for years.
>
>
> Whether or not you want to have Wazuh dump directly into SO's Elasticsearch depends on your data retention and replication requirements. For me, I want to hold onto at least parts of my Wazuh-collected log data much longer than my massive streams of Bro records will ever last in SO's Elasticsearch. I also want the Wazuh-collected log data in a multi-node Elasticsearch cluster with data replication. Eventually I may try to use cross cluster search to join together SO Elastic and Wazuh Elastic sources, as these data collections are so very complimentary for security analysis and monitoring purposes. You have likely seen the awesome SO Elastic dashboards. You should also have a look at the Wazuh Kibana app (https://documentation.wazuh.com/current/index.html#example-screenshots).
>
>
> Beats and Wazuh both have pros and cons for conveying logs to the Elastic Stack. If you are mainly focued on conveying the logs, then Beats may be the best fit for your use case. I am very impressed with how Winlogbeat conveys Windows logs (including event log channels) in a structured way for dynamic parsing of all Windows log fields. I also understand there are native Filebeat modules for parsing a few other kinds of application logs like Nginx and MySQL.
>
>
> If in addition to conveying and parsing logs, you also want HIDS analysis of those logs, then Wazuh is really the way to go, since it provides a HIDS rule feed of over 1600 different rules spanning many different log sources. It also natively parses logs from over 75 different applicaitons. You can do a certain level of HIDS analysis without Wazuh by using ElastAlert to periodically query Elasticsearch for pattern matches, but you have to collect your own rules and I doubt this would scale well for the purposes of broad HIDS analysis of your log data.
>
>
> As with anything, it really depends on your specific use case. I hope my comments are helpful for evaluating what is best for you.
>
>
> Regards,
> Kevin Branch
>
Kevin Branch
Here are some of the features we’ve added to OSSEC:
*Scalability and reliability*
- Cluster support for managers to scale horizontally.
- Support for Puppet, Chef, Ansible and Docker deployments.
- TCP support for agent-manager communications.
- Anti-flooding feature to prevent large burst of events from being lost or negatively impact network performance.
- AES encryption used for agent-manager communications (instead of Blowfish).
*Installation and configuration management*
- MSI signed package for Windows systems, with auto registration and configuration support.
- Unified RPM and Deb Linux packages.
- Support for AIX, Solaris, Mac OS X and HP-UX.
- RESTful API for status monitoring, querying and configuration management.
- Ability to upgrade agents from the managers.
- Improved centralized configuration management using agent groups.
*Intrusion detection*
- Improved log analysis engine, with native JSON decoding and ability to name fields dynamically.
- Updated ruleset with new log analysis rules and decoders.
- Native rules for Suricata, making use of JSON decoder.
- Native integration with Owhl project for Suricata.
- Support for IP reputation databases (e.g. AlienVault OTX).
- Module for native integration with Amazon AWS (pulling data from Cloudtrail).
*Regulatory compliance*
- Alert mapping with PCI DSS and GPG13 requirements.
- Compliance dashboards in Kibana.
- Use of Owhl Suricata mapping for compliance.
- SHA256 hashes used for file integrity monitoring (in addition to MD5 and SHA1).
*Elastic Stack integration*
- Provides the ability to index and query data.
- Data enrichment using GeoIP logstash module.
- Kibana plugin used to visualize data (integrated using Wazuh REStful API).
- Web user interface pre-configured extensions, adapting it to your use cases.
*Incident response*
- Module for collection of software and hardware inventory data.
- Ability to query for software and hardware via RESTful API.
- Module for integration with third-party tools (e.g. GRR or osquery).
- Implementation of new output options for log collector component.
- Module for integration with Virustotal.
*Vulnerability detection and configuration assessment*
- Dynamic creation of CVE vulnerability databases, gathering data from OVAL repositories.
- Cross correlation with applications inventory data to detect vulnerable software.
- Module for integration with OpenScap allows the user to remotely configured scans.
- Support for CIS-CAT scanner integration.
Kevin