Autor: m.urban 4. November 2019

IT-Sicherheits-Management nutzt Risikomanagement um den Einbau von Sicherheitsmaßnahmen rechtfertigen zu können. In großen Unternehmen sind die Prozesse hierzu weitestgehend etabliert und standardisiert. Doch wie können Risiko-Assessments für kleinere Gruppen und überschaubare Teams integriert werden? Ist es überhaupt möglich Risiken in wesentlich kürzerer Zeit zu erkennen, bewerten und dann zu behandeln? Wie agiles Sicherheits-Risikomanagement zu einem stabilen Produkt führt, auch wenn es von Teams von ca. 350 Mitarbeiter-/innen entwickelt wird, beschreibt dieser Artikel.

Dieser Artikel ist eine Ergänzung zu „Sicherheitsstandards in DevOps integrieren“ aus 2016. Zu der Zeit hatte ich noch keinen praktischen Einblick in Agile Softwareentwicklung. Mein Horizont war beschränkt auf den DevOps Ansatz, für den ich bei Kunden hilfreiche Methoden und Prozesse integriert habe, um das Shift-Left Prinzip für Sicherheitsmaßnahmen umzusetzen sowie Maßnahmen für ein  Verbesserungs-Stufen-System (Maturity-Prinzip) definiert hatte.

In diversen weitere Projekte beschäftigte ich mich mit der Einführung von IT-Sicherheit in Scrum-Teams bzw. der Erweiterung um IT-Sicherheits-Management in agilen Projekten. Anlass zur Erstellung dieses Artikels sah ich dann als ich mit einem Programm in Berührung kam, welches SAFe nutzt. Die Vorgehensweisen dort erlebte ich als echten Clash zwischen einerseits klassischem Sicherheits-Management mit umfassenden Anforderungskatalogen und andererseits dem agilen Arbeitsmodell eines Teams von ca. 350 Mitarbeiter-/innen die eine komplexe Cloud-Plattform aufbauten.

SAFe und seine Sicherheits-Aspekte

Die Entwickler von SAFe haben sich natürlich Gedanken gemacht wie man IT-Sicherheits-Aspekte in diesem Modell berücksichtigt. Nachdem ich sowohl die Ideen in dem SAFe Modell geprüft hatte, als auch im laufenden Projekt mir die Umsetzung angesehen hatte, empfand ich das die SAFe Vorgaben weitestgehend aufgesetzt worden waren. Dazu zählt das Einrichten eines Sicherheits-Architekten, der gemeinsam mit den anderen Architekten Patterns entwickelte, die von Entwicklern und dem Betrieb auf- und eingebaut wurden. Weiterhin wurden sogenannte Guilden etabliert die sich um verteilte Spezialthemen gekümmert hatten. Diese Interessengruppen fanden sich zusammen zu Themen wie Testmanagement, DevOps, Frontends, API und auch „Security“. Die Security Guilde traf sich alle zwei Wochen und es sollte aus jedem Entwicklerteam ein Security Experte bzw. Privacy Experte dazu kommen. Dieses Guilde Konzept findet man auch bei anderen Unternehmen wie z.B. Spotify. Scheint also ein durchaus verbreiteter Ansatz zu sein.

Zusätzlich wurde ein Sicherheits-Manager auf das gesamte Programm gesetzt, welcher sich um die Durchsetzung der Konzern-Sicherheits-Anforderungen kümmern musste.

Ungünstig umgesetzt wurde dabei folgendes:
– Der Sicherheits-Architekt wurde aus den Reihen der System-Architekten besetzt und arbeitete primär an Kommunikations-Patterns.
– Die Security-Guilde-Calls wurden zum Beantworten der Konzern-Sicherheits-Anforderungen genutzt, wobei sich alle diejenigen unterbeschäftigt sahen, deren Team bzw. Entwicklungsprodukt gerade nicht untersucht wurde. Darurch wurde keine Implementierungs-Erfahrung zwischen den Sicherheits-Experten ausgetauscht.
– Der Sicherheits-Manager war reaktiv unterwegs und beseitigte Mängel nachdem sie bereits eingebaut wurden. Außerdem wurden Dinge adressiert die aus Konzernsicht hohe Priorität hatten, aus Projektsicht jedoch erst hätten später gelöst werden müssen.
– Der Fokus zum Einbau technischer Sicherheitsmaßnahmen beschränkte sich z.T. nur auf die Entwickler-Teams. Sie wurden mit Maßnahmen konfrontiert, die sie größtenteils nicht selber umsetzen konnten und auf die Betriebs-Umgebungen abgewälzt wurden.

Es musste also einerseits diese Umsetzung korrigiert als auch SAFe untersucht werden um einen verbesserten Sicherheits-Management-Ansatz einzubringen. Ziel war es  mit den Werkzeugen des agilen Projektmanagements und einer risikobasierten Priorisierung das gesamte Sicherheitsniveau des eigentlichen Cloud-Produktes anzuheben.

Sicherheits-Prinzipien als Basis

Ich besann mich auf Sicherheits-Prinzipien die ich im Laufe meiner Erfahrung in ganz unterschiedlichen Projekten gesammelt und immer weiter verfeinere. Diese Prinzipien sollten die Grundlage für die weiteren Maßnahmen sein die ich sowohl methodisch, als auch technologisch einführen musste. Im Grunde sind diese Mechanismen ganz einfach wenn man das erste Prinzip durch alle anderen hindurch zieht. Hierbei handelt es sich um das Prinzip „Defense in depth“ (1). Das bedeutet das man einen mehrschichtigen Ansatz wählt und mehrere verschieden wirkende Sicherheitsmechanismen kombiniert. Die anderen Prinzipien erweitern dieses erste und beschäftigen sich mit der „Klassifizierung aller Informationen“ (2), mit Ihrem „Life-Cycle“ (6) oder den „Zugriff auf diese Informationen“ (7). Insgesamt wende ich 8 Prinzipen an, die in diesem Fall mit folgenden wichtigen Elementen aus anderen IT-Security-Domänen kombiniert in einen agilen Ansatz überführen musste.

Klassische Security-Elemente

Security- und Risk-Management: Der Deming Zyklus ist vielen bekannt und wurde zentraler Bestandteil der ISO27001. Security-Management sieht insgesamt wie ein schwergewichtiger Prozess aus, insbesondere wenn man sich die Verbindungen zu anderen Prozessen anschaut (siehe auch IT Security Management ITIL Wiki Seiten). Es handelt sich um eine Organisationseinheit die ein dokumentiertes Informations-Sicherheits-Management-System betreiben muss, welche nach o.g. PDCA (Deming) Zyklus funktioniert und die Ziele einer Informations-Sicherheits-Richtlinie umsetzt. Der andere zentrale Bestandteil ist der Risiko-Assessment Prozess welcher zusätzlich Kriterien für Risikoakzeptanz aufstellen muss.
Beide Elemente müssen so angepasst werden, dass wesentliche Aufgaben hieraus auch in der agilen SAFe Umgebung funktionieren.

Change Mangagement: Änderungen an Produktion bedürfen einem geregelten Freigabemechanismus. Dieses wird in agilen DevOps Pipelines eher auf viele Verantwortlichkeiten verteilt – ist also kein Widerspruch und indirekt vorhanden.

Vulnerability Management: Verwundbarkeiten werden durch regelmäßigen Abgleich der installierten Versionen von (kommerziellen) Produkten in der Pipeline oder auch der Softwareentwicklung mit Verwundbarkeitsdatenbanken wie CVE (Common Vulnerabilities and Exposures) vom MITRE oder der NVD (U.S. National Vulnerability Database) vom NIST.

Incident Management: Das Störfallmanagement lässt sich eigentlich nicht neu erfinden oder anders aufbauen. Die in vielen Firmen vorhandenen Incident-Analysten müssen mit Sicherheits-Ereignissen versorgt werden, die von kritischen Infrastruktur-Komponenten erzeugt werden. In einem agilen Programm gilt es zusätzlich die erstellten Softwareelemente (Microservices) so zu erweitern, das sie bei potentiellen Fraud-Situationen Sicherheits-Ereignisse an die Incident-Analysten verschicken können.

Benutzer- und Berechtigungsmanagement: In vielen Organisation wird eine eigene Abteilung zum Identity- und Access-Team benannt. Hier wird sicher gestellt das Berechtungen nach bestimmter Zeit überprüft werden (Rezertifizierung) als auch das Rollen-Management aus der Betreiber-Verantwortung heraus geholt wird (Separation of Duties).

Sicherheits-Prinzipien und klassische Security-Elemente in SAFe integrieren

Die oben angesprochenen Sicherheits-Prinzipien lassen sich im Full SAFe Framework wie folgt verorten:
(1) Defense in depth ist eine Aufgabe für den Security-Architekten der Mitarbeiter-/in im Enterprise Architekten-Teams ist. Er kümmert sich um die folgerichtige Einteilung von Sicherheits-Patterns und die Ebenen-Struktur je nach Maßnahmentyp.
(2) Informations-Klassifizierung erfolgt strategisch über Unternehmens-Richtlinien. Sie definieren wie Informationen einzuteilen sind und bestimmen ihre Vertraulichkeitsklasse bzw. welche Informationen unter Datenschutz fallen.
(7) Die Methoden des Zugriffs auf Informationen (durch Trennung von Authentisierung und Autorisierung) wird vom Sicherhsits-Architekten im Enterprise-Architekten Team diskutiert und Rollenberechtigungen werden durch den System-Architekt geschnitten. Zur Einhaltung des Prinzips von „Separation of duties“ wird das Rollen-Management (also das Zuweisen von Usern oder System zu Rollen) jemand anderen zugewiesen – hier im Beispiel dem Produkt-Manager.

Fast alle Berater lernen das Konzept von People – Process – Technology (PPT) kennen, einer Methode zur Prozessverbesserung in einer Organisation. Zuerst benannt wurde dieses Konzept im Jahr 1964 von Harold Leavitt einem Management Psychologen. Wenn wir die Elemente „People“ und „Process“ betrachten, dann können wir im „Full SAFe“ Modell die oben genannten klassischen Security-Elemente an folgenden Stellen verorten.

Der Security-Manager hat die Aufgabe die Unternehmens-Sicherheits-Anforderungen in das Programm hinein zu bringen und nimmt daher eine Strategische Rolle in SAFe ein. Er hat Einfluss auf das Backlog und überwacht die EPICs auf Sicherheits-Anforderungen bzw. baut diese zu Beginn einer jeden PI (Programm Increment) Planung in das Backlog mit ein.

Der Change-Manager wird in SAFe durch den Product Owner während der System-Demos realisiert. Er ist Verantwortlich für das fehlerlose Zusammenspiel der entwickelten neuen Features. Er greift dabei auf das Test-Team zurück welches die Funktionalität vor Produktivsetzung testet und sicher stellt.

Einen Vulnerability-Manager verortet man im einerseits im DevOps Team weil hier die notwendigen Infrastruktur-Elemente betrieben werden. Andererseits sind die Entwickler-Teams für die Aktualität ihrer  Werkzeuge und Libraries verantwortlich. Der Betrieb (Operator) bedient sich automatischer Werkzeuge die einen Abgleich mit Verwundbarkeitsdatenbanken durchführen. Durch Security-Scanner  (entspricht dem „Technology“ aus PPT) gefundene Schwachstellen in Software oder Anwendungen werden mit dem Security-Manager abgesprochen und durch Patching oder Bugfixing+Rebuild behoben.

Das Incident-Management konnte in meinem Fall auf ein vorhandenes Team außerhalb des Programms übertragen werden.

Zum Aufbau eines Benutzer- und Berechtigungsmanagements erfolgt eine Aufteilung in einen Rollen-Administrator (schneidet Rollen und Berechtigungen) welcher durch den System-Architect (Teil vom RTE Team) besetzt wird, und einen Rollen-Manager (weist Systeme oder User den Rollen zu) welcher durch einen Produkt-Manager (Teil vom RTE Team) besetzt wird.

Agile Risk-Assessments werden durch eine initiale Vereinbarung von Risiko-Akzeptanzschwellen mit dem Business-Owner ermöglicht. Im weiteren werden in jeder Sprint-Planung Risk-Assessments durch Threat-Modelling im Entwickler-Team durchgeführt. Die Risiken werden dann an den Produkt-Manager gemeldet der die vom Business-Owner festgelegten Risiko-Akzeptanzschwellen anwendet. Damit ist der Produkt-Owner derjenige der IT-Risiken verstehen und behandeln muss. Vorausgesetzt ist ein Mapping von Business-Risiken in IT-Risiken, welches in einem Folge-Artikel besprochen wird.
Bei Bedarf, also wenn der Business-Owner das gemeldete Risiko nicht tragen möchte, muss der Produkt-Manager entsprechende Sicherheits-Maßnahmen mit dem Entwickler-Team erstellen im Backlog festhalten und je nach Risikohöhe in einem der nächsten Sprints umsetzen. Es spielt hierbei keine Rolle ob diese Maßnahmen als NFRs eingebracht werden, oder als Issue in das Backlog gehen.

Zusammenfassung

In diesem Artikel werden nicht alle Maßnahmen dargestellt die zur Verbesserung des Programms beigetragen haben. Doch die wichtigsten Veränderungen sind diese:
Der Business-Owner macht die Risikoakzeptanz-Vorgabe, die Produktmanager werden zu Risikomanagern, Entwickler werden zu Risiko-Analysten, Product-Owner nehmen in der Solution-Demo als Change-Manager die neuen Releases ab, das Dev-Ops Team sowie die Entwickler kümmern sich um das Schwachstellen-Mangement, die User-Verwaltung wird aufgeteilt zwischen dem System-Architekt und dem Product-Manager und die Unternehmens-Sicherheits-Anforderungen werden vom Security-Manager im Planungs-Inkrement-Meeting (oder Refinement-Meetings) als strategische Themen über die EPICS in das Produkt einbegracht.

Bewährt hat sich zudem (als Ergänzung zu den Shared Teams) die Einrichtung eines spezielles POC Teams, welches neue Lösungen testet (Proof of Concept) die später in die Produktion übernommen werden sollen.

In diesem Konzept erhalten die EPICs die allgemeinen Sicherheitsziele durch Erweiterung der Beschreibungen um Adjektive wie „vertraulich“, „verlässlich“ (für verfügbar), sowie „unverändert“ (für integer). Die User-Stories in den Sprints enthalten Sicherheits-Abnahme-Kriterien die im besten Fall über Testcases nachgewiesen werden können.