ISMS-Tools in der Praxis (1) : Erfolgsfaktoren für die Nutzung von ISMS-Tools bei Aufbau und Betrieb eines ISMS
Im Rahmen des Aufbaus eines Informationssicherheits-Managemant (ISMS) stellt sich häufig die Frage, wo und womit man die dabei entstehenden und benötigten Informationen dokumentiert und pflegt. Viele Organisationen starten mit vorhandenen Werkzeugen bekannter Office-Suiten wie Microsoft Excel, stoßen dann aber schnell an die Grenzen dieser Werkzeuge und begeben sich auf die Suche nach einem spezialisierten ISMS-Tool. Dieser Artikel beleuchtet die Vor- und Nachteile beim Einsatz dedizierter ISMS-Tools sowie Stolpersteine und Erfolgsfaktoren bei deren Nutzung.
Von Knut Haufe, Berlin
Beim Aufbau eines Informationssicherheits-Managementsystems (ISMS) fallen vielfältige Aufgaben an, die einerseits einer strukturierten Datengrundlage bedürfen und andererseits auch selbst strukturiert dokumentiert werden müssen. Beispiele für Aufgaben, die eine strukturierte Datengrundlage erfordern, sind im IT-Grundschutz die Dokumentation der Struktur eines Informationsverbunds oder in der „ISO-Welt“ die Dokumentation des Asset-Inventars.
Darauf aufbauende Aufgaben basieren auf diesen Daten und deren Ergebnisse sind ebenfalls strukturiert zu dokumentieren:
- Abgrenzung des Geltungsbereichs (Informationsverbund)
- Visualisierung der Strukturanalyse beziehungsweise Assets in einem Netzwerkplan
- Schutzbedarfsfeststellungen: Dokumentation des Schutzbedarfs inklusive Begründung sowie den Fakten, wer wann diese Entscheidung getroffen hat, nebst Anwendung von Vererbungsregeln
- Ergebnisse des Vergleichs von Best-Practice-Maßnahmen mit der Realität (Grundschutzchecks beziehungsweise Ist-Analyse zum Umsetzungsstand von Maßnahmen)
- Ergebnisse von Risikoanalysen und der Auswahl von Risikobehandlungsoptionen
- Vorgabedokumente wie Leitlinien und Richtlinien
- Planung und Nachverfolgung noch offener Aufgaben – beispielsweise zur Umsetzung von Maßnahmen
All diese Informationen sind dabei voneinander abhängig oder beeinflussen sich gegenseitig. Weiterhin handelt es sich dabei nicht um einmalige, in sich abgeschlossene Tätigkeiten, sondern um Daueraufgaben, die eine kontinuierliche Aktualisierung der dokumentierten Informationen erfordern. So bestimmen die Ergebnisse der Strukturanalyse beispielsweise die notwendigen Schutzbedarfsfeststellungen, welche die Notwendigkeit einer Risikoanalyse beeinflussen. Für die Risikoanalyse muss wiederum bekannt sein, welche Maßnahmen bereits umgesetzt sind.
Die Dokumentation muss dabei insgesamt den Anforderungen des jeweils angewendeten Standards entsprechen, konsistent und widerspruchsfrei, zugänglich sowie möglichst einfach zu pflegen sein.
Dokumentation mit und ohne dediziertes ISMS-Tool
Beim Aufbau eines ISMS werden Dokumentationserfordernisse häufig erst mit der Bearbeitung der Aufgaben gemäß dem jeweiligen Vorgehensmodell (z. B. BSI 200-2) nach und nach erkannt. Der Umfang, die Komplexität und der Aufwand zur Pflege der Dokumentationen werden dabei oft erheblich unterschätzt. Infolgedessen liegt die Nutzung bestehender Office-Suiten für die Dokumentation zunächst nahe.
So wird beispielsweise begonnen, die Strukturanalyse in Microsoft Excel zu dokumentieren. Was mit einer einfachen Liste der IT Systeme anfängt, wächst jedoch schnell zu einem viele Tabellenblätter umfassenden Excel-Tool heran, dessen Tabellen untereinander verlinkt sind und mithilfe von Makros auch eine grundlegende Logik abbilden. Eine derartige umsetzungsbegleitende Eigenentwicklung geht einher mit typischen Aspekten der Softwareentwicklung wie Moving Targets, Versionspflege, Dokumentation der Entwicklung und Quellcodes, Tests, mangelndem Entwicklungs-Know-how (bes. bei komplexen Makros sowie Änderung/Ergänzung von Funktionen) et cetera, die ebenfalls oft unterschätzt werden. Auch die Gewährleistung der Datenkonsistenz zwischen einzelnen Tabellen ist häufig nur schwer abbildbar – gerade bei Änderungen und der Unterstützung von Betriebsaufgaben.
Der „Missbrauch“ von Tabellenkalkulations- Werkzeugen (mit hohen Entwicklungskosten) für Aufgaben, die in einem dedizierten datenbankgestützten Werkzeug besser aufgehoben wären, führt dann nicht selten später doch zum Umstieg auf ein solches dediziertes ISMS-Tool. Auch für kleine und mittlere Organisationen ist letztlich der Einsatz eines dedizierten ISMS-Tools in der Regel alternativlos, um die Anforderungen an die Dokumentation – initial sowie im Betrieb des ISMS – zu erfüllen. Vor- und Nachteile des Einsatzes eines ISMS-Tools im Vergleich zur schleichenden Eigenentwicklung mit Office-Suiten verdeutlicht Tabelle 1.
ISMS ohne dediziertes ISMS-Tool | ISMS mit dediziertem ISMS-Tool | |
---|---|---|
Vorteile | • keine Investition in ein dediziertes ISMS-Tool | • alle benötigten Informationen an einer Stelle zentral zugreifbar |
Nachteile | • hohe Anforderungen an fachliches Know-how | • kein Tool ist out-of-the-box nutzbar – Tool- |
Einsatz eines dedizierten ISMS-Tools
Auch die Auswahl und Nutzung von dedizierten ISMS-Tools bedürfen einer sorgfältigen Planung. Aktuelle Werkzeuge konzentrieren sich oft darauf, Tätigkeiten im Rahmen des initialen Aufbaus des ISMS dokumentarisch zu unterstützen – oft liegt der Fokus auf dem Nachweis der Tätigkeiten und ihrer Ergebnisse im Rahmen von Compliance-Audits (z. B. für Zertifizierungen).
Doch welche Betriebsaufgaben sollte ein ISMS-Tool dauerhaft und wiederkehrend unterstützen? Zunächst sind die initial erfassten Daten zu pflegen und zu aktualisieren – und das nicht erst kurz vor dem nächsten Audit! Weiterhin müssen die erfassten Daten im Betrieb des ISMS genutzt werden – andernfalls wäre deren Erfassung sinnlos und unnötig. Ein ISMS-Tool muss daher auf die Unterstützung der Nutzung der Daten fokussieren. Die Kernfrage lautet: Wobei und wie kann das ISMS-Tool den Informationssicherheitsbeauftragten* und das ISMS-Team bei ihren täglichen Aufgaben unterstützen?
Häufige Stolpersteine
Im Folgenden werden zunächst die drei häufigsten Stolpersteine bei der Nutzung aktueller ISMS-Tools erläutert.
Fokus auf einmalige, complianceorientierte Aufgaben – kein Fokus auf wiederkehrende Aufgaben im Rahmen der ISMS-Prozesse
Sowohl das Datenbankmodell als auch die Funktionen des ISMS-Tools fokussieren auf die Abbildung eines oder mehrerer Standards. Oft werden Tätigkeiten zur Pflege und Änderung der Daten (Changemanagement) jedoch nur unzureichend unterstützt. Der hohe Einmalaufwand zur initialen Befüllung des ISMS-Tools rentiert sich dann nicht, da das Tool mangels Unterstützung von Datennutzung sowie Änderungen/Datenpflege nicht fortlaufend genutzt wird und Datenbestände schnell veralten.
Aufbau von Datenredundanzen zu bestehenden Tools in Verbindung mit mangelnder Integration derselben
Oft werden Daten im ISMS-Tool manuell und zusätzlich zu bestehenden Dokumentationen erfasst (Redundanz). Häufige Beispiele hierfür sind Teile der IT-Dokumentation (z. B. Client- und Server-Listen) oder Sicherheitsvorfälle, die oft bereits in Ticketsystemen aufgenommen wurden. Pflegt man diese Dokumentationen dann nicht über möglichst automatisierte Schnittstellen, entsteht eine mit vermeidbarem Aufwand manuell zu pflegende redundante und oft inkonsistente Datenhaltung.
Fehlerhafte Integration multipler Anforderungssets
Das einem ISMS-Tool zugrunde liegende Datenmodell wird bei der Integration mehrerer Anforderungssets – wie dem BSI IT-Grundschutz und der ISO/ IEC 27001 – oft nicht zu Ende gedacht. Ein Beispiel hierfür ist die Erfassung eines Servers in der Strukturanalyse nach BSI IT-Grundschutz, der aber in der ISO-Sicht nicht automatisch in der Liste der Assets erscheint. Ursache hierfür sind unvollständig integrierte Datenmodelle, die bei der Nutzung des Tools zu Mehraufwand und Inkonsistenzen führen.
Erfolgsfaktoren
Im Gegensatz zu den vorausgegangenen Punkten können die im Folgenden beschriebenen sechs Erfolgsfaktoren für eine neue Generation von ISMS-Tools stehen:
Klares Zielbild der Datennutzung sowie deren Unterstützung
Grundlage der Konzeption des Datenmodells und der Funktionen eines ISMS-Tools muss ein klares Zielbild hinsichtlich der zu unterstützenden Datennutzung im Sinne der Betriebsaufgaben eines ISMS sein. Das ISMS-Tool muss diese Betriebsaufgaben geeignet unterstützen – beispielsweise durch Workflows oder Assistenten, die Nutzer bei der Umsetzung von Aufgaben durch das ISMS-Tool führen.
Redundanzfreiheit
Bei der Konzeption der Nutzung eines ISMS-Tools muss redundanzfrei festgelegt werden, welche Aufgaben man in welchem Tool bewältigen will. Dies ist – abhängig von der bestehenden Tool-Landschaft – für jede Organisation individuell zu definieren. Hierbei sollten beispielsweise Sicherheitsvorfälle nicht sowohl im Ticketsystem des Help-Desks als auch im ISMS-Tool gesteuert werden.
Diese Redundanzfreiheit muss auch auf Datenebene gelten: Es muss eineindeutig klar sein, welches Tool für welche Informationen in der Organisation führend ist. Dies schließt nicht zwingend redundante Datenbestände aus (ggf. auf unterschiedlichen Abstraktionsebenen) – Voraussetzung hierfür sind allerdings eine geeignete Integration und Schnittstellen, die eine Automatisierung der Datenpflege und die Vermeidung von Inkonsistenzen gewährleisten. Im ISMS-Tool müssen daher im Funktionsumfang enthaltene Aufgaben modular abschaltbar sein.
Automatisierung in der Pflege der Stammdaten – Schnittstellen und Integration
Viele Daten, die ein ISMS-Tool erfasst, sind auch in anderen Systemen vorhanden oder werden dort führend und in einem höheren Detailgrad vorgehalten. Beispiel: Die Configuration-Management-Database der IT-Abteilung ist hinsichtlich der IT-Assets das führende Tool, dennoch werden diese Informationen auf einer höheren Abstraktionsebene in der Strukturanalyse oder im Asset-Register im ISMS-Tool repliziert.
Derartige Stammdaten sollten möglichst nicht manuell eingepflegt, sondern über automatisierte Schnittstellen in das ISMS-Tool repliziert werden. Auf diese Weise übernommene Daten sollte man dort auch nicht ändern können – das ISMS-Tool sollte einzig und allein für solche Informationen führend sein, die durch das ISMS anhand der Stammdaten neu erstellt wurden (z. B. Risikoanalysen).
Vordefiniertes und flexibel anpassbares Datenmodell
ISMS-Tools nutzen häufig unterschiedliche Kombinationen von Anforderungssets – beispielsweise IT-Grundschutz, ISO/IEC 27001, NIS-2 et cetera. Das ISMS-Tool sollte daher ein für die relevanten Anforderungssets vordefiniertes, integriertes und modularisiertes Datenmodell (siehe auch den nachfolgenden Erfolgsfaktor) „out of the Box“ enthalten.
Ein ISMS-Tool, welches das nicht bietet, ist nichts weiter als eine leere Datenbank, mit der man zwar alles machen kann, die den Nutzer damit aber allein lässt – oder für die Entwicklung des Datenmodells zusätzliche Zahlungen fordert. Oft verwirren Marketingaussagen zu aktuellen ISMS-Tools dahingehend: „Im Tool xy kann die IT-Grundschutzmethodik abgebildet werden“ oder „Tool xy ist kompatibel mit IT-Grundschutz“. In einer leeren Datenbank kann man natürlich die IT-Grundschutzmethodik im Datenmodell abbilden und diese ist durchaus auch kompatibel mit dem IT-Grundschutz – das heißt aber noch nicht, dass ein grundschutzkonformes Datenmodell im Auslieferungszustand enthalten wäre. Weiterhin muss das Datenmodell an gegebenenfalls zukünftig zu nutzende Anforderungssets anpassbar sein.
Unterstützung multipler Standards mit gemeinsamem integriertem Datenmodell
Da, wie bereits angesprochen, in einem ISMS-Tool häufig unterschiedliche Kombinationen von Anforderungssets genutzt werden, sollte das ISMS-Tool über ein redundanzfreies, vordefiniertes, integriertes und modulares Datenmodell verfügen. Damit sollten dann beispielsweise Informationen aus Grundschutzcheck und Risikoanalysen (IT-Grundschutz-Sicht) automatisch genutzt werden, um das Statement of Applicability in der ISO-Sicht auszufüllen. IT-Systeme, Anwendungen et cetera, die in der Strukturanalyse des ISMS-Tools erfasst sind, sollten auch automatisch als Assets in einer ISO-Sicht im ISMS-Tool erscheinen.
Beim Wechseln zwischen Ansichten für die Bearbeitung von Risikoanalysen, Schutzbedarfsfeststellungen und Business-Impact Analysen (BIA) sollten Daten aus den jeweiligen Analysen für eine logische Wiederverwendung bereitgestellt beziehungsweise logisch verknüpft werden:
- Eine Schutzbedarfsfeststellung ist nichts anderes als eine Auswirkungsanalyse. Der bereits erfasste Schutzbedarf hinsichtlich der Verfügbarkeit eines Prozesses sollte daher auch in der BIA weiterverwendet werden (und sich nicht abweichend erfassen lassen). Werden in einer Schutzbedarfsfeststellung beispielsweise sehr hohe Auswirkungen bei einem Integritätsverlust notiert sollten in der Risikoanalyse die Auswirkung von G.046 „Integritätsverlust schützenswerter Informationen“ entsprechend definiert sein und sich die Auswirkungen nicht abweichend als vernachlässigbar dokumentieren lassen.
- Erfasste und klassifizierte Sicherheitsvorfälle sollten automatisch mit den Informationen der Risikoanalyse abgeglichen werden. Dafür könnte etwa eine logische Prüfung hinsichtlich der Eintrittswahrscheinlichen erfolgen: Wenn in der Risikoanalyse eine Eintrittswahrscheinlichkeit für den Verlust von IT-Systemen mit „einmal im Jahr“ dokumentiert ist, aber im laufenden Jahr bereits fünf Fälle aufgetreten sind, sollte das hinterfragt werden. Gleichermaßen sollte das ISMS-Tool bei der Erfassung von Sicherheitsvorfällen abfragen, welches Risiko aus den Risikoanalysen hier eingetreten ist oder vorschlagen, anhand realer Sicherheitsvorfälle neue Risiken zu erfassen, falls diese noch nicht erfasst waren.
Unterstützung von Modularisierung, Hierarchisierung und Standardisierung der Sicherheitskonzeption
Oft wird der Komplexität einer Sicherheitskonzeption in der Praxis durch deren Modularisierung, Hierarchisierung und Standardisierung begegnet. Hierbei lässt sich zwischen Anforderungen unterscheiden, die durch übergreifende Lösungen erfüllt werden, und Anforderungen, die individuell für ein Asset oder einen abgegrenzten Teil im Geltungsbereich eines ISMS erfüllt werden.
Ein Beispiel hierfür sind übergreifende Sicherheitsregelungen in „Allgemeinen Vertragsbedingungen für Dienstleister“ (OPS.2.3.A4) oder die „Erstellung einer Outsourcing-Strategie“ (OPS.2.3.A8), die durch einzelvertragliche Regelungen (gem. OPS.2.3.A6) ergänzt werden. Im BSI IT-Grundschutz sind sowohl die übergreifend zu lösenden als auch die individuellen Anforderungen im Baustein „Nutzung von Outsourcing“ enthalten, der auf jeden Outsourcing-Dienstleister einmal anzuwenden ist. Das Sicherheitskonzept für den Dienstleister setzt sich in der Praxis dann aus übergreifenden sowie individuellen Regelungen zusammen. Ein ISMS-Tool sollte diese Modularisierung beispielsweise durch geeignete Sichten auf das Sicherheitskonzept, Vergabe von Zuständigkeiten bei der Umsetzung und Aufteilung in „Module“ unterstützen.
Fazit
Der Einsatz eines dedizierten ISMS-Tools ist heute in der Regel auch für kleine und mittlere Organisationen alternativlos, um die Anforderungen an die Dokumentation initial und im Betrieb des ISMS zu erfüllen. Hierfür sind eine sorgfältige Einsatz-Planung, Konzeption und Auswahl sowie Integration in eine bestehende Tool-Landschaft erforderlich. Kein ISMS-Tool kann jedoch einfach nur beschafft und „out of the Box“ genutzt werden.
Der zweite Teil dieses Beitrags vertieft in der nächsten <kes> Kriterien zur Einsatzplanung sowie, Auswahl oder Entwicklung eines ISMS-Tools.
Prof. Dr. Knut Haufe ist Director im Bereich Cyber-Security-Services bei der EY Consulting GmbH.