CIS-benchmarkbewijs

CIS Benchmarks  zijn op consensus gebaseerde aanbevelingen voor veilige configuratie. CIS beschrijft Level 1 als een breed bruikbare baseline en Level 2 als defense in depth die bruikbaarheid of prestaties kan beïnvloeden. Pas elk profiel eerst toe in een testomgeving.

OpenFactory kan geselecteerde controls toepassen en een catalogus van machinechecks uitvoeren. Een geslaagde run is bewijs over dat artefact, die benchmarkversie, dat profiel en dat tijdstip. Het is geen CIS-certificering, geen garantie over deployment-instellingen en geen bewijs van naleving van een ander kader.

Huidige grens van remediatie

De functie cis-benchmarks heeft één volledig, vastgezet remediatiepad:

Het Ubuntu-pad schakelt bewust geselecteerde upstream rules uit of past ze aan voor de offline-first-boot- en image-omgeving. Het gegenereerde manifest legt provenance en gekozen instellingen vast. Die aanpassingen maken exact bewijs en exceptions noodzakelijk.

security-hardening en os.security.hardening_level zijn aparte algemene hardening-controls. Ze koppelen niet automatisch aan een volledig CIS Level 1- of Level 2-profiel.

Benchmarkuitvoering

Scenario’s kunnen een exacte catalogus en level kiezen:

{
  "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"
}

De runner heeft ook catalogi voor Debian 12 en Debian 13 en een intern GxP-gericht check set. Een catalogusnaam is geen bewijs van officiële CIS-inhoud of actualiteit. Bevestig provenance, licentie, versie en control definitions van de catalogus voordat u die in een audit gebruikt.

Gebruik geen oudere OS-benchmark als conformance claim voor een nieuwere release. De resolver heeft momenteel goedgekeurde same-family fallbacks voor sommige nieuwere Ubuntu- en Debian-targets zodat tests kunnen draaien, maar de output moet gelabeld worden als compatibility assessment tegen de oudere catalogus, niet als conformance aan een benchmark voor het nieuwere OS.

Een resultaat lezen

Bewaar minstens:

• artifact- en build-ID’s;
• image digest en source snapshot;
• base OS identity en version;
• benchmark/catalog ID, profile en digest;
• applicable, passed, failed, skipped en not-applicable controls;
• raw command output en timestamps;
• remediation provenance;
• gedocumenteerde exceptions met owner en approval; en
• de omgeving waarin de checks liepen.

Een percentage alleen verbergt applicability en severity. Een run met nul failed applicable controls zegt niets over controls buiten de catalogus, wijzigingen tijdens deployment, credentials, netwerken, physical hardware of latere drift.

Veilige workflow

1. Kies een benchmark die exact bij de target release past.
2. Bekijk het profiel en elke OpenFactory-aanpassing.
3. Bouw het artefact en wacht op first-boot remediation readiness.
4. Voer de volledige applicable check set uit in een clean guest.
5. Onderzoek failures; zet ze niet stilzwijgend om naar not applicable.
6. Test application- en operational behavior na hardening.
7. Laat exceptions goedkeuren door de accountable security owner.
8. Voer opnieuw uit na elke wijziging in packages, recipe of deployment.

Gebruik CIS’s eigen profile guidance  als normatief startpunt en verkrijg de applicable benchmark via uw authorized CIS distribution channel.