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.
- Monitoring file and directory access
- Monitoring commands run as root
Monitoring file and directory access
- 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
- 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
-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.
Level | Title | Description |
---|---|---|
1 | Ignored | No action taken. Used to avoid false positives. |
These rules are scanned before all the others. | ||
Include events with no security relevance. | ||
2 | System low priority | System notification or status messages. These have no security relevance. |
3 | Successful/Authorized events | These include successful login attempts, firewall allow events, etc. |
4 | System low priority error | Errors related to bad configurations or unused devices/applications. |
These have no security relevance and are usually caused by default | ||
installations or software testing. | ||
5 | User generated error | These include missed passwords, denied actions, etc. By themselves, these |
have no security relevance. | ||
6 | Low relevance attack | These 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" matching | These include words like "bad", "error", etc. These events are most of the |
time unclassified and may have some security relevance. | ||
8 | First time seen | Include 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). | ||
9 | Error from invalid source | Include 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. | ||
10 | Multiple user generated | These include multiple bad passwords, multiple failed logins, etc. These |
errors | may indicate an attack or may just be that a user forgot their credentials. | |
11 | Integrity checking warning | These 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). | ||
12 | High importance event | These include error or warning messages from the system, kernel, etc. |
These may indicate an attack against a specific application. | ||
13 | Unusual error (high | Most of the time it matches a common attack pattern. |
importance) | ||
14 | High importance event | Most of the time done with correlation and it indicates an attack. |
15 | Severe attack | No 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:
- Log data analysis
- Configuration assessment
- Malware detection
- File integrity monitoring
- Vulnerability detection
- Active response
- System inventory
- Visualization and dashboard
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:
- Visualization and dashboard
- Log data analysis
- Configuration assessment
- Malware detection
- File integrity monitoring
- Vulnerability detection
- Active response
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