Wazuh is usually used to meet compliance requirements (such as PCI DSS or HIPAA) and configuration standards (CIS hardening guide). It is also very popular among IaaS users (such as Amazon AWS, Azure or Google Cloud), and deploying host-based IDS in running instances can be combined with infrastructure event analysis (extracted directly from cloud provider API).

Here are some common use cases:

(1) Log Analysis Based on Signature

(2) file integrity monitoring

(3)rootkit detection

(4) Security policy monitoring

Second, log analysis based on signature.

Automatic log analysis and management accelerates threat detection. In many cases, evidence of attacks can be found in the logs of devices, systems and applications. Wazuh can be used to automatically aggregate and analyze log data.

Wazuh agent running on the monitoring host is usually responsible for reading operating system and application log messages and forwarding these messages to Wazuh server for analysis. When no agent is deployed, the server can also receive data from network devices or applications through syslog.

Wazuh uses a decoder to identify the source application of the log message, and then uses application-specific rules to analyze the data. The following are examples of rules for detecting SSH authentication failure events:

The rule includes a matching field that defines the pattern that the rule will look for. It also has a level field that specifies the priority of generated alerts.

Manager generates an alert whenever an agent or event collected through syslog matches a rule with a level greater than zero.

The following is an example in/var/ossec/logs/alerts/alerts.json:

Once generated by the manager, the alert is sent to the elastic stack component, where it is enriched by storing and indexing geographic location information. Kibana can then be used to search, analyze and visualize data. The warning is displayed in the following interface:

Wazuh provides a default rule set that is updated regularly, providing more than 1600 rules for different applications.

Third, file integrity monitoring.

When operating system and application files are modified, the file integrity monitoring (FIM) component will detect and issue an alarm. This feature is usually used to detect access to or changes to sensitive data. If your server is within the scope of PCI DSS, the requirements of 1 1.5 indicate that you must install a file integrity monitoring solution to pass the audit.

The following is an example of generating a warning when a monitored file changes. Metadata includes MD5 and SHA 1 checksums, file size (before and after changes), file permissions, file owners, content changes and who made these changes. File integrity monitoring

The FIM dashboard provides a drill-down function to view all the details that triggered the alarm, from which a good summary of file changes can be found.

Fourthly, rootkit detection.

Wazuh agent periodically scans the monitoring system to detect the kernel and user-level rootkit. This malware usually replaces or changes existing operating system components to change the behavior of the system. Rootkit can hide other processes, files or network connections, just like itself.

Wazuh uses different detection mechanisms to find system anomalies or known intrusions. This is done periodically by the Rootcheck component:

The following is an example of an alert generated when a hidden process is found. In this example, the affected system is running a Linux kernel-level rootkit (named Diamorph):

Verb (abbreviation of verb) security policy monitoring

SCAP is a standardized compliance inspection solution for enterprise infrastructure. It is a set of specifications maintained by the National Institute of Standards and Technology (NIST), aiming at maintaining the security of enterprise systems.

OpenSCAP is an auditing tool, which makes use of Extensible Configuration Inventory Description Format (XCCDF). XCCDF is a standard method to express the contents of the checklist and define the safety checklist. It is also combined with other specifications (such as CPE, CVE, CCE and OVAL) to create a list that can be represented by scap for scap-verified products.

Wazuh agent uses OpenSCAP internally to verify whether the system meets the CIS hardening standard. The following is an example of a SCAP rule to check whether the SSH daemon is configured to allow empty passwords:

SCAP checks run regularly (once a day by default), and the results are set to the Wazuh server, where they are processed through OpenSCAP decoders and rules. The following are examples of warnings generated when the Linux Audit Policy (auditd) is not configured to monitor user actions:

In addition, Wazuh WUI can also be used to visualize and analyze the scanning results of policy monitoring. For example, the following is a screenshot of the data collected when scanning a CentOS system using a server benchmark and a PCI DSS v3 predefined profile: