CIS-benchmarkbevis

CIS Benchmarks  er konsensusbaserede anbefalinger til sikker konfiguration. CIS beskriver Level 1 som en bredt anvendelig baseline og Level 2 som defense in depth, der kan påvirke anvendelighed eller ydeevne. Anvend hver profil først i et testmiljø.

OpenFactory kan anvende udvalgte controls og køre en katalog af maskintjek. Et bestået run er bevis om det artefakt, den benchmarkversion, den profil og det tidspunkt. Det er hverken CIS-certificering, garanti for deployment-indstillinger eller bevis for overholdelse af et andet framework.

Nuværende grænse for remediering

Funktionen cis-benchmarks har én fuld, fastlåst remedieringssti:

Ubuntu-stien deaktiverer eller tilpasser bevidst udvalgte upstream rules til offline-first-boot- og image-miljøet. Det genererede manifest registrerer provenance og valgte indstillinger. Disse tilpasninger gør præcist bevis og exceptions nødvendige.

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

Benchmarkkørsel

Scenarier kan vælge præcis 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-orienteret check set. Et katalognavn er ikke bevis for officielt CIS-indhold eller aktualitet. Bekræft katalogets provenance, licens, version og control definitions, før du bruger det i en audit.

Brug ikke en ældre OS-benchmark som conformance claim for en nyere release. Resolveren har i øjeblikket godkendte same-family fallbacks for nogle nyere Ubuntu- og Debian-targets, så tests kan køre, men output skal mærkes som compatibility assessment mod den ældre catalog, ikke som conformance til en benchmark for det nyere OS.

Læse et resultat

Behold mindst:

• 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;
• dokumenterede exceptions med owner og approval; og
• miljøet, hvor tjekkene kørte.

En procentdel alene skjuler applicability og severity. Et run med nul failed applicable controls siger intet om controls uden for kataloget, ændringer ved deployment, credentials, netværk, physical hardware eller senere drift.

Sikker workflow

1. Vælg en benchmark, der matcher target release præcist.
2. Gennemgå profilen og hver OpenFactory-tilpasning.
3. Byg artefakten og vent på first-boot remediation readiness.
4. Kør det fulde applicable check set i en clean guest.
5. Undersøg failures; konverter dem ikke stille til not applicable.
6. Test application og operational behavior efter hardening.
7. Få exceptions godkendt af accountable security owner.
8. Kør igen efter enhver ændring af package, recipe eller deployment.

Brug CIS’ egen profile guidance  som normativt udgangspunkt, og skaff applicable benchmark via jeres authorized CIS distribution channel.