Mit <kes>+ lesen

Alles beginnt mit einem Satz (2) : Praktische ISMS-Implementierung durch Verwendung von Content-Management-Systemen am Beispiel von XWiki

Bei der Implementierung eines Informationssicherheits-Managementsystems (ISMS) nach ISO/IEC 27001 müssen Organisationen 7 Clauses und 93 Controls systematisch umsetzen und nachvollziehbar dokumentieren. Während die Arbeit mit spezialisierten Tools einer mehr oder weniger starren Vorgehensweise folgt, bieten Content-Management-Systeme (CMS) die Möglichkeit, den Bedürfnissen der eigenen Organisation stärker Rechnung zu tragen. Im ersten Teil dieses Artikels wurde beleuchtet, wie man eine ISMS-Implementierung mit beliebigen Content Management- und Ticket-Systemen realisieren kann [1]. Der vorliegende zweite Teil stellt nun Möglichkeiten für eine praktische Umsetzung mit der Open-Source-Software XWiki vor.

Die hier beschriebene Vorgehensweise einer ISMS-Implementierung basiert auf der Gliederung der ISMS-Dokumentation in Frameworks und Compliance- Mappings, wie sie der Autor als Consultant im Rahmen von Implementierungsprojekten entwickelt hat und wie sie im ersten Teil dieses Beitrags [1] vorgestellt wurde. Sie berücksichtigt die Ergebnisse der gemeinsamen Forschung zur Komplexität der Einzelanforderungen der ISO/IEC 27001 von Sebastian Klipper und Steffen Hessler am Center for Advanced Internet Studies CAIS NRW [2].

XWiki-Überblick

Als Content-Management-System verwendet das in diesem Artikel beschriebene ISMS die Open-Source-Wikisoftware XWiki (www.xwiki.org), die mit kommerziellen Produkten wie Confluence von Atlassian vergleichbar ist. Die Firma XWiki SAS (https://xwiki.com/) bietet hierzu auch kommerzielle Erweiterungen und Dienstleistungen an. Darüber hinaus wird XWiki in der Open-CoDE-Plattform der öffentlichen Verwaltung für das Wissensmanagement empfohlen [3]. XWiki ist ein 2nd-Generation-Wiki. Während die erste Wiki-Generation der gemeinsamen Arbeit an einem Content-Pool diente, bieten 2nd-Generation-Wikis die Möglichkeit zur Erstellung strukturierter, kollaborativer Webanwendungen. XWiki kann man sowohl als 1st- als auch als 2nd-Generation-Wiki verwenden.

Gerade die Entwicklung kleiner Anwendungen geht mit dem App-Within-Minutes-Wizard schnell von der Hand. Mit der Template-Skriptsprache Velocity lassen sich unkompliziert Erweiterungen vornehmen und kleine Tools programmieren. Dies führt allerdings gegebenenfalls dazu, dass Content und Code vermischt werden, was aus Sicherheitsaspekten problematisch sein kann. Je größer die programmierten Abschnitte werden, umso schwieriger ist es darüber hinaus, in dem integrierten WYSIWYG-Editor flüssig am Content zu arbeiten, weil dieser für skriptbasierte Bestandteile nicht nutzbar ist. Hier gilt es, eine Balance zu finden zwischen programmierten Teilen und gut editierbarem Content.

XWiki stellt Inhalt in einer hierarchischen Struktur aus Seiten und Unterseiten dar, die in einer 1-zu-n-Baumstruktur abgelegt werden. Sollen Inhalte an mehreren Stellen der Baumstruktur auftauchen, lassen sich diese teilweise oder als Ganzes über das display-Makro in einer vorhandenen Seite einblenden. Angezeigt werden diese Inhalte jedoch nur für Konten, die für beide Äste der Baumstruktur Leseberechtigungen besitzen. Neben den Seiten besitzt XWiki ein Datenmodell zur Speicherung von Klassen und Objekten innerhalb der Seitenstruktur.

XWiki bietet alle üblichen Gestaltungselemente einer modernen Webseite mit formatiertem Text, Links, der Einbindung von Bildern, Videos oder beliebigen Dateien. Fortgeschrittene Gestaltungselemente wie responsives Design lassen sich mit dem Bootstrap-Framework als eingebundene HTML-Quelltexte oder (besser) in XWikieigener Syntax [4,5] realisieren. Nicht alle Möglichkeiten der XWiki-Syntax sind jedoch dokumentiert, weswegen es sich lohnt, auch im XWiki-Forum (https://forum.xwiki.org) nach Hilfestellung und Anregungen zu suchen.

Einfache Demo-Instanz

Die einfachste Möglichkeit für einen Test bietet eine lokale XWiki-Demo-Instanz, die man von xwiki.org als vorkonfiguriertes ZIP-Paket herunterladen kann [6]. Sie enthält bereits alle benötigten Komponenten, um die hier beschriebenen Schritte nachzuvollziehen.

Wichtige XWiki-Elemente

Für die ISMS-Implementierung bietet XWiki neben einer Versionierung von Editierungen eine Reihe von Möglichkeiten, von denen das hier beschriebene Szenario umfangreich Gebrauch macht. Dazu gehören das Tagging von Seiten mit Stichworten, der App-Within-Minutes-Wizard, der Objekt- und Klasseneditor sowie die Verwendung einfacher Skripte und ihre Einbindung. Im Folgenden werden diese Möglichkeiten jeweils anhand konkreter Anwendungsfälle einer ISMS-Implementierung vorgestellt. Die Beispiele greifen auf die im ersten Teil dieses Artikels detailliert beschriebene Vorgehensweise zurück [1].

Getaggte Seiten

XWiki bietet die Möglichkeit, Seiten mit einem oder mehreren Tags zu versehen [9]. Auf diese Weise lassen sich Inhalte einem bestimmten Thema zuordnen, ohne dafür den hierarchischen Seitenaufbau zu verwenden. Zum Beispiel können alle Inhalte, die auf die Erfüllung von Control A.5.1 einzahlen, mit dem Tag control-5-1 markiert und so gruppiert werden (vgl. Abb. 1).

Abbildung 1: Inhalte können mithilfe von Tags einfach einem bestimmten Thema im ISMS zugeordnet werden.

XWiki bietet die Möglichkeit, Seiten mit einem oder mehreren Tags zu versehen [9]. Auf diese Weise lassen sich Inhalte einem bestimmten Thema zuordnen, ohne dafür den hierarchischen Seitenaufbau zu verwenden. Zum Beispiel können alle Inhalte, die auf die Erfüllung von Control A.5.1 einzahlen, mit dem Tag control-5-1 markiert und so gruppiert werden (vgl. Abb. 1).

Abbildung 2: Mit Tags generierte Link-Liste in einer ISMS-Dokumentation mit XWiki

In den im ersten Teil dieses Artikels vorgestellten Mappings können diese Inhalte dann mithilfe eines einfachen Velocity-Scripts [7] für jedes Control als dynamische Link-Liste eingebunden werden (Abb. 2):

#set ($references =
$xwiki.tag.getDocumentsWithTag(‚control-5-1‘))
#foreach($reference in $references)
#set ($document =
$xwiki.getDocument($reference))
#set ($label = $document.getTitle())
[[$label>>$reference]]
#end

Ein vollständiges Mapping für die 30 Überschriften der Clauses und die 93 Controls der ISO/IEC 27001 besteht dann aus 123 Script-Snippets. Auf diese Weise lassen sich durch getaggte Inhalte einfach und schnell beliebige tabellarische Mappings erstellen, die als übersichtlicher Nachweis der Erfüllung von Compliance-Vorgaben dienen.

App Within Minutes (AWM)

Abbildung 3: Definition von Feldern im AWM-Wizard

XWiki bietet mit dem integrierten Wizard App Within Minutes (AWM) eine Möglichkeit zum schnellen Aufbau einer Datenstruktur, die im Ergebnis als sogenannte Live Table dargestellt wird [8]. In vier Schritten legt man zunächst fest, wie die Anwendung heißen und wo sie gespeichert werden soll, bevor die Definition der Felder der Live Table folgt. Hierfür stehen in der Felder-Palette 12 Möglichkeiten zur Auswahl – vom einfachen Zahlenfeld bis zur fortgeschrittenen Datenabfrage. Abbildung 3 zeigt die beispielhafte Konfiguration eines Auswahlfelds, das den Implementierungsstatus für ein Control erfasst.

Im dritten Schritt werden ein Icon für die App und der Speicherort der Daten festgelegt, die XWiki jeweils als Objekte einer zugehörigen Seite in der Seiten-Hierarchie ablegt und anzeigt.

Abbildung 4: Seitenstruktur einer AWM-App

Am Ende konfiguriert man schließlich die Seite, auf der die Live Table der AWM-App dargestellt wird. Hierbei geht es vor allem um Auswahl und Darstellung der zuvor festgelegten Felder der Datenstruktur sowie die Gestaltung eines Seiten Headers. Nach dem Abschluss des Wizards wird die AWM-App in Unterseiten dieser Seite gespeichert. (siehe Abb. 4)

Die unterhalb der Seite CODE abgelegten Seiten enthalten dabei die Klassendefinition, einen Vorlagenprovider (Ergänzung des Dialogs zum Erstellen einer neuen Seite), das App-Sheet (Darstellung der Felder innerhalb einer neuen Seite), das App Template (vorgegebener Inhalt der Felder) und eine Lokalisierungsdatei zur Übersetzung von Feldbezeichnern.

Live Tables beginnen standardmäßig mit einer Tag-Cloud und können so nach den Tags der Seiten gefiltert werden. Wer für neue Einträge der AWM-App von Beginn an ein festgelegtes Tag vergeben möchte, muss hierfür das App-Template mit einem Tag versehen.

Der AWM-Wizard bietet allerdings in allen Schritten nur rudimentäre Gestaltungs- und Anpassungsmöglichkeiten. Bereits die vorgegebene Sortierreihenfolge der Tabelle muss manuell angepasst werden. Im XWiki-Quellcode der Live Table ist das jedoch schnell machbar:

##code
#set ($options = {

‚defaultOrder‘: ‚desc‘
})

Die Darstellung der Tag-Cloud im Tabellenkopf und die Anzahl der angezeigten Einträge lässt sich ebenfalls schnell anpassen:

##code
#set ($options = {

‚tagCloud‘: false,
‚rowCount‘: 100,

})

Diese und andere manuelle Änderungen gehen jedoch bei einem erneuten Durchlauf des AWM-Wizards verloren – das gilt besonders auch für Anpassungen am App-Sheet und im App-Template. Hier liefert eine angemessene Dokumentation der App oder die Seitenhistorie Aufschluss über die manuell durchzuführenden Modifikationen. Darüber hinaus bietet der Wizard im zweiten Schritt die Möglichkeit, die Aktualisierung von App-Sheet und App-Template manuell zu deaktivieren (siehe Abb. 5). In der Beratungspraxis des Autors wurden die folgenden Aspekte eines ISMS bereits erfolgreich in AWM-Apps realisiert:

  • Offene-Punkte-Listen
  • FAQ
  • Risikoinventare
  • Incident-Handling-App
  • Policy-Review-Planung
  • Audit-Programme
  • Auditplan-Questionaires
  • Security-Qualification-Requests
  • ISMS-Change-Requests
  • Information-Asset-Management
  • Control-Implementation
  • Security-Quick-Checks
  • On-Cross-Off-Boarding-App
Abbildung 5: Im AWM-Wizard lässt sich die Aktualisierung einzelner Code-Unterseiten manuell deaktivieren.

Teilweise waren hierfür keine manuellen Anpassungen nach Durchlaufen des Wizards nötig. Im Fall der realisierten Risikoinventare und der Audit-Programme wurden hingegen beispielsweise umfassende Änderungen – besonders am App-Sheet – vorgenommen, um den zugrunde liegenden Prozess visuell und durch Hilfetexte zu unterstützen.

Der App-Within-Minutes-Wizard ermöglicht es kleineren und mittleren Organisationen, im ISMS komplett oder teilweise auf ein Ticket-System zu verzichten, denn viele Funktionen eines Ticket-Systems lassen sich in einer AWM-App realisieren. Das ist besonders für kleinere Aspekte wie eine einfache Liste offener Punkte sinnvoll, kann aber auch für komplexere Anwendungen in Betracht gezogen werden.

Objekte- und Klasseneditor

Abbildung 6: Zugriff auf Klassen und Objekte einer XWiki-Seite

Das vom AWM-Wizard genutzte Datenmodell von XWiki bietet deutlich mehr Konfigurationsund Nutzungsmöglichkeiten, als der Wizard es vermuten lässt [10]. Auf diese kann man bei entsprechenden Rechten über den Dialog zum Bearbeiten einer Seite zugreifen (siehe Abb. 6). Darüber hinaus stehen in XWiki zahlreiche vorkonfigurierte Klassen zu Verfügung, die im ISMS wertvoll sein können. Im Klasseneditor können auch AWM-Klassen eingesehen und gegebenenfalls manuell angepasst werden.

Abbildung 7: Beispiel einer Vertraulichkeitskennzeichnung über ein UIExtensionClass-Objekt (z. B. an der Extension-Point-ID org.xwiki.platform.template.content.header.after – Parameternicht abgebildet)

Beispielhaft soll hier die XWiki.UIExtensionClass [11] herausgehoben werden, mit der sich per Default an ausgewählten Stellen Einblendungen vorsehen lassen. Dies kann etwa für Vertraulichkeitskennzeichnungen, Gefahrenhinweise oder Störungsmeldungen hilfreich sein, die im gesamten XWiki angezeigt werden sollen (vgl. Abb. 7).

Grafische Auswertung der AWM-Daten

Abbildung 8: AWM-Daten können zur Realisierung von Dashboards skriptbasiert (z. B. mittels XWQL-Abfrage) abgefragt und grafisch dargestellt werden.

Die in den AWM-Apps enthaltenen Daten können in XWiki per Application-Programming-Interface (API) abgefragt [12] und als Variablenabruf direkt im Content oder beispielsweise mithilfe des Chart- Makros [13] visuell aufbereitet angezeigt werden (Abb. 8).

Bei der Auswahl der verwendeten Skript-Sprache sollte man dem Least-Privilege-Prinzip folgen – vor allem wenn Content und Code in derselben Seite gespeichert werden. Im Rechtekonzept von XWiki lassen sich solche Abfragen mit Velocity- Skripten realisieren, die weniger Rechte als etwa Groovy oder Java benötigen und aufgrund des geringen Funktionsumfangs bei einem Angriff deutlich weniger Spielraum bieten.

AWM-Apps sind einfach zu erstellen und die mit ihnen erfassten Daten können leicht für Auswertungen genutzt werden. In großen Implementierungen kann man jedoch auch an Performance-Grenzen stoßen.

Snippets

Auch bei der Verwendung einer Skriptsprache mit geringem Funktionsumfang sollten Code und Content möglichst getrennt gespeichert werden – vor allem falls Personen die Seiten bearbeiten, die nicht zum Kreis des Admin-Personals gehören.

Zur Trennung von Content und Code können Unterseiten angelegt werden, die den Code enthalten. Diese Seiten werden im Rahmen dieses Artikels als Snippets bezeichnet und können mit dem display-Makro auf einer oder mehreren anderen Seiten eingebunden werden. Für Snippets lassen sich die Schreibrechte dann im Rollen- und Rechtekonzept von XWiki gezielt auf Personen oder Gruppen beschränken, die entsprechende Rechte besitzen.

Zum Speichern von Seiten mit Velocity-Skripten benötigt man die Berechtigung Script oder Admin – hat man diese nicht, kann man Seiten mit Velocity Skripten zwar trotzdem ändern und abspeichern, aber das Skript wird erst wieder ausgeführt, wenn die Seite mit einem Konto mit entsprechenden Rechten gespeichert wird. Dies ist immer dann der Fall, wenn es Konten oder Gruppen gibt, die explizit Schreibrechte für eine Seite benötigen, aber keine Skript-Rechte haben sollen. Wenn Seiten mit Konten ohne Skript-Rechte bearbeitet werden sollen, kann man die Skripte auslagern und mit dem include-Makro auf der übergeordneten Seite einbinden.

Ob man für ausgegliederte Skripte restriktivere Rechte festlegt, kommt darauf an, wie groß und wie vertrauenswürdig der Personenkreis ist, der die Seite sehen und bearbeiten soll. Dies ist im Fall einer konkreten Implementierung für die jeweilige Organisation individuell zu prüfen und gegebenenfalls anzupassen.

Was zunächst unproblematisch klingt, spielt in einem realen ISMS keine unbedeutende Rolle: Für das oben genannte Mapping zur ISO/IEC 27001 müssten über hundert Snippets angelegt und mit passenden Rechten ausgestattet werden, um Code und Content zu trennen. Hierdurch entsteht mehr als hoher Pflegeaufwand: Darüber hinaus muss XWiki zur Darstellung der Seite dann nicht nur über hundert Datenbankabfragen starten, sondern hierbei jeweils alle Snippets aufrufen, was die Ladezeiten weiter verschlechtern würde. Hier gilt es abzuwägen und den Content im ISMS – wie bereits bei den AWM-Apps – insgesamt klug und gemäß der eigenen Performance- Anforderungen zu gliedern.

Da sich der Inhalt einer Seite – wie bei einem Mapping – nur sehr selten ändert (nämlich bei einer Anpassung der regulatorischen Grundlage), kann die Bearbeitung in den meisten Anwendungsfällen auf Personen mit Script- oder Adminrechten beschränkt werden, sodass eine Trennung von Code und Content unnötig ist.

Seitenstruktur des ISMS

Im ersten Teil dieses Beitrags wurden verschiedene Frameworks und Compliance-Mappings als zentrale Einstiegspunkte in das ISMS und als dauerhafte und flexible Informationsquelle zu den Anforderungen der ISO/ IEC 27001 vorgestellt. Ausgehend von dieser Gliederung beginnt der Aufbau einer ISMS Dokumentation in XWiki mit der Erstellung von Unterseiten für Frameworks und Mappings, die das ISMS in thematische Blöcke gliedern. Sie leiten sich direkt aus den Anforderungen ab, die die ISO/IEC 27001 an das ISMS hat und sollten den Kontext der eigenen Organisation angemessen berücksichtigen.

Das gilt besonders, falls komplexere Berechtigungsstrukturen realisiert werden sollen. Das ist mit XWiki nicht immer leicht, da die Vergabe und sogar die Anzeige von Berechtigungen auf Seiten und Unterseiten nicht ganz einfach zu durchschauen und noch schwerer zu pflegen sind. Hier sollte man unbedingt vor dem Aufbau der Seitenstruktur die Anforderungen der eigenen Organisation ausreichend berücksichtigen! Die Möglichkeiten des Berechtigungseditors der Open-Source-Version von XWiki sind nämlich wenig komfortabel.

Beispiel: Management-Review

Abbildung 9: Beispiel für die Seitenstruktur eines Frameworks mit Snippets im Bereich der Überwachung und Messung

Als Beispiel für den Aufbau einer entsprechenden Seitenstruktur soll im Folgenden das Management-Review gemäß Clause 9.3 dienen (vgl. Abb. 9). Dazu muss die Seitenstruktur naturgemäß zunächst alle Anforderungen der Clause und gegebenenfalls weitere regulatorische Anforderungen erfüllen, die ins Management-Review gehören.

Es soll zusätzlich eine Übersichtsseite „Aktuelles Management-Review“ geben, die alle Aspekte auf einer einzelnen Seite so darstellt, dass sie durch das Management-Review führt. Darüber hinaus soll diese Übersichtsseite derart gestaltet sein, dass für das Top-Management jederzeit der Status des ISMS per Laptop, Handy oder Tablet eingesehen werden kann. Das Top-Management soll innerhalb des Management-Review-Frameworks aller ebenengerecht aufbereiteten Informationen zum ISMS finden.

Gliederung

Die Gliederung besteht nach diesen Vorüberlegungen unter der Startseite des Frameworks aus den folgenden Seiten:

  • Anforderungen aus Clause 9.3 und gegebenenfalls
  • weiteren regulatorischen Anforderungen
  • Abschnitte gemäß 9.3.2 a bis g Entscheidungen und Aufträge
  • Hintergrundinformationen
  • Übersicht „Aktuelles Management-Review“
  • Dokumentation bisheriger Termine

Die Seite mit den Anforderungen kann sich ihren Content unter Verwendung des display-Makros aus den relevanten Mappings ziehen oder manuell angelegt und auf der Startseite eingeblendet werden. Danach werden jeweils Seiten für die geforderten Abschnitte gemäß 9.3.2 a bis g und für Entscheidungen und Aufträge des Top-Managements gemäß 9.3.3 angelegt. Eine Seitenstruktur für Hintergrundinformationen und zur Dokumentation bisheriger Termine runden den Seitenbaum ab.

Snippets

In den Abschnitten gemäß Clause 9.3.2 und 9.3.3 erfolgen umfangreiche skriptbasierte Auswertungen von Daten aus den vorhandenen AWM-Apps: Für die Seite „Überwachung und Messung“ könnten beispielsweise mehrere Diagramme zu wichtigen KPIs gewünscht sein. Für jedes Diagramm wird dazu jeweils ein Snippet mit dem benötigten Code angelegt und auf der übergeordneten Seite eingeblendet, die wiederum auf der Seite „Aktuelles Management-Review“ eingeblendet wird.

Diese Gliederung in drei Stufen

  • ermöglicht eine vollständige Übersichtsseite bei schlechterer Ladezeit,
  • eine Detailansicht zur Überwachung und Messung – bei besserer Ladezeit sowie
  • die Speicherung des Codes in Snippets (Trennung von den Content-Seiten).

In dem in Abbildung 9 dargestellten Beispiel wurden fünf Snippets im Abschnitt „Überwachung und Messung“ angelegt. Insgesamt besteht das Framework bei Erfüllung aller Anforderungen aus rund 40 Seiten, wobei die „Offene-Punkte- Liste“ (OPL) als AWM-App realisiert wurde. Diese neutrale Beispiel-Implementierung greift dabei auf fünf weitere AWM-Apps innerhalb der gesamten Dokumentation zu.

Tagging der Seiten für die Mappings

In der Seitenstruktur werden schließlich für die drei Absätze von Clause 9.3 die Tags clause-9-3-1, clause-9-3-2 sowie clause-9-3-3 vergeben, falls die entsprechenden Fundstellen im Mapping zu den Anforderungen der ISO/IEC 27001 an der passenden Stelle als Nachweis auftauchen sollen.

Externe Audit-Teams können sich so anhand des Mappings bereits in einem Stage-1-Audit intensiv einarbeiten und alles finden, was auch in Stage 2 vorgestellt und besprochen werden soll.

Responsives Design

Zur Realisierung eines responsiven Web-Layouts für mobile Endgeräte werden alle Inhalte in Absätzen und Tabellen unter Anwendung des Raster-Systems des Bootstrap-Frameworks [14] optimiert.

Abschätzung des Gesamtumfangs

Auf dem hier gezeigten Weg lässt sich eine vollständige ISMSDokumentation in XWiki ohne Rückgriff auf weitere externe Dokumentationsquellen oder Ticket-Systeme anlegen. In einer Testumgebung des Autors besteht eine Musterinstallation aktuell aus etwas mehr als 800 Seiten, rund 30 Apps und Tools sowie 10 Vorlagenprovidern:

Rund 120 Seiten kapseln Code oder wiederholt verwendeten Content in Snippets. Etwa 140 Seiten entfallen auf das Policy-Framework und 47 Seiten enthalten in einer AWM-App Risiko-Assessments für die „Elementaren Gefährdungen“ gemäß BSI IT-Grundschutz-Kompendium. Rund 40 Seiten enthalten Beispiele. Darüber hinaus umfassen die Seiten der Musterinstallation mindestens 2000 manuell angelegte Links (ohne die Links aus dynamisch angelegten Link-Listen).

Während der Implementierungsphase in einer konkreten Organisation fallen durchaus einige Seiten weg (etwa Beispiele oder nicht benötigte Apps) und einige kommen hinzu (konkrete Risiken, offene Punkte oder konkrete Incidents). Für die meisten erforderlichen Dokumente (z. B. Policies und Guidelines) sollten in einer Musterinstallation aber bereits Musterseiten vorliegen. In einer konkreten Organisation in kleinen bis mittleren Organisationen besteht eine nach diesem Muster angelegte ISMS-Dokumentation am Ende der Implementierungsphase erwartungsgemäß aus etwa 1000 Seiten und 3000 Verlinkungen.

Diese Komplexität scheint auf den ersten Blick sehr umfangreich. Sie steht jedoch in einem angemessenen Verhältnis zur Komplexität der in [2] ermittelten etwa 800 Einzelanforderungen der ISO/ IEC 27001:2013, die in der dort durchgeführten Modellrechnung für ein beispielhaftes ISMS rund 2000 umzusetzende Einzelpunkte ohne Personalbezug ergeben hatte.

Fazit und Ausblick

ISMS-Implementierungen mit nicht enden wollenden Tabellen und unübersichtlichen Ordnerstrukturen sind heutzutage eine häufig anzutreffende Realität. Vorhandene Tools liefern Hilfestellungen, legen aber auch eine konkrete Vorgehensweise fest.

Die hier vorgestellte ISMSImplementierung mittels der 2nd-Generation-Wiki-Software XWiki ist demgegenüber flexibel und kann, wie in Teil eins dieses Artikels erläutert [1], mit einem Satz auf Seite eins beginnen und sukzessive aufgebaut und an die eigenen Bedürfnisse angepasst werden.

Gerade die vorhandenen Möglichkeiten zur Strukturierung von Content und Daten in XWiki ermöglichen es, die Komplexität eines ISMS zu beherrschen und nicht zuletzt durch Links und dynamische Inhalte stets aktuell zu halten. Content bleibt tatsächlich auffindbar, wenn beispielsweise in einem Audit danach gefragt wird.

Die intensive Nutzung des Wissensmanagements im ISMS mit einer Software wie XWiki kann Vorbild und Enabler für weitere Projekte und Management-Systeme sein. Der hier vorgestellte Ansatz lässt sich auf andere CMS oder Wikis übertragen, sofern gleiche oder ähnliche Tools, Skriptsprachen und Datenstrukturen zur Verfügung stehen.

Abbildung 10: Beispiel eines Tool-Dashboards für das ISMS-Team mit 12 Kennzahlen aus der Implementierungsphase eines ISMS

Neben den konkret aufgezeigten Möglichkeiten lassen sich nahezu beliebige Kennzahlen zur ISMS-Dokumentation skriptbasiert erzeugen. Auswertungen, die früher in einer Tabellenkalkulation aufwendig erstellt wurden und drei Tage später veraltet waren, bleiben so immer auf dem aktuellen Stand: Einmal als Snippet angelegt, lassen sie sich an verschiedenen Stellen der Dokumentation flexibel ein- und ausblenden und erleichtern die Arbeit im ISMS deutlich (vgl. Abb. 10).

Sebastian Klipper (sk@cyclesec.com) ist Managing Consultant und Geschäftsführer des Hamburger Beratungsunternehmens CycleSEC und Fachbuchautor bei Springer Vieweg und DIN Media.

 

Literatur

[1] Sebastian Klipper, Lars Albert, Louisa Frick, Alles beginnt mit einem Satz, Content-Management- und Ticket-Systeme als ISMS-Tools, <kes> 2023#5, S. 51

[2] Sebastian Klipper, Steffen Hessler, 27001 – Odyssee im Sprachraum, Wie linguistische Textanalyse bei Komplexitätsbewertung und Verständnis der ISO/IEC 27001 hilft, <kes> 2021#1, S. 10

[3] Komm.ONE, openDesk – Der Souveräne Arbeitsplatz / Knowledge Management, https://gitlab.opencode.de/bmi/opendesk/componentcode/knowledge-management, auf: Open CoDE, Open-Source-Code für die öffentliche Verwaltung, opencode.de

[4] XWiki.org Community, Front-end Resources, XWiki Documentation, Juni 2024, www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/FrontendResources/

[5] XWiki.org Community, XWiki Syntaxes, XWiki Documentation, März 2022, www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax

[6] XWiki.org Community, Download XWiki, Juli 2024, www.xwiki.org/xwiki/bin/view/Download

[7] XWiki.org Community, Display pages with a specific tag, XWiki snippets, März 2021, https://snippets.xwiki.org/xwiki/bin/view/Extension/Display%20pages%20with%20a%20specific%20tag/

[8] XWiki.org Community, App Within Minutes Application, XWiki extensions, Juli 2024, https://extensions.xwiki.org/xwiki/bin/view/Extension/App%20Within%20Minutes%20Application

[9] XWiki.org Community, Tag Application, XWiki extensions, Juli 2024, https://extensions.xwiki.org/xwiki/bin/view/Extension/Tag%20Application

[10] XWiki.org Community, XClass Application, XWiki extensions, Juli 2024, https://extensions.xwiki.org/xwiki/bin/view/Extension/XClass%20Application, abgerufen am 19.05.2024

[11] XWiki.org Community, Extension Point Tutorial, XWiki Documentation, Oktober 2023, www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/UIXTutorial/, abgerufen am 19.05.2024

[12] XWiki.org Community, Query API, XWiki extensions, Juli 2024, https://extensions.xwiki.org/xwiki/bin/view/Extension/Query%20Module

[13] XWiki.org Community, Chart Macro, XWiki extensions, Juli 2024, https://extensions.xwiki.org/xwiki/bin/view/Extension/Chart%20Macro

[14] Bootstrap Community, Raster-System, auf: Bootstrap Framework mit HTML, CSS und JS, undatiert, https://holdirbootstrap.de/css/#grid

Diesen Beitrag teilen: