Vom SANS zum Standard: Wie die CIS Controls geboren wurden

Vom SANS zum Standard: Wie die CIS Controls geboren wurden

Es fängt – wie vieles in der Informationssicherheit – nicht mit einem großen Plan an, sondern mit Frust. Frust darüber, dass Unternehmen immer wieder an denselben Stellen getroffen werden. Frust darüber, dass dicke Ordner voller Richtlinien kaum helfen, wenn ein Angreifer mit banalen Mitteln durch eine unentdeckte Fernwartungsschnittstelle spaziert. Frust darüber, dass jede Organisation aufwendig eigene Kataloge schreibt, während die Kriminellen längst arbeitsteilig, wiederholbar und effizient vorgehen. Aus diesem Frust entsteht eine Idee, die zunächst beinahe unverschämt schlicht wirkt: Statt noch ein Rahmenwerk, noch eine Norm, noch eine Auslegungshilfe zu veröffentlichen, bündeln wir das, was wirklich wirkt, und bringen es in eine priorisierte Reihenfolge. Keine Theorielehre, sondern ein Programm. Kein schönes Plakat, sondern eine Handlungsanweisung. Aus dieser Idee wurden erst die „Top 20 Critical Security Controls“ – und im nächsten Schritt das, was wir heute als CIS Controls kennen.

Die Ausgangslage: Zu viel Theorie, zu wenig Wirkung

Die frühen 2000er-Jahre sind eine Zeit des Aufbruchs – und der Ernüchterung. Die Sicherheitsgemeinde verfügt über Rahmenwerke en masse: ISO/IEC 27001 mit seinem Managementansatz, NIST SP 800-53 mit seinem umfassenden Kontrollkatalog, COBIT für Governance, ITIL für Serviceprozesse. All das ist wertvoll. Doch im Maschinenraum der Unternehmen bleiben immer wieder dieselben Lücken offen: nicht inventarisierte Systeme, veraltete Software, grob fahrlässige Standardkonfigurationen, allzu großzügige Administratorrechte, schwache Protokollierung, zu seltene Auswertung. Wer ein Incident-Response-Team begleitet, erkennt Muster. Wer viele Reaktionen begleitet, erkennt immer dieselben Muster.

Parallel professionalisieren sich Angreifer. Würmer und Bots werden massentauglich, Exploit-Kits standardisieren den Missbrauch von Schwachstellen, initiale Kompromittierungen finden nicht mehr zufällig statt, sondern entlang eines geübten Drehbuchs. Währenddessen diskutieren Unternehmen weiter über Dokumentvorlagen. Die Kluft zwischen Papier-Compliance und operativer Wirksamkeit wird größer.

Genau hier setzt die SANS-Community an. Aus einem Kreis von Praktikerinnen und Praktikern, die tagtäglich echte Kompromittierungen sehen, entsteht ein Konsens: Wir brauchen keinen weiteren Katalog von Möglichkeitsformen, sondern einen abgespeckten, evidenzbasierten Pflichtenkern. Er soll Angriffe dort unterbrechen, wo sie erfahrungsgemäß am häufigsten und am effektivsten verlaufen. Er soll messbar sein, automatisierbar wo immer möglich, und priorisiert – damit Organisationen mit begrenzten Mitteln zuerst die größten Löcher schließen.

Die Geburtsstunde: Konsens statt Komitee

Am Anfang steht ein ungewohnter Prozess. Nicht ein Gremium schreibt seinen Willen in Paragrafen, sondern ein offener Konsens-Workshop bündelt Feldwissen. Strafverfolger, Incident-Responder, Penetrationstester, Forensiker, Verteidiger aus großen Unternehmen und Behörden – sie alle schreiben zusammen, was sie am häufigsten sehen und was in der Praxis hilft. Der ursprüngliche Arbeitstitel „Consensus Audit Guidelines“ verrät das Programm: prüfbare Maßnahmen, um den realen Angriffswegen das Wasser abzugraben. Aus dieser Zusammenarbeit formt sich die erste Top-20-Liste. Keine Komplettlösung, keine Norm; vielmehr ein Startprogramm mit maximaler Wirkung pro investierter Stunde.

Zwei Entscheidungen prägen diese frühe Fassung:

1. Priorisierung vor Vollständigkeit. Die Controls werden bewusst gewichtet. Wer nur wenig Kapazität hat, soll trotzdem Wirkung erzielen können.
2. Messbarkeit vor Rhetorik. Zu jedem Control gibt es Subcontrols, die prüfen, zählen, verifizieren lassen – idealerweise automatisiert. Damit wird aus dem „Du solltest“ ein „So überprüfst du, ob du es tust“.

Damit ist der Nerv getroffen. In Incident-Teams beginnt man, Maßnahmenpläne nicht mehr an Abteilungsgrenzen, sondern entlang der Controls zu bauen. In Security-Operations-Teams entstehen Dashboards, die nicht bunte Kurven, sondern Kontrollreife zeigen. Und in Vorständen lässt sich Wirkung plötzlich in Monaten statt in Jahren spüren.

Warum die Controls anders sind: Angriffspfad statt Abteilungsgrenze

Der vielleicht wichtigste Unterschied zu klassischen Rahmenwerken liegt in der Angreiferperspektive. Die Controls sind nicht nach Organisationsdiagrammen sortiert („Netzwerkteam“, „Datenbankteam“, „Endpointteam“), sondern entlang des Angriffsverlaufs:

• Wie kommt der Gegner hinein? (unautorisierte Geräte/Software, Phishing, Fernzugänge)
• Wie verbreitet er sich? (fehlende Härtung, offene Dienste, schwache Adminkontrollen)
• Wie bleibt er unbemerkt? (mangelnde Protokollierung, fehlende Auswertung)
• Wie exfiltriert oder zerstört er Daten? (fehlende Segmentierung, unkontrollierte Datenflüsse)

Diese Sicht macht den Unterschied im Alltag. Wenn ein Team alle zwei Wochen die gleiche Geschichte erzählt – nur mit anderen Systemnamen –, dann hilft eine Maßnahme, die immer dieselbe Engstelle schließt, überproportional. Genau deshalb stehen Inventarisierung, Härtung, Schwachstellenmanagement und Adminrechtedisziplin so weit oben: Sie verkürzen oder unterbrechen den Angriffsweg früh.

Von der Liste zum Programm: Subcontrols, Kategorien, Automatisierung

Ein Control ohne Subcontrols ist ein guter Vorsatz. Erst die feinere Körnung macht es prüfbar. Früh wurden die Subcontrols in Anwendungskategorien gegliedert, die in der Praxis Orientierung geben:

• Quick Wins: kurzfristig umsetzbar, hoher Effekt.
• Verbesserte Sichtbarkeit und Attribution: Maßnahmen, die Angreiferhandlungen transparent machen.
• Konfigurations-/Hygienemaßnahmen: nachhaltige Härtungen, Standardisierungen, Baselines.
• Fortgeschrittene Kontrollen: aufwendiger, aber wirkungsvoll gegen hartnäckige Gegner.

Diese Einteilung ist mehr als Kosmetik. Sie erlaubt es, Roadmaps zu bauen, die weder Blauäugigkeit pflegen („Alles auf einmal!“) noch Resignation („Wir sind zu klein dafür.“) zulassen. Noch ein zweiter Gedanke prägt die Subcontrols: Automatisierung. Überall dort, wo ein Export, ein Scan, ein zentrales Log, ein Dashboard die Arbeit erleichtert, wird genau das verlangt – nicht als Luxus, sondern als Grundbedingung, damit Kontrolle im Alltag gelebt werden kann.

Die ersten 20: Warum gerade diese Themen zuerst kamen

Wer die frühen „Top 20“ liest, erkennt sofort das Programm. Control 1: Inventar autorisierter und unautorisierter Geräte. Denn was man nicht kennt, kann man nicht schützen. Control 2: Inventar autorisierter und unautorisierter Software. Denn wo beliebige Software läuft, laufen Angreifer mit. Control 3: Sichere Konfigurationen für Systeme und Anwendungen. Denn Standard-Setups sind bequeme Einfallstore. Control 4: Kontinuierliches Schwachstellenmanagement. Denn die Zeit zwischen Advisory und Exploit lässt keine Quartalsrhythmen zu. Control 5: Kontrollierter Einsatz privilegierter Konten. Denn die schnellste Rolltreppe Richtung Totalschaden ist ein weit offenes Adminkonto.

Die Liste geht weiter – über Malwareabwehr, Log-Management, Grenzschutz, Datenwiederherstellung, Netzwerksegmentierung, Browser-/E-Mail-Sicherheit, Sicherheitsbewusstsein bis hin zu Penetrationstests und Red-Team-Übungen. Was auffällt: Vieles wirkt unspektakulär. Es geht nicht um exotische Kryptographie oder hochglänzende Appliances. Es geht um Disziplin, Wiederholbarkeit, Sichtbarkeit. Dort, wo Organisationen genau diese Tugenden ausbauen, sinkt die Trefferquote typischer Angriffe drastisch.

Übersetzen statt ersetzen: Mappings zu ISO, NIST & Co.

Ein häufiger Einwand lautete anfangs: „Wir haben doch schon ISO 27001, warum noch eine Liste?“ Die Antwort war nie „stattdessen“, sondern „dazwischen“. Die Controls ersetzen keine Managementnorm und auch keinen umfassenden Regelkatalog. Sie füllen die Lücke zwischen Managementzielen und Betrieb. Deshalb entstanden früh Mappings: Jede Control wird auf NIST SP 800-53, ISO/IEC 27001/27002, COBIT und andere Referenzen abgebildet. So kann ein Unternehmen zeigen: Was wir operative tun, erfüllt zugleich unsere formalen Pflichten. Und Audits erhalten eine gemeinsame Sprache mit dem Betrieb.

Vom SANS-Projekt zur unabhängigen Trägerschaft

Was als Community-Liste begann, brauchte eine Heimat, die dauerhafte Pflege und Neutralität sichert. Es reifte der Gedanke, die Controls nicht als Eigentum einer Trainingsorganisation zu führen, sondern unter den Schirm einer gemeinnützigen, herstellerunabhängigen Institution zu stellen – mit klaren Prozessen, offenen Konsultationen, breiter Beteiligung von Wirtschaft, Verwaltung und Forschung. Die Verantwortung wanderte Schritt für Schritt aus dem SANS-Umfeld in eine eigenständige Trägerschaft, mit dem Ziel, die Controls vom De-facto-Toolkit zum offiziell gepflegten Standardwerk reifen zu lassen.

Dieser Schritt veränderte mehr als nur Logos. Er professionalisierte den Redaktionsprozess: Arbeitsgruppen, öffentliche Review-Phasen, dokumentierte Abwägungen bei Änderungen, klare Regeln für Versionierung und Archivierung. Aus einer Liste, die „richtig klang“, wurde ein lebendiges Regelwerk, das angreifergetrieben bleibt und dennoch die Sorgfalt eines Standards mitbringt.

Warum die Controls nicht stehen bleiben: Intelligence und Iteration

Ein Rahmenwerk, das hält, was es verspricht, muss sich schneller bewegen als die nächste Angriffswelle. Deshalb verankern die Controls ein Prinzip, das in vielen Normen erst langsam Fuß fasst: intelligence-driven Iteration. Jede neue Version wertet Vorfallberichte, Erfahrungen aus Red-Team-Übungen, forensische Analysen und staatliche Lagebilder aus. Kontrollen werden geschärft, überlappende Subcontrols zusammengeführt, veraltete Anforderungen gestrichen, neue Beobachtungen eingearbeitet. Der Anspruch ist nicht, „alles“ abzudecken, sondern den Wirkungsgrad zu maximieren. Wenn eine neue Technik (etwa die stark wachsende Bedeutung von Anwendungs-Whitelisting oder Application Control auf Endpunkten) in der Praxis überproportional hilft, rückt sie im Katalog nach oben – unabhängig davon, ob sie in Lehrbüchern bereits prominent ist.

Die Praxisrevolution: Vom Auditkatalog zur Betriebssteuerung

In Unternehmen, die den Katalog ernsthaft einführen, ändert sich die Art zu arbeiten. Die Controls werden nicht zum weiteren Audit-Kästchen, sondern zur Betriebssteuerung. Drei Muster tauchen immer wieder auf:

1. Transparenz als Taktgeber. Statt alle sechs Monate mühsam „Listen zu ziehen“, entstehen automatisierte Exporte: Gerätelisten aus Verzeichnisdiensten, Softwareinventare aus Managementsystemen, Schwachstellenalter aus Scannern, Admin-Sitzungen aus PAM-Tools, Restore-Protokolle aus Backup-Systemen. Diese fließen in Dashboards, die Schwellen kennen – und Eskalationen auslösen, wenn sie gerissen werden.
2. Roadmaps statt Alibi. Unternehmen priorisieren entlang der Controls – nicht entlang interner Machtlogiken. Was oben steht, wird zuerst gemacht, mit klaren Fristen und Re-Checks. So verschwindet der beliebte Fluchtweg „Wir sind so besonders, wir brauchen das nicht“.
3. Proben statt Phrasen. Wo Controls eine Übung verlangen (z. B. Wiederherstellung), wird geübt. Nicht weil es Prüfer verlangen, sondern weil die Teams so verlässliche Zeiten und Integritätsbelege ermitteln, die im Ernstfall Leben retten: das der Daten und das der Organisation.

Szenen aus dem Maschinenraum: Wie drei Häuser umstellen

Ein Zahlungsdienstleister stellt fest, dass jeder ernsthafte Vorfall mit identischen Zutaten beginnt: vergessene Systeme, zu breite Privilegien, spärliche Logs. Er baut ein „Control-Brett“, das wöchentlich überprüft, wie viele Assets mit unbekannter Eigentümerschaft existieren, wie viele Adminrechte ohne Begründung leben, wie viele Endpunkte fehlende Agenten aufweisen. Drei Monate später sind die Zahlen halbiert; sechs Monate später steigen die SOC-Treffer bereits früher in der Kill Chain ein.

Ein Industriekonzern kämpft mit Schatten-IT. Statt sie zu verdammen, koppelt er Netzwerkzugänge an die Inventare (Control 1/2) und setzt Application Control auf kritischen Fertigungsrechnern durch (Control 3/7). Gleichzeitig werden Wartungsfenster für Schwachstellenremediation verbindlich (Control 4). Ergebnis: In einem Jahr sinken unautorisierte Softwarefunde um 70 %, Notfall-Patches werden planbar, ungewollte Prozessstillstände nehmen messbar ab.

Eine Behörde ringt mit Forensik nach Vorfällen. Erst das Zusammenspiel aus Protokollierung (Control 6) und Auswertung (Control 14 in frühen Fassungen; später klarer in den Logging/Monitoring-Anforderungen verankert) erlaubt es, Angreiferpfade nachzuvollziehen. Ein zentrales Zeitquellen-Management (NTP-Härtung) verhindert widersprüchliche Zeitstempel. Binnen kurzer Zeit wechselt die Tonlage im Krisenraum von „Wir vermuten“ zu „Wir wissen“.

Die Debatte: „20 Maßnahmen reichen nicht“ – und warum das richtig ist

Kritiker bemängeln, die Controls seien nicht vollständig. Das stimmt – und es ist Absicht. Der Katalog will wirken, nicht alles sein. Er ersetzt weder ein Informationssicherheits-Managementsystem noch branchenspezifische Anforderungen, ersetzt nicht die Governance-Aufgaben von Vorstand und Aufsichtsrat und schon gar nicht die rechtlichen Pflichten aus Datenschutz, Finanzaufsicht oder Kritikalitätsregimen. Was er leistet: Priorisieren. Er schiebt das, was erwiesenermaßen die meisten Einbrüche verhindert oder früh erkennt, nach oben, und er zwingt die Organisation, Messbarkeit und Automatisierung zum Prinzip zu machen.

Wer dann später weiter verfeinert – mit tiefer Segmentierung, mit speziellen Kryptovorgaben, mit feinjustierten DevSecOps-Pipelines –, baut auf einem tragfähigen Fundament auf, statt in einem Haus ohne Keller teure Kunst an die Wand zu hängen.

Messen, was zählt: Von Kennzahlen zu Konsequenzen

Ein Katalog ohne Konsequenzen endet als Poster. Die Controls haben daher implizit eine Governance-These eingebaut: Wenige, harte Kennzahlen schlagen lange Listen, wenn sie Schwellen, Owner, Eskalationswege und Fristen besitzen. In reifen Häusern sehen sie so aus:

• Anteil inventarisierter Assets (Systeme und Software) – mit definierter Mindestquote und Toleranz für Ausnahmen.
• Schwachstellen-Alterskurve je Kritikalität – mit maximaler Verweildauer, Ausnahmeprozessen und Kompensation.
• Quote erfolgreich geübter Restores auf Anwendungsebene – samt Integritätsbelegen.
• Nutzung privilegierter Konten – inklusive Reviews und Verfallsdaten.
• Vollständigkeit und Zeitnähe von Logs auf kritischen Systemen – inklusive Auswerte-Coverage.

Jede Zahl ist nicht Dekoration, sondern Auslöser: für Tickets, für Maßnahmen, für Re-Tests. So entsteht aus der Liste ein Takt.

Sicherheit als Mannschaftssport: Training, Kultur, Verhalten

Die Controls erwähnen nicht nur Technik. Sie verlangen Schulung – nicht als Pflichtübung, sondern als Verhaltensänderung. Das ist unbequem, aber wirkungsvoll: Wiederkehrende, anwendungsnahe Awareness-Formate zu Phishing-Mustern, Passwort-Bewirtschaftung, Datenklassifikation, Meldewegen. Und es braucht Vorbilder: Führungskräfte, die selbst MFA konsequent nutzen, Ausnahmen nur befristet genehmigen, Near-Miss-Meldungen belohnen statt bestrafen und Lessons Learned als Chefsache begreifen. Ohne diese Kultur kippt jeder technische Fortschritt unter dem Gewicht alter Gewohnheiten.

Warum die Controls immer öfter in Ausschreibungen und Prüfungen auftauchen

Wenn etwas praktisch wirkt, wird es zum gemeinsamen Nenner. Immer mehr Ausschreibungen und Verträge verlangen deshalb nicht die sterile Formel „nach anerkannter Regel der Technik“, sondern konkrete Control-Reife: Application Control auf Endpunkten, definierte Patch-Zeiten, belegte Restore-Übungen, belegte Admin-Disziplin, belegte Logging-Coverage. Prüfer wiederum verwenden die Controls als Fragengerüst, um nicht in Formalien zu ersticken: „Zeigen Sie mir die Liste der Admins“, „Zeigen Sie mir den letzten Restore-Beleg“, „Zeigen Sie mir die zehn ältesten offenen Kritikalitäten“, „Zeigen Sie mir die Systeme ohne aktuelle Agenten“. Wer dann zeigen kann, statt zu erklären, erlebt Prüfungen als Bestätigung – und nicht als Bedrohung.

Von der Werkstatt auf die Landkarte: Einordnung in die große Governance-Welt

Die Controls lösen nicht das Governance-Problem an sich. Sie lösen den Übersetzungsschmerz: Wie mache ich aus ISO-Zielen, NIST-Katalogen, regulatorischen Pflichten tägliche Arbeit, die nachweisbar wirkt? In dieser Rolle wachsen sie zur Integrationsschicht: Das Managementsystem definiert Ziele und Rollen; der Control-Katalog liefert konkrete, priorisierte Maßnahmen; betriebliche Tools liefern Evidenzen; Audits prüfen Wirksamkeit statt Wortlaut. Es ist kein Zufall, dass viele Häuser ihre Policy-Sets an den Controls ausrichten: ausufernde Regelwerke werden komprimiert, widersprüchliche Vorgaben aufgeräumt, Doppelarbeit abgebaut.

Der Blick nach vorn: Was bleibt, was sich ändert

Rahmenwerke mit Bestand haben zwei Eigenschaften: Stabilität im Kern und Anpassungsfähigkeit im Detail. Stabil bleiben die ersten Prinzipien – Inventarisierung, Härtung, Schwachstellenmanagement, Admin-Disziplin, Logging & Auswertung, Wiederherstellung. Sie sind die Schwerkraft der Abwehr. Bewegen werden sich die Subcontrols und die Gewichtungen: Cloud-spezifische Ausprägungen, Container-Härtung, Identitäts- und Zugriffsmodelle jenseits des klassischen Perimeters, neue Telemetrie-Quellen, aufkommende Angriffswege. Der Prozess, der das möglich macht, steht: angreifergetriebene Iteration, offen, messbar, dokumentiert.

Ein kurzer Leitfaden für den Einstieg – ohne Ausreden

Wer heute beginnt, braucht keine zehn Projekte. Drei aufeinanderfolgende Schritte reichen, um das Fundament zu legen:

1. Erheben. Geräte- und Softwareinventar automatisiert ziehen, Ownership klären, Sichtbarkeitslücken markieren.
2. Disziplinieren. Baselines für Härtung definieren und erzwingen, Patch-Fenster verbindlich machen, Adminrechte aufräumen und befristen, Logging-Quellen vereinheitlichen, zentrale Auswertung aufsetzen.
3. Beweisen. Restore-Übungen mit Integritätsbeleg durchführen, Kennzahlen mit Schwellen versehen, Eskalationswege und Re-Checks festlegen.

Alles Weitere folgt aus diesen drei Dingen. Wer sie konsequent tut, spürt in Wochen, nicht in Jahren, einen Unterschied – messbar, verlässlich, wiederholbar.

Warum die Geschichte wichtig ist

Man könnte sagen: „Es ist doch nur eine Liste.“ Aber das wäre, als würde man über ein Orchester sagen: „Es sind doch nur Instrumente.“ Die Controls sind mehr als eine Aufzählung. Sie sind die Erzählung eines gemeinsamen Lernens: aus echten Vorfällen, aus echten Fehlern, aus echten Verbesserungen. Sie erzählen, dass Sicherheitsarbeit handwerklich ist und als solche geübt werden will. Sie erzählen, dass Priorisierung nicht Verzicht bedeutet, sondern Wirkung. Und sie erzählen, dass Standardisierung kein Korsett sein muss, sondern ein Exoskelett: Es macht stärker, ausdauernder, belastbarer.

Am Ende bleibt die einfache Wahrheit, die am Anfang stand: Angreifer arbeiten wiederholbar. Verteidigung muss es auch tun. Die Reise von den SANS-Workshops zu einem gepflegten, breitenwirksamen Standard zeigt, wie das geht: Konsens im Inhalt, Konsequenz in der Umsetzung, Evidenz im Betrieb. Wer diesen Dreiklang verinnerlicht, hat mehr als einen Katalog. Er hat einen Kompass – und die Gewissheit, dass jeder Schritt messbar näher ans Ziel führt, nicht perfekt zu sein, aber schwer zu brechen.