Důkazy benchmarku CIS

CIS Benchmarks  jsou doporučení pro bezpečnou konfiguraci vyvinutá konsenzem. CIS popisuje Level 1 jako široce použitelnou základní úroveň a Level 2 jako defense in depth, které může ovlivnit použitelnost nebo výkon. Každý profil nejdřív použijte v testovacím prostředí.

OpenFactory může aplikovat vybrané controls a spustit katalog kontrol na stroji. Úspěšný běh je důkaz o daném artefaktu, verzi benchmarku, profilu a okamžiku v čase. Nejde o certifikaci CIS, záruku nastavení deploymentu ani důkaz souladu s jiným frameworkem.

Současná hranice remediaci

Funkce cis-benchmarks má jednu úplnou, připnutou cestu remediaci:

Cesta pro Ubuntu záměrně vypíná nebo upravuje vybraná upstream pravidla tak, aby seděla prostředí offline-first-boot a image. Vygenerovaný manifest zaznamenává provenance a zvolená nastavení. Tyto úpravy vyžadují přesné důkazy a exceptions.

security-hardening a os.security.hardening_level jsou samostatné obecné controls pro hardening. Automaticky se nemapují na úplný profil CIS Level 1 ani Level 2.

Spuštění benchmarku

Scénáře mohou zvolit přesný catalog a 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"
}

Runner má také katalogy pro Debian 12 a Debian 13 a interní sadu kontrol zaměřenou na GxP. Název catalogu nedokazuje oficiální obsah CIS ani aktuálnost. Před použitím v auditu ověřte provenance, licenci, verzi a control definitions katalogu.

Nepoužívejte starší benchmark OS jako conformance claim pro novější vydání. Resolver má v současnosti schválené same-family fallbacks pro některé novější cíle Ubuntu a Debian, aby testy mohly běžet, ale output musí být označen jako compatibility assessment vůči staršímu catalogu, ne jako conformance k benchmarku pro novější OS.

Čtení výsledku

Uschovejte alespoň:

• ID artefaktu a buildu;
• image digest a source snapshot;
• base OS identity a version;
• benchmark/catalog ID, profile a digest;
• applicable, passed, failed, skipped a not-applicable controls;
• raw command output a timestamps;
• remediation provenance;
• zdokumentované exceptions s owner a approval; a
• prostředí, ve kterém checks proběhly.

Samotné procento skrývá applicability a severity. Běh s nulovým počtem failed applicable controls nic neříká o controls mimo catalog, změnách v čase deploymentu, credentials, sítích, physical hardware ani o pozdější drift.

Bezpečný postup

1. Zvolte benchmark, který přesně odpovídá target release.
2. Projděte profil a každou adaptaci OpenFactory.
3. Sestavte artefakt a počkejte na first-boot remediation readiness.
4. Spusťte úplnou applicable check set v clean guest.
5. Prozkoumejte failures; tiše je nepřevádějte na not applicable.
6. Otestujte application a operational behavior po hardeningu.
7. Nechte accountable security owner schválit exceptions.
8. Po každé změně package, recipe nebo deploymentu spusťte znovu.

Jako normativní výchozí bod použijte vlastní profile guidance od CIS  a applicable benchmark získejte přes authorized CIS distribution channel.