Skip to main content

How to start configuring a compliance security tool on your Node?

SSH into the Node: Access your Node through SSH using the credentials provided. You will need the IP address or hostname of the Node and the appropriate SSH client on your local machine.

Locate the ossec.conf file: Most of the configurations for Compliance Security Tool are done in the "ossec.conf" file. The file path is typically /var/ossec/etc/ossec.conf on Linux systems.

Configure Each Module: Within the "ossec.conf" file, you can configure each module as needed. Modules are responsible for monitoring specific aspects of your system, such as logs and events. Enable and adjust the modules based on your requirements.

That's it! These are the essential steps to get started with configuring your Node. Remember to save the changes you make to the "ossec.conf" file and restart the Compliance Security Tool service for the changes to take effect.

How to configure the File Integrity module?

The FIM(File Integrity module) module runs scans on Windows, Linux, and macOS operating systems. You must specify the directories where the File Integrity Monitoring module must monitor the creation, modification, and deletion of files or configure the specific files you need to monitor. You can specify the file or directory to monitor on the Compliance Security Tool server and the Compliance Security agent configuration files. You can also configure this capability remotely using the centralized configuration file.

Following, you can see how to configure the File Integrity Monitoring module to monitor a file and directory. Replace FILEPATH/OF/MONITORED/FILE and FILEPATH/OF/MONITORED/DIRECTORY with your own file paths.

Add the following settings to the Compliance Security agent configuration file, replacing the directories values with your own file paths:


<syscheck>
<directories>FILEPATH/OF/MONITORED/FILE</directories>
<directories>FILEPATH/OF/MONITORED/DIRECTORY</directories>
</syscheck>

Linux:

/var/ossec/etc/ossec.conf

Windows:

C:\Program Files (x86)\ossec-agent\ossec.conf

macOS:

/Library/Ossec/etc/ossec.conf

Restart the Compliance Security agent with administrator privilege to apply any configuration change:

Linux:

systemctl restart wazuh-agent

Windows:

Restart-Service -Name wazuh

macOS:

/Library/Ossec/bin/wazuh-control restart

Configuring File Integrity module for real time analysis

This guide explains how to configure File Integrity Monitoring (FIM) using the Compliance Security agent. You can set up real-time monitoring for directories on Windows and Linux endpoints. File Integrity Monitoring records file attributes like checksums, sizes, owners, permissions, and modification times. Scheduled scans can be adjusted to run at specific intervals or times to avoid alert flooding. Additionally, you can enable the report_changes attribute to track exact content changes in text files. Exclusions can be added using the ignore option or custom rules with alert level 0 to ignore specific files and directories from File Integrity Monitoring alerts.

Here are the step-by-step instructions for configuring File Integrity Monitoring (FIM) using Compliance Security Tool on the agent:

Step 1: Configure Real-Time Monitoring

  • On the Compliance Security agent, open the respective configuration files:

Linux:

systemctl restart wazuh-agent

Windows:

Restart-Service -Name wazuh
  • Add the following configuration to enable real-time monitoring for a specific directory:

<syscheck>
<directories realtime="yes">FILEPATH/OF/MONITORED/DIRECTORY</directories>
</syscheck>

Replace FILEPATH/OF/MONITORED/DIRECTORY with the desired directory path.

  • Save the configuration file.
  • Restart the Compliance Security agent with administrator privilege:

Linux:

systemctl restart wazuh-agent

Windows

Restart-Service -Name wazuh

Step2: Record File Attributes


  • You can record specific file metadata by configuring the directories option. Various attributes are supported.
  • To enable recording of specific attributes, modify the <directories> element in the agent configuration file. For example, to record MD5, SHA-1, and SHA-256 hashes of files, use the following configuration:
<syscheck>
<directories check_md5sum="yes" check_sha1sum="yes" check_sha256sum="yes">FILEPATH/OF/MONITORED/FILE</directories>
</syscheck>

Replace FILEPATH/OF/MONITORED/FILE with the desired file path.

  • Save the configuration file.
  • Restart the Compliance Security agent as before.

Step3: Scheduled Scans

  • To modify the schedule of File Integrity Monitoring module scans, set the frequency in seconds or specify the scan_time and scan_day options.
  • To configure scans every 15 minutes (900 seconds), add the following configuration to the agent configuration file:
<syscheck>
<frequency>900</frequency>
</syscheck>
  • Alternatively, to run scans every Saturday at 10 PM, use the following configuration:
<syscheck>
<scan_time>10pm</scan_time>
<scan_day>saturday</scan_day>
</syscheck>
  • Save the configuration file and restart the Compliance Security agent.

Step4: Report Changes in File Values

  • To enable reporting of exact content changes in a text file, use the *report_changes attribute.
  • Modify the <directories> element to include the *report_changes attribute:
<syscheck>
<directories check_all="yes" report_changes="yes">FILEPATH/OF/MONITORED/FILE</directories>
</syscheck>
  • Save the configuration file and restart the Compliance Security agent.

Step5: Adding Exclusions

  • To ignore specific files or directories, use either the ignore option or custom rules with alert level 0.
  • To use the *ignore option, add the following configuration to the agent configuration file:
<syscheck>
<ignore>FILEPATH/OF/MONITORED/FILE</ignore>
<ignore type="sregex">.log$|.tmp$</ignore>
</syscheck>
  • To use custom rules with alert level 0, create a fim_ignore.xml file in the /var/ossec/etc/rules/ directory on the Compliance Security Tool server.
  • Add the following rules to the fim_ignore.xml file to ignore specific files:
<group name="syscheck">
<rule id="100345" level="0">
<if_group>syscheck</if_group>
<field name="file">/var/www/htdocs/private.html</field>
<description>Ignore changes to $(file)</description>
</rule>
</group>
  • Restart the Compliance Security Tool manager on the server to apply the configuration changes.

  • These steps should help you configure File Integrity Monitoring with Compliance Security Tool on the agent.

Vulnerability Module :Configuring and running scans

Running vulnerability scans in the Compliance Security Tool involves enabling the Vulnerability Detector module and configuring the scan settings. Follow these steps to configure the vulnerability detection components on the Compliance Security agent:

Enable Syscollector (if not already enabled)

  • Open the shared agent configuration file located at /var/ossec/etc/shared/default/agent.conf on the Compliance Security Tool server. Alternatively, you can configure these options in each agent's ossec.conf configuration file.

  • Add the following settings to enable Syscollector for vulnerability detection:

<wodle name="syscollector">
<disabled>no</disabled>
<interval>1h</interval>
<os>yes</os>
<packages>yes</packages>
<hotfixes>yes</hotfixes>
</wodle>

Using the System auditing module

The Linux Audit system generates numerous events for write access, read access, execute access, attribute change, or system call rule. Compliance Security Tool uses the key argument in audit rules because it is difficult to distinguish audit events using rules and decoders alone. As previously explained, each audit rule can add a descriptive key value to identify what rule generated a particular audit log entry. We use a CDB list to determine the types of audit rules fired. This list will have the following syntax:

Monitored endpoint

  • To use the Linux Audit system, you must install the audit package on your endpoint. If you do not have this package installed, execute the following command as the root user to install it:
yum install -y auditd

Note: If the audit package is already present on the endpoint before installing the Compliance Security agent, the actions below should not be performed. This configuration will be added by default.

  • Add the configuration below to the Compliance Security agent configuration /var/ossec/etc/ossec.conf file. This configures Compliance Security Tool to read the audit file log to process events the Linux Audit system detects:
<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>
  • Restart the Compliance Security agent to apply the changes:systemctl restart wazuh-agent

Create proper audit rules using the auditctl command or the audit rules file.You can find more information here https://github.com/Neo23x0/auditd/blob/master/audit.rules

Some case of using system auditing.

  1. Monitoring file and directory access
  2. Monitoring commands run as root

Monitoring file and directory access

  1. Run the commands below to configure the following audit rules:
echo "-w /home -p w -k audit-wazuh-w" >> /etc/audit/audit.rules
echo "-w /home -p a -k audit-wazuh-a" >> /etc/audit/audit.rules
echo "-w /home -p r -k audit-wazuh-r" >> /etc/audit/audit.rules
echo "-w /home -p x -k audit-wazuh-x" >> /etc/audit/audit.rules
  1. Reload the audit rules to apply the changes:
auditctl -R /etc/audit/audit.rules
auditctl -l

Output

-w /home -p w -k audit-wazuh-w
-w /home -p a -k audit-wazuh-a
-w /home -p r -k audit-wazuh-r
-w /home -p x -k audit-wazuh-x

Monitoring commands run as root

Add the rules below in the /etc/audit/audit.rules audit rule file:

echo "-a exit,always -F euid=0 -F arch=b64 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules
echo "-a exit,always -F euid=0 -F arch=b32 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules
Note

-a always,exit: Specifies that the audit event should always be generated, regardless of whether the system call was successful or not.

-S execve: Specifies that the rule should match events that involve the execve system call.

-F euid=0: Specifies that the rule should only match events where the effective user ID (euid) is equal to 0, which is the root user.

-k audit-wazuh-c: Specifies a key value that will be used to tag the generated audit events.

Overall, this rule generates audit events for every execution of the execve system call by the root user (euid=0) and tags those events with the key "audit-wazuh-c".

Reload the audit rules to apply the changes:

auditctl -R /etc/audit/audit.rules
auditctl -l

Output

-w /home -p w -k audit-wazuh-w
-w /home -p a -k audit-wazuh-a
-w /home -p r -k audit-wazuh-r
-w /home -p x -k audit-wazuh-x
-a always,exit -F arch=b64 -S execve -F euid=0 -F key=audit-wazuh-c
-a always,exit -F arch=b32 -S execve -F euid=0 -F key=audit-wazuh-c

Rules classification

The rules are classified in multiple levels, from the lowest (0) to the maximum (16). Some levels are not used at this moment. The following table describes each one, which can be useful to understand the severity of each triggered alert or creating custom rules.

LevelTitleDescription
1IgnoredNo action taken. Used to avoid false positives.
These rules are scanned before all the others.
Include events with no security relevance.
2System low prioritySystem notification or status messages. These have no security relevance.
3Successful/Authorized eventsThese include successful login attempts, firewall allow events, etc.
4System low priority errorErrors related to bad configurations or unused devices/applications.
These have no security relevance and are usually caused by default
installations or software testing.
5User generated errorThese include missed passwords, denied actions, etc. By themselves, these
have no security relevance.
6Low relevance attackThese indicate a worm or a virus that has no effect on the system (like
code red for Apache servers, etc). These also include frequent IDS events
and frequent errors.
7"Bad word" matchingThese include words like "bad", "error", etc. These events are most of the
time unclassified and may have some security relevance.
8First time seenInclude first-time-seen events. First time an IDS event is fired or the
first time a user logged in. It also includes security relevant actions
(like the starting of a sniffer or something like that).
9Error from invalid sourceInclude attempts to login as an unknown user or from an invalid source.
May have security relevance (especially if repeated). These also include
errors regarding the "admin" (root) account.
10Multiple user generatedThese include multiple bad passwords, multiple failed logins, etc. These
errorsmay indicate an attack or may just be that a user forgot their credentials.
11Integrity checking warningThese include messages regarding the modification of binaries or the
presence of rootkits (by Rootcheck). These may indicate a successful
attack. Also included are IDS events that will be ignored (high number of
repetitions).
12High importance eventThese include error or warning messages from the system, kernel, etc.
These may indicate an attack against a specific application.
13Unusual error (highMost of the time it matches a common attack pattern.
importance)
14High importance eventMost of the time done with correlation and it indicates an attack.
15Severe attackNo chances of false positives. Immediate attention is necessary.

Using Compliance Security Tool for PCI DSS compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle credit cards. The standard was created to increase controls around cardholder data to reduce credit card fraud. Compliance Security Tool helps ensure PCI DSS compliance by performing log collection, file integrity checking, configuration assessment, intrusion detection, real-time alerting, and active response. The Compliance Security Tool dashboard displays information in real-time, allowing filtering by different types of alert fields, including compliance controls. We have also developed a couple of PCI DSS dashboards for convenient viewing of relevant alerts. The syntax used for tagging PCI DSS relevant rules is pci_dss_ followed by the number of the requirement (e.g., pci_dss_10.2.4 and pci_dss_10.2.5). This guide explains how Compliance Security Tool capabilities and modules assist with meeting PCI DSS version 4.0 requirements:

  • Compliance Security Tool for PCI DSS V4 Guide PDF <https://wazuh.com/resources/WAZUH-PCI-DSS-V4.0-guide.pdf>_

In the following sections, we show some use cases on how to use Compliance Security Tool capabilities and modules to meet PCI DSS version 4.0 requirements:

Using Compliance Security Tool for HIPAA compliance

The Health Insurance Portability and Accountability Act (HIPAA) has specifications and procedures for handling health information. This act aims to improve the effectiveness of healthcare services. It includes standards for electronic health care transactions and code sets. It also includes standards for security and unique health identifiers. Because changes in technology can impact the privacy and security of healthcare data, HIPAA provisions have sections that require the use of federal privacy protections for individually identifiable health information. Part 164, subpart C (Security Standards For The Protection Of Electronic Protected Health Information), provides guidelines for the transmission, handling, storage, and protection of electronic healthcare information. Compliance Security Tool has various capabilities that assist with HIPAA compliance such as log data analysis, file integrity monitoring, configuration assessment, threat detection and response. Compliance Security Tool includes default rules and decoders for detecting security incidents, system errors, security misconfigurations, and policy violations. By default, these rules are mapped to the associated HIPAA standard. In addition to the default rule mapping provided by Compliance Security Tool, it’s possible to map your custom rules to one or more HIPAA standards by adding the compliance identifier in the <group> tag of the rule. The syntax used to map a rule to a HIPAA standard is hipaa_ followed by the number of the requirement, for example, hipaa_164.312.b. Refer to the ruleset section <https://documentation.wazuh.com/current/user-manual/ruleset/index.html>_ for more information.

The Compliance Security Tool for HIPAA guide <https://wazuh.com/resources/Wazuh-for-IPAA-guide-V2.0.pdf>_ focuses on part 164, subpart C (Security Standards For The Protection Of Electronic Protected Health Information) of the HIPAA standard. This guide explains how the various Compliance Security Tool modules assist in complying with HIPAA standards. We have use cases in the following sections that show how to use Compliance Security Tool capabilities and modules to comply with HIPAA standards:

RULES and GROUPS

Ruleset

This part of the documentation explains how to install, update, and contribute to Node security Ruleset. These rules are used by the system to detect attacks, intrusions, software misuse, configuration problems, application errors, malware, rootkits, system anomalies, or security policy violations. OSSEC provides an out-of-the-box set of rules that we update and expand, in order to increase Node security detection capabilities.

We update and maintain the out-of-the-box rules provided by OSSEC, both to eliminate false positives and to increase accuracy. In addition, we map the rules to PCI-DSS compliance controls, making it easy to identify when an alert is related to a specific compliance requirement.

https://github.com/wazuh/wazuh/tree/4.4/ruleset https://www.wazuh.com/resources/Wazuh_Ruleset.pdf

Groups

Groups are variables that define behavior. When an alert includes that group label, this behavior will occur.

Add additional groups to the alert. Groups are optional tags added to alerts.

They can be used by other rules by using if_group or if_matched_group, or by alert parsing tools to categorize alerts.

<rule id="3801" level="4">
<description>Group for rules related with spam.</description>
<group>spam,</group>
</rule>

Now, every rule with the line spam, will be included in that group.