HIDS在普通OSSEC或Wazu叉之间进行选择

Question

我打算设立OSSEC，并注意到似乎有两种主要口味:普通OSSEC和Wazu叉。

从我收集到的信息来看(从网站和文档)来看，Wazuh的主要优势是：

• 它与麋鹿结合的能力
• 改进的规则集
• restful

我不想在这个项目中使用ELK，但是我们已经有了一个预先存在的灰日志实例，我想要连接到OSSEC，它应该可以在常规的OSSEC中使用syslog cef格式。

我假设我可以使用改进的规则集，即使我运行常规的OSSEC，至少我还没有看到任何其他的指示。

至于restful，我仍然非常缺乏经验，而且我最近才听说过REST --我甚至不知道该如何开始使用它--所以我不确定是否应该为此使用Wazu叉。

目标是在我们的云环境中的机器上运行OSSEC代理，并将它们指向已经用于在同一网络上进行日志管理和监视的机器中的OSSEC服务器。

运行Wazuh而不是常规的OSSEC还有其他好处吗？还有什么我应该考虑的吗？

Answer 1

关于与OSSEC的Wazuh差异，Wazuh正在更新文档以更好地解释这些文档(以及一个新的发行版和安装程序)。

Wazuh新版本(2.0，目前在主分支下找到)重点如下：

• OpenSCAP集成为代理的一部分，允许用户运行OVAL检查。
• 新的WUI在Kibana 5之上，并与RESTful API集成，以监视管理器的配置、代理的规则和状态。
• 改进日志分析和FIM功能。
• Ruleset与遵从性映射。
• 通过TCP支持代理-管理器通信。一个模块管理器，它将允许将来集成其他工具(路线图中是OSquery和威胁情报来源)

在这里可以找到完整的变更量：

https://github.com/wazuh/wazuh/blob/master/CHANGELOG.md

如果你好奇的话，这里有一些WUI的截图。

https://github.com/wazuh/wazuh-documentation/tree/2.0/source/images/screenshots

同样值得一提的是，Wazuh作为一个分支，是基于OSSEC开发人员和贡献者所做的工作，我们对此表示感谢。Wazuh计划继续为OSSEC Github存储库提供bug修复，但我们也有自己的路线图，因此，很有可能，这两个项目将以不同的方式发展。

Answer 2

虽然我的观点在这里可能存在偏见(我是Wazuh的一员)，但下面是关于OSSEC和Wazuh之间差异的最新情况：

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).
•   Multi-thread support for manager processes, dramatically increaing their performance.

Intrusion detection
•   Improved log analysis engine, with native JSON decoding and ability to name fields dynamically.
•   Increased maximum message size from 6KB to 64KB (being able to analyze much larger log messages).
•   Updated ruleset with new log analysis rules and decoders.
•   Native rules for Suricata, making use of JSON decoder.
•   Integration with Owhl project for unified NIDS management.
•   Support for IP reputation databases (e.g. AlienVault OTX).
•   Native integration with Linux auditing kernel subsystem and Windows audit policies to capture who-data for FIM events.

Integration with cloud providers
•   Module for native integration with Amazon AWS (pulling data from Cloudtrail or Cloudwatch).
•   New rules and decoders for Amazon AWS.
•   Module for native integration with Microsoft Azure.
•   New rules and decoders for Microsoft Azure.

Regulatory compliance
•   Alert mapping with PCI DSS and GPG13 requirements.
•   Compliance dashboards for Elastic Stack, provided by Wazuh Kibana plugin.
•   Compliance dashboards for Splunk, provided by Wazuh app.
•   Use of Owhl project Suricata mapping for compliance.
•   SHA256 hashes used for file integrity monitoring (in addition to to MD5 and SHA1).
•   Module for integration with OpenScap, used for configuration assessment.

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 Osquery, being able to run queries on demand.
•   Implementation of new output options for log collector component.
•   Module for integration with Virustotal, used to detect the presence of malicious files.

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, by Center of Internet Security scanner integration.

链接到文件：

https://documentation.wazuh.com/current/migrating-from-ossec/

这表明，在过去三年中，我们在OSSEC的基础上做了很多工作，我相信，这些工作是有理由使用Wazuh的。