Dovezi benchmark CIS

CIS Benchmarks  sunt recomandări de configurare securizată dezvoltate prin consens. CIS descrie Level 1 ca linie de bază larg utilizabilă și Level 2 ca defense in depth care poate afecta utilitatea sau performanța. Aplicați fiecare profil mai întâi într-un mediu de test.

OpenFactory poate aplica controls selectate și rula un catalog de verificări pe mașină. O rulare reușită este dovadă despre acel artefact, versiunea benchmarkului, profilul și momentul în timp. Nu este certificare CIS, garanție pentru setările de deployment și nici dovadă de conformitate cu alt framework.

Limita actuală a remedierii

Funcția cis-benchmarks are o singură cale completă, fixată, de remediere:

Calea Ubuntu dezactivează sau adaptează în mod deliberat reguli upstream selectate pentru mediul offline-first-boot și image. Manifestul generat înregistrează provenance și setările alese. Aceste adaptări fac dovada exactă și exceptions esențiale.

security-hardening și os.security.hardening_level sunt controls generale separate de hardening. Nu se mapează automat la un profil CIS Level 1 sau Level 2 complet.

Executarea benchmarkului

Scenariile pot selecta un catalog și un level exacte:

{
  "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-ul are și cataloage pentru Debian 12 și Debian 13 și un set intern de verificări orientat GxP. Numele catalogului nu dovedește conținut CIS oficial sau actualitate. Confirmați provenance, licența, versiunea și control definitions ale catalogului înainte de utilizare într-un audit.

Nu folosiți un benchmark OS mai vechi ca conformance claim pentru o versiune mai nouă. Resolver-ul are în prezent same-family fallbacks aprobate pentru unele ținte Ubuntu și Debian mai noi, astfel încât testele să poată rula, dar output-ul trebuie etichetat ca compatibility assessment față de catalogul mai vechi, nu ca conformance la benchmark pentru OS-ul mai nou.

Citirea rezultatului

Păstrați cel puțin:

• ID-urile artefactului și build-ului;
• image digest și source snapshot;
• base OS identity și version;
• benchmark/catalog ID, profile și digest;
• applicable, passed, failed, skipped și not-applicable controls;
• raw command output și timestamps;
• remediation provenance;
• exceptions documentate cu owner și approval; și
• mediul în care au rulat checks.

Un procent singur ascunde applicability și severity. O rulare cu zero failed applicable controls nu spune nimic despre controls din afara catalogului, schimbări la deployment, credentials, rețele, physical hardware sau drift ulterior.

Flux de lucru sigur

1. Selectați un benchmark care se potrivește exact cu target release.
2. Revizuiți profilul și fiecare adaptare OpenFactory.
3. Construiți artefactul și așteptați first-boot remediation readiness.
4. Rulați setul complet applicable check set într-un clean guest.
5. Investigați failures; nu le convertiți în tăcere în not applicable.
6. Testați application și operational behavior după hardening.
7. Obțineți aprobarea exceptions de la accountable security owner.
8. Rulați din nou după orice schimbare de package, recipe sau deployment.

Folosiți ghidul de profil al CIS  ca punct de plecare normativ și obțineți applicable benchmark prin authorized CIS distribution channel.