CIS-Benchmark-Nachweis

CIS Benchmarks sind konsensbasierte Secure-Configuration-Empfehlungen. CIS beschreibt Level 1 als breit nutzbare Baseline und Level 2 als Defense in Depth, die Utility oder Performance beeinflussen kann. Wenden Sie jedes Profil zuerst in einer Test-Umgebung an.

OpenFactory kann ausgewählte Controls anwenden und einen Katalog maschineller Checks ausführen. Ein bestandener Lauf ist Evidenz über dieses Artefakt, Benchmark-Version, Profil und Zeitpunkt. Es ist keine CIS-Zertifizierung, keine Garantie für Deployment-Settings und kein Nachweis für Compliance mit einem anderen Framework.

Aktuelle Remediation-Grenze

Das Feature cis-benchmarks hat einen vollen, gepinnten Remediation-Pfad:

Base	Aktuelles Verhalten
Ubuntu 24.04	Staged `ansible-lockdown/UBUNTU24-CIS` release 1.6.0 at commit `c893ca6836fb32b1ea067d4a63c341e39693074b`, verifiziert archive digest, wendet Level 1 server oder workstation profile at first boot an.
Andere unterstützte Linux bases	Wendet nur kleine portable safety baseline an. Läuft nicht die Ubuntu role und darf nicht als equivalent CIS remediation beschrieben werden.

Der Ubuntu-Pfad deaktiviert oder passt bewusst ausgewählte upstream rules für offline-first-boot und image environment an. Generiertes manifest dokumentiert Provenienz und gewählte Settings. Diese Anpassungen machen exakte Evidenz und Exceptions essentiell.

security-hardening und os.security.hardening_level sind separate general-hardening controls. Sie mappen nicht automatisch auf vollständiges CIS Level 1 oder Level 2 profile.

Benchmark-Ausführung

Szenarien können exakten catalog und level wählen:


{
  "id": "ubuntu-cis-evidence",
  "name": "Ubuntu 24.04 CIS evidence",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "cis_benchmark": "CIS_Ubuntu_Linux_24.04_LTS_Benchmark_v1.0.0",
  "cis_level": "L1"
}

Der Runner hat auch Kataloge für Debian 12 und Debian 13 und ein internes GxP-oriented check set. Ein catalog name beweist nicht official CIS content oder Aktualität. Provenienz, Lizenz, Version und control definitions des Katalogs bestätigen vor Audit-Nutzung.

Nutzen Sie keinen älteren OS benchmark als conformance claim für neueres Release. Der Resolver hat derzeit approved same-family fallbacks für manche neuere Ubuntu und Debian targets, damit Tests laufen können, aber Output muss als compatibility assessment gegen älteren catalog gelabelt werden, nicht als conformance zu benchmark für neueres OS.

Ergebnis lesen

Mindestens behalten:

Artefakt- und Build-IDs;
image digest und source snapshot;
base OS identity und version;
benchmark/catalog ID, profile und digest;
applicable, passed, failed, skipped und not-applicable controls;
raw command output und timestamps;
remediation provenance;
dokumentierte exceptions mit owner und approval; und
Umgebung, in der checks liefen.

Ein Prozentsatz allein verbirgt applicability und severity. Ein Lauf mit zero failed applicable checks sagt nichts über controls außerhalb des catalogs, deployment-time changes, credentials, Netzwerke, physical hardware oder spätere drift.

Sicherer Workflow

Benchmark wählen, der exakt zum target release passt.
Profil und jede OpenFactory adaptation prüfen.
Artefakt bauen und auf first-boot remediation readiness warten.
Vollständiges applicable check set in clean guest ausführen.
Failures untersuchen; nicht still in not applicable umwandeln.
Application und operational behavior nach hardening testen.
Exceptions vom accountable security owner genehmigen lassen.
Nach package-, recipe- oder deployment change erneut laufen.

Nutzen Sie CIS eigenes profile guidance als normativen Startpunkt und beschaffen Sie applicable benchmark über Ihren authorized CIS distribution channel.