Von 20 auf 18: Wie v8 die CIS Controls neu strukturiert

Von 20 auf 18: Wie v8 die CIS Controls neu strukturiert

Es passiert nicht oft, dass ein technischer Katalog das Zeug zur gemeinsamen Sprache einer ganzen Branche hat. Die CIS Controls sind so ein Fall – und mit Version 8 haben sie sich neu sortiert, ohne ihre DNA zu verlieren. Aus 20 wurden 18 Controls, aus verstreuten Unterpunkten wurden präziser formulierte Safeguards, aus „Hardware“ und „Software“ wurden Enterprise Assets, aus höflichen Empfehlungen wurden umsetzbare Anforderungen für eine Welt, in der Workloads in die Cloud wandern, Mitarbeiter von überall arbeiten und Lieferketten zum größten Risiko werden können. v8 ist kein kosmetisches Update; es ist die Antwort auf die Frage: Wie priorisiert man Sicherheitsarbeit, wenn Infrastruktur, Identitäten und Daten längst über Rechenzentrum, SaaS und mobile Endpunkte verstreut sind – und wenn die Angreifer inzwischen Produktmanagement in eigener Sache betreiben?

Warum es eine Neuordnung brauchte

Die frühen Fassungen der Controls kamen aus einem ganz bestimmten Schmerz: Immer wieder öffentlich ausgenutzte Schwachstellen, vernachlässigte Baselines, keine Übersicht über Assets, zu breite Adminrechte, Protokolle, die niemand liest, Backups, die im Ernstfall nicht zurückspielen. Version 7 brachte diese Einsichten in eine klare, priorisierte Reihenfolge. Aber die Realität drehte schneller: Cloud wurde Standard, SaaS wurde Geschäftsgrundlage, Identitäten wurden zur neuen Perimeter-Kante, Remote Work wurde Alltagsbetrieb, und Drittparteirisiken wurden sichtbar – nicht nur regulatorisch, sondern operativ. Viele Unternehmen stellten fest, dass v7 zwar wirkt, aber Vokabular und Zuschnitt die neuen Infrastrukturen nur unzureichend abbildeten. v8 reagiert darauf, ohne den Kern (Priorisieren, Messen, Automatisieren) zu verwässern.

Drei Leitgedanken prägen die neue Struktur:

1. Realitätsnähe: Controls sprechen von Enterprise Assets statt nur „Hardware/Hosts“. Das umfasst physische, virtuelle, containerisierte, mobile und Cloud-Ressourcen.
2. Identitätszentrierung: Rechteverwaltung wird geteilt und geschärft: Account Management und Access Control Management als getrennte, aber verzahnte Disziplinen.
3. Lieferkette & Betrieb: Service Provider Management als eigenes Control, Audit Log Management als zentrale Lebensader, Incident Response und Data Recovery mit handfesten Nachweisen.

Von 20 auf 18: Was zusammenrückte – und warum

Die Reduktion der Zahl klingt nach „weniger“, bedeutet aber Konsolidierung. Themen, die in v7 auseinanderlagen, wurden in v8 zusammengeführt, wenn sie im Betrieb ohnehin untrennbar sind:

• Hardware- und Softwareinventar bleiben getrennte Controls (1 & 2), aber die Perspektive verschiebt sich von „Geräte“ und „Programme“ hin zu Enterprise Assets und Software Assets – explizit inkl. Cloud-Instanzen, virtueller Maschinen, Container, mobiler Geräte und SaaS-Komponenten.
• Boundary Defense, Network Device Configuration und Wireless Control werden unter Netzwerkinfrastruktur bzw. flankierenden Controls konsolidiert. Drahtlos ist kein exotischer Sonderfall mehr, sondern Infrastruktur – verwaltet mit denselben Prinzipien (Baseline, Monitoring, Härtung).
• Controlled Use of Administrative Privileges spaltet sich logisch in Account Management (Lebenszyklus der Konten) und Access Control Management (Rechtevergabe, Least Privilege, Just-in-Time).
• Application Software Security wird breiter gedacht: sicherer Entwicklungsprozess statt reiner Randsicherung von Applikationen; Shift-left-Sicherheit wird zur Regel.
• Data Protection rückt nach vorn und wird enttechnisiert formuliert: Klassifikation, Minimierung, Zugriffspfade, Verschlüsselung, Schlüsselverwaltung, Wiederherstellbarkeit als integraler Bestandteil.

Gleichzeitig kommt ein Thema neu und prominent: Service Provider Management. Was früher in Outsourcing-Textpassagen oder Lieferantenrichtlinien am Rand auftauchte, wird zur eigenen Steuerungsdisziplin – mit Anforderungen an Due Diligence, Informations- und Prüfungsrechte, Telemetrie, Meldewege, Subdienstleister-Transparenz und Exit/Portabilität.

Safeguards statt Subcontrols: Woran man Wirksamkeit misst

„Subcontrol“ klang nach Fußnote. Safeguard klingt nach Absicherung – und genau das ist beabsichtigt. v8 benennt pro Control konkrete Safeguards, die operativ prüfbar sind. Sie folgen einer Devise, die aus der Praxis geboren ist:

• Automatisieren, wo möglich: Inventare, die sich per Export füttern; Baselines, die als Code erzwungen werden; Konfigurationsdrifts, die Alarm auslösen; Schwachstellen, die nicht nur gezählt, sondern abgebaut werden – mit Alterskurven und Fristen.
• Beweisen, nicht behaupten: Ein Restore ohne applikationsseitigen Integritätsbeleg gilt nicht als Nachweis. Ein „MFA ist ausgerollt“ ohne Nutzungsdaten bleibt Rhetorik.
• Schwellen & Konsequenzen: Jeder wichtige Safeguard lebt von einer Schwelle, einem Owner, einer Eskalationslogik und einer Frist – sonst endet er als hübsche Prozessgrafik.

Die Safeguards sind so formuliert, dass kleine Teams damit starten können und große Häuser sie skalieren. Genau dafür gibt es die Implementation Groups (IG1–IG3) – eine der wichtigsten Stärken von v8.

Implementation Groups: Cyber-Hygiene für alle, Tiefe für die, die müssen

v8 sortiert die Safeguards in drei Implementierungsgruppen:

• IG1: Das Basisset sinnvoller „Cyber-Hygiene“ – das Minimum, das jedes Unternehmen unabhängig von Größe oder Branche erfüllen sollte. Es ist bewusst so geschnitten, dass es mit begrenzten Mitteln machbar ist, aber einen spürbaren Effekt auf gängige Angriffe hat.
• IG2: Baut auf IG1 auf und adressiert Unternehmen mit komplexeren Umgebungen, mehreren Standorten, höherer Regulierungstiefe. Hier geht es stärker um Segmentierung, Überwachung, Ausnahmenmanagement und strukturierte Nachweise.
• IG3: Für besonders gefährdete oder kritische Organisationen. Enthält weiterführende Erkennungs- und Widerstandsfähigkeitsmaßnahmen, tiefere Telemetrie, strengere Reife in Prozessen und Testregime.

Der Clou: IG1 ist kein Alibi. Es deckt die häufigsten Einstiegswege und Fehlkonfigurationen ab. Wer IG1 konsequent implementiert, nimmt Angreifern die leichten Siege – und verschafft seinen Teams Zeit, die schwierigen Probleme zu lösen.

Die 18 Themenfelder – als Steuerungslogik, nicht als Poster

Man kann die 18 Controls wie eine Liste lesen. Sinnvoller ist es, sie als Ablauf zu verstehen: sehen → härten → schließen → nachweisen → reagieren → lernen.

1. Enterprise-Assets-Inventar: Sichtbarkeit ist die erste Verteidigung. Ohne automatisierte, eigentümergepflegte Inventare (inkl. Cloud, Container, Mobil) arbeitet man im Blindflug.
2. Software-Assets-Inventar: Nur, was freigegeben ist, gehört in die Produktionswelt. Application Control/Allowlisting in kritischen Zonen, Paketquellen kuratieren, Schatteninstallationen sichtbar machen.
3. Data Protection: Klassifizieren, minimieren, Flüsse verstehen, Schlüssel verwalten, Daten wiederherstellen können – mit Integritätsbeleg.
4. Secure Configuration: Baselines als erzwingbarer Code; Drift-Erkennung; hardened Images; sichere Defaults; Cloud-Policies (Guardrails) als Standard.
5. Account Management: Lebenszyklus von Konten – Eintritt, Wechsel, Austritt – automatisiert; Service-Accounts katalogisiert; „Shared Accounts“ ausgerottet.
6. Access Control Management: Least Privilege, Just-in-Time-Privilegien, Sitzungsaufzeichnung und Review – Identität ist der neue Perimeter.
7. Vulnerability Management: Kontinuierlich scannen, altersbasiert abbauen, Ausnahmen befristen, Kompensationen nachweisen.
8. Audit Log Management: Protokolle zentralisieren, zeitsynchronisieren, Use-Cases definieren und auswerten; Logs „haben“ reicht nicht – sie müssen Antworten geben.
9. E-Mail- und Browser-Schutz: Die häufigste Eintrittstür bekommt die konsequenteste Härtung, inkl. Phishing-Schutz, isolierten Ausführungsumgebungen, Attachment-Handling.
10. Malware-Abwehr: Von Signaturen zur Verhaltensanalyse, von Endpoint-Isolierung bis zur sauberen Update-Kette auch in Offline-Segmenten.
11. Data Recovery: Backups sind Kosten; Restores sind Nachweise. Regelmäßige Wiederherstellungsübungen auf Anwendungsebene mit Integritätstest sind Pflicht.
12. Network Infrastructure Management: Inventar, Baselines, Härtung, Segmentierung – Wireless inklusive. Netzwerk ist kein Wildwuchs, sondern verwaltetes Asset.
13. Network Monitoring & Defense: Sichtbarkeit von Traffic-Mustern, Anomalieerkennung an den richtigen Stellen, Use-Case-getriebene Alarme statt Lärm.
14. Security Awareness & Skills Training: Rollenspezifisch, regelmäßig, mit Verhaltensmessung statt nur Teilnahmequote.
15. Service Provider Management: Due Diligence, Informations-/Prüfrechte, Telemetrie statt PDF, Meldewege, Subdienstleister-Transparenz, Exit/Portabilität – vertraglich und praktisch.
16. Application Software Security: Secure-by-Design: Threat-Modeling, SAST/DAST/IAST, Secrets-Management, Dependency-Management, SBOM; Gates in CI/CD, „no pass, no deploy“.
17. Incident Response Management: Runbooks mit Zeitstempeln, Entscheidungsjournal, Meldeketten intern/extern, Tabletop-Übungen, Evidence-Handling.
18. Penetration Testing: Gezielte Tests, die die Sicherheitsannahmen angreifen; Findings werden zu CAPA (Corrective/Preventive Actions) – mit Re-Tests.

Wer die Controls so versteht, merkt schnell: Sie sind eine Betriebsanleitung – nicht für Tools, sondern für Steuerung.

Cloud, Remote Work, SaaS: v8 spricht die Sprache der Gegenwart

v8 verwendet Begriffe, die Cloud- und SaaS-Teams täglich nutzen: Guardrails (Policies in Cloud-Landing-Zones), Workload-Identitäten, Service-Accounts, SBOM (Software Bill of Materials), Secrets-Management (statt „Passwortdatei“), API-Logging (statt nur Syslog). Das ist kein Stilbruch; es ist Absicht. Sicherheit entsteht dort, wo die DevOps-Pipeline arbeitet, nicht am Ende in einem Review-Meeting.

Beispiel: Secure Configuration in der Cloud. v7 beschrieb Baselines oft hostzentriert. v8 verlangt erzwingbare Policies: keine ungeprüften öffentlichen Buckets, keine unverschlüsselten Volumes, keine Security Groups mit 0.0.0.0/0 auf kritischen Ports, MFA für privilegierte Konsolenlogins, Rotation von Keys, definierte Tagging-Standards für Asset-Eigentümerschaft. Diese Regeln blocken Deployments, die sie verletzen – mit Ausnahmeführung, die befristet und begründet ist.

Beispiel: Account & Access Control im Remote-Betrieb. v8 nimmt IdP (Identity Provider) und PAM (Privileged Access Management) ins Herz der Steuerung: Provisionierung gekoppelt an HR, JIT-Privilegien mit Sitzungsaufzeichnung, regelmäßige Rezertifizierungen mit Konsequenzen; sicheres Gerätestatus-Signal (Compliance, Patches, Verschlüsselung) als Voraussetzung für Zugriffe.

Service Provider Management: Drittparteien führbar machen

Viele Häuser sind dort verletzlich, wo Verträge romantischer sind als die Telemetrie. v8 dreht daran: Sehen–bewerten–reagieren–belegen gilt auch für Lieferanten. Praktisch heißt das: Scorecards mit SLA- und Security-Kennzahlen, verbindliche Meldezeiten für Vorfälle, Subdienstleister-Spiegel (wer hängt an wem), Portabilität (Daten & Konfigurationen raus und rein in definierten Fristen), gemeinsame Tests (Restore, Failover, Kommunikationsübung). So wird aus „Third Party Risk“ eine steuerbare Disziplin.

Metriken mit Führungskraft: Wenige Zahlen, harte Konsequenz

Wer v8 ernst nimmt, reduziert Kennzahlen, aber erhöht ihren Biss. In der Praxis bewähren sich fünf Familien:

1. Sicht & Hygiene
   • Abdeckung des Asset- und Softwareinventars (% gemanagter Assets, Agent-Installationsquote).
   • Baseline-Compliance (Drift-Rate, Zeit bis Remediation).
2. Schwachstellen & Patches
   • Alterskurven je Kritikalität (30/60/90 Tage), Ausnahmen mit Verfallsdatum und Kompensation.
3. Identitäten & Privilegien
   • De-Provisioning-Dauer, Rezertifizierungsquote, JIT-Nutzungs- und Review-Raten, „Dormant Admins“.
4. Erkennung & Wiederherstellung
   • MTTD/MTTR, Anteile Use-Case-basierter Alarme, Restore-Erfolgsquote auf Anwendungsebene, RTO/RPO-Erfüllung, Integritätsbelege.
5. Lieferkette
   • SLA-Compliance, Incident-Meldezeiten, Audit-Findings pro Anbieter, Exit-Readiness (Probemigrationen), Telemetrie-Liefertreue.

Jede Zahl: Schwelle, Owner, Eskalation, Frist, Re-Check. Erst dann werden Dashboards zu Entscheidungen.

Migration von v7 auf v8: Ohne Schmerzen, aber nicht ohne Arbeit

Die gute Nachricht: Wer v7 ernsthaft betrieben hat, steht nicht nackt da. Die noch bessere: v8 räumt auf. Ein pragmatischer Pfad:

• Mapping: Bestehende v7-Maßnahmen den v8-Controls zuordnen; Lücken sichtbar machen – besonders bei Service Provider, Data Protection (inkl. Wiederherstellung mit Integritätsbeleg), Audit Log Management und Access Control (Least Privilege/JIT).
• IG-Plan: IG1 vollständig schließen, dann IG2/IG3 risikobasiert priorisieren.
• Policy-as-Code: Baselines in Pipelines und Cloud-Guardrails bringen; Manual Checks sterben lassen.
• Evidence-Baukasten: Standard-Exporte (Assets, Software, Vulns, Admins, Logs, Restores) versioniert und unveränderlich (WORM/Hash) ablegen – damit Nachweise bei Entstehung entstehen.
• Kohärenz-Review: Monatlich Risiko, Incidents, Tests, Lieferkette, Management-Report abgleichen; Widersprüche zu Tickets mit Fristen machen.
• Testkalender: Restore- und Tabletop-Übungen mit Akzeptanzkriterien (Zeit, Integrität, Kommunikation) fest verankern.

So wird aus der „neuen Struktur“ gelebte Steuerung.

Drei Einsatzbilder – und was v8 jeweils verändert

SaaS-Anbieter
Vorher: Dev und Ops sprechen aneinander vorbei, Security kommt spät.
Mit v8: Controls 4, 8, 16 bilden den Korridor. Baselines als IaC, Gates in CI/CD, SBOM pro Release, Secrets-Management, Telemetrie standardisiert, Use-Cases im SOC. Ergebnis: schnellere Releases, weniger Rework, prüfbare Sicherheit.

Finanzdienstleister
Vorher: Starke Prozesse, aber Lieferkette im PDF.
Mit v8: Control 15 zwingt zur Telemetrie mit Outsourcern, Restore-Tests fachlich, Identität konsequent JIT/PAM, Data Protection mit Integritätsbelegen, Incident-Backbone mit Mehrfachadressierung (intern, Kunden, Aufsicht). Ergebnis: weniger Überraschungen, bessere Prüfungsfähigkeit, robustere Resilienz.

Industrie/OT
Vorher: „Geht nicht, wir haben Produktionsfenster.“
Mit v8: Inventare über Netzwerkzugänge, segmentierte Updates, Baselines mit minimalem Eingriff, Restore bis Rezeptur-/Chargenebene, definierte Notfallprozesse für Fernwartung, kontrollierte Service-Accounts. Ergebnis: Stabilität steigt, Notfälle werden führbar.

Anti-Patterns – v8 erkennt sie schneller

• Policy ohne Pipeline: Regeln existieren, Deployments brechen sie. Heilmittel: Guardrails, Blocker, Ausnahmeprozesse mit Verfallsdatum.
• Backups ohne Beweis: „Wir sichern“ vs. „wir können“. Heilmittel: applikationsseitige Restores, Integrität, Re-Tests.
• Inventar als Excel: lebt nur am Audit-Tag. Heilmittel: Systemexporte, Agent-Abdeckung als KPI, fehlende Agenten = Incident.
• Schwachstellen als Jahresprojekt: Altlasten wachsen. Heilmittel: Alterskurven, Fristen, Kompensation, Owner, Re-Checks.
• IAM im Bauchgefühl: Schattenrechte, langsame Offboarding-Prozesse. Heilmittel: HR↔IdP-Kopplung, JIT-PAM, Sitzungsreview, Rezertifizierung.
• Logging ohne Use-Cases: Datenmüll statt Einsicht. Heilmittel: priorisierte Use-Cases, Triage-SLA, Zeitquellen-Disziplin.

v8 liefert die Schnittstellen, um diese Muster in Zahlen zu gießen – und damit zu verändern.

120-Tage-Plan: v8 in den Betrieb bringen

Tag 1–30 – Sichtbarkeit
Automatisierte Exporte aktivieren (Assets, Software, Vulns, Admins, Logs), Eigentümer pflegen, Baseline-Entwürfe, Top-5 SOC-Use-Cases festlegen, Lieferantenliste mit Telemetrie-Optionen erstellen.

Tag 31–60 – Hygiene
Baselines als Code durchsetzen (Cloud/Server/Clients/Netzwerk), Drift-Alarm, Patch-Fenster mit Fristen, JIT-Privilegien + Sitzungslogging, Logquellen normalisieren & zeitsynchronisieren, erste Restore-Übungen auf Anwendungsebene.

Tag 61–90 – Nachweise
Schwachstellen-Alterskurven produktiv, Ausnahmeprozesse mit Verfallsdatum, Scorecards für Dienstleister, Awareness rollenspezifisch, Incident-Backbone (Entscheidungsjournal, Meldeketten), Lessons Learned → CAPA.

Tag 91–120 – Verstetigung
Dashboards mit Schwellen/Owner/Eskalation/Fristen live, monatliches Kohärenz-Review, Evidence-Baukasten (WORM/Hash) institutionalisieren, Probe-Audit mit Stichproben (Tickets, Logs, Restores, SBOM), Re-Tests planen.

Nach vier Monaten ist v8 kein Poster, sondern Taktgeber.

Warum v8 überall ankommt: Es macht Security führbar

Die Controls waren nie ein Ersatz für ein Managementsystem – sie waren dessen Übersetzung in tägliche Arbeit. v8 verfeinert genau diese Rolle. Führungskräfte erhalten Sicht in Prioritäten und Wirksamkeit. Teams erhalten klare Safeguards statt vager Ziele. Prüfer und Kunden sehen Evidenzen statt Prosa. Lieferanten werden anhand vergleichbarer Kriterien steuerbar. Und die Technik profitiert, weil Baselines, Gates und Telemetrie Fehlerkosten senken und Release-Sicherheit erhöhen.

Das Geheimnis ist nicht die magische Zahl 18. Es ist der Mechanismus: Priorisieren, Automatisieren, Beweisen. Wer diesen Mechanismus annimmt, spürt den Unterschied dort, wo Sicherheit sich beweisen muss – im Betrieb und unter Druck.

Fazit: Weniger Zahl, mehr Zugkraft

v8 hat die Controls entschlackt und modernisiert. Aus 20 wurden 18 – nicht, weil Themen weniger wichtig wären, sondern weil Zusammengehöriges zusammenrückt und Wiederholung verschwindet. Die neuen Zuschnitte – Enterprise Assets, Account vs. Access, Data Protection als Grundpfeiler, Service Provider als eigene Disziplin – treffen den Nerv dessen, was heute wirklich gesteuert werden muss. Dazu kommen Safeguards, die prüfbar sind, und Implementation Groups, die realistische Einstiege erlauben.

Wer in v7 gedacht hat, muss kein neues Evangelium lernen. Er muss strenger werden in der Automatisierung, konsequenter in Nachweisen, konkreter in der Lieferkettensteuerung – und ehrlicher in der Frage, ob Backups nur beruhigen oder Betrieb retten. Dann tut v8, wofür es geschaffen wurde: Es macht Sicherheitsarbeit wirksam, bevor ein Vorfall beweist, was gefehlt hat.