Dowody benchmarku CIS

CIS Benchmarks  to rekomendacje bezpiecznej konfiguracji opracowane w konsensusie. CIS opisuje Level 1 jako szeroko użyteczną linię bazową, a Level 2 jako defense in depth, które może wpływać na użyteczność lub wydajność. Każdy profil najpierw stosuj w środowisku testowym.

OpenFactory może stosować wybrane controls i uruchamiać katalog kontroli maszyny. Udany przebieg to dowód dotyczący tego artefaktu, wersji benchmarku, profilu i momentu w czasie. To nie certyfikacja CIS, nie gwarancja ustawień deploymentu ani dowód zgodności z innym frameworkiem.

Obecna granica remediacji

Funkcja cis-benchmarks ma jedną pełną, przypiętą ścieżkę remediacji:

Ścieżka Ubuntu celowo wyłącza lub dostosowuje wybrane upstream rules do środowiska offline-first-boot i image. Wygenerowany manifest rejestruje provenance i wybrane ustawienia. Te adaptacje sprawiają, że dokładny dowód i exceptions są konieczne.

security-hardening i os.security.hardening_level to oddzielne ogólne controls hardeningu. Nie mapują się automatycznie na pełny profil CIS Level 1 ani Level 2.

Uruchamianie benchmarku

Scenariusze mogą wybrać dokładny catalog i 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 ma też katalogi dla Debian 12 i Debian 13 oraz wewnętrzny zestaw kontroli zorientowany na GxP. Nazwa catalogu nie dowodzi oficjalnej treści CIS ani aktualności. Przed użyciem w audycie potwierdź provenance, licencję, wersję i control definitions katalogu.

Nie używaj starszego benchmarku OS jako conformance claim dla nowszego wydania. Resolver ma obecnie zatwierdzone same-family fallbacks dla niektórych nowszych targetów Ubuntu i Debian, aby testy mogły działać, ale output musi być oznaczony jako compatibility assessment względem starszego catalogu, a nie jako conformance do benchmarku dla nowszego OS.

Odczyt wyniku

Zachowaj co najmniej:

• ID artefaktu i buildu;
• 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;
• udokumentowane exceptions z owner i approval; oraz
• środowisko, w którym działały checks.

Sam procent ukrywa applicability i severity. Przebieg z zerem failed applicable controls nic nie mówi o controls poza catalogiem, zmianach w czasie deploymentu, credentials, sieciach, physical hardware ani późniejszej drift.

Bezpieczny workflow

1. Wybierz benchmark dokładnie pasujący do target release.
2. Przejrzyj profil i każdą adaptację OpenFactory.
3. Zbuduj artefakt i poczekaj na first-boot remediation readiness.
4. Uruchom pełny applicable check set w clean guest.
5. Zbadaj failures; nie zamieniaj ich po cichu na not applicable.
6. Przetestuj application i operational behavior po hardeningu.
7. Niech accountable security owner zatwierdzi exceptions.
8. Uruchom ponownie po każdej zmianie package, recipe lub deploymentu.

Użyj własnych wskazówek profilowych CIS  jako normatywnego punktu wyjścia i uzyskaj applicable benchmark przez authorized CIS distribution channel.