CIS-benchmarkbevis

CIS Benchmarks  är konsensusbaserade rekommendationer för säker konfiguration. CIS beskriver Level 1 som en brett användbar baseline och Level 2 som defense in depth som kan påverka användbarhet eller prestanda. Tillämpa vardera profil först i en testmiljö.

OpenFactory kan tillämpa utvalda controls och köra en katalog av maskinkontroller. En godkänd körning är bevis om den artefakten, benchmarkversionen, profilen och tidpunkten. Det är varken CIS-certifiering, garanti om deployment-inställningar eller bevis på efterlevnad av ett annat ramverk.

Nuvarande gräns för remediering

Funktionen cis-benchmarks har en fullständig, fäst remedieringsväg:

Ubuntu-vägen inaktiverar eller anpassar medvetet utvalda upstream rules för offline-first-boot- och image-miljön. Det genererade manifestet registrerar provenance och valda inställningar. Dessa anpassningar gör exakt bevis och exceptions nödvändiga.

security-hardening och os.security.hardening_level är separata allmänna hardening-controls. De mappar inte automatiskt till en fullständig CIS Level 1- eller Level 2-profil.

Benchmarkkörning

Scenarier kan välja exakt catalog och 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"
}

Runnern har också kataloger för Debian 12 och Debian 13 samt en intern GxP-inriktad check set. Ett katalognamn är inte bevis på officiellt CIS-innehåll eller aktualitet. Bekräfta katalogens provenance, licens, version och control definitions innan du använder den i en revision.

Använd inte en äldre OS-benchmark som conformance claim för en nyare release. Resolvern har för närvarande godkända same-family fallbacks för vissa nyare Ubuntu- och Debian-targets så att tester kan köras, men output måste märkas som compatibility assessment mot den äldre catalogen, inte som conformance till en benchmark för det nyare OS:et.

Läsa ett resultat

Behåll minst:

• artifact- och build-ID;
• image digest och source snapshot;
• base OS identity och version;
• benchmark/catalog ID, profile och digest;
• applicable, passed, failed, skipped och not-applicable controls;
• raw command output och timestamps;
• remediation provenance;
• dokumenterade exceptions med owner och approval; samt
• miljön där kontrollerna kördes.

En procentsats ensam döljer applicability och severity. En körning med noll failed applicable controls säger inget om controls utanför katalogen, ändringar vid deployment, credentials, nätverk, physical hardware eller senare drift.

Säker arbetsgång

1. Välj en benchmark som exakt matchar target release.
2. Granska profilen och varje OpenFactory-anpassning.
3. Bygg artefakten och vänta på first-boot remediation readiness.
4. Kör den fullständiga applicable check set i en clean guest.
5. Utred failures; omvandla dem inte tyst till not applicable.
6. Testa application och operational behavior efter hardening.
7. Låt accountable security owner godkänna exceptions.
8. Kör om efter varje ändring av package, recipe eller deployment.

Använd CIS egna profile guidance  som normativ utgångspunkt och skaffa applicable benchmark via er authorized CIS distribution channel.