CIS-benchmark-todisteet

CIS Benchmarks  ovat konsensuksella laadittuja suosituksia turvalliseen konfiguraatioon. CIS kuvaa Level 1:n laajasti käytettävän perustason ja Level 2:n defense in depth -tasoa, joka voi vaikuttaa käytettävyyteen tai suorituskykyyn. Ota kumpikin profiili ensin käyttöön testiympäristössä.

OpenFactory voi soveltaa valittuja controls -kohtia ja ajaa koneellisten tarkistusten luettelon. Onnistunut ajo on todiste kyseisestä artefaktista, benchmark-versiosta, profiilista ja ajankohdasta. Se ei ole CIS-sertifiointi, takuu deployment-asetuksista eikä todiste noudattamisesta toista kehystä kohtaan.

Nykyinen remedioinnin raja

Ominaisuudella cis-benchmarks on yksi täydellinen, kiinnitetty remedioinnin polku:

Ubuntu-polku poistaa tai mukauttaa tarkoituksella valittuja upstream rules -sääntöjä offline-first-boot- ja image-ympäristöön. Luotu manifest tallentaa provenance-tiedot ja valitut asetukset. Nämä mukautukset tekevät tarkasta todisteesta ja exceptions -poikkeuksista välttämättömiä.

security-hardening ja os.security.hardening_level ovat erillisiä yleisiä hardening-controls -kohtia. Ne eivät vastaa automaattisesti täyttä CIS Level 1- tai Level 2 -profiilia.

Benchmarkin suoritus

Skenaariot voivat valita tarkan catalogin ja levelin:

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

Runnerilla on myös luettelot Debian 12:lle ja Debian 13:lle sekä sisäinen GxP-painotteinen check set. Catalog-nimi ei todista virallista CIS-sisältöä tai ajantasaisuutta. Vahvista catalogin provenance, lisenssi, versio ja control definitions ennen audit-käyttöä.

Älä käytä vanhempaa OS-benchmarkia conformance claim -väitteenä uudemmalle julkaisulle. Resolverilla on tällä hetkellä hyväksytyt same-family fallbacks -varavaihtoehdot joillekin uudemmille Ubuntu- ja Debian-target -kohteille, jotta testit voivat ajaa, mutta output on merkittävä compatibility assessment -arvioksi vanhempaa catalogia vastaan, ei conformance -noudattamiseksi uudemman OS:n benchmarkiin.

Tuloksen lukeminen

Säilytä vähintään:

• artifact- ja build-ID:t;
• image digest ja source snapshot;
• base OS identity ja version;
• benchmark/catalog ID, profile ja digest;
• applicable, passed, failed, skipped ja not-applicable controls;
• raw command output ja timestamps;
• remediation provenance;
• dokumentoidut exceptions owner- ja approval-tiedoilla; ja
• ympäristö, jossa tarkistukset ajettiin.

Pelkkä prosentti piilottaa applicabilityn ja severityn. Ajo, jossa failed applicable controls on nolla, ei kerro catalogin ulkopuolisista controls -kohdista, deployment-aikaisista muutoksista, credentials -tunnistetiedoista, verkoista, physical hardware -laitteista tai myöhemmästä driftistä.

Turvallinen työnkulku

1. Valitse benchmark, joka vastaa täsmälleen target release -julkaisua.
2. Käy läpi profiili ja jokainen OpenFactory-mukautus.
3. Rakenna artefakti ja odota first-boot remediation readiness -valmiutta.
4. Aja täydellinen applicable check set puhtaassa clean guest -ympäristössä.
5. Tutki failures; älä muunna niitä hiljaa not applicable -tilaan.
6. Testaa application- ja operational behavior hardeningin jälkeen.
7. Anna accountable security ownerin hyväksyä exceptions.
8. Aja uudelleen jokaisen package-, recipe- tai deployment-muutoksen jälkeen.

Käytä CIS:n omaa profile guidance -ohjetta  normatiivisena lähtökohtana ja hanki applicable benchmark authorized CIS distribution channel -kanavan kautta.