私はOSSECをセットアップするつもりで、2つの主なフレーバーがあることに気づきました:プレーン[〜#〜] ossec [〜#〜]とWazuhフォーク。
私が収集できたことから(Wazuhの website および documentation から)、Wazuhの主な利点は次のとおりです。
このプロジェクトでELKを使用することに関心はありませんが、OSSECに接続したい既存のgraylogインスタンスがすでにあります。これは、syslog cef形式を使用する通常のOSSECで可能になるはずです。
通常のOSSECを実行している場合でも、改善されたルールセットを使用できると思います。少なくとも、それ以外のことを示すものは何も見ていません。
残りのAPIについては、私はまだ非常に経験が浅く、最近REST-それをどのように使用するようになるのかさえ知りません。そのためだけにワズのフォークを使うべきかどうかわからない。
目的は、クラウド環境のマシンでOSSECエージェントを実行し、同じネットワークでログの管理と監視にすでに使用されているマシンのOSSECサーバーを指すようにすることです。
通常のOSSECの代わりにWazuhを実行することの他の利点はありますか?他に考慮すべきことはありますか?
WazuhとOSSECの違いに関して、Wazuhチームはドキュメントを更新して、それらをよりよく説明するように(そして新しいリリースとインストーラーで)取り組んでいます。
Wazuhの新しいバージョン(2.0、現在はmasterブランチの下にあります)のハイライトは次のとおりです。
完全な変更ログはここにあります:
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リポジトリへの貢献を続ける予定ですが、独自のロードマップもあるので、おそらく両方のプロジェクトが異なる方法で進化します。
私の意見はおそらくここで偏っていますが(私は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/
これは、過去3年間にOSSECに加えて私たちが行った多くの作業がWazuhの代わりに正当化されていることを示しています。