Evidenza benchmark CIS

I CIS Benchmarks sono raccomandazioni configurazione sicura sviluppate per consenso. CIS descrive Level 1 come baseline ampiamente utilizzabile e Level 2 come defense in depth che può influire su utilità o performance. Applica uno dei profili prima in ambiente test.

OpenFactory può applicare controlli selezionati ed eseguire un catalogo controlli macchina. Una run superata è evidenza su quell’artefatto, versione benchmark, profilo e punto nel tempo. Non è certificazione CIS, garanzia su impostazioni deploy o prova conformità a un altro framework.

Confine remediation attuale

La feature cis-benchmarks ha un solo percorso remediation pin completo:

Base	Comportamento attuale
Ubuntu 24.04	Prepara `ansible-lockdown/UBUNTU24-CIS` release 1.6.0 al commit `c893ca6836fb32b1ea067d4a63c341e39693074b`, verifica digest archivio e applica profilo server o workstation Level 1 al first boot.
Altre basi Linux supportate	Applica solo una piccola baseline sicurezza portabile. Non esegue il ruolo Ubuntu e non va descritta come remediation CIS equivalente.

Il percorso Ubuntu disabilita o adatta deliberatamente regole upstream selezionate per l’ambiente first-boot offline e immagine. Il manifest generato registra provenienza e impostazioni selezionate. Questi adattamenti rendono evidenza ed eccezioni esatte essenziali.

security-hardening e os.security.hardening_level sono controlli hardening generale separati. Non mappano automaticamente a un profilo CIS Level 1 o Level 2 completo.

Esecuzione benchmark

Gli scenari possono selezionare catalogo e livello esatti:


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

Il runner ha anche cataloghi per Debian 12 e Debian 13 e un insieme controlli orientato GxP interno. Un nome catalogo non prova contenuto CIS ufficiale o attualità. Conferma provenienza, licenza, versione e definizioni controllo del catalogo prima dell’uso in audit.

Non usare un benchmark OS più vecchio come affermazione conformità per una release più nuova. Il resolver ha attualmente fallback same-family approvati per alcuni target Ubuntu e Debian più nuovi così i test possono girare, ma l’output deve essere etichettato valutazione compatibilità contro catalogo più vecchio, non conformità a benchmark per OS più nuovo.

Leggere un risultato

Conserva almeno:

ID artefatto e build;
digest immagine e snapshot sorgente;
identità e versione OS base;
ID benchmark/catalogo, profilo e digest;
controlli applicabili, superati, falliti, saltati e non applicabili;
output comando grezzo e timestamp;
provenienza remediation;
eccezioni documentate con owner e approvazione; e
ambiente in cui i controlli sono girati.

Una percentuale da sola nasconde applicabilità e severità. Una run con zero controlli applicabili falliti non dice nulla su controlli fuori catalogo, cambi al deploy, credenziali, reti, hardware fisico o drift successivo.

Flusso sicuro

Seleziona un benchmark che corrisponda esattamente alla release target.
Rivedi profilo e ogni adattamento OpenFactory.
Builda l’artefatto e attendi readiness remediation first-boot.
Esegui l’insieme controlli applicabile completo in un guest pulito.
Indaga fallimenti; non convertirli silenziosamente in non applicabile.
Testa comportamento applicazione e operativo dopo hardening.
Fai approvare eccezioni dall’owner sicurezza responsabile.
Riesegui dopo qualsiasi cambio pacchetto, ricetta o deploy.

Usa la guida profilo CIS come punto di partenza normativo e ottieni il benchmark applicabile tramite il canale distribuzione CIS autorizzato.