Perfekte Sicherheitsrichtlinien gibt es nicht, weil sie so schwer zu formulieren wären, sondern weil sie die Realität nur unzureichend abbilden. Zwischen einer schriftlichen Richtlinie und einer schriftlichen Richtlinie, die sich auch durchsetzen lässt, liegen Welten.
Die meisten Richtlinien sind nicht darauf ausgelegt, dem schnelllebigen, ständigen Wandel unserer Umgebungen standzuhalten. Sie werden mit den besten Absichten geschrieben, scheitern aber, sobald sie für „ideale“ Zustände und perfekte Szenarien formuliert sind.
Darum scheitern gute Richtlinien in der Praxis
Als ich noch Sysadmin und für das Patch-Management zuständig war, bin ich genau in diese Falle getappt. Ich hatte eine scheinbar unkomplizierte Richtlinie eingeführt: Alle kritischen Patches müssen innerhalb von 30 Tagen nach Veröffentlichung ausgerollt werden. Eine klare Kennzahl, leicht messbar und, was am wichtigsten war, im Einklang mit den regulatorischen und Compliance-Anforderungen, die wir erfüllen mussten.
Auf dem Papier war das großartig und genau so, wie gute Sicherheit aussehen sollte. Oder etwa nicht? In der Praxis fiel das Ganze jedenfalls fast sofort in sich zusammen.
Da ich auch Teil des Teams war, das Patches auf unseren Endpunkten und Servern nachverfolgen und installieren musste, hatte ich mir damit unbemerkt meine gesamte freie Zeit weggenommen. Bis ich ermittelt hatte, was wann gepatcht werden musste, bis wir intern in der IT getestet hatten (wir waren immer die Versuchskaninchen), bis Wartungsfenster für das restliche Unternehmen geplant und die Patches schließlich ausgerollt waren, waren fast 30 Tage vergangen. Und dann begann der Zyklus von vorn. Für alles andere als das Babysitten von Patches blieb mir keine Zeit mehr.
Erschwerend kam hinzu: Wir ließen einen Penetrationstest durchführen, und dessen Ergebnisse unterschieden sich deutlich von denen unserer Schwachstellen-Scans. Die Pentester drängten uns, die von ihnen entdeckten Probleme zu beheben, doch einige davon waren nicht als „kritisch“ eingestuft. Diese Punkte mit hohem Risiko blieben deshalb noch eine ganze Weile nach den kritischen Befunden unbehoben.
Das war kein Scheitern der guten Absicht. Es war nicht falsch, zeitnahes Patching zu wollen. Die Richtlinie scheiterte, weil sie die tatsächliche Umgebung, das reale Risiko für das Unternehmen und konkurrierende Prioritäten nicht berücksichtigte. Genau an dieser Stelle brechen die meisten Sicherheitsrichtlinien zusammen. Sie sind für perfekte Bedingungen gemacht, die es in echten IT-Umgebungen nicht gibt, und oft fehlen ihnen echte risikobasierte Entscheidungen. Am Ende werden solche Richtlinien nicht befolgt, sondern umgangen oder komplett ignoriert.
In diese Falle tappen nicht nur selbst gestrickte Richtlinien. Auch breit anerkannte Industriestandards können scheitern, wenn sie angewendet werden, ohne die Besonderheiten des eigenen Unternehmens und der eigenen Umgebung zu kennen.
Wenn „Industriestandard“ nicht mehr weiterhilft
Industriestandards gibt es aus gutem Grund. Sie beruhen auf den Lehren aus Sicherheitsvorfällen und Datenschutzverletzungen und bündeln das gesammelte Fachwissen von Sicherheitsexpert:innen. Sie liefern eine Basis, die für die meisten Unternehmen die meiste Zeit funktioniert. Das Problem: „die meisten Unternehmen die meiste Zeit“ lässt immer noch viel Raum zum Scheitern.
Ein IT-Team in einem produzierenden Unternehmen musste das auf die harte Tour lernen, als es seine Windows-Server mit den CIS-Level-1-Benchmarks härten wollte. CIS-Benchmarks sind hervorragende Ausgangspunkte. Sie sind weithin anerkannt, werden regelmäßig aktualisiert und von Auditor:innen und Sicherheitsfachleuten empfohlen. Das war nicht das Problem.
Das Problem war die Annahme, man könne sie einheitlich auf jedes System der Umgebung anwenden. Die Steuerungssysteme in der Produktion sind aber keine typischen Endbenutzer:innen-Systeme. Sie haben einen bestimmten Zweck und spezifische Anforderungen, die sich zum Beispiel von denen einer Buchhaltungsumgebung unterscheiden.
Die Benchmarks deaktivierten mehrere Legacy-Protokolle und -Dienste, auf die die 15 Jahre alten Industrieanlagen zur Kommunikation mit dem Server angewiesen waren. Die Folge: Die Produktion stand den Großteil des Tages still (6 Stunden), während das Team die Änderungen hektisch zurücknahm. Die finanziellen Auswirkungen waren nicht unerheblich. Kein existenzbedrohendes Ausmaß, aber Anlass für einige Sorge und reichlich Chaos in den IT- und Produktionsteams.
Der Einsatz von CIS-Benchmarks war nicht der falsche Ansatz. Sie sind für moderne IT-Umgebungen mit aktuellen Betriebssystemen und zeitgemäßer Hardware konzipiert. Aber sie sind ein Ausgangspunkt, und nicht jede einzelne Einstellung darin passt zwangsläufig zu einer Umgebung der Betriebstechnik, in der Upgrades deutlich schwieriger sind und Ausfallzeit ernsthafte finanzielle Folgen haben kann.
Genau hier kann blindes Befolgen von „Industriestandards“ schaden. Diese Benchmarks basieren auf Annahmen über Ihre Umgebung, Ihre Ressourcen und Ihren Betrieb. Wenn diese Annahmen nicht zu Ihrer tatsächlichen Umgebung passen, etwa weil Sie Legacy-Systeme betreiben, in einer spezialisierten Branche arbeiten oder anderen Einschränkungen unterliegen, die die Benchmarks nicht berücksichtigen, schafft das blinde Befolgen von Best Practices mehr Probleme, als es löst.
Benchmarks sind ein nützliches Tool und sollten genutzt werden. Zu oft schreiben Richtlinien ihren Einsatz jedoch nur vor, um ein Compliance-Häkchen zu setzen, ohne vorher die spezifischen Anforderungen der eigenen Umgebung zu verstehen.
So gestalten Sie Richtlinien, die in der Realität funktionieren
Nachdem meine ursprüngliche 30-Tage-Patching-Richtlinie gescheitert war, haben mein Team und ich sie rund um Ergebnisse statt um Fristen neu aufgebaut. Unsere neue Richtlinie war auf Risiko ausgerichtet. Es gab viele Ergänzungen, aber diese bringt den Kern am deutlichsten auf den Punkt:
„Kritische Schwachstellen in Assets mit Internetanbindung, bei denen eine aktive Ausnutzung nachgewiesen ist, müssen innerhalb von 72 Stunden gemindert werden. Kritische Schwachstellen mit verfügbarem Proof-of-Concept-Code müssen innerhalb von 7 Tagen gepatcht werden. Zur Minderung zählen Patching, kompensierende Kontrollen oder die vorübergehende Isolierung eines Dienstes. Alle Maßnahmen und Ausnahmen sind zu dokumentieren und erfordern eine Risikoakzeptanz durch den Chief Information Security Officer.“
Die eigentliche Veränderung waren nicht nur die Fristen. Wir priorisierten Schwachstellen und Patching nach der tatsächlichen Exponiertheit: ob Systeme am Internet hingen, ob Exploits bereits im Umlauf waren und mit welchen Daten diese Systeme in Berührung kamen.
Genauso wichtig war aber die Erkenntnis, dass Transparenz für die IT geschäftskritisch ist. Wir haben automatisiertes Schwachstellen-Scanning eingeführt, das direkt in unser Patch-Management-Dashboard einfloss. Wenn Systeme aus der Compliance fielen und kritische Patches fehlten, wussten wir es sofort. So konnten wir unsere Kennzahlen über die Zeit verfolgen und sehen, wie gut (oder schlecht) wir abschnitten und wo wir nachbessern mussten.
Uns war außerdem klar, dass Patching innerhalb der Frist aus ganz unterschiedlichen Gründen manchmal nicht möglich ist. In diesen Fällen brauchten wir kompensierende Kontrollen, eine Dokumentation und eine Freigabe durch die Führungsebene.
Bei der Richtlinie zu den CIS-Benchmarks war die Lehre ähnlich, das IT-Team ging die Sache aber von einer anderen Seite an. Es verwarf die Benchmarks nicht vollständig und strich sie auch nicht aus der Richtlinie. Stattdessen verlangte die überarbeitete Richtlinie CIS-Hardening-Bewertungen für jeden Systemtyp im Unternehmen, um eine Grundlage dafür zu schaffen, welche Benchmarks produktionskritische Komponenten beeinträchtigen und welche nicht. Das IT-Team dokumentierte, welche Benchmarks für welchen Systemtyp galten, welche mit den Anforderungen dieses Systemtyps kollidierten und welche kompensierenden Kontrollen zum Einsatz kamen. Die Produktionssysteme bekamen ihre eigene Hardening-Baseline, ebenso die Endbenutzer:innen-Systeme und die Server.
Der Weg nach vorn
Wie wir alle wissen, ist in IT und Security so gut wie nichts ideal. Innovation und technologischer Fortschritt werden der Sicherheit immer einen Schritt voraus sein.
Unsere Aufgabe als IT- und Security-Fachleute besteht darin, das Beste aus dem zu machen, was uns zur Verfügung steht: Systeme, Prozesse und Richtlinien zu gestalten, die sicher genug sind, damit Benutzer:innen, Abteilungen und Geschäftsbereiche so sicher wie möglich arbeiten können, ohne diese Abläufe allzu stark zu behindern.
Wir müssen akzeptieren, dass es perfekte Sicherheit nicht gibt, und verstehen, dass Richtlinien, die Perfektion verlangen, scheitern werden.
Sicherheit funktioniert am besten, wenn sie Teil des täglichen IT-Betriebs ist und nicht nachträglich aufgesetzt wird. Sicherheit funktioniert am besten, wenn sie die effizienteste und naheliegendste Option ist. Wenn sie so wenig wie möglich im Weg steht.
Wenn Ihr Team zwischen „Arbeit erledigen“ und „Sicherheitsrichtlinie befolgen“ wählen muss, wird es sich jedes Mal für die Arbeit entscheiden. Gestalten Sie Ihre Richtlinien so, dass beides dieselbe Entscheidung ist.
