Exploring Wazuh's Security Configuration Assessment module. Understanding CIS benchmarks for Linux, Windows, and macOS, integration with cis_cat, baseline configuration scanning, creating YAML-based custom policies, and reading compliance scores in the dashboard.

In episode 9, you learned to detect vulnerabilities in installed software with the Vulnerability Detection module. But an application free of CVEs doesn't automatically make your host secure. Many incidents actually start from weak configurations: loose file permissions, unnecessary services running, or overly permissive SSH options.
Episode 10 covers Security Configuration Assessment, or SCA. This module scans hosts against established security baselines, like CIS benchmarks for Linux, Windows, and macOS, then shows how many requirements are met.
We'll also look at the cis_cat integration for certain scenarios, how to create YAML-based custom policies, and how to read compliance scores in the dashboard. By the end of this episode, you can assess a host's hardening level in just a few minutes.
SCA is the process of comparing a system's actual configuration against a desired standard. Wazuh automates this with checklists called policies. Each policy contains hundreds of checks, and each check is one yes or no question about a system condition.
A simple check example: whether the /etc/passwd file permissions are correct, or whether root login via SSH is disabled. The agent runs these checks periodically, sends the results to the manager, and the results become alerts plus a compliance score.
What's interesting about SCA is that its results are objective. There's no interpretation, no opinion. The system passes or fails against each requirement, and that result can be presented directly to an auditor.
Info
SCA scans run inside the agent, so no external admin credentials are needed. Configuration is assessed, not changed, so the results are always safe and never damage the system.
CIS stands for the Center for Internet Security. This organization publishes benchmarks that are the most widely used hardening yardsticks in the world. Wazuh ships several of these benchmarks as built-in policies, for Linux, Windows, and macOS alike.
Each benchmark is differentiated by level. Level 1 is the baseline that can be applied without disrupting primary functions, while level 2 is stricter and often trades convenience for security. You can choose according to your business priorities.
For Linux, examples include CIS Distribution Independent, CIS Ubuntu, CIS Debian, and Red Hat derivatives. For Windows, benchmarks for Windows Server and Windows 10 are available, including both older and newest versions. macOS also gets attention through a dedicated benchmark.
Most SCA checks run directly inside the agent. But sometimes Wazuh needs help from an external tool, especially for systems whose checks are complicated to run locally. That's where CIS-CAT comes in.
CIS-CAT is the official CIS tool that runs benchmarks thoroughly. Wazuh can call it through the cis-cat wodle, for example to scan Windows hosts from the manager side over SSH. The CIS-CAT scan results are then converted into normal SCA alerts.
<ossec_config>
<wodle name="cis-cat">
<disabled>no</disabled>
<run_on_start>yes</run_on_start>
<interval>1d</interval>
<scan_timeout>1800</scan_timeout>
<server>192.168.10.15</server>
<user>sca_user</user>
<password>changeme</password>
</wodle>
</ossec_config>This integration requires a CIS-CAT Pro license, so not every environment enables it. For those needing the most accurate audit results from CIS, this option is worth considering. Remember, cis_cat scans over the network, so make sure the SSH connection to the target host works smoothly before enabling it.
Now let's discuss what's actually checked. Baseline configuration scanning touches several system layers at once.
The key concept is the baseline: the ideal condition that serves as a reference. The closer a system is to the baseline, the smaller its attack surface. SCA makes that baseline real and measurable, not just a document on paper.
The SCA module runs inside the agent and is active by default on normal installations. Its configuration lives in the sca section of the agent's ossec.conf. We can set when the first scan runs and how often subsequent scans repeat.
<ossec_config>
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
<skip_verify>yes</skip_verify>
</sca>
</ossec_config>With the configuration above, the agent scans immediately at start and then repeats every 12 hours. After changing the file, run systemctl restart wazuh-agent on each host. The results will appear in the SCA module in the dashboard shortly after.
The available policies are automatically selected based on the agent's operating system. You can also explicitly limit certain policies via the policies list in the configuration.
Sometimes the built-in benchmarks don't answer specific needs. Teams can have stricter internal standards, or unique customer requirements. For that, Wazuh supports custom policies written in YAML.
Each YAML policy has a policy block and a list of checks. Each check consists of an id, title, rationale, remediation, and one or more rules with comparison operators. Here's a simple example for Ubuntu.
policy:
id: "my_ubuntu_hardening"
name: "Hardening Dasar Ubuntu"
description: "Pemeriksaan baseline keamanan untuk server Ubuntu"
checks:
- id: 10001
title: "Pastikan izin berkas passwd hanya ditulis root"
rationale: "Izin longgar memungkinkan penambahan akun oleh orang lain"
remediation: "Jalankan chmod 0644 pada berkas passwd"
condition: "all"
rules:
- type: "file"
field: "/etc/passwd"
operator: "=="
value: "0644"
- id: 10002
title: "Pastikan login root via SSH dimatikan"
rationale: "Login root langsung memperbesar risiko bila kredensial bocor"
remediation: "Set PermitRootLogin no pada sshd_config"
condition: "all"
rules:
- type: "command"
command: "grep PermitRootLogin /etc/ssh/sshd_config"
operator: "contains"
value: "no"Policies are stored in the sca directory under the manager's shared folder, then synced to all agents. To see which policies are available on each agent, you can inspect the contents of /var/ossec/etc/shared/sca/.
ls -l /var/ossec/etc/shared/sca/Once the custom policy is synced, the agent evaluates every check and reports it. Make sure the policy id doesn't clash with built-in policies, and save changes through git so the history can be audited.
All scan results eventually flow into the dashboard. The SCA module in the Wazuh Dashboard shows the compliance score as a percentage, the number of passed and failed checks, and a breakdown per policy.
You can browse each failed check one by one, read the rationale and remediation steps, then mark it after it's applied. This score is also honest material for conversations with management: where we stand and what needs fixing.
To trigger a manual rescan, you can restart the agent via the service manager. For those who like automation, SCA results can also be pulled via the API for monitoring and period-over-period comparison.
Episode 10 taught how Wazuh assesses host configuration against established security baselines. We understand the CIS benchmarks for Linux, Windows, and macOS, the cis_cat integration for special scenarios, baseline configuration scanning, YAML-based custom policies, and reading compliance scores in the dashboard.
Key takeaways:
A compliance score alone isn't enough without understanding the regulations that bind you. In episode 11, we'll map all these results to compliance frameworks: GDPR, NIST 800-53, HIPAA, PCI DSS, and TSC, complete with report generation for audit purposes. See you there!