IT-Grundschutz / Sicherheitsmanagement

Die Quadratur der Dokumenten-Pyramide

Wie man mit einem datenbankgestützten Framework verständliche Vorgaben macht, statt Richtlinien-Bibliotheken aufzutürmen

Wo jeder sein eigenes Süppchen kocht, kann man kaum erwarten, dass alle jedes Rezept kennen – in Sachen Sicherheit und Compliance häufen jedoch viele Organisationen unzählige verschiedene Richtlinien und Regelungswerke an, die kaum überschaubare Bibliotheken oder monumentale Strukturen bilden. Besser wäre es, Mitarbeiter:inne:n genau die Vorgaben zur Sicherheit zu präsentieren, die für sie und ihre Arbeit wichtig sind – passgenau, aktuell und interdisziplinär.

Von Theo Nick, Berlin

Jede Organisation bildet eine eigene Kultur – das geht von informellen Ritualen, wie dem Geburtstagskuchen in der Teeküche, über die Wahl der Du- oder Sie-Form bis hin zum Umgang mit verschiedenen Arten von Risiken. Als Sicherheitsberater lernt man, das ergibt sich schon aus der Stellenbezeichnung, in erster Linie die Sicherheitskultur von Unternehmen kennen – von der freundlichen Begrüßung an der Pforte oder dem Empfang, dem Gang durch geschäftige Büroräume bis hin zur aufladbaren Casinokarte. Überall lassen sich kleine Details der Sicherheitskultur erkennen: Wird am Eingang ein Besucherausweis geprüft? Wird eine Clear- Desk-Policy umgesetzt und sind die Bildschirme gesperrt? Welche Informationen geben die Casinokarten über ihre Besitzer:innen preis?

Ein großer Teil der Sicherheitskultur, nämlich das individuelle Verhalten der Beschäftigten, lässt sich nur sehr bedingt beeinflussen. Entsprechende Schulungen erfreuen sich, sagen wir mal, einer „durchmischten“ Beliebtheit (s. a. S. 38). Auf der anderen Seite steht die niedergeschriebene Sicherheitskultur, die sich in mehr oder minder vielen Leitlinien, Konzepten und Richtlinien manifestiert.

Wären all diese Dokumente nicht mittlerweile digital, so könnte wohl jedes mittelgroße Unternehmen eine kleine Bibliothek betreiben: In hohen und staubigen Regalen stehen darin Richtlinien zur Kryptografie, dem sicheren IT-Betrieb, dem Dienstleistermanagement und viele mehr. Hinzu kommen die sogenannten dokumentierten Informationen, die eine Zertifizierung nach beispielsweise ISO 27001 voraussetzt. All das füllt zusammen die erste Regalreihe. Doch Richtlinien entwickeln sich: Neue Risiken werden identifiziert und ihnen müssen Maßnahmen entgegengestellt werden. Im Laufe der Jahre entstehen immer neue Versionen der Dokumente und füllen die (nunmehr virtuelle und womöglich verteilte) Bibliothek immer weiter – manchmal zieht auch jemand eine Richtlinie aus den Regalen und sortiert sie an anderer Stelle wieder ein; vielleicht geht sogar mal eine verloren.

Letztendlich entsteht eine Bibliothek von Sicherheitsvorgaben, die für unterschiedliche Personen gelten und die unterschiedlich aktuell sind. Wer etwa in der Personalabteilung arbeitet und alle für ihn einschlägigen Vorgaben kennen soll (von Interviews bis zum Onboarding- Prozess), der kann schnell frustriert aufgeben oder sich im Versions- und Zuständigkeitswirrwarr verirren. Richtlinien, die man nicht kennt, kann man aber nicht einhalten – selbst wenn Wille und Bereitschaft noch so groß sind. Und wer sich an Richtlinien orientiert, die nicht mehr aktuell sind, dessen Bemühungen sind schnell wirkungs- oder schlicht sinnlos. Letztlich sucht manch einer den kurzen Dienstweg und fragt einfach mal bei den Verantwortlichen in der Hoffnung, dass die Kolleg:inn:en alle Regeln auswendig kennen. Die sollten einem doch sagen können, was aus Sicherheitsperspektive zu beachten ist – und idealerweise auch warum?! Doch das ist längst nicht immer so.

Dynamische Digitalisierung

In wenigen Jahren wird es solche Richtlinien- Bibliotheken wohl nicht mehr geben: Die Sicherheitsorganisation innerhalb von Unternehmen sollte antiquierte statische Richtlinienlandschaften hinter sich lassen und dynamische Sicherheitsvorgaben entwickeln. Beschäftigte können dann auf ein zentrales Verwaltungssystem zugreifen, um exakt die für sie zutreffenden Sicherheitsvorgaben zu erhalten – immer in der aktuellen Version und der individuellen Risikoexposition angemessen.

Möglich wird das durch eine Datenbank vieler einzelner Sicherheitsvorgaben – ein Sicherheitsvorgaben- Framework. Atomare Vorgaben adressieren darin einen Aspekt an eine umsetzungsverantwortliche Rolle. Diese ist wiederum nur eines von mehreren Attributen, die an eine Sicherheitsvorgabe geknüpft sind (vgl. Abb. 1). Diese Attribute definieren letztlich, wer eine Sicherheitsvorgabe umsetzt, für welche Werte (Assets) sie gilt, welche Schutzziele sie erfasst und welches Sicherheitsniveau sich durch sie erreichen lässt. Mitarbeiter der Personalabteilung können etwa die Sicherheitsvorgaben filtern und so genau die Vorgaben selektieren, die sie umsetzen müssen – so lässt sich herausfinden, in welchem Arbeitskontext sie anzuwenden sind und welche Erwartungshaltung das Management hier an den Tag legt.

Abbildung 1: Eine parametrisierte Anfrage beim Sicherheitsvorgaben-Framework liefert Mitarbeitern passgenau die durch sie im konkreten Umfeld einzuhaltenden Vorgaben.

Eine solche Datenbank wirkt sich positiv auf eine breite Akzeptanz notwendiger Sicherheitsvorgaben in Unternehmen aus: Denn Abfragen erfolgen individuell und geben nur die gerade geltenden Vorgaben zurück. Beschäftigte geben dazu an, welche Rolle(n) sie innehaben und erhalten nur die Sicherheitsvorgaben, für deren Umsetzung sie tatsächlich verantwortlich sind.

In der Branche der Finanzleistungen wird mehrheitlich auf das so genannte „Three Lines of Defense“-Modell verwiesen – vereinfacht ausgedrückt eine Funktionstrennung zwischen Vorgabe und Umsetzung. Dieses Modell lässt sich sehr gut durch ein Sicherheitsvorgaben- Framework umsetzen: Die Regelungen des CISO (2nd Line of Defense) werden dazu mit den Umsetzungshinweisen der IT (1st Line of Defense) verknüpft und gehen so Hand in Hand. Das Sicherheitsvorgaben- Framework trägt indirekt auch zu einer Erhöhung des Sicherheitsniveaus bei, da bekannte und akzeptierte Normen nachvollziehbarerweise eher umgesetzt werden, als solche, die Beschäftigten unbekannt oder für sie nur schwer verständlich sind.

Link zum Risikomanagement

Die Attribute der Sicherheitsvorgaben können jedoch noch mehr: Viele Organisationen betreiben bereits ein Informationssicherheitsmanagementsystem (ISMS). Zentraler Bestandteil dieses Managementsystems ist es, regelmäßig den Schutzbedarf von Informationen zu ermitteln. Ohne das Wissen darum, welche Informationen man schützen möchte und welchen Wert sie haben, ist eine effektive und wirtschaftliche Sicherheitsplanung schließlich unmöglich. Der Schutzbedarf der Informationen lässt sich auch auf die sogenannten informationsverarbeitenden Einrichtungen vererben – üblicherweise die Anwendungen, welche die Informationen verarbeiten und die Systeme auf denen sie gehostet werden. Schlussendlich wird der Schutzbedarf auf die gesamte Infrastruktur vererbt, die zum Einsatz kommt.

Diese Infrastruktur ist Gefährdungen ausgesetzt, die von mutwilliger Zerstörung oder menschlichem Versagen herrühren oder natürlichen Ursprungs sein können. Im Rahmen des Information-Risk- Management sollten diese Gefährdungen ermittelt und das Risiko analysiert werden, das durch sie für Informationen entsteht. Das Ergebnis ist die Übersicht der schützenswerten Informationen auf der einen und der Gefährdungen, denen informationsverarbeitende Einrichtungen ausgesetzt sind, auf der anderen Seite.

An dieser Stelle kommt das Sicherheitsvorgaben-Framework ins Spiel: Jede Vorgabe im Framework zielt darauf ab, Gefährdungen für genutzte Einrichtungen und damit auch für die Informationen selbst zu reduzieren. Jeder Vorgabe ist zudem zugeordnet, auf welchen Assets sie umzusetzen ist: Vorgaben zur Systemprotokollierung werden zum Beispiel mit dem Asset „Firewall“ verknüpft, Vorgaben zur physischen Sicherheit mit dem Asset „Gebäude“ oder „Raum“.

Allen Informationssicherheits- Risiken werden eine oder mehrere Sicherheitsvorgaben gegenübergestellt, um die Risiken zu reduzieren. Alle Sicherheitsvorgaben befinden sich in einer zentralen Datenbank und sind für die umsetzungsverantwortlichen Rollen leicht verfügbar – wird eine Sicherheitsvorgabe nicht umgesetzt, ist das entstandene Risiko sofort transparent erkennbar (vgl. Abb. 2). Die klare Verknüpfung von Risiko zu Asset zu Sicherheitsvorgabe macht dies möglich.

Abbildung 2: Die Nutzung eines Sicherheitsvorgaben-Frameworks ermöglicht durch die Verknüpfung von Risiken und Sicherheitsvorgaben eine hohe Transparenz von „offenen“ Risiken.

Eins für alles

Nicht alle Vorgaben der Informationssicherheit basieren jedoch auf einem erkannten Risiko: Das Thema Security erfreut sich seit einigen Jahren auch einer großen Beliebtheit bei der Gesetzgebung und dem Erlass von Verordnungen. All diese Anforderungen sind in interne Vorgaben zu übersetzen und müssen auch tatsächlich umgesetzt werden. Dabei entstehen unangenehme Verantwortungsüberschneidungen, wenn zum Beispiel der Datenschutzbeauftragte technische und organisatorische Maßnahmen (TOM) empfiehlt, die etwa unwissentlich nicht im Einklang mit den Kryptografievorgaben der Informationssicherheit stehen.

Ein gutes Sicherheitsvorgaben- Framework verfolgt daher einen Multi-Normen-Ansatz: Jeder Sicherheitsvorgabe im Framework wird über ein Attribut die zugehörige Anforderungsquelle zugeordnet – dadurch ist bekannt, aufgrund welcher Norm, durch welches Gesetzes oder welche Verordnung dieser Aspekt geregelt wird.

Auf der Basis eines etablierten Standards, etwa der ISO 27001, kann man dafür zunächst ein Basis- Set an Sicherheitsvorgaben erstellen: Jeder Aspekt, den die ISO 27001 behandelt, wird in eine oder mehrere Sicherheitsvorgaben formuliert, und operationalisiert – so entsteht ein Basisframework der Informationssicherheit. Im Anschluss kann man alle relevanten externen Anforderungsquellen heranziehen, auf ihren Regelungsgehalt hin prüfen und mit dem Basisframework abgleichen: Basis-Sicherheitsvorgaben können ergänzt, angepasst oder ersetzt werden – vielleicht ergeben sich Widersprüche, die vorher nicht ersichtlich waren und nun im Detail abgewogen werden müssen.

In jedem Fall ist es möglich, jede Sicherheitsmaßnahme zu ihrem gesetzlichen Ursprung zurückzuverfolgen und zu begründen. Unternehmen, die ihre Produkte in unterschiedlichen Branchen und regulatorischen Kontexten anbieten, können jeder externen regulatorischen Anforderung eine interne Sicherheitsvorgabe gegenüberstellen. Inhaltlich redundante Anforderungen lassen sich in einer einzelnen Sicherheitsvorgabe zusammenfassen und erfüllen. Zudem kann man bei externen Anforderungen eine gewisse Auslegungsfreiheit nutzen, um individuelle Lösungen zu finden, die gleich mehreren Regularien gerecht wird.

Trotz einer Vielzahl von externen Anforderungen muss auf diese Weise die Richtlinienbibliothek nicht mehr wachsen – vielmehr kann sie sogar schrumpfen. Unternehmen können zudem darauf verzichten, ihre Bibliotheken in Sektionen zu unterteilen und komplizierte Register zu pflegen. Gleichzeitig bewegen sie sich souverän in den Regularien ihres jeweiligen Branchenumfelds oder etwa denen kritischer Infrastrukturen.

Fortlaufende Aktualisierung

Wie bereits erörtert, ist durch das Sicherheitsvorgaben-Framework erkennbar, welche Risikoexposition und/oder Compliance-Verstöße entstehen, wenn eine Sicherheitsvorgabe nicht eingehalten wird. Die Risikoexposition sowie gestellten Anforderungen sind jedoch generell permanenten Änderungen unterworfen – daher ist ein kontinuierliches Monitoring der Bedrohungslage und der externen Anforderungen erforderlich, um das Framework aktuell zu halten.

Eine mögliche Umsetzung dieser Beobachtungen ist das Konzept der Radare: Der Kontext, der Einfluss auf die Gestaltung des Sicherheitsvorgaben-Frameworks hat, wird dazu beobachtet und thematisch sortiert. Es kann dabei sinnvoll sein, zwischen einem Bedrohungsradar, einem regulatorischen Radar und einem Technologieradar zu unterscheiden (vgl. Abb. 3). So erfasst man (thematisch sortiert) Ereignisse und Entwicklungen, die sich auf die Vorgabengestaltung auswirken können und priorisiert.

Abbildung 3: Mittels thematisch sortierter „Radarortungen“ lassen sich Bedrohungslage und externe Anforderungen beobachten, die Einfluss auf interne Vorgaben ausüben, um das Sicherheitsvorgaben-Framework aktuell zu halten.

Genau wie bei einem klassischen Radar, das die Entfernung von Objekten rund um die Messstelle erfasst, ordnet man auch die Beobachtungen in Sachen Security und Compliance in konzentrische Ringe ein: Im äußersten Ring des regulatorischen Radars erscheinen Normen und Gesetze, in deren Regelungsbereich ein Unternehmen erst perspektivisch fallen kann. Im mittleren Ring werden anstehende Änderungen von Gesetzen oder Normen erfasst, die direkte Auswirkungen auf die Vorgabengestaltung des Unternehmens haben. Im Jahr 2020 hätte dies beispielsweise die Novellierung der bankaufsichtlichen Anforderungen an die IT (BAIT) sein können – im Laufe des Jahres 2021 wird diese Anforderungsquelle bis in das Zentrum der Radarscheibe vorrücken.

Ein gleichartiges Beobachtungs- und Priorisierungsverfahren bietet sich für Themen, wie Technologieentwicklung und die Bedrohungslage an. Der Output dieser Radarschirme dient als Input für das Framework und garantiert dessen Aktualität und Angemessenheit – das aktuelle Framework ist gegen neue und veränderte Anforderungen zu prüfen und Sicherheitsvorgaben sind gegebenenfalls anzupassen.

Auch Umkehrschlüsse sind möglich: Bestehen keine externen Anforderungen, einen bestimmten Aspekt zu regeln, und würde dadurch kein Risiko behandelt, dann ist eine Sicherheitsvorgabe unnötig. Jede Maßnahme, die unternommen wird, um eine unbegründete Sicherheitsvorgabe zu erfüllen, ist unwirtschaftlich. So lassen sich Ressourcen für die Sicherheit ermitteln, die an anderer Stelle sinnvoller eingesetzt werden können.

Fazit

Regelmäßig hört man von einer immer komplexer werdenden Welt und von dynamischen Bedrohungslagen. Papiere oder große Dokumentenbibliotheken sind jedoch geduldig – mit althergebrachten Richtlinienbibliotheken werden wir diesen Herausforderungen nicht gerecht werden können.

Das hier vorgestellte Konzept ist nicht fundamental neu, sondern basiert auf Bestehendem – im Bankenumfeld gibt es beispielsweise bereits solche Kataloge. Der Autor plädiert jedoch dafür, weiter zu gehen: Integrierte Managementsysteme sind bekannt, aber ihre Regelungen sollten auch miteinander im Einklang stehen. Das dargestellte Sicherheitsvorgaben-Framework sollte daher mit verschiedenen Disziplinen – von der Informationssicherheit über den Datenschutz bis hin zur physischen Sicherheit – und ihren Akteur:inn:en interagieren.

Wichtiger als Sicherheitsrichtlinien, die bis ins letzte Detail durchdacht wurden, ist zudem eine reaktionsschnelle Anpassung an Bedrohungslagen sowie die breite Akzeptanz und Umsetzung der enthaltenen Sicherheitsvorgaben. Vorgaben müssen für die Menschen gemacht werden, die sie umsetzen, nicht für externe Prüfer:innen oder den oder die CISO. Sicherheit derart integriert umzusetzen, erfordert ein zentrales und disziplinübergreifendes Vorgaben-Framework.

 

Theo Nick ist Managing Consultant Security Consulting bei der HiSolutions AG.