Das Yin-Yang-Prinzip: Agile Security

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.

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.

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.

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.

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.

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.