Agiles Sicherheits-Risikomanagement in SAFe integrieren
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.
