Wazuh Replace EDR

[Eric]

Hello Everyone, 

We are considering to implement replace Bitdefender EDR with open source SIEM (Wazuh). I see many things about Wazuh working on since we used it a few months ago to monitor our cloud infrastructure. It's awe-inspiring. Now, we are a lot of desktops that using Bitdefender EDR. I want to remove Bitdefender EDR on all of the desktops. It's using many OS different like Windows 10, Windows 7, macOS (300 machines). Then set up Wazuh Agent to replace. With this method, we can reduce costs by using Wazuh Agent instead of using EDR. So, I have a few questions that need clarity. 

1/ Wazuh itself has the features of an Endpoint Detection and Response (EDR). So it can be replaced entirely with the functions of EDR like Bitdefender EDR, Kaspersky EDR. If yes, please could you list some of the capabilities with EDR comparison? 

2/ If no, we must keep the software of EDR on the desktop. Is it conflict with Wazuh Agent? If I want to integrate EDR with Wazuh. How can I do that? Please could you share a way to go?

Regards,

[Alejandro Ruiz Gonzalez]

Hello!

The Wazuh architecture is based on agents, running on the monitored endpoints, that forward security data to a central server. Moreover, agentless devices (such as firewalls, switches, routers, access points, etc.) are supported and can actively submit log data via Syslog, SSH, or using their own API. The central server decodes and analyzes the incoming information, and passes the results along to an Elasticsearch cluster for indexing and storage.

I will send you a summary of our capabilities:

An Elasticsearch cluster is a collection of one or more nodes that communicate with each other to perform read and write operations on indexes. Small Wazuh deployments, which do not require processing large amounts of data, can easily be handled by a single-node cluster. Multi-node clusters are recommended when there is a large number of monitored endpoints, when a large volume of data is anticipated, or when high availability is required.

In your case, you said that you have 300 machines more or less. In the all-in-one deployment, both the Wazuh server and Elastic Stack are installed on the same host. A typical use case for this kind of environment supports around 100 agents. I would recommend you install a Distributed deployment, you can find more information about this here:

https://documentation.wazuh.com/current/installation-guide/requirements.html#distributed-deployment

Now,  I will send you a summary about the capabilities of Wazuh:

Log data collection: Log data collection is the real-time process of making sense out of the records generated by servers or devices. This component can receive logs through text files or Windows event logs. It can also directly receive logs via remote syslog which is useful for firewalls and other such devices. 

The purpose of this process is the identification of application or system errors, mis-configurations, intrusion attempts, policy violations or security issues.

The memory and CPU requirements of the Wazuh agent are insignificant since its primary duty is to forward events to the manager. However, on the Wazuh manager, CPU and memory consumption can increase rapidly depending on the events per second (EPS) that the manager has to analyze.

The below image illustrates how events flow through the Wazuh environment.

File integrity monitoring: Wazuh’s File integrity monitoring (FIM) system watches selected files and triggering alerts when these files are modified. The component responsible for this task is called syscheck. This component stores the cryptographic checksum and other attributes of a known good file or Windows registry key and regularly compares it to the current file being used by the system, watching for changes.

The FIM module is located in the Wazuh agent, where runs periodic scans of the system and stores the checksums and attributes of the monitored files and Windows registry keys in a local FIM database. The module looks for the modifications by comparing the new files’ checksums to the old checksums. All detected changes are reported to the Wazuh manager.

Auditing who-data: From version 3.4.0, Wazuh incorporates a new functionality which obtains the who-data information from monitored files.

This information contains the user who made the changes on the monitored files and also the program name or process used to carry them out.

-Auditing who-data in Linux: The who-data monitoring functionality uses the Linux Audit subsystem to get the information about who made the changes in a monitored directory. These changes produce audit events that are processed by syscheck and reported to the manager.

-Auditing who-data in Windows:The who-data monitoring functionality uses the Microsoft Windows auditing subsystem to get the related information about who made modifications in a monitored directory. These changes produce audit events that are processed by syscheck and reported to the manager. This feature is only compatible with systems greater than Windows Vista.


Anomaly and malware detection: Anomaly detection refers to the action of finding patterns in the system that do not match the expected behavior. Once malware (e.g., a rootkit) is installed on a system, it modifies the system to hide itself from the user. Although malware uses a variety of techniques to accomplish this, Wazuh uses a broad spectrum approach to finding anomalous patterns that indicate possible intruders.

The main component responsible for this task is rootcheck, however, Syscheck also plays an important role.

You can find here more information about How it Works.

Security Configuration Assessment: There are multiple Wazuh integrations that perform configuration assessment scans (see Policy monitoring section) including CIS-CAT and more recently the Security Configuration Assessment (SCA). The SCA was created by the Wazuh development team to overcome limitations that were inherent to the other integrations, to name a few:

• The CIS-CAT tool is proprietary software which requires an external license for its use.

• The Rootcheck module depends on the Syscheck daemon and its policies feeds are often outdated.

The Security Configuration Assessment (SCA) module aims to provide the user with the best possible experience when performing scans about hardening and configuration policies. Some of its key features include:

• The last state of each scanned check of every policy is stored in the manager and can be consulted by the SCA tab in the Wazuh App.

• To avoid alert flooding and repeated alerts in each scan. Now, only state changes and new checks are alerted, being those states updated in the manager database.

• Current policies used by Rootcheck have been enriched and updated to a new YAML format. CIS policies are based on CIS benchmarks.
  

You can find here more information about it:

• What is SCA
  
• How SCA works

Monitoring security policies: Policy monitoring is the process of verifying that all systems conform to a set of predefined rules regarding configuration settings and approved application usage.

Wazuh uses three components to perform this task: Rootcheck, OpenSCAP, and CIS-CAT.

Monitoring system calls: The Linux Audit system provides a way to track security-relevant information on your machine. Based on preconfigured rules, Audit proves detailed real-time logging about the events that are happening on your system. This information is crucial for mission-critical environments to determine the violator of the security policy and the actions they performed.

Audit uses a set of rules to define what is to be captured in the log files. There are three types of Audit rules that can be specified:

• Control rules allow the Audit system’s behavior and some of its configuration to be modified.

• File system rules, also known as file watches, allow the auditing of access to a particular file or a directory.

• System call rules allow logging of system calls that specified programs makes.

Command monitoring: There are times when you may want to monitor things that are not in the logs. To address this, Wazuh incorporates the ability to monitor the output of specific commands and treat the output as though it were log file content.

Active response: Active responses perform various countermeasures to address active threats, such as blocking access to an agent from the threat source when certain criteria are met.

Active responses execute a script in response to the triggering of specific alerts based on the alert level or rule group. Any number of scripts can be initiated in response to a trigger, however, these responses should be considered carefully. Poor implementation of rules and responses may increase the vulnerability of the system.

Agentless monitoring: Agentless monitoring allows you to monitor devices or systems with no agent via SSH, such as routers, firewalls, switches and linux/bsd systems. This allows users with software installation restrictions to meet security and compliance requirements.

Alerts will be triggered when the checksum on the output changes and will show either the checksum or the exact diff output of the change.

Anti-flooding mechanism: This mechanism is designed to prevent large bursts of events on an agent from negatively impacting the network or the manager. It uses a leaky bucket queue that collects all generated events and sends them to the manager at a rate below the specified events per second threshold. This helps to avoid the loss of events or unexpected behavior from the Wazuh components.

Additionally, agent modules can be configured to limit their event production rate, reducing the risk of saturating the leaky bucket’s buffer.

Agent labels: This feature allows the user to customize the alert information from agents to include specific information related to the agent generating the alert. This can prove useful when addressing or reviewing alerts. In addition, in large environments this capability can be used to identify groups of agents by any common characteristic like their time zone, for example.

System inventory: The Wazuh agents are able to collect interesting system information and store it into an SQLite database for each agent on the manager side. The Syscollectormodule is in charge of this task.

Vulnerability detection: Wazuh is able to detect vulnerabilities in the applications installed in agents using the Vulnerability Detector module. This software audit is performed through the integration of vulnerability feeds indexed by Canonical, Debian, Red Hat, and the National Vulnerability Database. Check here How it works.

VirusTotal integration: Wazuh can scan monitored files for malicious content in monitored files. This solution is possible through an integration with VirusTotal, which is a powerful platform that aggregates multiple antivirus products along with an online scanning engine. Combining this tool with our FIM engine provides a simple means of scanning the files that are monitored to inspect them for malicious content.

Osquery: Wazuh module that allows to manage the Osquery tool from Wazuh agents, being able to set the Osquery configuration and collect the information generated by Osquery to send it to the manager, generating the corresponding alerts if necessary.

Osquery can be used to expose an operating system as a high-performance relational database. This allows you to write SQL-based queries to explore operating system data.

Agent key polling: Wazuh module that allows fetching the keys stored on an external database.

This module allows retrieving the agent information from an external database, like MySQL or any database engine, for registering it to the client.keys file.

To do this, it is necessary to create a binary or script in any language that can be integrated into your database engine and thus request the agents’ information. The wazuh-authd daemon must be running.

Below you can see the flow diagram:

Fluentd forwarder: This module allows Wazuh to forward messages to a Fluentd server. Fluentd it’s an open source data collector logger that comes along with great plugins to build your own logging layer.

This module allows the forwarding of the received messages from a dedicated UDP socket to a Fluentd server. The Fluentd server could be located on the same local machine or a remote machine.

Wazuh-Logtest: The Wazuh-Logtest whole solution was designed to replace ossec-logtest, now allowing to test and verify rules and decoders remotely, sharing the rules engine with wazuh-analysisd. 

 Regarding the deplyment, It can be deployed on-premises or in hybrid and Cloud. environments.

In addition, if you want is possible to integrate Bitdefender and Kaspersky with Wazuh.

Hope this was useful to you. 

Don't hesitate to contact us if you have any other questions.

[Eric]

Hello Alejandro, 

Sorry for the late reply. I got all of the answers.

Thank you so much for being so supportive & contributing to the community. 

Regards, 

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/0ab36488-02de-497e-882a-7e7024d503e6n%40googlegroups.com.