HIDS - Scegliere tra la normale forcella OSSEC o Wazuh

Naviga le tue risposte
7

Intendo impostare OSSEC e ho notato che sembrano esserci due sapori principali: plain OSSEC e Wazuh .

Da ciò che sono stato in grado di raccogliere (dal sito Web a documentazione ), i principali vantaggi di Wazuh sono:

  • la sua capacità di integrazione con ELK
  • un set di regole migliorato
  • API restful

Non ho alcun interesse ad usare ELK per questo progetto, ma abbiamo già un'istanza di Grayl preesistente che mi piacerebbe collegare con OSSEC, che dovrebbe essere possibile in OSSEC regolare usando il formato cef syslog.

Suppongo di poter usare il set di regole migliorato anche se eseguo OSSEC regolare, almeno non ho visto nulla che indichi il contrario.

Per quanto riguarda l'API riposante, sono ancora molto inesperto e ho sentito parlare solo di REST - Non so nemmeno come inizierei a utilizzarlo - quindi non sono sicuro se dovrei usare la forcella Wazuh solo per quello.

L'obiettivo è di eseguire gli agenti OSSEC sulle macchine nel nostro ambiente cloud e indirizzarli a un server OSSEC in una macchina già utilizzata per la gestione e il monitoraggio dei registri sulla stessa rete.

Ci sono altri vantaggi nel far girare Wazuh invece del normale OSSEC? C'è qualcos'altro che dovrei prendere in considerazione?

    
posta simoesf 27.01.2017 - 12:32
fonte

2 risposte

6

Riguardo alle differenze di Wazuh con OSSEC, il team di Wazuh sta lavorando all'aggiornamento della documentazione per spiegarle meglio (e su una nuova versione e installatori).

I punti salienti di Wazuh nuova versione (2.0, attualmente trovato sotto il ramo principale) sono:

  • OpenSCAP integrato come parte dell'agente, che consente agli utenti di eseguire OVAL controlli.
  • Nuovo WUI su Kibana 5 e integrato con RESTful API per monitorare la configurazione del gestore, le regole e lo stato di agenti.
  • Analisi del registro e funzionalità FIM migliorate.
  • Set di regole con mappatura della conformità.
  • Comunicazioni agente-manager su TCP supportate. Un gestore di moduli che consentirà l'integrazione futura di altri strumenti (nella roadmap sono presenti le fonti di OSquery e Threat Intelligence)

Il log delle modifiche completo può essere trovato qui:

link

Se sei curioso, ecco alcuni screenshot della WUI.

link

Vale anche la pena ricordare che il progetto Wazuh, come un fork, si basa sul lavoro svolto dagli sviluppatori e dai contributori OSSEC ai quali siamo grati. Wazuh intende continuare a contribuire al repository Github di OSSEC con correzioni di bug, ma abbiamo anche la nostra tabella di marcia quindi, molto probabilmente, entrambi i progetti si evolveranno in modi diversi.

    
risposta data 14.03.2017 - 09:09
fonte
2

Anche se la mia opinione è probabilmente parziale (faccio parte del team di Wazuh), ecco un aggiornamento sulle differenze tra OSSEC e 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.

Link alla documentazione:

link

Questo dimostra che c'è sicuramente molto lavoro che abbiamo svolto in OSSEC negli ultimi tre anni che, credo, giustifichi invece l'uso di Wazuh.

    
risposta data 23.08.2018 - 06:22
fonte

Leggi altre domande sui tag

Perchè la debolezza di SHA-1 è considerata una minaccia alla sicurezza TLS Crittografia asimmetrica e firma eseguita a mano