CIS Level 1: Fundament oder Fessel?

Ich habe vor Kurzem etwas erlebt, das mich nicht losgelassen hat.

Ein Team führte CIS Level 1 ein. Gut so. CIS Level 1 ist eine solide Basis, und jede Organisation sollte sie haben. Im Zuge der Einführung wurden bestehende Regeln gelöscht. Regeln, die nicht Teil der Baseline waren. Das Ergebnis: Eine Führungskraft stellte plötzlich fest, dass sie Unternehmensdaten auf ein privates Gerät herunterladen konnte. Eine Fähigkeit, die vorher absichtlich nicht vorhanden war.

Im Namen der Sicherheit wurde die Sicherheit reduziert.

Was CIS Level 1 ist. Und was nicht.

CIS Benchmarks sind Konfigurationsempfehlungen des Center for Internet Security, entstanden aus internationalem Expertenkonsens. Level 1 deckt die grundlegende Hygiene ab: Passwortrichtlinien, Firewall-Grundkonfiguration, Deaktivierung ungenutzter Dienste. Wichtige Maßnahmen. Kein Unternehmen sollte darunter bleiben.

Aber CIS selbst sagt dazu:

"Consider them the minimum level of security that all organizations should aim to meet or exceed."

Meet or exceed. Die Betonung liegt auf "oder übertreffen". Level 1 ist der Startpunkt, nicht das Ziel. CIS beschreibt explizit, dass nach der Baseline-Implementierung "additional controls as needed" folgen sollen, für die Angriffe, die spezifisch für das eigene Unternehmen relevant sind.

Eine Baseline schützt gegen generische Angriffe. Sie schützt nicht gegen die Angriffe, die auf dein Threat-Profil zugeschnitten sind.

Das Problem mit blinder Gefolgschaft

Jedes Unternehmen ist anders. Ein Versicherungsunternehmen trägt andere Risiken als ein produzierender Betrieb. Ein Finanzdienstleister in einer regulierten Branche hat andere Anforderungen als ein Startup. Die eigene Geschichte (vergangene Vorfälle, Audit-Findings, Erkenntnisse aus dem Threat Hunting) ist in keiner generischen Baseline abgebildet.

Wenn man bestehende, wirksame Kontrollen deaktiviert, weil sie nicht in einer Checkliste stehen, passieren zwei Dinge:

Erstens: Man entfernt Schutz, den jemand bewusst eingebaut hat. Oft aus gutem Grund, oft nach einem konkreten Vorfall oder einer Risikoanalyse.

Zweitens: Man behandelt eine Baseline als vollständige Sicherheitslösung. Das ist sie nicht. Sie war nie dafür gedacht.

Was die Regulatorien dazu sagen

Die wichtigsten Rahmenwerke sind in diesem Punkt eindeutig:

ISO 27001 (Clause 6.1.3) beschreibt den Prozess so: Erst Risikoanalyse, dann notwendige Maßnahmen ableiten, dann gegen den Kontrollkatalog prüfen, nicht umgekehrt. Controls werden auf Basis von Risiken ausgewählt, nicht weil sie in Annex A stehen.

NIS2 (Artikel 21) verlangt „angemessene und verhältnismäßige Maßnahmen" unter Berücksichtigung des „Gesamtrisikoprofils" der Organisation. Kein Standard für alle, sondern ein risikobasierter, organisationsspezifischer Ansatz.

DORA (Artikel 4) formuliert das Proportionalitätsprinzip: Maßnahmen richten sich nach Größe, Risikoprofil und Komplexität des Unternehmens. Besonders relevant für regulierte Branchen wie Finanzdienstleister und Versicherungen.

BSI IT-Grundschutz unterscheidet explizit zwischen Basisabsicherung und weitergehenden Maßnahmen. Der BSI-Standard 200-3 existiert genau dafür: um über die Basis hinaus organisationsspezifische Risiken zu berücksichtigen und daraus individuelle Maßnahmen abzuleiten.

Alle diese Frameworks schreiben denselben Ansatz vor: risikobasiert, verhältnismäßig, organisationsspezifisch. Keines sagt: "Implementiere eine Baseline und entferne alles, was darüber hinausgeht."

Das richtige Modell: Schichten, keine Checkliste

Eine Baseline ist keine Sicherheitsstrategie. Sie ist die unterste Schicht davon.

┌──────────────────────────────────────┐
│  Schicht 1: Baseline (CIS Level 1)   │
│  Generische Hygiene, non-negotiable  │
├──────────────────────────────────────┤
│  Schicht 2: Org-spezifische Controls │
│  Aus Risikoanalyse, Compliance,      │
│  Audit-Findings, Branchenanforderung │
├──────────────────────────────────────┤
│  Schicht 3: Threat-Profil-spezifisch │
│  Was Threat Hunting zeigt,           │
│  bisherige Vorfälle, bekannte TTPs   │
└──────────────────────────────────────┘

Jede Schicht hat ihre Berechtigung. Die Baseline zu haben ist gut. Aber nur die Baseline zu haben und alles andere zu entfernen ist schlechter als der Ausgangszustand.

Was ich aus dem eingangs beschriebenen Vorfall gelernt habe

Der Vorfall war kein Fehler aus Böswilligkeit. Er entstand aus einem Missverständnis darüber, was eine Baseline leisten soll.

Die Lektion: Change Management für Sicherheitskontrollen funktioniert genauso wie für alles andere. Bevor eine Regel entfernt wird, braucht es die Frage: Warum existiert diese Regel? Was hat sie ursprünglich verhindert? Ist dieses Risiko heute anderweitig abgedeckt, oder fällt es einfach weg?

Eine Dokumentation der eigenen Controls mit Begründung (ähnlich einem ISO-Statement-of-Applicability) schützt vor genau diesem Fehler. Nicht bürokratisch, sondern praktisch: Man weiß, was man hat, warum man es hat, und was passiert, wenn man es entfernt.

Es wäre schlau, wenn...

CIS Level 1 ist ein ausgezeichneter Startpunkt. Es ist kein Endpunkt.

Eine Baseline schützt gegen das, wogegen alle geschützt sein sollten. Dein Threat-Profil, deine Branche, deine Geschichte und deine Risikoanalyse bestimmen, was darüber hinaus nötig ist.

Wer bestehende Schutzmaßnahmen im Namen einer Baseline entfernt, hat die Baseline missverstanden. Möglicherweise hat er die eigene Organisation in einem Bereich verwundbar gemacht, den jemand anderes bereits identifiziert und geschlossen hatte.