CIS-benchmarkbevis

CIS Benchmarks  er konsensusbaserte anbefalinger for sikker konfigurasjon. CIS beskriver Level 1 som en bredt brukbar baseline og Level 2 som defense in depth som kan påvirke nytte eller ytelse. Bruk hver profil først i et testmiljø.

OpenFactory kan bruke utvalgte controls og kjøre en katalog med maskinsjekker. Et bestått run er bevis om det artefaktet, benchmarkversjonen, profilen og tidspunktet. Det er verken CIS-sertifisering, garanti for deployment-innstillinger eller bevis på etterlevelse av et annet rammeverk.

Nåværende grense for remediering

Funksjonen cis-benchmarks har én full, fastlåst remedieringssti:

Ubuntu-stien deaktiverer eller tilpasser bevisst utvalgte upstream rules for offline-first-boot- og image-miljøet. Det genererte manifestet registrerer provenance og valgte innstillinger. Disse tilpasningene gjør nøyaktig bevis og exceptions nødvendige.

security-hardening og os.security.hardening_level er separate generelle hardening-controls. De mapper ikke automatisk til en full CIS Level 1- eller Level 2-profil.

Benchmarkkjøring

Scenarioer kan velge nøyaktig catalog og level:

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

Runneren har også kataloger for Debian 12 og Debian 13 og et internt GxP-orientert check set. Et katalognavn er ikke bevis på offisielt CIS-innhold eller aktualitet. Bekreft katalogens provenance, lisens, versjon og control definitions før du bruker den i en revisjon.

Ikke bruk en eldre OS-benchmark som conformance claim for en nyere release. Resolveren har for tiden godkjente same-family fallbacks for noen nyere Ubuntu- og Debian-targets slik at tester kan kjøre, men output må merkes som compatibility assessment mot den eldre catalogen, ikke som conformance til en benchmark for det nyere OS-et.

Lese et resultat

Behold minst:

• artifact- og build-ID-er;
• image digest og source snapshot;
• base OS identity og version;
• benchmark/catalog ID, profile og digest;
• applicable, passed, failed, skipped og not-applicable controls;
• raw command output og timestamps;
• remediation provenance;
• dokumenterte exceptions med owner og approval; og
• miljøet der sjekkene kjørte.

En prosentandel alene skjuler applicability og severity. Et run med null failed applicable controls sier ingenting om controls utenfor katalogen, endringer ved deployment, credentials, nettverk, physical hardware eller senere drift.

Sikker arbeidsflyt

1. Velg en benchmark som matcher target release nøyaktig.
2. Gå gjennom profilen og hver OpenFactory-tilpasning.
3. Bygg artefaktet og vent på first-boot remediation readiness.
4. Kjør hele applicable check set i en clean guest.
5. Undersøk failures; ikke konverter dem stille til not applicable.
6. Test application og operational behavior etter hardening.
7. Få exceptions godkjent av accountable security owner.
8. Kjør på nytt etter endring i package, recipe eller deployment.

Bruk CIS’ egen profile guidance  som normativt utgangspunkt, og skaff applicable benchmark via deres authorized CIS distribution channel.