Wazuh SCA für Debian 13: Abweichungen vom aktuellen CIS Benchmark richtig behandeln

Einleitung

Die Security Configuration Assessment von Wazuh ist ein wirkungsvolles Werkzeug, um Fehlkonfigurationen, unzureichende Härtung und Abweichungen von Sicherheitsstandards auf Endpoints sichtbar zu machen. Die Aussagekraft der Ergebnisse hängt jedoch unmittelbar von der verwendeten SCA-Policy ab. Stimmen Betriebssystemversion, Benchmark-Version und technische Prüfregeln nicht überein, können formal plausible Ergebnisse entstehen, die nicht dem tatsächlich geforderten Sicherheitsstandard entsprechen.

Genau dieses Problem betrifft die in Wazuh enthaltene SCA-Policy für Debian 13. Obwohl Dateiname, Policy-ID und Anzeigename Debian 13 nennen, basiert der aktuelle Inhalt weiterhin auf dem CIS Debian Linux 12 Benchmark v1.1.0. Die Wazuh-Wartungsübersicht bestätigt diese Abweichung und führt den CIS Debian Linux 13 Benchmark v1.0.0 als aktuell verfügbare Zielversion.

Für produktive Umgebungen bedeutet das: Ein erfolgreicher Scan mit der integrierten Policy darf nicht automatisch als Nachweis einer vollständigen Konformität mit dem CIS Debian Linux 13 Benchmark v1.0.0 interpretiert werden.

Ausgangslage / Problemstellung

Auf einem Debian-13-System wird nach der Installation des Wazuh Agents die Policy cis_debian13.yml verwendet. Die Anforderungen innerhalb der Datei prüfen ausdrücklich auf Debian 13:

requirements:
  name: "Check Debian version."
  description: "Requirements for running the SCA scan against Debian Linux 13."
  condition: all
  rules:
    - "f:/etc/debian_version -> r:13\\."
    - "f:/proc/sys/kernel/ostype -> r:Linux"
    - "f:/etc/os-release -> r:NAME= && r:Debian"
    - "f:/etc/os-release -> r:VERSION= && r:13"

Die Metadaten vermitteln ebenfalls den Eindruck einer nativen Debian-13-Policy:

policy:
  id: "cis_debian13"
  file: "cis_debian13.yml"
  name: "CIS Debian Linux 13 Benchmark v1.1.0"

Im Header derselben Datei steht jedoch:

# Based on:
# Center for Internet Security Debian Linux 12 Benchmark v1.1.0 - 09-26-2024

Damit enthält die Policy einen grundlegenden Widerspruch: Die Betriebssystemerkennung ist auf Debian 13 angepasst, die Kontrollstruktur und ein wesentlicher Teil der Prüfregeln stammen jedoch aus dem Debian-12-Benchmark. Zusätzlich bezeichnet die Beschreibung die Policy als Debian-13-Benchmark v1.1.0, während die Wazuh-Wartungsübersicht für Debian 13 den CIS Benchmark v1.0.0 als aktuell verfügbare Version nennt.

Die Wartungsübersicht klassifiziert Debian 13 deshalb nicht als aktuell, sondern dokumentiert ausdrücklich:

aktuell in Wazuh: basierend auf Debian 12 v1.1.0
verfügbarer CIS Benchmark für Debian 13: v1.0.0
separate Erstellung beziehungsweise Überarbeitung der Debian-13-Policy ausstehend

Ein zugehöriger Vorgang zur Erstellung einer eigenständigen Debian-13-SCA-Policy ist vorhanden und war zuletzt noch offen.

Technische Analyse

Eine umbenannte Policy ist keine neue Benchmark-Implementierung

Eine CIS-SCA-Policy besteht nicht nur aus einer Prüfung der Betriebssystemversion. Sie bildet einen konkreten Benchmark mit dessen Kontrollnummern, Beschreibungen, Audit-Prozeduren, Sollwerten und Remediation-Anweisungen ab.

Zwischen zwei Debian-Hauptversionen können sich unter anderem folgende Bereiche verändern:

verfügbare oder standardmäßig installierte Pakete
systemd-Units und deren Standardzustände
PAM-Konfigurationen
Dateipfade und Konfigurationsdateien
Kernelparameter und Standardwerte
auditd-Regeln
Bootloader-Konfigurationen
kryptografische Vorgaben
empfohlene Mount-Optionen
Reihenfolge und Nummerierung der CIS Controls

Wird eine Debian-12-Policy lediglich mit einer Debian-13-Erkennung versehen, prüft Wazuh zwar tatsächlich einen Debian-13-Endpoint, interpretiert dessen Zustand aber anhand eines anderen Kontrollkatalogs.

Mögliche False Positives

Ein False Positive entsteht, wenn Wazuh eine Einstellung als fehlgeschlagen meldet, obwohl das Debian-13-System entsprechend der aktuellen Debian-13-Empfehlung konfiguriert ist.

Typische Ursachen sind:

ein unter Debian 13 geänderter Dateipfad
eine neue Ausgabe eines Systemkommandos
ein abweichender systemd-Unit-Name
eine modernisierte auditd-Regel
ein regulärer Ausdruck, der nur zur Ausgabe unter Debian 12 passt
eine Kontrollanforderung, die im Debian-13-Benchmark nicht mehr identisch vorhanden ist

Das führt zu unnötigen Remediation-Arbeiten. Im ungünstigsten Fall wird eine korrekte Debian-13-Konfiguration verändert, um eine ältere Prüflogik zufriedenzustellen.

Mögliche False Negatives

Kritischer sind False Negatives. Dabei meldet die Policy einen erfolgreichen Check oder enthält gar keine Prüfung für eine neue Debian-13-Anforderung.

Mögliche Folgen sind:

eine sicherheitsrelevante Einstellung bleibt ungeprüft
eine neue CIS-Empfehlung fehlt vollständig
ein veralteter Sollwert wird weiterhin akzeptiert
eine Prüfung kontrolliert nur die persistente Konfiguration, nicht aber den laufenden Systemzustand
eine Regel erkennt lediglich das Vorhandensein einer Konfigurationszeile, nicht deren tatsächliche Wirksamkeit

Aus dem abweichenden Kontrollkatalog folgt daher, dass der Wazuh-Score nicht direkt mit einem Audit gegen den offiziellen Debian-13-Benchmark gleichgesetzt werden kann.

Statische und aktive auditd-Konfiguration

Besonders fehleranfällig sind die auditd-Prüfungen. Eine vollständige Bewertung sollte zwei Zustände unterscheiden:

Die persistente Konfiguration unter /etc/audit/rules.d/
Die aktuell in den Kernel geladenen Regeln, beispielsweise über auditctl -l

Eine Prüfung ausschließlich der statischen Dateien kann erfolgreich sein, obwohl die Regeln noch nicht geladen wurden. Umgekehrt können aktive Regeln vorhanden sein, die nach einem Neustart verloren gehen.

Ein öffentlich verfügbares Beispiel für überarbeitete Debian-13-auditd-Prüfungen verwendet modernere syscall-basierte Regeln statt veralteter Watch-Syntax. Das Beispiel bezeichnet sich allerdings selbst als erste Iteration, deckt teilweise nur statische Dateien ab, enthält unvollständige Kontrollen und verwendet provisorische Check-IDs. Es eignet sich deshalb als technische Referenz, nicht als ungeprüfte produktive Komplett-Policy. Auffällig ist außerdem, dass seine Metadaten von einem Debian-13-Benchmark v1.1.0 sprechen, während die offizielle Wazuh-Wartungsübersicht v1.0.0 als aktuelle Debian-13-Version führt.

Nicht implementierte und manuelle Kontrollen

Auch eine betriebssystemspezifische Wazuh-Policy ist nicht automatisch mit einem vollständigen CIS-Audit gleichzusetzen. In der aktuellen Datei sind mehrere Kontrollen ausdrücklich als nicht implementiert oder manuell gekennzeichnet. Ein SCA-Ergebnis kann daher nur die tatsächlich implementierten technischen Checks bewerten.

Organisatorische, manuelle oder kontextabhängige Anforderungen müssen weiterhin separat geprüft und dokumentiert werden.

Lösung / Best Practices

Bis eine vollständig auf dem CIS Debian Linux 13 Benchmark basierende Policy offiziell bereitgestellt wird, ist eine eigene SCA-Policy die sauberste Lösung.

1. Verwendete Benchmark-Version verbindlich festlegen

Vor der technischen Umsetzung muss dokumentiert werden, welche Baseline geprüft werden soll:

Betriebssystem: Debian GNU/Linux 13
Benchmark: CIS Debian Linux 13 Benchmark v1.0.0
Profil: Level 1 Server, Level 2 Server oder organisationsspezifisch
Wazuh-Version: konkret eingesetzte Agent- und Manager-Version
Policy-Version: eigene interne Versionsnummer

Die Original-Benchmark-Dokumentation sollte entsprechend den geltenden CIS-Nutzungs- und Lizenzbedingungen bezogen und verwendet werden. Kontrolltexte sollten nicht ungeprüft aus älteren Wazuh-Policies übernommen werden.

2. Integrierte Policy nicht direkt verändern

Die Standard-Policies befinden sich auf Linux-Agents unter:

/var/ossec/ruleset/sca/

Änderungen in diesem Verzeichnis sind nicht updatesicher. Wazuh weist ausdrücklich darauf hin, dass Inhalte im Standard-Ruleset bei Installation oder Aktualisierung ersetzt werden können. Eigene Policies sollten deshalb in einem separaten Verzeichnis liegen.

Beispiel:

mkdir -p /var/ossec/etc/custom-sca-files
chmod 750 /var/ossec/etc/custom-sca-files

Anschließend wird eine eigene Datei angelegt:

/var/ossec/etc/custom-sca-files/org_debian13_cis_v1_0_0.yml

3. Eindeutige Policy- und Check-IDs verwenden

Policy-ID und numerische Check-IDs müssen über alle geladenen SCA-Policies hinweg eindeutig sein. Wazuh unterstützt in einer Policy die Bereiche policy, requirements, optional variables und checks. Für Prüfungen stehen Datei-, Verzeichnis-, Prozess- und Kommando-Regeln sowie unterschiedliche Bedingungen zur Verfügung.

Ein minimales Grundgerüst kann folgendermaßen aussehen:

policy:
  id: "org_debian13_cis_v1_0_0"
  file: "org_debian13_cis_v1_0_0.yml"
  name: "Organizational Debian 13 Security Baseline"
  description: >
    Organization-specific implementation of selected controls for
    Debian GNU/Linux 13, aligned with the approved security baseline.
  references:
    - "https://www.cisecurity.org/cis-benchmarks/"
  regex_type: "pcre2"

requirements:
  title: "Validate Debian GNU/Linux 13"
  description: "Run this policy only on Debian 13 endpoints."
  condition: all
  rules:
    - 'f:/etc/debian_version -> r:^13(\.|$)'
    - 'f:/etc/os-release -> r:^ID="?debian"?$'
    - 'f:/etc/os-release -> r:^VERSION_ID="?13"?$'

checks:
  - id: 913000
    title: "Ensure the nodev option is active on /tmp"
    description: >
      Verifies that the active /tmp mount does not permit device files.
    rationale: >
      Device files are not required on a temporary filesystem and
      unnecessarily increase the attack surface.
    remediation: >
      Add nodev to the persistent /tmp mount configuration and remount
      the filesystem. Validate application compatibility before rollout.
    condition: all
    rules:
      - 'c:findmnt -no OPTIONS /tmp -> r:(^|,)nodev(,|$)'

Dieses Beispiel ist lediglich ein technisches Grundgerüst. Für einen belastbaren Benchmark müssen alle benötigten Kontrollen einzeln aus der freigegebenen Baseline umgesetzt und getestet werden.

4. Jede Regel gegen reale Debian-13-Systeme testen

Für jeden Check sollte mindestens ein positiver und ein negativer Testfall existieren:

sicher konfigurierte Referenzmaschine
gezielt unsicher konfigurierte Testmaschine
Debian-13-Minimalinstallation
Debian-13-Server mit typischen Rollen
Systeme mit abweichenden, aber zulässigen Konfigurationen
x86_64 und gegebenenfalls weitere verwendete Architekturen

Die innerhalb der SCA-Regel verwendeten Befehle sollten zunächst manuell ausgeführt werden. Dabei sind Rückgabewert, Standardausgabe, Fehlerausgabe und Spracheinstellungen zu prüfen.

Beispiel:

findmnt -no OPTIONS /tmp
echo $?

Reguläre Ausdrücke sollten keine zufälligen Teiltreffer akzeptieren. Für kommaseparierte Mount-Optionen ist beispielsweise eine Begrenzung wie (^|,)nodev(,|$) robuster als die einfache Suche nach nodev.

5. Persistenten und aktiven Zustand getrennt bewerten

Insbesondere bei auditd, sysctl, systemd und Mount-Konfigurationen sollten getrennte Checks vorgesehen werden.

Für auditd:

# Persistente Regeln
grep -R --line-number --extended-regexp 'relevantes-muster' \
  /etc/audit/rules.d/

# Aktive Regeln
auditctl -l

Für sysctl:

# Persistente Konfiguration
grep -R --line-number 'kernel.randomize_va_space' \
  /etc/sysctl.conf /etc/sysctl.d/

# Aktiver Wert
sysctl kernel.randomize_va_space

Für systemd:

systemctl is-enabled <unit>
systemctl is-active <unit>

Ein System kann persistent korrekt, aber aktuell noch nicht remediated sein. Ebenso kann ein aktiver Zustand nach dem nächsten Neustart verloren gehen.

6. Eigene Policy aktivieren und die alte Policy deaktivieren

Die eigene Policy wird im <sca>-Block der Agent-Konfiguration eingetragen. Gleichzeitig sollte die integrierte Debian-13-Policy deaktiviert werden, damit keine widersprüchlichen oder doppelten Ergebnisse entstehen.

Beispiel für /var/ossec/etc/ossec.conf:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>

  <policies>
    <policy enabled="no">ruleset/sca/cis_debian13.yml</policy>
    <policy>/var/ossec/etc/custom-sca-files/org_debian13_cis_v1_0_0.yml</policy>
  </policies>
</sca>

Wazuh unterstützt sowohl vollständige als auch zum Installationsverzeichnis relative Pfade. Policies können über das Attribut enabled="no" deaktiviert werden.

Danach wird der Agent neu gestartet:

systemctl restart wazuh-agent

Die Verarbeitung kann im Agent-Log kontrolliert werden:

grep -i sca /var/ossec/logs/ossec.log

Zu prüfen sind insbesondere:

YAML-Parserfehler
ungültige Operatoren
doppelte Check-IDs
nicht erfüllte Requirements
fehlerhafte reguläre Ausdrücke
Timeouts bei Kommando-Prüfungen
unerwartete Not applicable-Ergebnisse

7. Zentrale Verteilung kontrolliert umsetzen

Für größere Umgebungen kann die Policy über eine Wazuh-Agent-Gruppe verteilt werden. Die Policy wird dazu beispielsweise auf dem Manager im Shared-Verzeichnis der Gruppe abgelegt und in der zugehörigen agent.conf aktiviert:

<agent_config>
  <sca>
    <policies>
      <policy enabled="no">ruleset/sca/cis_debian13.yml</policy>
      <policy>etc/shared/org_debian13_cis_v1_0_0.yml</policy>
    </policies>
  </sca>
</agent_config>

Wazuh dokumentiert, dass zentral bereitgestellte Policies auf dem Endpoint im Verzeichnis etc/shared/ gespeichert und über einen relativen Pfad eingebunden werden können.

Enthält eine zentral verteilte Policy Kommando-Regeln, kann die Aktivierung von sca.remote_commands=1 erforderlich sein:

echo "sca.remote_commands=1" >> \
  /var/ossec/etc/local_internal_options.conf

Diese Option ist sicherheitsrelevant. Sie ermöglicht die Ausführung von durch den Manager bereitgestellten SCA-Kommandos auf dem Endpoint. Bei einer Kompromittierung des Managers vergrößert sich dadurch der mögliche Wirkungsbereich. Wazuh deaktiviert diese Funktion daher standardmäßig. Wer Policies über ein separates Konfigurationsmanagement lokal ausrollt, muss Remote Commands nicht aktivieren.

8. Ergebnisse korrekt kennzeichnen

Die eigene Policy sollte im Dashboard nicht als unveränderte offizielle CIS-Policy ausgegeben werden. Eine transparente Bezeichnung ist beispielsweise:

Organizational Debian 13 Baseline – aligned with CIS Debian 13 v1.0.0

Zusätzlich sollten Policy-Version, Freigabedatum, Verantwortlicher und Teststatus dokumentiert werden:

policy:
  id: "org_debian13_cis_v1_0_0"
  file: "org_debian13_cis_v1_0_0.yml"
  name: "Organizational Debian 13 Baseline"
  description: >
    Internal policy version 1.3. Approved 2026-07-20.
    Covers automated controls selected from the approved Debian 13 baseline.

So bleibt nachvollziehbar, dass es sich um eine organisationsspezifische technische Implementierung und nicht um eine Zertifizierung durch CIS oder Wazuh handelt.

Lessons Learned / Best Practices

Policy-Dateiname und Betriebssystemerkennung reichen nicht aus

Bei jeder SCA-Policy sollten mindestens folgende Metadaten überprüft werden:

head -n 30 /var/ossec/ruleset/sca/cis_debian13.yml

Relevant sind:

tatsächliche Benchmark-Quelle
Benchmark-Version
Veröffentlichungsdatum
Policy-ID
Policy-Name
Betriebssystem-Requirements
vorhandene nicht implementierte Kontrollen

Gerade bei neuen Betriebssystemgenerationen können zunächst Policies ausgeliefert werden, die auf dem Vorgänger-Benchmark basieren.

Compliance-Scores benötigen Versionskontext

Ein Wert wie „92 Prozent bestanden“ ist ohne Angabe der Policy-Version nicht belastbar. In Reports sollten deshalb immer mindestens folgende Informationen enthalten sein:

Betriebssystem und Release
Wazuh-Agent-Version
Policy-ID
Policy-Dateiversion oder Commit
zugrunde liegende Benchmark-Version
gewähltes Profil
Anzahl nicht implementierter Kontrollen
Anzahl manueller Kontrollen
dokumentierte Ausnahmen

Ohne diese Angaben können zwei zeitlich getrennte Scans nicht sinnvoll verglichen werden.

Policy-Updates wie Code behandeln

Eigene SCA-Policies sollten versioniert, geprüft und über einen kontrollierten Release-Prozess verteilt werden:

Änderung in einem Versionsverwaltungssystem
technische Prüfung der YAML-Struktur
Test gegen positive und negative Referenzsysteme
fachliche Freigabe
Rollout auf eine Pilotgruppe
Auswertung von False Positives und False Negatives
schrittweiser produktiver Rollout
dokumentierter Rollback

Direkte Änderungen auf einzelnen Agents führen dagegen schnell zu nicht reproduzierbaren Ergebnissen.

Unveränderlichkeit der Referenz sicherstellen

Für Audits sollte exakt die verwendete Policy-Version archiviert werden. Ein Verweis auf den jeweils aktuellen main-Branch reicht nicht aus, da sich dessen Inhalt ändern kann.

Sinnvoll sind:

sha256sum org_debian13_cis_v1_0_0.yml

sowie die Dokumentation von:

Commit-ID
SHA-256-Prüfsumme
Freigabedatum
Gültigkeitszeitraum
zugeordneten Agent-Gruppen

Community-Beispiele nicht ungeprüft produktiv einsetzen

Ein vorhandenes Beispiel kann wertvolle Lösungsansätze für auditd-Regeln, reguläre Ausdrücke oder Debian-13-spezifische Pfade enthalten. Es ersetzt jedoch keine vollständige technische und fachliche Prüfung.

Besondere Warnsignale sind:

leere Beschreibungen oder Remediation-Felder
provisorische Check-IDs
auskommentierte Kontrollen
ausschließlich statische Prüfungen
fehlende Laufzeittests
unvollständige Benchmark-Abdeckung
widersprüchliche Versionsangaben

Offizielle Policy später kontrolliert übernehmen

Sobald Wazuh eine native Debian-13-Policy auf Basis des vorgesehenen Benchmarks bereitstellt, sollte nicht sofort ungeprüft zurückgewechselt werden.

Stattdessen empfiehlt sich:

neue offizielle Policy in einer Testumgebung installieren
Metadaten und Benchmark-Version prüfen
Ergebnisse mit der eigenen Policy vergleichen
neue und entfallene Controls identifizieren
Abweichungen fachlich bewerten
Ausnahmen und interne Ergänzungen übernehmen
Migration zunächst auf einer Pilotgruppe durchführen
alte Policy erst nach erfolgreichem Vergleich deaktivieren

Eine offizielle Aktualisierung kann neue Check-IDs erzeugen und damit historische Dashboard-Vergleiche, Ausnahmen oder angebundene Reporting-Prozesse beeinflussen.

Fazit

Die derzeitige Wazuh-SCA-Policy für Debian 13 prüft zwar Debian-13-Systeme, basiert inhaltlich jedoch auf dem CIS Debian Linux 12 Benchmark v1.1.0. Die Wazuh-Wartungsübersicht dokumentiert den CIS Debian Linux 13 Benchmark v1.0.0 als aktuelle Zielversion und führt die Erstellung einer nativen Policy separat.

Damit sind die vorhandenen Ergebnisse weiterhin als Hardening-Indikator nutzbar, aber nicht als gleichwertiger Nachweis eines vollständigen Debian-13-CIS-Audits. Für Umgebungen mit verbindlichen Compliance-Anforderungen sollte eine eigene, versionierte und gegen reale Debian-13-Systeme getestete SCA-Policy eingesetzt werden.

Entscheidend ist nicht der Dateiname der Policy, sondern die nachweisbare Übereinstimmung zwischen Betriebssystem, Benchmark-Version, Kontrollkatalog und technischer Implementierung.