CIS benchmark bizonyíték

A CIS Benchmarks  konszenzussal készült biztonságos konfigurációs ajánlások. A CIS a Level 1-et széles körben használható alapvonalnak írja le, a Level 2-t pedig defense in depth megoldásnak, amely befolyásolhatja a használhatóságot vagy a teljesítményt. Mindkét profilt először tesztkörnyezetben alkalmazza.

Az OpenFactory kiválasztott controls alkalmazására és gépi ellenőrzések katalógusának futtatására képes. Egy sikeres futás bizonyíték az adott artefaktumról, benchmark verzióról, profilról és időpontról. Ez nem CIS tanúsítás, nem garancia a deployment beállításaira, és nem bizonyíték más framework szerinti megfelelésre.

Jelenlegi remediaciós határ

A cis-benchmarks funkciónak egy teljes, rögzített remediaciós útja van:

Az Ubuntu út szándékosan kikapcsol vagy igazít kiválasztott upstream szabályokat az offline-first-boot és image környezethez. A generált manifest rögzíti a provenance-t és a kiválasztott beállításokat. Ezek az adaptációk miatt a pontos bizonyíték és az exceptions elengedhetetlen.

A security-hardening és az os.security.hardening_level külön általános hardening controls. Automatikusan nem mapelődnek teljes CIS Level 1 vagy Level 2 profilra.

Benchmark futtatása

A scenariók pontos catalogot és levelt választhatnak:

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

A runnernek Debian 12 és Debian 13 katalógusai is vannak, valamint egy belső, GxP-re fókuszáló ellenőrzéskészlet. A catalog neve nem bizonyítja a hivatalos CIS tartalmat vagy naprakészséget. Audit előtt erősítse meg a katalógus provenance-ét, licencét, verzióját és control definitions elemeit.

Ne használjon régebbi OS benchmarkot conformance claimként egy újabb kiadáshoz. A resolver jelenleg jóváhagyott same-family fallback-ekkel rendelkezik egyes újabb Ubuntu és Debian célokhoz, hogy a tesztek fussanak, de az outputot compatibility assessmentként kell címkézni a régebbi catalog ellen, nem conformance-ként az újabb OS benchmarkjához.

Eredmény értelmezése

Legalább ezt őrizze meg:

• artefaktum és build ID-k;
• image digest és source snapshot;
• base OS identity és version;
• benchmark/catalog ID, profile és digest;
• applicable, passed, failed, skipped és not-applicable controls;
• raw command output és timestamps;
• remediation provenance;
• dokumentált exceptions owner-rel és approval-lal; valamint
• a környezet, amelyben a checks futottak.

Az önmagában vett százalék elrejti az applicability-t és a severity-t. Egy nulla failed applicable controls eredményű futás semmit nem mond a catalogon kívüli controls-ról, deployment idejű változásokról, credentials-ről, hálózatokról, physical hardware-ről vagy későbbi drift-ről.

Biztonságos munkafolyamat

1. Válasszon a target release-hez pontosan illő benchmarkot.
2. Tekintse át a profilt és minden OpenFactory adaptációt.
3. Építse az artefaktumot, és várjon a first-boot remediation readiness-re.
4. Futtassa a teljes applicable check set-et clean guest-en.
5. Vizsgálja a failures-eket; ne alakítsa őket csendben not applicable-re.
6. Tesztelje az application és operational behavior viselkedést hardening után.
7. Kérje az accountable security owner jóváhagyását az exceptions-ökre.
8. Futtassa újra minden package, recipe vagy deployment változás után.

Normatív kiindulópontként használja a CIS saját profile guidance anyagát , és az applicable benchmarkot authorized CIS distribution channelen keresztül szerezze be.