Yin und Yang sind sogenannte Gegensatzpaare. Gegensätze ziehen sich an. Sie ergänzen sich. Sie bedingen sich. Mal ist das Yin stärker, mal tritt das Yang in den Vordergrund. Der Schlüssel dabei ist ein langfristiges Gleichgewicht. Ist dieses etabliert verstärken sich die Paare und bilden ein perfektes Ganzes.
Gilt dieses Prinzip auch für das Paar Agilität und IT-Sicherheit - also für agile Vorgehensmodelle und Sicherheitsanforderungen in Produkt-, Software- und Infrastrukturprojekten?
Doch Moment – warum ist dieses Yin-Yang von Agilität und IT-Security überhaupt relevant? Dass agile Vorgehensmodelle in moderner Produkt- und Software-Entwicklung einen hohen Stellenwert haben, ist bekannt. Die Gründe sowie Vor- und Nachteile sind an vielen anderen Stellen vielfältig diskutiert. Auch die Sinnhaftigkeit von angemessen hoher IT-Sicherheit in Produkten und ihren Infrastrukturen wird nicht in Frage gestellt.
Jedoch: die Kombination von Agilität und IT-Sicherheit birgt, schlecht umgesetzt, die eigentliche Herausforderung. Die Erfahrungen in verschiedenen Projekten zeigt, dass am Ende die Agilität (oder einfach der Zeit- oder Kostendruck) gewinnt und verlangsamende, behindernde, übergestülpte Sicherheitsprozesse und Regeln sehr kreativ umgangen werden – wie das „Security-Gate“ eines Gehweges über den rutschigen, matschigen Pfad auf der Wiese.
Ist eben meistens schneller - zumindest solange es nicht regnet.
Dieser Artikel beschreibt konkrete Lösungsansätze zur angewandten IT-Sicherheit in agilen Projekten. Dabei fokussieren wir die Organisation und die methodischen, agilen Aspekte und streifen am Ende noch das Thema der Security-Automatisierung.
Dieser Ansatz kann verschiedene Namen haben: SecDevOps, Agile Security oder auch Secure Scrum. Ein wohlklingender Name hilft möglicherweise beim Zeichnen des mentalen Bildes, was gemeint sein könnte, aber am Ende muss eine Organisation selbst ihren eigenen, individuellen Weg zum "perfekten Ganzen" finden. Das Ergebnis kann verschiedenen Namen haben. Das eine universelle Rezept dazu gibt es nicht.
Was sind aber Zutaten, die wir bei erfolgreichen Implementierungen von Agile Security angetroffen haben und wie haben diese zusammengewirkt?
Wir haben hier drei Kernbereiche identifiziert, deren korrekte Umsetzung zum erfolgreichen Zusammenwirken von agiler Vorgehensweise und Sicherheit führt:
Diese drei Aspekte stellen wir nun im Detail vor und geben Hinweise hin zu Ihrem individuellen Gleichgewicht von Yin und Yang.
Wer trägt eigentlich bei Ihnen die Verantwortung, wenn im jüngst gelaunchten Onlineshop die vorgeschriebenen, heißgeliebten Abfragen zur Verwendung von Cookies datenschutztechnisch nicht korrekt umgesetzt sind und Ihre Unternehmung ein Bußgeld durch die Aufsichtsbehörden bekommt?
Ja, richtig, am Ende ist die Geschäftsführung haftbar, ist verantwortlich. Beziehen wir die Frage auf Ihre Unternehmens- oder Projektorganisation: Wer hätte da die verbrannten Kekse gebacken und bekäme den schlecht gelaunten Anruf von der Geschäftsführung? Vermutlich eine Rolle mit Vorsitz in der Produktentwicklung. Und das ist auch korrekt so, denn Datenschutz ist, eben schon von Gesetz wegen, beim Produktentwurf mitzudenken, mit zu berücksichtigen und als Anforderungen, im Agilen vielleicht in User Stories zu formulieren.
Leider passiert das aus verschiedenen Gründen (und die fehlende gesetzliche Anforderung ist nur einer davon) für die Themen der IT-Sicherheit oft nicht. Diese werden meist viel später im Entwicklungsprozess eingebracht – und dann noch problematischer – oft zentral in der IT für alle Produkte verantwortet.
Hier hinge das Yin-Yang der Agile Security erstmals schief - ist nicht in der Balance.
Dabei ist etwas, wie z. B. eine 2-Faktor-Authentifizierung genau genommen ein Produkt-Feature. Sie sollte sich in die Usability des Produktes "seamless" integrieren und einfach zu bedienen sein. Medienbrüche sind dabei zu vermeiden und designtechnisch soll sie hübsch anzuschauen sein.
Der "Produkt Owner" ist verantwortlich für die Sicherheit seines Produktes! Er denkt die Sicherheitsfunktionen von Anfang an mit und formuliert dieses zusammen mit weitergehenden Sicherheitsanforderungen in User Stories, wie jeden anderen Produktwunsch auch.
Das agile Entwicklungsteam, welches selbstverständlich interdisziplinär zusammengesetzt ist (vgl. "SecDevOps"), ist für die sichere Umsetzung und den sicheren Betrieb verantwortlich - doch wieder ist es der Product Owner, der dafür sorgt, dass die nötigen Rahmenbedingungen vorliegen (Priorität, Budget, etc.), damit das Team dieser Verantwortung auch nachkommen kann.
Am Ende ist es - zumindest indirekt - der "Product Owner", der im Fall der Fälle den Anruf der Geschäftsführung bekommen sollte.
Erwirke durchgehende Ende-zu-Ende Verantwortung für die Security eines Produktes!
Doch warum sollte das erste Prinzip der Agile Security diesen besagten Anruf besser verhindern können als die klassische Aufbauorganisation mit Verantwortungsteilung?
Die Antwort ist trivial: Weil eine Organisation, die auf durchgehende Ende-zu-Ende Verantwortung in der IT-Security ausgelegt ist, erfolgskritische Faktoren früher und konsequenter im Gesamtentwicklungsprozess berücksichtigt und damit ein Produkt nachweislich besser, sicherer und nutzbarer wird.
Da jede agile Organisation ihre eigene Interpretation von den verschiedenen agilen Frameworks lebt, gibt es nicht die eine richtige, für alle passende Methode. Daher geben wir hier drei Eckpfeiler mit, die Sie integrieren könnten, unabhängig des Frameworks. Zum einfacheren Verständnis halten wir uns dabei nahe an der Terminologie von Scrum. Die Aspekte sind jedoch auf andere agile Frameworks übertragbar.
Erstellen Sie ein Security-Epic!
Um trotz kurzer Sprints einen langfristigen Rahmen zum Thema Security einem Produkt zu geben, empfiehlt es sich auf Epic-Ebene allgemeine, übergreifenden Ziele und Anforderungen in einem dedizierten Epic zu formulieren. Hier können sich bspw. Themen wie die folgenden wiederfinden:
Das Security-Epic sollte also den groben Rahmen setzen und sich auf übergreifende Aspekte fokussieren – nicht auf Feature-Ebene Security beschreiben. Als Fixstern zur sicheren Navigation.
Integrieren Sie Sicherheit in die „Definition of Ready (DoR)“
Definition of Ready ist eine aus Scrum stammende Bezeichnung, die aber auf andere Methoden übertragbar ist. Hierbei ist DoR nicht mit Definition of Done (DoD) zu verwechseln. Wichtig ist, dass eine Anforderung, ein Feature, eine User Story, generell ein „Product Backlog Item“ erst dann als vollständig beschrieben gilt, wenn auch die Security-Aspekte betrachtet wurden und die sich aus der Betrachtung ergebenen Security-Anforderung ergänzt wurden. Wir könnten hier z. B. Jeremy Jarrells „INVESST in User Stories“ um ein S erweitern: Eine User Story sollte „Independent, Negotiable, Valuable, Estimable, Small, Secure and Testable“ sein.
In der Praxis hat es sich als sehr hilfreich erwiesen, wenn der Product Owner bereits während der Erstellung einer User Story ein „Security Sounding“ durchführt: In einer Session zwischen Product Owner und z. B. einem Security Architekt, wird noch möglichst untechnisch das neue Feature diskutiert und die sich ergebenden Aspekte bezüglich Security notiert oder gleich mit als Anforderung in der User Story ergänzt. Hierbei ist es wichtig, zunächst mental auf der Ebene von Funktionen aus Sicht des Anwenders zu bleiben und zu eruieren, ob die Funktion „sicher erdacht wurde“. Es geht noch nicht um konkrete, technische Implementierungen – ob Protokoll A oder B sicherer ist. Idealerweise werden genau hier gleich weitere Aspekte, wie z. B. „testable“, festgelegt: Wie lässt sich diese (neue) Security-Anforderung auch - im Idealfall automatisiert - testen?
Ist das „Security Sounding“ durchgeführt und dokumentiert, gilt die Story im Sinne der DoR und dem INVESST-Paradigma als „Secure“. Erst dann ist diese aus Sicht der Security "ready" und kann für die Umsetzung, z. B. in einem Sprint eingeplant werden.
Es ist selbsterklärend, dass sich analog zu den DoR die gefundenen Security Aspekte auch passend in der „Definition of Done“ wiederfinden. Insbesondere ist es deswegen wichtig, um im mentalen Bild des agilen Teams das Thema Sicherheit immer wieder erscheinen zu lassen und es „normal“ wird, auch diese Themen zu durchdenken.
Sprechen Sie im Sprint Review über Security
Der dritte Punkt zahlt mehr auf die Security Kultur in einem agilen Team ein - mit Wirkung nach innen und außen. Werden User Stories im Sprint Review vorgestellt, sollte beim Erstellen einer Liste der Dinge, die zu einer Story gezeigt oder erläutert werden, auch immer über Security nachgedacht werden. Gibt es erwähnenswerte Aspekte oder hat die User Story direkt Security-Anforderungen umgesetzt? Erwähnen Sie sie! Gerade im diversen Auditorium eines Sprint Review Meetings ist das wichtig, weil es den bewussten Umgang mit diesem wichtigen Thema fördert.
Wir durften beispielsweise Situationen in Projekten erleben, in denen sich Budget oder Aufwandsdiskussionen zu Security-Themen deutlich entspannter gestalteten, weil über längere Zeit Entscheidern (Business Ownern) in Sprint Reviews mehr oder weniger subtil die Security-Themen nähergebracht wurden.
Verankern Sie die Security individuell in der jeweiligen agilen Methode und sprechen Sie drüber!
Die Security muss in die Anforderungsartefakte der agilen Methodik natürlich eingebaut sein, und zwar auch in den Teil, der beim Product Owner liegt. Natürlich heißt das hier, dass sich nicht die Methode ändert, sondern sinnvoll ergänzt wird. Es reicht nicht, die DoD zu nutzen und „nur“ im Sprint-Planning" über eine technisch sichere Umsetzung zu sprechen.
Meine Tochter stellte neulich fest, dass je schneller sie auf dem Fahrrad unterwegs ist, umso sicherer – weniger wackelig - sei ihre Fahrt. Entgegen dem ersten Impuls und vielleicht etwas überraschend gilt das für agile Software- oder IT-Projekte prinzipiell auch!
In agilen Software-Projekten deployen wir heute teilweise mehrmals täglich in Produktionsumgebungen. Wir sind schnell unterwegs. Allerdings wird das Ganze leider nicht wie beim Fahrrad auf Grund der physikalischen Fliehkraft, automatisch immer stabiler – also sicherer.
Hohe Änderungsgeschwindigkeiten oder -häufigkeiten gepaart mit der allgemein gestiegenen Komplexität von IT-Systemen und Anwendungen sowie die Verknüpfung diverser eingebundener 3rd Party Frameworks und Services ergeben sich zunächst einmal mehr Risiken aus Sicht der IT-Sicherheit. Jedoch führen die Maßnahmen und Werkzeuge, die grundsätzlich notwendig sind, um überhaupt kontrolliert „so schnell fahren zu können“ direkt oder indirekt zu deutlich höherer Sicherheit und beherrschbaren Risiken, sofern korrekt umgesetzt.
Folgende zwei Punkte sind eine wichtige Basis, wenn es darum geht Geschwindigkeit und Komplexität aus Sicht IT-Sicherheit beherrschbar zu machen:
Wenn wir, erstmal unabhängig von Sicherheitsaspekten, einen hohen Grad an Testautomatisierung in unserer CI/CD-Pipeline realisiert haben und wenn – und hier hinkt der Vergleich mit dem Fahrrad – wir schnell rückwärtsfahren können, also ein Release automatisiert zurückrollen können, ist bereits eine solide Basis geschaffen, auch „sicher fahren“ zu können.
Werden die üblichen Unit- und Feature-Tests nun noch um sicherheitsbezogene Test-Cases erweitert, können explizite Anforderungen in diesem Bereich überprüft werden.
Allerdings ist das nur sinnvoll in Kombination mit regelmäßigen, automatisierten Schwachstellentests und im Idealfall einem Intrusion Detection System (IDS), also generell Datenpunkte (z. B. aus Anwendungs-Logfiles), die eher einem Security Operation Center zuzuordnen sind. Wie für Business-relevante KPI (z. B. aktive Sessions, Anzahl Orders / Zeiteinheit, etc.), die überwacht werden und die bei detektierten Abweichungen nach Deployments in Systemen mit hohem Reifegrad automatisch ein Rollback anstoßen, sollte hier analog für verschiedene Security-KPIs vorgegangen werden. Für beides (Schwachstellentests und IDS) gilt, dass die Ergebnisse maschinell verarbeitbar sein müssen und zur Event-Synchronisation die relevanten Zeitpunkte von z. B. den regelmäßigen Deployments allen beteiligten Systemen programmatisch erreichbar zur Verfügung stehen.
So kann über die Integration der Business-Datenpunkte, der Datenpunkte aus der Verfügbarkeitsüberwachung und eben den Datenpunkten der IT-Security die Rollback-Mechanismen einer IT-Anwendung gesteuert werden, um nach Deployments automatisiert reagieren zu können.
Der generelle Anspruch möglichst schnell fahren zu können, sollte also indirekt die IT-Sicherheit fördern.
Investiere in Test- und Security Automatisierung als unabdingbare Versicherung für eine agile Pace.
Wir fassen zusammen:
Man bette das Thema Sicherheit in die Verantwortlichkeit des Product Owner ein, füge Sicherheitsanforderung der eigenen agilen Methodik hinzu und garniere das Ganze mit Test- und Security Automatisierung – und schon ist das Yin-Yang in perfekter Balance zwischen Agilität und Sicherheit erreicht?
In diesem Artikel ging es bisher um Rollen, Methodik und Werkzeuge. Ein entscheidender, wenn nicht sogar der entscheidende Faktor, der zwischen Erfolg oder Misserfolg von Agile Security steht, ist aber der Mensch in dem kulturellen Gefüge von Organisation und agilen Teams. Wir beobachten bei der Umsetzung von Agile Security ähnliche Hürden, wie bei dem Wandel hin zu einer DevOps Kultur. Alte Rollenmodelle müssen gedanklich abgelegt werden. Eigene Verantwortungen müssen erweitert und neue Themen mit durchdacht werden.
Hier ist Leadership gefragt, aus Veränderung eine Chance zu machen:
Es gilt persönliche und fachliche Entwicklungsperspektiven einzelner mit dieser Veränderung zu verknüpfen sowie eine Umgebung zu schaffen, in welcher ein Team aus heterogenen Expertinnen und Experten Freude hat, neue Werkzeuge und Methoden zu kombinieren, um flexibler, schneller und sicherer Produkte zu entwickeln.
Erschaffe eine Kultur der positiven IT-Security!
