Alles beginnt mit einem Satz (1) : Content-Management- und Ticket-Systeme als ISMS-Tools
Bei der Implementierung eines Informationssicherheitsmanagementsystems (ISMS) nach ISO/IEC 27001 müssen Organisationen 7 Clauses und 93 Controls systematisch umsetzen und für ein Zertifizierungsaudit nachvollziehbar dokumentieren. Je nach Komplexität sind dabei schnell tausende Aufgaben zu koordinieren [1]. Zahlreiche Anbieter stellen hierfür mehr oder minder hilfreiche Tools zur Verfügung, die jeweils unterschiedliche Handlungsoptionen eröffnen. Unser Artikel beleuchtet die Möglichkeiten, eine ISMS-Implementierung stattdessen mit Content-Management-Systemen (CMS) und Ticket-Systemen zu steuern, um so eine Integration in bestehende Prozesse und eine optimale Anpassung an die eigenen Bedürfnisse zu ermöglichen.
„Diese Seite dient dem Aufbau der Dokumentation zu unserem ISMS nach ISO/IEC 27001.“
Ausgehend von diesem einen Satz stellen wir im Folgenden einen Ansatz zur Implementierung eines ISMS vor, der dadurch bereits im Implementierungsprojekt konsequent der Prämisse der kontinuierlichen Verbesserung folgt. Von diesem ersten Satz bis zum zertifizierten ISMS ist es natürlich noch ein weiter Weg, bei dem Content-Management- und Ticket-Systeme allerdings der Schlüssel zum Erfolg sein können.
Die hier dargestellte Vorgehensweise mit ISMS-Frameworks und Compliance-Mappings wurde im Rahmen von ISMS-Implementierungsprojekten mit Kunden der Hamburger Unternehmensberatung CycleSEC entwickelt und erprobt. Sie basieren auf praktischen Erfahrungen und auf den Forschungsergebnissen, die der Autor Sebastian Klipper zusammen mit Steffen Hessler am Center for Advanced Internet Studies CAIS NRW erzielt und bereits in Heft 2021# 1 in der veröffentlicht hat [1].
Bevor wir, die Autoren dieses Beitrags, den Blick auf die ersten Schritte mit CMS und Ticket-System lenken, schauen wir zunächst auf alternative Wege zur Unterstützung einer ISMS-Implementierung.
Office-Anwendungen
Eine der am weitesten verbreiteten Methoden zur Dokumentation einer ISMS-Implementierung ist die Ablage von Office-Dokumenten in einer Ordnerstruktur oder auf einem Dokumentenmanagementserver. Die Inhalte werden dabei mit Office-Komponenten wie Textverarbeitung, Tabellenkalkulation und Präsentationssoftware erstellt und im Original oder als PDF-Dokument abgelegt.
Die Erstellung und vor allem die Pflege der mindestens benötigten Dokumente stellt viele Organisationen schnell vor unüberschaubare Aufgaben. Der Betrieb des ISMS gleicht dabei oft einem Kampf gegen veraltete, inkonsistente oder gar widersprüchliche Dokumentlandschaften. Zusammenhänge und Relationen lassen sich meist nur mit weiteren Dokumenten und hohem Pflegeaufwand bereitstellen, zum Beispiel durch Kreuzreferenz-Tabellen. Ob zu einem Audit dann alles gut und schlüssig zusammenspielt, ist oft schwer vorherzusehen.
Hier können CMS und Ticket-Systeme besonders durch die Möglichkeit der (relationalen) Verknüpfung und der Prozessintegration die Arbeit enorm erleichtern beziehungsweise eine Tiefe der Bearbeitung erreichen, die mit Office, Dateiablage und Co. nicht möglich ist.
In unserem Ansatz verzichten wir daher vollständig auf Office-Software, sofern ihre Verwendung nicht explizit vom Top-Management vorgegeben wird. In diesem Fall werden ausschließlich Export-Funktionen zu PDF oder Office genutzt, während die Bearbeitung des Contents konsequent im CMS und im Ticket-System erfolgt.
ISMS-Tools
Natürlich gibt es für die ISMS-Implementierung auch eine Reihe spezialisierter Tools, die eine Erleichterung bei der Implementierung bieten (vgl. z. B. verinice). Dafür enthalten sie umfangreiche Möglichkeiten speziell für die Arbeit im ISMS, lassen sich aber häufig nur schwer oder gar nicht in die bestehende Systemlandschaft integrieren. Der hier vorgestellte Ansatz erteilt daher auch der Verwendung spezialisierter ISMS-Tools eine Absage.
CMS und Ticket-Systeme
In diesem Artikel betrachten wir gezielt die Möglichkeiten und die Methodik zur ISMS-Implementierung auf Basis eines Content-Management-Systems und eines Ticket-Systems, um Produkte zu nutzen, die bereits für andere Aufgaben in einer Organisation genutzt werden oder verwendet werden könnten. Im besten Fall existieren also schon ein CMS und ein Ticket-System, in denen einzelne oder sogar alle Fachabteilungen arbeiten und welche bereits für Dokumentationen zu internen Prozessen und Regularien vorhanden sind.
CMS-Systeme
Eine wesentliche Stärke von CMS ist die Möglichkeit einer sehr einfachen automatischen und revisionssicheren Versionierung. Das erleichtert es erheblich die ISMS-Dokumentation Schritt für Schritt zu verbessern, weil sich Änderungen immer lückenlos nachvollziehen lassen. Die veröffentlichte Version einer Seite ist damit stets auch die gültige Version.
Einige Content-Management-Systeme bieten von Haus aus die Möglichkeit, Seiten auszuchecken und Entwurfsversionen zwischenzuspeichern. Andere speichern Zwischenentwürfe im Browser und wieder andere bieten keine der beiden Möglichkeiten oder nur, wenn zusätzliche Plugins installiert werden. Inwieweit sich also sogar ein Entwurfs-, Freigabe- und Änderungsprozess im CMS darstellen lässt, hängt von den Möglichkeiten des konkret verwendeten CMS ab.
Zusammenfassend lässt sich jedoch sagen, dass sich die Prozesse zur Dokumentenlenkung mit jedem CMS im Einklang mit den Anforderungen der ISO/IEC 27001 an dokumentierte Informationen realisieren lassen – im Zweifelsfall durch geschickte Workarounds.
Gerade kommerzielle CMS bieten sogar die Möglichkeit, einer Seite Attribute und Prozesszustände zuordnen zu können. Einige Systeme erlauben das von Haus aus, andere jeweils mit Unterstützung von Plugins. In diesem Beitrag gehen die Autoren davon aus, dass das nicht unbedingt notwendig ist und hierfür explizit ein Ticketsystem genutzt werden soll – CMS-Seiten also nur die zwei Zustände „veröffentlicht“ und „nicht veröffentlicht“ haben.
Nach bisherigen Erfahrungen lassen sich Aspekte, für die man einen Status pflegen, anzeigen und reporten möchte, besser mit allen anderen Aufgaben im Ticket-System dokumentieren. Die Reports selbst lassen sich dann aber eher als CMS-Seiten gestalten, für die in der Regel weitreichendere und einfachere Möglichkeiten zum Seitenlayout existieren.
Je nach gewünschtem Aufbau kann die ISMS-Dokumentation in einem oder in mehreren Bereichen auf einem CMS-Server strukturiert werden, die jeweils aus einer übergeordneten Portalseite und beliebig vielen Unterseiten bestehen.
Ticket-Systeme
Durch die Kombination mit einem Ticket-System kann man die ISMS-Prozesse jeweils als Tasks modellieren und nahezu beliebig anpassen. Während Prozesse im CMS entlang der Artefakte modelliert werden müssten, spielen im Ticket-System Tasks und ihre relational zugeordneten Attribute die Hauptrolle.
Auch hier kann es sinnvoll sein, ein oder mehrere Projekte auf einem Ticket-Server einzurichten. Das Anlegen mehrerer CMS-Bereiche und Ticket-Projekte erleichtert je nach Größe der Organisation oft besonders die Rechteverwaltung. Je größer und arbeitsteiliger eine Organisation ist, umso sinnvoller kann eine Unterteilung sein, während in kleinen Organisationen die zentralen Themen häufig ohnehin nur von wenigen Personen bearbeitet werden. Hier bringt eine Unterteilung dann eventuell keinen Vorteil mehr.
Integration der Systeme
In der Kombination aus einem CMS und einem Ticket-System bieten sich zwei grundlegende Wege eine CMS-Seite anzulegen. Der erste entspricht der Generierung einer CMS-Seite aus Content, der innerhalb des CMS selbst gespeichert ist – was nicht mit jedem CMS gut funktioniert und zu Inkonsistenzen und Pflegeaufwand zwischen CMS und Ticket-System führen kann.
Der zweite und bessere Weg ist die Integration beider Systeme und die Generierung einer CMS-Seite aus Content, der im Ticket-System gespeichert ist. Die CMS-Seite dient dann nur zur Darstellung (Layout) der Informationen, während der Content aus dem Ticket-System geladen wird.
Die erstellten Tickets können jeweils einzeln für sich stehen oder als hierarchische Struktur definiert werden oder einfacher ausgedrückt als Überaufgabe mit mehreren Unteraufgaben. Das hat den Vorteil, dass die Verantwortlichen den Zustand einer Überaufgabe sehr leicht überwachen, reporten und steuern können. Hierfür bieten die meisten Ticket-Systeme bereits vorgefertigte Ansichten. Im Laufe dieses Artikels führen wir verschiedene Klassen von Tickets ein – sogenannte Vorgangstypen (z. B. für Controls, Aufgaben oder Non-Conformities) – und listen sie am Ende zusammenfassend auf.
Man sollte sich immer vor Augen führen, dass die Integration von CMS und Ticket-System wesentlich davon abhängt, wie gut die beiden konkret verwendeten Systeme miteinander harmonieren. Es ist also eventuell etwas Kreativität und Geschick im Umgang mit den vorhandenen Möglichkeiten gefragt. Während kommerzielle Systeme desselben Anbieters häufig weitreichende Möglichkeiten zur Integration bieten, sieht das bei Systemen verschiedener Hersteller und bei Open-Source-Produkten manchmal anders aus. Steht der verfügbare Technologie-Stack in der Organisation bereits fest, ergibt sich die Art der Umsetzung dann gegebenenfalls aus den technischen und personellen Möglichkeiten und nicht nur aus dem Bedarf.
ISMS-Templates
Für einige CMS-Systeme existieren Vorlagenpakete, mit denen man durch einen Import ein vollständiges oder in Teilen vorbereitetes ISMS erhält. Ob als Office-Dokument-Paket oder CMS-Import – ISMS-Templates haben immer den Vorteil in kurzer Zeit einen sehr großen Schritt voranzukommen. Sie haben ebenso immer den Nachteil, dass man nach diesem Schritt nicht so ganz genau weiß, wo man steht und wie und warum man da hingekommen ist. Das eigenständige Erstellen einer Dokumentation ist unserer Erfahrung nach weiterhin die beste Vorbereitung auf ein Audit: Der Weg ist das Ziel und der beginnt mit dem ersten Satz. Gerade bei Muster-Policies besteht das Risiko, dass diese im Stage-1-Audit eine gute Figur machen, bevor sich dann im Stage-2-Audit vor Ort herausstellt, dass sie nicht ausreichend bekannt sind oder im Widerspruch zu bereits vorhandenen Regularien stehen.
Big Bang oder kontinuierliche Verbesserung
Eine wichtige Frage bei der Implementierung des ISMS ist also, ob man mit einem Big Bang ein fertiges ISMS präsentieren möchte oder ob man auf der grünen Wiese beginnt und das ISMS Schritt für Schritt auf- und regelmäßig umbaut.
Der Einsatz von ISMS-Templates entspräche der ersten Option: Alles ist bereits vorgegeben und vorbereitet. Die Frage ist nur wo und wie. Jede Person, die sich mit dem ISMS auseinanderzusetzen hat, muss dann von 0 auf 100 Prozent in einem einzigen großen Schritt – mit der Gefahr von Widerständen und einer Abwehrhaltung, die mit großen Veränderungen oft einhergeht. Bei diesem Ansatz nachzusteuern ist dann kaum möglich und häufig mit einem Gesichtsverlust vor dem Management oder der Organisation verbunden.
Die Big-Bang-Implementierung mittels CMS und Ticket-Systemen entspräche dann einer Vorbereitung „im stillen Kämmerlein“ und einer Veröffentlichung der gesamten Dokumentation zu einem oder wenigen Meilensteinen des ISMS-Implementierungsprojekts. Dabei gibt die ISO/IEC 27001 in Clause 10 eigentlich bereits den Weg vor: Kontinuierliche Verbesserung ist essenzieller Bestandteil jedes ISMS und wie könnte man das besser in die DNA des eigenen ISMS verankern, als von Beginn an konsequent Schritt für Schritt voranzuschreiten – im Extremfall sogar beginnend mit einem einzigen Satz. Die Implementierung eines ISMS mit CMS und Ticket-Systemen bietet hierzu einen optimalen Ansatz.
„Diese Seite dient dem Aufbau der Dokumentation zu unserem ISMS nach ISO/IEC 27001.“
Mehr als diesen einen Satz gibt es dann eben noch nicht, aber Schritt 1 ist getan und die Seite kann für alle Personen im Geltungsbereich des ISMS verfügbar gemacht werden, für die dieser Satz als hilfreich erachtet wird. In dieser sehr frühen Version des kontinuierlichen Verbesserungsprozesses wäre das vor allem das ISMS-Team, also alle, die aktiv zum ISMS beitragen sollen. Jetzt denken Sie vielleicht: „Das könnte man da doch auch hinschreiben und wer gehört überhaupt zum ISMS-Team?“ Guter Punkt. Das sollten wir verbessern:
„Diese Seite dient dem ISMS-Team beim Aufbau der Dokumentation zu unserem ISMS nach ISO/IEC 27001. Das ISMS-Team wird vom CISO geleitet. Es besteht aus jeweils einer abgeordneten Person aus allen Fachabteilungen.“
Jetzt besteht die ISMS-Dokumentation bereits aus drei Sätzen. Die letzten beiden enthalten jeweils Aufgaben:
Die erste besteht darin, dass der CISO mit der Leitung des ISMS-Teams beauftragt werden sollte. Es ist also eine Management-Entscheidung anzustoßen. Die zweite Aufgabe besteht darin, dass alle Abteilungsleitungen eine Person benennen müssen, die künftig ins ISMS-Team abgeordnet wird. Auch das muss angewiesen und dann von jeder Abteilungsleitung erledigt werden. Bei fünf Fachabteilungen wären das also sieben Aufgaben.
Wie verteilt man Aufgaben richtig?
Vielleicht wäre jetzt ihr erster Reflex, diese Aufgaben per E-Mail, Telefon oder im nächsten Flurgespräch zu verteilen. In einem ISMS geht es aber nicht nur darum, Aufgaben zu erledigen, sondern darum, sie systematisch gesteuert, dokumentiert und richtig im Sinne der ISMS-Anforderungen auszuführen.
Eine E-Mail kann immer nur einen Zustand haben und sie selbst sagt nichts zum Zustand der Aufgabe aus. Man sieht ihr nicht mal an, ob sie bereits beantwortet oder längst vergessen wurde. Wenn die Verantwortlichen Tausende von Aufgaben zuweisen und steuern wollen, stoßen sie mit E-Mails, Telefonaten und Flurgesprächen sehr schnell an Wirtschaftlichkeitsgrenzen.
Wie könnte man die sieben Aufgaben also besser verteilen? Hier werfen wir zunächst einen Blick in die ISO/ IEC 27001 und die Ticket-Systeme kommen ins Spiel. Die ISO/IEC 27001 hilft uns dabei herauszufinden, was richtig ist und ein Ticket-System unterstützt uns dabei, Aufgaben zu steuern und die Abarbeitung im Auge zu behalten. Management-Entscheidungen werden nach ISO/IEC 27001 9.3.2 im Management-Review getroffen und gemäß 9.3.3 dokumentiert. Die Ausstattung mit Ressourcen gehört zu Clause 7.1, die Festlegung von Kompetenzen zu Clause 7.2 und die Etablierung von Rollen zu Clause 5.3.
Drei Sätze im CMS und sieben erledigte Tickets liefern also bereits Evidenzen für die Erfüllung von fünf wichtigen Clauses. Das ist eine wesentliche Stärke des Ansatzes mit CMS und Ticket-System: Jeder Schritt der ISMS-Implementierung wird als Evidenz für die Erfüllung der Anforderungen dokumentiert.
Bereits hier existiert und funktioniert das ISMS, und die ISO/IEC 27001 bietet für jeden denkbaren Fortgang der ersten sieben Aufgaben ein passendes Vorgehen. Aber wie findet man das?
Zentrale Einstiegspunkte ins ISMS
Aktuell besteht das ISMS in unserer Überlegung aus einer eher zufällig entstandenen CMS-Seite mit drei Sätzen und sieben Tickets. Wir brauchen jetzt vor allem mehr Informationen darüber, was genau zu tun ist und wir müssen dringend mit der Dokumentation beginnen, was wir davon bereits erledigt haben. Spätestens im internen Audit müssen wir uns dazu erklären.
Was wir bereits wissen: Es wird nicht bei drei Sätzen und sieben Tickets bleiben. Wir werden tausende bis eventuell Zehntausende von Aufgaben und Arbeitsschritten koordinieren müssen [1]. Dafür brauchen wir einen systematischen Ansatz, der flexibel, fokussiert und skalierbar ist.
Im Folgenden etablieren wir hierzu ISMS-Frameworks und Compliance-Mappings als zentrale Einstiegspunkte in das ISMS und als dauerhafte und flexible Informationsquelle zu den Anforderungen der ISO/IEC 27001. Für jedes Framework, jedes Mapping und jede Unterseite gilt wiederum der Ansatz, dass alles mit einem einzigen Satz beginnen kann. Besser in kleinen Schritten vorankommen, als in Perfektion auf der Stelle treten.
Was mit einem Satz begann, wird dann jeweils Schritt für Schritt weiterentwickelt, bis irgendwann auch der letzte Schritt getan ist und das ISMS allen Anforderungen der ISO/IEC 27001 entspricht.
ISMS-Frameworks und Compliance-Mappings
Nachdem die ersten Schritte im Aufbau des ISMS sehr klein waren, gilt es also einerseits die zu erwartende Komplexität in machbare Etappenziele zu zerlegen und dabei andererseits stets einen Überblick über alle Anforderungen des Standards zu haben.
In der Struktur eines CMS geht es in diesem Schritt darum, zur ersten CMS-Seite Unterseiten zu etablieren, die das ISMS in thematische Blöcke gliedern. Diese thematischen Blöcke bezeichnen wir im Folgenden als Framworks und leiten sie direkt aus den Anforderungen ab, die ISO/IEC 27001 und unsere Organisation an das ISMS haben. Das bedeutet, dass Sie die folgende Liste möglicher Frameworks im eigenen ISMS durchaus anpassen können oder sogar müssen.
Gründe für eine Anpassung der Framework-Struktur könnten insbesondere abweichende Abteilungszuständigkeiten sein oder ein hohes Maß an Arbeitsteilung in großen Organisationen.
Durch die Frameworks ergibt sich die folgende Ebenenstruktur des CMS:
- Ebene 1: Startseite(n)
- Ebene 2: Frameworks
- Ebene 3: Conten
ISMS-Team-Framework
Ausgehend von den ersten drei Sätzen auf der Startseite unseres Beispiel-ISMS können wir das erste Framework ableiten. Das ISMS-Team benötigt mehr Informationen und einen eigenen Bereich. Im ISMS-Team Framework fassen wir also die Arbeit des ISMS-Teams zusammen. Konkret richten wir hierfür eine Unterseite im CMS ein, die wiederum weitere Unterseiten enthält. Das Framework bietet also einen Einstiegspunkt ins ISMS für alle Mitglieder des ISMS-Teams. Die weitere Struktur unterhalb des Frameworks könnte dann wie folgt aussehen :
- Berechtigungskonzept des CMS
- Meilensteinplan der ISMS-Implementierung
- ISMS-Team-Besprechungen a. Planung und Protokolle b. Liste der offenen Punkte (OPL) c. FAQ
- ISMS-Workshops
- Standards und weitere Quellen
- Scratchbook und Skizzen
Welche der Punkte für das eigene ISMS wichtig sind und welche nicht, hängt einerseits von den eigenen Wünschen ab und andererseits auch vom konkret verwendeten CMS. Der zweite Teil dieses Artikels stellt in der nächsten Ausgabe die praktische Implementierung mit Open-Source-Produkten vor.
Bietet das CMS nur unzureichende Möglichkeiten, Entwurfsversion zu pflegen, kann ein Bereich „Scratchbook und Skizzen“ hilfreich sein (Seite mit Unterseiten). Das ist ebenfalls der Fall, wenn das ISMS-Team noch keine Erfahrungen im Umgang mit einem CMS hat und kein separates Testsystem zur Verfügung steht, mit dem man auch mal „was ausprobieren“ kann. So hält man die Versionshistorie der eigentlichen Dokumentation zum Beispiel frei von erfolglosen Layout-Versuchen.
Weitere Frameworks
In unserer bisherigen Beratungspraxis haben sich die folgenden weiteren Frameworks als besonders hilfreich erwiesen:
- ISMS-Core-Framework a. ISMS-Handbuch b. Statement of Applicability (SoA)
- Prozess-Framework (nach ISO/IEC 27022)
- Compliance-Framework (mit Mappings zu allen Anforderungen an das ISMS)
- Management-Review-Framework
- Risiko-Framework
- Framework der Rollen und Verantwortlichkeiten
- Policy-Framework
- Communication-Framework
- Info-Framework
- Qualifizierungsframework
- Security-Awareness-Framework
- Audit-Framework
Die wichtigsten Frameworks werden im Folgenden jeweils kurz vorgestellt.
ISMS-Core-Framework
Im ISMS-Core-Framework wird das ISMS-Handbuch gepflegt, dass zwar gemäß ISO/IEC 27001 nicht vorgeschrieben, aber dennoch weit verbreitet ist. Es wird oft als textuelle Beschreibung zur Umsetzung der Clauses eingesetzt und folgt dabei sogar in der Nummerierung der Struktur des Textteils der ISO/IEC 27001. Das Handbuch dient der Einarbeitung ins ISMS und als grundlegendes Überblicksdokument. In einem Stage-1-Audit erleichtert es einem Audit-Team die Arbeit.
Das Statement of Applicability (SoA) hingegen ist ein zwingend erforderliches Dokument, das den expliziten Anforderungen aus Clause 6.1.3 genügen muss. In einer Implementierung mit einem CMS lässt sich das SoA komplett automatisiert generieren, sodass es jederzeit aktuell ist. Wie bereits weiter oben dargestellt, bietet die Kombination eines CMS mit einem Ticket-System hierfür zwei Wege.
Im ersten Fall würde die SoA-Seite aus Content aufgebaut werden, der auf Unterseiten innerhalb des CMS gespeichert ist. Im zweiten Fall würde die SoA-Seite aus Content im Ticket-System generiert. Im ersten Fall müsste man dafür 93 Unterseiten für die Controls anlegen und im zweiten für alle Controls je ein Ticket. Es spricht einiges dafür, im Falle der Controls beide Wege zu gehen und jeweils Seiten und übergeordnete Tickets anzulegen. Die Controls haben eine so herausragende Position im ISMS, dass es sinnvoll ist, ihren Inhalt und die Hinweise zur Implementierung der ISO/IEC 27002 in beiden Systemen anzeigen zu lassen. Je nach Integrationsgrad können die Inhalte dafür ausschließlich im Ticket-System hinterlegt werden und das CMS zeigt diese nur auf einer Übersichtsseite zu jedem Control an.
Im Ticket-System kann der Zustand „Implementiert“ dann davon abhängig gemacht werden („is blocked by“), dass alle Subtasks zu dem Control den Zustand „erledigt“ haben und es keine offenen Non-Conformities aus einem Audit geben darf, die den Zustand „Implementiert“ infrage stellen.
Prozess-Framework (nach ISO/IEC 27022)
Mit der Neufassung der ISO/IEC 27001:2022 haben die ISMS-Prozesse deutlich an Wichtigkeit gewonnen. Das Prozess-Framework lässt sich sehr einfach unter Rückgriff auf die ISO/IEC 27022 in Form von miteinander verknüpften Prozess-Steckbriefen im CMS aufbauen.
Konkret benötigt man hierzu für jeden Input, für jede Aktivität und jeden Output aller ISMS-Prozesse mindestens einen Link auf eine CMS-Seite oder ein Ticket. Bei der Implementierung mit Tickets kann man dann jeweils auch den Umsetzungsstatus anzeigen lassen, sodass der Prozess-Steckbrief gleichzeitig, automatisiert und tagesaktuell ein Prozess-Reporting ermöglicht.
Compliance-Framework (mit allen Mappings)
Das Compliance-Framework enthält mindestens ein Mapping auf alle Anforderungen der ISO/IEC 27001 (Clauses und Controls).
Gemäß Control 5.31 sind im ISMS jedoch auch die Umsetzung aller rechtlichen, regulatorischen und vertraglichen Anforderungen an die Informationssicherheit zu dokumentieren. Für all diese können im Compliance-Framework weitere Mappings angelegt werden.
Die Mappings realisiert man am besten so, dass sie nach ihrer Erstellung nie wieder aktualisiert werden müssen und sich stattdessen automatisiert aufbauen. Hierzu müssen die konkreten Anforderungen jeweils mit allen verfügbaren Seiten im CMS und allen relevanten Tickets verlinkt werden. Das lässt sich leicht als Tabellendarstellung mit mindestens vier Spalten umsetzen.
- Spalte 1: Quellenverweis / Nummer der Anforderung
- Spalte 2: Zitat der Anforderung
- Spalte 3: Links auf alle relevanten CMS-Seiten
- Spalte 4: Links auf alle relevanten Tickets
Die Links werden dabei nicht manuell eingegeben, sondern in Form von Tag-basierten Linklisten automatisch erzeugt. Man würde also zum Beispiel alle Seiten zum Thema „Information Backup“ mit dem Tag „isms-control-8-13“ markieren und im Mapping die Links zu allen Seiten einblenden lassen, die mit dem Tag „isms-control-8-13“ versehen sind. Gleiches gilt für die Links ins Ticket-System. Die Festlegung der Tags sollte dabei systematisch aufgebaut sein und es sollten keine Tags verwendet werden, die anderweitig vergeben sind. Es muss klar sein, dass sie ausschließlich zum Aufbau der Mappings dienen.
Die Pflege der Tags ist damit eine wesentliche Aufgabe der ISMS-Implementierung, der Umsetzungsdokumentation, der Feststellungen im internen Audit und der Vorbereitung von externen Audits.
Management-Review-Framework
Im Management-Framework werden alle gemäß Clause 9.3 geforderten Aspekte jeweils als Unterseiten angelegt. Diese lassen sich dann in einer Übersichtsdarstellung als Dashboard einblenden, das der Durchführung des Management-Reviews dient.
Hierbei gilt es, eine Balance zwischen automatisierter, tagesaktueller Darstellung und Dokumentation der Inhalte zu einem bestimmten Stichtag zu finden. Gerade dieses Gleichgewicht kann sehr individuell ausfallen und ist von Organisation zu Organisation verschieden.
Es gibt einerseits Organisationen, für die Online-Meetings und die Arbeit mit CMS und Ticket-System auch im Top-Management gängige Praxis sind und andererseits Organisationen, in denen die ausgedruckte Tischvorlage die übliche Basis für Entscheidungen des Top-Managements sind. Auch letzterer Fall lässt sich in einem CMS realisieren, vorausgesetzt man hat eine gute Export-Möglichkeit zu den eigenen Office-Anwendungen.
Risiko-Framework
Das Risiko-Framework dient der textuellen Beschreibung, wie die Anforderungen an das Risikomanagement konkret umzusetzen sind. Zusätzlich kann das Risikoinventar als Auswertung dargestellt werden. Auch hier besteht wieder die Möglichkeit, Risikoanalysen als CMS-Seite zu realisieren oder als Vorgangstyp im Ticket-System.
Das Risiko-Framework sollte mindestens die folgenden Unterseiten enthalten:
- festgelegte Risikokategorien
- Risiko-Assessment-Methodik
- Risiko-Assessment-Programm
- Risikoinventar
- Risikobehandlungsplan
Die ersten beiden Seiten legen fest, nach welchen Kriterien und nach welcher Methodik im ISMS mit Risiken umgegangen werden soll. Die weiteren lassen sich bei einem vollständig auf Tickets basierenden Risiko-Assessment automatisiert und eventuell in verschiedenen Detailtiefen zielgruppenorientiert aufbauen. Einmal angelegt sollte das Risiko-Framework nur noch selten angepasst werden. Die Risiken selbst werden von der Identifikation bis zum Abschluss der Risikobehandlung mit unterschiedlichen Vorgangstypen als Tickets gesteuert.
Policy-Framework
Das Policy-Framework dokumentiert Entwürfe und in Kraft gesetzte Policies. Je nach Höhe der Dokumentenpyramide in der Organisation können weitere Frameworks für Guidelines, Betriebsvereinbarungen oder Ähnliches angelegt werden. Je nach eingesetztem CMS und den vorhandenen Möglichkeiten zur Versionierung und Abstimmung von Entwürfen kann es nötig sein, jeweils ein Framework für die Entwurfs- und Abstimmungsphase anzulegen und eins für die in Kraft gesetzten Dokumente.
Security-Awareness-Framework
Im Security-Awareness-Framework werden alle Aktivitäten zusammengefasst, die zur Erfüllung der Anforderungen zu einem angemessenen Sicherheitsbewusstsein beitragen. In diesem Zusammenhang existiert eine enge Verwandtschaft mit dem Communication-, dem Info- und dem Qualifizierungsframework. Ob hier ein Framework ausreicht oder mehrere Frameworks sinnvoll sind, hängt zum Beispiel davon ab, ob es eine eigene Abteilung für interne Kommunikation oder eine Medienabteilung gibt und ob Qualifizierung eine Sache der Fachabteilungen ist oder diese über die Personalabteilung zentral gesteuert werden.
Die folgenden Unterseiten bieten einen guten Start zum Thema Security-Awareness:
- Gefährdungslage
- Zielgruppenanalyse
- Awareness-Konzept
- Awareness-Maßnahmen
Audit-Framework
Als letztes Framework wird meistens das Audit-Framework etabliert. Zu diesem Zeitpunkt hat das ISMS und die Umsetzung der Controls ein ausreichendes Niveau erreicht, um in einem internen Audit zu prüfen, wie weit man wirklich ist. Für das Audit-Framework sind die folgenden Unterseiten unerlässlich:
- Auditprogramm mit Auditplänen
- Nachweis der Audit-Ergebnisse
- Nachweis der (Non)-Conformities
- Nachweis der Corrective Action
Wie bereits im Risiko-Framework sollten sich die Seiten des Audit-Frameworks im Wesentlichen automatisch aus Content aufbauen, der in einem eigenen Ticket-Projekt aus den dort genutzten Vorgangstypen gezogen wird.
Fehlt etwas?
Diese Frage lässt sich jetzt bereits – vorausgesetzt, man hat jedes Framework vollständig mit den korrekten Tags versehen – im ISO/IEC-27001-Mapping ablesen. Dort sollte dann automatisch in Spalte 3 zu jeder Clause jeweils mindestens ein Framework als Link angezeigt werden. Die Mappings dienen so auch als Checkliste für die Vollständigkeit der ISMS-Dokumentation. Wenn man die Frameworks und Mappings immer wieder als Einstiegspunkt ins ISMS nutzt, besteht die Vorbereitung eines externen Audits – wie bereits zuvor beim internen Audit – nur noch aus dem Anlegen eines Auditplans und der Zuweisung an den User-Account der externen Audit-Teamleitung. Die wichtigsten Einstiegsseiten in einem Audit sind dann das ISO/IEC-27001-Mapping, das ISMS-Handbuch und das Prozess-Framework. Von diesen drei Seiten lässt sich die gesamte ISMS-relevante Dokumentation in wenigen Klicks mit den zugrunde liegenden Anforderungen in Verbindung bringen.
Projekte und Vorgangstypen im Ticketsystem
In unserer bisherigen Beratungspraxis hat sich die Unterteilung des Ticket-Systems zumindest in mehrere Projekte und Vorgangstypen als hilfreich erwiesen, die wir im Folgenden kurz vorstellen.
Information Security Change Management (ISCM)
Im ISCM werden zunächst alle Controls als dedizierter Vorgangstyp erfasst. Danach zerlegt man die Anforderungen des Controls in ihre Teilanforderungen und definiert diese als weiteren Vorgangstyp. Das ist nötig, da die Teilanforderungen teilweise in unterschiedlicher Zuständigkeit liegen und sich so eindeutig zuordnen lassen. Erst danach kommen die konkret zu erledigenden Aufgaben als dritter Vorgangstyp.
Daraus ergibt sich die folgende Ebenenstruktur im Ticket-System:
- Ebene 1: Controls
- Ebene 2: Teilanforderungen
- Ebene 3: resultierende Aufgaben
Auf Ebene 2 und Ebene 3 kann es nötig sein, sogenannte Clones der Tasks anzulegen, falls diese mehrfach erledigt werden müssen – zum Beispiel mehrere Rechenzentren mit sehr unterschiedlicher Konfiguration oder eine jährliche Belehrung aller Personen in jedem Team. Dieser Aufwand lohnt sich, sobald es darum geht, im Management-Review ein stichfestes Reporting zum Status des ISMS zu liefern und vor allem um aufzuzeigen, welche Abteilungen die Zielvorgaben des Managements nicht erfüllen.
Das ISMS steuert dann nur noch Aufgaben, die zumindest mittelbar auf die Zielerreichung auf Ebene 2 einzahlen. Eine Aufgabe, die sich nicht aus den oberen Ebenen ableitet, ist grundsätzlich noch nicht korrekt zugeordnet oder unwichtig. Die Ausnahmen zu diesem Grundsatz müssen sich entweder aus dem Risikomanagement, dem Management-Review oder den Audit-Aktivitäten ergeben.
Aber warum gibt es auf Ebene 1 und 2 keine Clauses? Diese werden bereits vom ISMS-Team im ISMS-Core-Framework und im ISMS-Handbuch dokumentiert und gesteuert. Natürlich könnte man für die Clauses ebenfalls auf Ebene 1 einen eigenen Vorgangstyp anlegen. Möglicherweise kann das in besonders großen, komplexen und langwierigen ISMS-Implementierungen nötig sein. In unserer Praxis hat sich das jedoch als unnötig erwiesen, da die Implementierung der Clauses meist in kurzer Zeit erreicht werden kann und Changes am ISMS danach jeweils über das Managment-Review-Framework und das Audit-Framework veranlasst werden.
Information Security Risk Management (ISRM)
Die Gestaltung der ISRM-Tickets erfolgt üblicherweise aus Gründen der besseren Zugriffssteuerung als separates Projekt im Ticket-System. In den meisten Fällen reicht ein Vorgangstyp, der sich mit seinen Attributen und möglichen Zuständen direkt aus den Kategorien und der Methodik ableitet, die im Risiko-Framework festgelegt sind. Wichtig ist die Möglichkeit der Verknüpfung der erfassten Risiken mit den Controls, die zur Behandlung des Risikos geeignet sind, so wie dies die ISO/IEC 27001 explizit fordert. Die Berechtigungsvergabe beziehungsweise die Trennung der Systeme sollte man also nie so restriktiv handhaben, dass sich die Ticket-Projekte untereinander nicht sehen können.
Information Security Audit Management (ISAM)
Im Ticket-Projekt zur Steuerung der Audit-Aktivitäten ist zunächst ein eigener Vorgangstyp für Audit-Pläne nötig. Zusätzlich werden mindestens Vorgangstypen für „(Non)-Conformities“ und „Corrective Action“ benötigt. Was die Dokumentation und die Berichterstattung angeht, besteht wiederum einerseits die Möglichkeit, diese als Seite im CMS aufzubauen und dort zum Beispiel eine Management-Summary zu verfassen. Andererseits kann man im Ticket-System auch eigene Vorgangstypen oder Felder zum Audit definieren.
Hier wie in allen anderen Fällen hängt diese Entscheidung oft von den Möglichkeiten des konkret genutzten CMS und des Ticket-Systems ab und davon, wie viel Wert man auf Layout und Gestaltungsmöglichkeiten legt.
Zusammenfassung und Ausblick
Die Dokumentation eines ISMS mit nicht enden wollenden Tabellen und unübersichtlich kaskadierenden Ordnerstrukturen ist die häufig anzutreffende Realität in der ISMS-Implementierung. Verschiedene Hersteller bieten hier spezialisierte Software-Tools und Templates als Erleichterung an.
Die vorgestellte ISMS-Implementierung mittels CMS und Ticket-Systemen ist demgegenüber komplex und erfordert Erfahrung. Kann man die im ISMS-Team vorweisen, bietet dieser Ansatz allerdings die Möglichkeit, das eigene ISMS auf ein völlig anderes Niveau zu heben.
Richtig angepackt kann die intensive Nutzung von CMS und Ticket-Systemen Vorbild und Enabler für weitere Projekte und Management-Systeme sein. Darüber hinaus ist der Ansatz voll skalierbar für integrierte Managementsysteme, während viele ISMS-Tools diese Möglichkeit nicht bieten.
In Teil 2 dieses Artikels im nächsten Heft stellen wir einen beispielhaften ISMS-Aufbau mit Open-Source-Produkten vor. Dabei zeigen wir, wie der automatische Aufbau von Seiten durch die Integration von CMS und Ticket-System praktisch erfolgt und wie sich ausgewählte Vorgangstypen konkret definieren lassen. Während Teil 1 einen Überblick über die Methodik bietet, legt Teil 2 einen Schwerpunkt auf die Verknüpfungen und zeigt, wie man sich mit dem vorgestellten Ansatz auf externe Audits vorbereiten kann.
Sebastian Klipper (sk@cyclesec.com) ist Managing Consultant und Geschäftsführer des auf ISMS-Implementierungen spezialisierten Hamburger Beratungsunternehmens CycleSEC.
Lars Albert (la@cyclesec.com) ist Senior Consultant bei CycleSEC.
Louisa Frick (lf@cyclesec.com) ist Junior Consultant bei CycleSEC
Literatur
[1] Sebastian Klipper und Steffen Hessler, 27001 – Odyssee im Sprachraum – Wie linguistische Textanalyse bei Komplexitätsbewertung und Verständnis der ISO/IEC 27001 hilft, 2021# 1