Dôkazy benchmarku CIS

CIS Benchmarks  sú odporúčania pre bezpečnú konfiguráciu vyvinuté konsenzom. CIS popisuje Level 1 ako široko použiteľnú základnú úroveň a Level 2 ako defense in depth, ktoré môže ovplyvniť použiteľnosť alebo výkon. Každý profil najprv použite v testovacom prostredí.

OpenFactory môže aplikovať vybrané controls a spustiť katalóg kontrol na stroji. Úspešný beh je dôkaz o danom artefakte, verzii benchmarku, profile a okamihu v čase. Nejde o certifikáciu CIS, záruku nastavení deploymentu ani dôkaz súladu s iným frameworkom.

Súčasná hranica remediacie

Funkcia cis-benchmarks má jednu úplnú, pripnutú cestu remediacie:

Cesta pre Ubuntu zámerne vypína alebo upravuje vybrané upstream pravidlá tak, aby sedeli prostrediu offline-first-boot a image. Vygenerovaný manifest zaznamenáva provenance a zvolené nastavenia. Tieto úpravy vyžadujú presné dôkazy a exceptions.

security-hardening a os.security.hardening_level sú samostatné všeobecné controls pre hardening. Automaticky sa nemapujú na úplný profil CIS Level 1 ani Level 2.

Spustenie benchmarku

Scenáre môžu zvoliť presný 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á tiež katalógy pre Debian 12 a Debian 13 a internú sadu kontrol zameranú na GxP. Názov catalogu nedokazuje oficiálny obsah CIS ani aktuálnosť. Pred použitím v audite overte provenance, licenciu, verziu a control definitions katalógu.

Nepoužívajte starší benchmark OS ako conformance claim pre novšie vydanie. Resolver má v súčasnosti schválené same-family fallbacks pre niektoré novšie ciele Ubuntu a Debian, aby testy mohli bežať, ale output musí byť označený ako compatibility assessment voči staršiemu catalogu, nie ako conformance k benchmarku pre novší OS.

Čítanie výsledku

Uschovajte aspoň:

• 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
• prostredie, v ktorom checks prebehli.

Samotné percento skrýva applicability a severity. Beh s nulovým počtom failed applicable controls nič nehovorí o controls mimo catalogu, zmenách v čase deploymentu, credentials, sieťach, physical hardware ani o neskoršej drift.

Bezpečný postup

1. Zvoľte benchmark, ktorý presne zodpovedá target release.
2. Prejdite profil a každú adaptáciu OpenFactory.
3. Zostavte artefakt a počkajte na first-boot remediation readiness.
4. Spustite úplnú applicable check set v clean guest.
5. Preskúmajte failures; potichu ich neprevádzajte na not applicable.
6. Otestujte application a operational behavior po hardeningu.
7. Nechajte accountable security owner schváliť exceptions.
8. Po každej zmene package, recipe alebo deploymentu spustite znova.

Ako normatívny východiskový bod použite vlastné profile guidance od CIS  a applicable benchmark získajte cez authorized CIS distribution channel.