Dokazi benchmarka CIS

CIS Benchmarks  so priporočila za varno konfiguracijo, razvita v konsenzu. CIS opisuje Level 1 kot široko uporabno osnovo in Level 2 kot defense in depth, ki lahko vpliva na uporabnost ali zmogljivost. Vsak profil najprej uporabite v testnem okolju.

OpenFactory lahko uporabi izbrane controls in zažene katalog strojnih preverjanj. Uspešen zagon je dokaz o tem artefaktu, različici benchmarka, profilu in trenutku v času. To ni certifikacija CIS, garancija za nastavitve deploymenta niti dokaz skladnosti z drugim frameworkom.

Trenutna meja remediacije

Funkcija cis-benchmarks ima eno popolno, pripeto pot remediacije:

Pot za Ubuntu namerno onemogoči ali prilagodi izbrana upstream pravila, da ustrezajo okolju offline-first-boot in image. Ustvarjen manifest zabeleži provenance in izbrane nastavitve. Te prilagoditve zahtevajo natančne dokaze in exceptions.

security-hardening in os.security.hardening_level sta ločena splošna controls za hardening. Samodejno se ne preslikata v popoln profil CIS Level 1 ali Level 2.

Izvajanje benchmarka

Scenariji lahko izberejo natančen catalog in 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 ima tudi kataloge za Debian 12 in Debian 13 ter notranji nabor preverjanj, usmerjen v GxP. Ime cataloga ne dokazuje uradne vsebine CIS niti aktualnosti. Pred uporabo v reviziji preverite provenance, licenco, različico in control definitions kataloga.

Ne uporabljajte starejšega benchmarka OS kot conformance claim za novejšo izdajo. Resolver trenutno ima odobrene same-family fallbacks za nekatere novejše cilje Ubuntu in Debian, da lahko testi tečejo, vendar mora biti output označen kot compatibility assessment glede na starejši catalog, ne kot conformance do benchmarka za novejši OS.

Branje rezultata

Hranite vsaj:

• ID-je artefakta in builda;
• image digest in source snapshot;
• base OS identity in version;
• benchmark/catalog ID, profile in digest;
• applicable, passed, failed, skipped in not-applicable controls;
• raw command output in timestamps;
• remediation provenance;
• dokumentirane exceptions z owner in approval; in
• okolje, v katerem so checks tekli.

Sam odstotek skriva applicability in severity. Zagon z nič failed applicable controls ne pove nič o controls zunaj cataloga, spremembah ob deploymentu, credentials, omrežjih, physical hardware ali kasnejši drift.

Varen potek dela

1. Izberite benchmark, ki natančno ustreza target release.
2. Preglejte profil in vsako adaptacijo OpenFactory.
3. Zgradite artefakt in počakajte na first-boot remediation readiness.
4. Zaženite celoten applicable check set v clean guest.
5. Raziščite failures; jih ne pretvarjajte tiho v not applicable.
6. Preizkusite application in operational behavior po hardeningu.
7. Naj accountable security owner odobri exceptions.
8. Po vsaki spremembi package, recipe ali deploymenta znova zaženite.

Kot normativno izhodišče uporabite lastno profile guidance CIS  in applicable benchmark pridobite prek authorized CIS distribution channel.