CIS Benchmarks und DISA STIGs als Härtungsbasis: Was sie sind und wie sie selektiv angewendet werden

Worum es geht

Das Center for Internet Security veröffentlicht die CIS Benchmarks: im Konsens erarbeitete Konfigurationsleitfäden für Betriebssysteme, Cloud-Plattformen und Anwendungen, die über cisecurity.org verteilt werden. Benchmarks sind üblicherweise in Profilstufen gegliedert: ein Basisprofil, das breit einsetzbar sein soll und den Betrieb nur begrenzt beeinträchtigt, sowie ein strengeres Profil für Umgebungen, die mehr funktionale Einschränkungen in Kauf nehmen. Welche Stufe gilt, legt jede Organisation selbst fest; sie ist nicht vorgegeben.

DISA STIGs (Security Technical Implementation Guides) sind das Gegenstück des US-Verteidigungsministeriums (DoD). Sie werden über den DoD Cyber Exchange unter public.cyber.mil/stigs/ veröffentlicht und erschlossen. STIG-Findings werden üblicherweise nach Schweregradkategorien eingestuft. Zu jeder Prüfung gehört eine Anleitung zur Behebung, sodass sich diese automatisieren oder manuell prüfen lässt.

Beide sind Empfehlungen, keine Gesetze: Eine Organisation wählt eine Baseline und entscheidet dann, welche einzelnen Prüfungen für einen bestimmten Host oder Dienst gelten.

Warum es wichtig ist

Eine Benchmark oder STIG, die für einen Allzweck-Server geschrieben wurde, kann eine Einstellung abschalten, von der eine bestimmte Anwendung abhängt, etwa eine Cipher, einen älteren Authentifizierungsmodus oder ein Verhalten von Servicekonten. Werden alle Empfehlungen bedingungslos und ohne Tests umgesetzt, ist das eine häufige Ursache für einen Ausfall, bei dem niemand an einen Zusammenhang mit einer «blossen Härtungsrunde» denkt. Wird die Baseline als Checkliste behandelt, an der man den Ist-Zustand misst, und werden Ausnahmen dokumentiert, bleibt der Audit-Trail wahrheitsgetreu darüber, was tatsächlich umgesetzt wurde.

So wird es angewendet

• Pro Host-Rolle eine einzige Baseline wählen (CIS oder STIG, keine ad hoc zusammengestellte Mischung) und festhalten, welche Profilstufe aus welchem Grund gewählt wurde.
• In gemischten oder älteren Umgebungen jede Prüfung vor der Umsetzung lesen; nicht sämtliche Empfehlungen ungeprüft maschinell anwenden.
• Für jede nicht umgesetzte Prüfung den Grund und die genehmigende Person festhalten; diese Liste ist selbst ein Audit-Artefakt.
• Dieselbe Baseline nach jedem grösseren Upgrade von Betriebssystem oder Anwendung erneut ausführen, da sich Empfehlungen und Standardeinstellungen mit der Zeit ändern.
• Sobald eine Baseline gewählt ist, automatisiertes Scanning (siehe OpenSCAP) der manuellen Überprüfung vorziehen, damit sich Nachprüfungen reproduzierbar wiederholen lassen.

Stolpersteine

• Ein strengeres Profil auf einen Host anwenden, der nie dagegen getestet wurde, und erst Tage später einen defekten Login-Pfad oder Backup-Job entdecken.
• «100 % bestanden» als Ziel betrachten statt «jede Abweichung ist eine dokumentierte, genehmigte Entscheidung».
• Vergessen, dass Benchmarks und STIGs versioniert sind; ein Scan gegen eine veraltete Kopie verbirgt neu relevante Prüfungen.