Konstantin Weber Atlassian Jira Software ist bekannt als unverzichtbares Development Tool für agile Teams in der Softwareentwicklung, welches neue Arbeitsorganisationen wie SCRUM und Kanban abbilden kann. Das neu getaufte Jira Service Management kannte man schon unter „Jira Service Desk“ als unkompliziertes Ticketsystem zur Aufnahme von Incidents und Service Requests, während sich Jira Core schon immer auf das Projektmanagement abseits der Softwareentwicklung fokussiert hat.
„Aber Jira als Risikomanagementsystem?“
Ja! Um die jährliche Risikoanalyse von Assets eines Betreibers kritischer Infrastruktur zu modernisieren und endlich das aufwändige Handling mit einer Vielzahl an Excel-Tabellen abzulösen, wurde in der schon bestehenden Atlassian Jira-Instanz ein neues Projekt entwickelt, welches den Anforderungen mit Funktionalitäten zur Zeitverfolgung, automatisierter Zuweisung von Aufgaben und Referenzieren der aus den jeweiligen Risiken abgeleiteten Maßnahmen gerecht wird. Ergebnis war eine Erneuerung der Vorgehensweise hin zu einer nachverfolgbaren, für den Risikomanager transparenteren und für die Zukunft vergleichbaren Risikoanalyse aller Assets, welche in Reports und Dashboards übersichtlich darstellbar gemacht werden kann. Funktionaleres Filtern von Szenarien, Assets und daraus resultierenden Risiken mit Referenz zu daraus abgeleiteten Maßnahmen gehört nun ebenso zum Funktionsumfang wie das Präsentieren der Effektivität dieser Maßnahmen in einer Risikomatrix.
„Wie macht Jira das?“
Im Prinzip erstellt Jira mit jedem Ticket oder Issue einen neuen kleinen Datensatz, der sich an die konfigurierten Gesetzmäßigkeiten des Projekts hält, also Einstellungen hinsichtlich der Bildschirmmasken, Workflows, Feldkonfigurationen, Berechtigungen und so weiter. Das Berechtigungsschema, Workflow-Conditions und das Vorgangssicherheitsschema des Projektes bedienen hier besonders die Metapher der Gesetzmäßigkeiten, da sie regeln, welcher User was genau tun, ausführen oder sehen darf. Diese wurden so konfiguriert, dass die Asset-Owner nur Assets in ihrer Zuständigkeit sehen können und nur handeln dürfen, wenn sie dazu aufgefordert wurden. Eine solche Aufforderung ist beispielsweise die vom Projektleiter, respektive Risikomanager, angestoßene Business Impact Analysis, bei welcher die Asset-Owner eine Einschätzung über den Schweregrad der Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit abgeben müssen. Die zuständigen Asset-Owner werden als Bearbeiter ihrer Assets eingetragen und können dann die BI-Analyse durchführen. Der Risikomanager kann unter anderem auch an dieser Stelle eine Fälligkeitsfrist dafür einstellen.
Nach abgegebener Analyse gehen die Assets durch eine Freigabe und die Risikoanalyse kann starten. Die einzupflegenden BI-Werte ergeben sich durch die Beschaffenheit und Verletzlichkeit der verschiedenen Assets. Die schon implementierten Maßnahmen zur Minderung dieser Auswirkungen werden in einem zweiten, bestenfalls niedrigeren Wert für jede der drei Betrachtungen festgehalten. Jegliche Wertänderungen werden von Jira registriert und in der Historie der einzelnen Datensätze mit Datum und ausführendem User gespeichert. Eine solche Nachvollziehbarkeit und Transparenz war schon immer eine Stärke Jiras.
„Okay, langsam. Es gibt also Assets und Szenarien und daraus ergeben sich Risiken?“
Richtig! Es gibt in dem Projekt Risikomanagement eigene Vorgangstypen für Assets, Szenarien, Risiken und Behandlungsmaßnahmen, welche aber eher als Vorschläge zur Mitigation gesehen werden müssen. Risiken entstehen durch das mögliche Eintreten von vordefinierten Szenarien aus dem Sicherheitskatalog, welche die Vertraulichkeit, Integrität oder Verfügbarkeit von Assets beeinträchtigen könnten. Behandlungsvorschläge können über den Workflow außerdem in konkrete und umzusetzende Maßnahmen verwandelt werden, welche schon vor dem Aufbau des Risikomanagements in einem separaten Jira-Projekt verwaltet wurden.
„Wie funktioniert die jährliche Risikobetrachtung jetzt genau?“
Die Risikoanalyse liegt zum Großteil in der Verantwortung der Asset-Owner. Wird nun ein neues Szenario identifiziert, welches ein Asset in irgendeiner Form bedroht, wird ein Asset-Owner den Datensatz dieses Szenarios über den Workflow mit dem des Assets verknüpfen. Jira erstellt dann automatisch einen neuen Datensatz unter dem Typ Risiko und nimmt Informationen aus Szenario und Asset mit auf. Zusammen mit der Verknüpfung wird ein Asset-Owner auch gleich gebeten, eine Einschätzung der Eintrittswahrscheinlichkeiten zu machen.
Die so aggregierten Werte zu den verschiedenen Business Impacts vor und nach der Implementierung von Maßnahmen werden in dem Risiko-Datensatz mit den Eintrittswahrscheinlichkeiten verrechnet und bilden so eine Risikokennzahl, wie das auch schon in den Excel-Tabellen gemacht wurde. In der Jira-Risikomatrix kann man so die Verschiebung von einer hohen Risikodichte im gelben und roten Bereich hin zu einer grünen Risikosituation durch die Implementierung von geeigneten Maßnahmen sehen.
„Und das kann Jira einfach so?“
Leider nein, aber mit der Unterstützung durch Plug-Ins aus dem Atlassian Marketplace konnte das jährliche Risikomanagement in Jira abgebildet werden. Während die JSU Automation Suite for Jira Workflows von Beecom (Appfire) vor allem das Kopieren von Feldwerten und das Erstellen von Risiken bei der Verknüpfung von Asset und Szenario ermöglicht, ist das Risk Register Plug-In von ProjectBalm für die Darstellung der Risikomatrix und weitere Funktionen verantwortlich. Abgerundet wird die Konfiguration durch den allseits beliebten ScriptRunner for Jira von Adaptavist, mit welchem über zehn Groovy-Skripte in Jira eingebunden wurden, um etwa Eingaben zu überprüfen oder Feldwerte zusammenzurechnen, da Jira letzteres nicht nativ beherrscht. Zusätzlich wurde mit dem Ziel die Benutzerfreundlichkeit und Fehleranfälligkeit zu verringern, einige Anpassungen in der UI vorgenommen und so überflüssige Buttons und Funktionen ausgeblendet.
„Ist das nicht Zweckentfremdung?“
Ja und nein. Das bei dem Betreiber kritischer Infrastruktur implementierte Risikomanagementsystem ist zwar vielleicht eine untypische Verwendung von Jira, aber doch werden Jira-übliche Funktionen ausgiebig genutzt. Es zeigt einmal mehr, was mit einem kundenspezifischen Customizing von Jira möglich gemacht werden kann! Für den Kunden hat das den Vorteil, dass nun die jährliche Risikoanalyse in einem Tool abgebildet werden kann, welches sowieso schon im Einsatz war. Jeder Mitarbeiter, von den Baustellen bis in das Back-Office, hatte auch vorher schon Zugriff auf Jira und kann dort nun komfortabler an der Risikobetrachtung teilhaben. Zusätzlich erleichtert diese Lösung viele Arbeiten des Risikomanagers, etwa weil nicht mehr mit unzähligen Excel-Tabellen gearbeitet werden muss, die Fälligkeitsfristen das ständige Nachfragen überflüssig machen und eine Nachvollziehbarkeit herrscht, die es in Excel-Tabellen nie gegeben hat.
