Wazuh Open Source SIEM Overview

0
110
Wazuh Open Source SIEM Overview

Wazuh is a scalable multi-platform, open-source host-based intrusion detection (HIDs) system. It was born as folk of strong correlation and analysis engine of Ossec. Wazuh has become a more comprehensive solution by integrating with Elastic Stack and OpenSCAP. Wazuh has a log analysis, file integrity checking, Windows Registry monitoring, rootkit detection, real-time warning, and active response structure. It can work on many operating systems, including Linux, OpenBSD, FreeBSD, MacOSX, Solaris and Windows.

Also Read: How to Setup Wazuh Open Source SIEM Virtual Machine

The main capabilities that are provided by Wazuh are as follow:

  • Security Analytics
    Wazuh is used to collect, aggregate, index and analyze security data, helping organizations detect intrusions, threats, and behavioral anomalies.As cyber threats are becoming more sophisticated, real-time monitoring and security analysis are needed for fast threat detection and remediation. That is why our light-weight agent provides the necessary monitoring and response capabilities, while our server component provides the security intelligence and performs data analysis.Wazuh Security Events
  • Intrusion Detection
    Wazuh agents scan the monitored systems looking for malware, rootkits, and suspicious anomalies. They can detect hidden files, cloaked processes or unregistered network listeners, as well as inconsistencies in system call responses. In addition to agent capabilities, the server component uses a signature-based approach to intrusion detection, using its regular expression engine to analyze collected log data and look for indicators of compromise.
  • Log Data Analysis
    Wazuh agents read the operating system and application logs and securely forward them to a central manager for rule-based analysis and storage. The Wazuh rules help make you aware of application or system errors, misconfigurations, attempted and/or successful malicious activities, policy violations and a variety of other security and operational issues.
  • File integrity Monitoring
    Wazuh agents read the operating system and application logs and securely forward them to a central manager for rule-based analysis and storage. The Wazuh rules help make you aware of application or system errors, misconfigurations, attempted and/or successful malicious activities, policy violations and a variety of other security and operational issues.Wazuh File Integrity Monitoring
  • Vulnerability Detection
    Wazuh agents read the operating system and application logs and securely forward them to a central manager for rule-based analysis and storage. The Wazuh rules help make you aware of application or system errors, misconfigurations, attempted and/or successful malicious activities, policy violations and a variety of other security and operational issues.
  • Configuration Assessment
    Wazuh agents read the operating system and application logs and securely forward them to a central manager for rule-based analysis and storage. The Wazuh rules help make you aware of application or system errors, misconfigurations, attempted and/or successful malicious activities, policy violations and a variety of other security and operational issues.
  • Incident Response
    Wazuh provides out-of-the-box active responses to perform various countermeasures to address active threats, such as blocking access to a system from the threat source when certain criteria are met. In addition, Wazuh can be used to remotely run commands or system queries, identifying indicators of compromise (IOCs) and helping perform other live forensics or incident response tasks.
  • Regulatory Compliance
    Wazuh provides some of the necessary security controls to become compliant with industry standards and regulations. These features, combined with its scalability and multi-platform support help organizations meet technical compliance requirements. Wazuh is widely used by payment processing companies and financial institutions to meet PCI DSS (Payment Card Industry Data Security Standard) requirements. Its web user interface provides reports and dashboards that can help with this and other regulations (e.g. GPG13 or GDPR).
  • Cloud Security Monitoring
    Wazuh helps to monitor cloud infrastructure at an API level, using integration modules that are able to pull security data from well-known cloud providers, such as Amazon AWS, Azure or Google Cloud. In addition, Wazuh provides rules to assess the configuration of your cloud environment, easily spotting weaknesses. In addition, Wazuh light-weight and multi-platform agents are commonly used to monitor cloud environments at the instance level.
  • Containers Security
    Wazuh provides security visibility into your Docker hosts and containers, monitoring their behavior and detecting threats, vulnerabilities and anomalies. The Wazuh agent has native integration with the Docker engine allowing users to monitor images, volumes, network settings, and running containers. Wazuh continuously collects and analyzes detailed runtime information. For example, alerting for containers running in privileged mode, vulnerable applications, a shell running in a container, changes to persistent volumes or images, and other possible threats.

Signature-based log analysis

Automated log analysis and management accelerate threat detection. There are many cases where evidence of an attack can be found in the logs of your devices, systems, and applications. Wazuh can be used to automatically aggregate and analyze log data.

The Wazuh agent running on the monitored host is usually the one in charge of reading operating system and application log messages, forwarding those to the Wazuh server where the analysis takes place. When no agent is deployed, the server can also receive data via Syslog from network devices or applications.

Wazuh uses decoders to identify the source application of the log message and then analyze the data using application-specific rules. Here is an example of a rule used to detect SSH authentication failure events:

 

<rule id="5716" level="5">
  <if_sid>5700</if_sid>
  <match>^Failed|^error: PAM: Authentication</match>
  <description>SSHD authentication failed.</description>
  <group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
</rule>

Rules include a match field used to define the pattern the rule is going to be looking for. It also has a level field that specifies the resulting alert priority.

The manager will generate an alert every time an event collected by one of the agents or via Syslog matches a rule with a level higher than zero.

Once generated by the manager, the alerts are sent to the Elastic Stack component where they are enriched with Geolocation information, stored and indexed. Kibana can then be used to search, analyze and visualize the data. See below an alert as displayed in the interface:

File integrity monitoring

The File integrity monitoring (FIM) component detects and alerts when operating system and application files are modified. This capability is often used to detect access or changes to sensitive data. If your servers are in scope with PCI DSS, the requirement 11.5 states that you must install a file integrity monitoring solution to pass your audit.

A good summary of file changes can be found in the FIM dashboard which provides drill-down capabilities to view all of the details of the alerts triggered.

Rootkits detection

The Wazuh agent periodically scans the monitored system to detect rootkits both at a kernel and user level. This type of malware usually replaces or changes existing operating system components in order to alter the behavior of the system. Rootkits can hide other processes, files or network connections like itself.

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

Active Response

The Wazuh Active Response capability allows scripted actions to be taken in response to specific criteria of Wazuh rules being matched. By default, AR is enabled in all agents and all standard AR commands are defined in ossec.conf on the Wazuh manager, but no actual criteria for calling the AR commands are included. No AR commands will actually be triggered until the further configuration is performed on the Wazuh manager.

For the purpose of automated blocking, a very popular command for blocking in Linux is using the iptables firewall, and in Windows the null routing / blackholing, respectively:

<command>
    <name>firewall-drop</name>
    <executable>firewall-drop.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
</command>

 

<command>
    <name>win_route-null</name>
    <executable>route-null.cmd</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
</command>

Each command has a descriptive <name> by which it will be referred to in the <active-response> sections. The actual script to be called is defined by <executable>. The <expect> the value specifies what log field (if any) will be passed along to the script (like srcip or username). Lastly, if <timeout_allowed> is set to yes, then the command is considered stateful and can be reversed after an amount of time specified in a specific <active-response> section (see timeout). For more details about configuring active response, see the Wazuh user manual.

Security Configuration Assessment

SCA performs scans in order to discover exposures or misconfigurations in monitored hosts. Those scans assess the configuration of the hosts by means of policy files, that contain rules to be tested against the actual configuration of the host. For example, SCA could assess whether it is necessary to change password related configuration, remove unnecessary software, disable unnecessary services, or audit the TCP/IP stack configuration.

Policies for the SCA module are written in YAML format. This was chosen due to having human readability in mind, which allows users to quickly understand and write their own policies or extend the existing ones to fit their needs. Furthermore, Wazuh is distributed with a set of policies, most of them based on the CIS benchmarks, a well-established standard for host hardening.

Here is an example from policy cis_debian9_L2.yml:

- id: 3511
  title: "Ensure auditd service is enabled"
  description: "Turn on the auditd daemon to record system events."
  rationale: "The capturing of system events provides system administrators [...]"
  remediation: "Run the following command to enable auditd: # systemctl enable auditd"
  compliance:
    - cis: ["4.1.2"]
    - cis_csc: ["6.2", "6.3"]
  condition: all
  rules:
    - 'c:systemctl is-enabled auditd -> r:^enabled'

System inventory

The main purpose of this module is to gather the most relevant information from the monitored system.

Once the agent starts, Syscollector runs periodically scans of defined targets (hardware, OS, packages, etc.), forwarding the newly collected data to the manager, which updates the appropriate tables of the database.

The agent’s inventory is gathered for different goals. The entire inventory can be found at the inventory tab of the Wazuh APP for each agent, by querying the API to retrieve the data from the DB. Also, the Dev tools tab is available, with this feature the API can be directly queried about the different scans being able to filter by any desired field.

In addition, the packages and hotfixes inventory is used as feed for Vulnerability detection.

Since Wazuh 3.9 version, Syscollector module information can be used to trigger alerts and show that information in the alerts’ description.

To allow this configuration, in a rule declaration set the <decoded_as> a field as syscollector.

As an example, this rule will be triggered when the interface eth0 of an agent is enabled and will show what IPv4 has that interface.

<rule id="100001" level="5">
    <if_sid>221</if_sid>
    <decoded_as>syscollector</decoded_as>
    <field name="netinfo.iface.name">eth0</field>
    <description>eth0 interface enabled. IP: $(netinfo.iface.ipv4.address)</description>
</rule>

When the alerts are triggered they will be displayed in Kibana this way:

Cloud security monitoring

Wazuh helps to monitor Amazon Web Services and Microsoft Azure infrastructures.

Amazon Web Services

Wazuh helps to increase the security of an AWS infrastructure in two different, complementary ways:

  • Installing the Wazuh agent on the instances to monitor the activity inside them. It collects different types of system and application data and forwards it to the Wazuh manager. Different agent tasks or processes are used to monitor the system in different ways (e.g., monitoring file integrity, reading system log messages and scanning system configurations).
  • Monitoring AWS services to collect and analyze log data about the infrastructure. Thanks to the module for AWS, Wazuh can trigger alerts based on the events obtained from these services, which provide rich and complete information about the infrastructure, such as the instances configuration, unauthorized behavior, data stored on S3, and more.

Microsoft Azure

The Activity Log provides information on subscription level events that have occurred in Azure, with the following relevant information:

  • Administrative Data: Covers the logging of all creation, update, deletion and action operations performed through the Resource Manager. All actions performed by a user or application using the Resource Manager are interpreted as an operation on a specific resource type. Operations such as write, delete, or action involve logging both the start and the success or failure of that operation in the Administrative category. The Administrative category also includes any changes to the role-based access control of a subscription.
  • Alert Data: Contains the log of all activations of Azure alerts. For example, we will be able to obtain an alert when the percentage of CPU usage of one of the virtual machines of the infrastructure exceeds a certain threshold. Azure provides the option to elaborate customized rules to receive notifications when an event coincides with the rule. When an alert is activated it is logged in the Activity Log.
  • Security Data: Here we contemplate the log of alerts generated by the Azure Security Center. For example, a log could be related to the execution of suspicious files.
  • Service HealthData: Covers the log of any service health incident that has occurred in Azure. There are five different types of health events: Action Required, Assisted Recovery, Incident, Maintenance, Information or Security, logged when a subscription resource is affected by the event.
  • Autoscale Data: Contains the logging of any event related to the autoscale engine based on the autoscale settings in your subscription. Autoscale start events and successful or failed events are logged in this category.
  • Recommendation Data: Includes Azure Advisor recommendation events.

To monitor the activities of our infrastructure we can use the Azure Log Analytics REST API or we can directly access the content of Azure Storage accounts. This section explains the two ways to proceed, looking at the steps to follow in the Microsoft Azure portal and using the azure-logs module on the Wazuh manager.

Here is an example of rules for alerts generation:

<rule id="87801" level="5">
    <decoded_as>json</decoded_as>
    <field name="azure_tag">azure-log-analytics</field>
    <description>Azure: Log analytics</description>
</rule>

<rule id="87810" level="3">
    <if_sid>87801</if_sid>
    <field name="Type">AzureActivity</field>
    <description>Azure: Log analytics activity</description>
</rule>

<rule id="87811" level="3">
    <if_sid>87810</if_sid>
    <field name="OperationName">\.+</field>
    <description>Azure: Log analytics: $(OperationName)</description>
</rule>

 

Containers security monitoring

Docker

All the features available in an agent can be useful to monitor the Docker server. The Docker wodle collects events on Docker containers such as starting, stopping or pausing.

In order to use the Docker listener module, it is only necessary to enable the wodle in the /var/ossec/etc/ossec.conf the file of the server running docker or this can also be done through central configuration management for agents. It will start a new thread to listen to Docker events.

<wodle name="docker-listener">
    <disabled>no</disabled>
</wodle>

That it for this article in the upcoming articles we will be covering more about how each component works.