Dieser Artikel beschäftigt sich mit einem Ansatz wie IT-Sicherheits-Risiken in agilen Umgebungen erkannt und angemessen behandelt werden können. Dazu wird zunächst eine agile IT-Betriebs-Umgebung beschrieben wie sie der Autor in großen Unternehmen vorgefunden hat. Weiterhin werden zwei Risikomanagement Methoden kurz angesprochen und Ansätze heraus gearbeitet welche in agilen IT-Betriebs-Umgebungen angewendet werden können. Abschließend zeigt der Artikel in einer Zusammenfassung die wichtigsten Maßnahmen auf, die zur optimalen Behandlung von IT-Risiken in agilen Umgebungen eingeführt werden sollten.

Was ist eine Agile Umgebung

Agile Umgebungen sollen eine flexible Softwareentwicklung ermöglichen. Damit soll Software schnell  entwickelt und dynamisch auf Anforderungen aus dem Markt reagieren. Die Ursprünge für agile Softwareentwicklung sind im sogenannten „extreme programming“ seit den 90er Jahren zu finden. Ziel war es dabei (wie heute mit aktuellen agilen Methoden) sich der Kundenanforderung in kleinen Schritten zu nähern und gleichzeitig das sonst übliche formalisierte Vorgehen eher zu vernachlässigen.

Es wird in den meisten Fällen in Sprints entwickelt und SCRUM als Projektmethode eingesetzt. Außerdem werden Entwicklungstools benötigt die einerseits das Arbeiten im Team unterstützten sowie sich um Versionierung, Codeprüfung, Funktionstests und Verteilung in die Zielsysteme kümmert.

Welche Sicherheitsrisiken sind in agilen Umgebungen zu erwarten

Betrachten wir zunächst Risiken unabhängig von den zu entwickelnden Anwendungen und konzentrieren uns auf die Umgebungen zur Entwicklung, Test und Produktion/Betrieb. In einer agilen Welt (DevOps) müssen die einzelnen Umgebungen näher zusammen rücken. Das ist notwendig damit einerseits kürzere Entwicklungszyklen realisiert werden und andererseits Entwickler sehr produktionsnahe programmieren können. Diese engere Verbindung widerspricht dem Trennungs-Prinzip welches zur Stabilität in den einzelnen Umgebungen beitragen sollte.

Weiterhin muss der Compile- und Test-Prozess weitestgehend automatisiert werden. Damit werden neue Funktionen schnell bis in die Produktion transportiert ohne detailliert auf potentiellen Missbrauch hin untersucht worden zu sein.

Agile Teams arbeiten in sogenannten Timeboxen, den Sprints, die zwischen zwei und vier Wochen dauern. Risikoanalysen hingegen können sehr zeitaufwendig sein und werden üblicherweise innerhalb einiger Wochen erstellt.

Man nutzt Rahmenwerken wie ISO 27005, NIST SP 800-37, oder auch Cobit. ISO/IEC 27005 empfiehlt ein systematisches Vorgehen welches nach der Eingrenzung des Betrachtungsgegenstandes in die Risikoidentifizierung übergeht, weiterhin beschreibt wie Risiken abzuschätzen, auszuwerten und letztlich zu behandeln sind. Risiken werden dann entweder reduziert, vermieden, übertragen/versichert oder akzeptiert und kommuniziert.

NIST 800-37 beschreibt ein ähnliches Vorgehen bei dem der Betrachtungsgegenstand zunächst beschrieben werden soll, anschließend die Sicherheitsmaßnahmen, die das Unternehmen bereit stellt, in einem Security-Plan aufgelistet werden und weiterhin die für den Betrachtungsgegenstand geeigneten Sicherheitsmaßnahmen implementiert werden. Es folgen weitere Schritte zur Untersuchung der vorhandenen Maßnahmen, Freigaben von Aktionsplänen und Aufbau eines dauerhaften Monitoring der Betrachtungsgegenstände. NIST 800-37 erwähnt die agile Implementierung eines Organisationsweiten Risikomanagement-Systems, beschreibt allerdings nicht was genau damit adressiert wird. Man findet lediglich einen Hinweis auf iterative Untersuchungen während ein Life-Cycle durchgeführt wird sowie die Empfehlung in der Projektstartphase die Anforderungen bereits richtig zu definieren.

Beide Methoden klingen sehr aufwendig, bei Beschränkung auf die Untersuchung wesentlicher Risiken sowie die Nutzung einer qualitativen Betrachtung (also Wahrscheinlichkeiten sowie Schadenhöhen in niedrig, mittel und hoch bewerten) wird es möglich eine Untersuchung innerhalb eines Sprints zu erledigen.

Welche Risiken wirken auf agil entwickelte Software

Jede Software stellt vorab definierte Funktionen einem Benutzer bereit. Dafür werden Testfälle geschrieben welche diese Anforderungen einzeln überprüfen bevor die Software abgenommen werden kann.

Tests von Software müssen immer schneller durchlaufen werden und damit steigt die Wahrscheinlichkeit dass manche anfangs noch durchgeführte Tests aus Zeitgründen später weg gelassen werden.

Softwareentwickler bedienen sich fast immer Bibliotheken. In vielen Fällen kommen diese aus offiziellen Quellen wie z.B.: Github. Man kann davon ausgehen dass Fehler in diesen Quellen früh gefunden werden weil die Community an Entwicklern groß ist. Bibliotheken die sich noch in frühem Stadium befinden enthalten fast immer Software-Defekte. Ihre eigentliche Auswirkung wird erst viel später entdeckt. Daher muss besonders Software aus externen Quellen genau untersucht werden bevor sie in Produktionssystemen eingesetzt wird.

Automation versus manuelle Prüfungen

Testfälle werden in der Regel zu jeder neuen Funktion gleich mit entwickelt. Auch für Software aus externen Quellen lassen sich automatische Security-Scans durchführen. Automatische Tests sind also möglich solange die Regeln statisch bleiben.

Unberücksichtigt bleiben dabei die abhängigen Funktionen welche sich in der Kombination von mehreren Anwendungsfällen ergeben. Beispielsweise können sich Überlagerungen ergeben wenn ein Auditor einen vertraulichen Report ausdruckt und gleichzeitig ein Administrator die Rolle des Auditors überarbeitet. Werden diese Fälle nicht richtig voneinander getrennt so ist eine Race-Condition nicht auszuschließen. Speicherbereiche müssen getrennt voneinander reserviert, verwaltet und frei gegeben werden. Eine automatische Prüfung solcher Überlagerungen muss zunächst erkannt und anschließend zumindest manuell eingeplant werden.

Außerdem können nur bekannte Software-Defekte automatisiert geprüft werden. Neu hineinprogrammierte (noch unbekannte) Fehler benötigen nach wie vor eine manuelle Prüfung.

Häufig werden aus verschiedenen Teams ähnliche Fragen an das Sicherheits-Team heran getragen wie zum Beispiel „welche Verschlüsselungsparameter müssen wir für streng vertrauliche Daten wählen“. Es geht meistens um die Wahrung der Vertraulichkeit oder Integrität von Daten. Es werden Datenbanken verwendet in denen „Geheimnisse“ (oder Credentials) gespeichert werden oder neue Benutzer-Verzeichnisse angelegt um Endkunden verwalten zu können. Ebenso wiederholen sich die Fragen um Single-Sign-On Lösungen oder die Auslagerung von Office Anwendungen in die Cloud. Dahinter verbergen sich Standardfragen zu sicheren Anmeldeprozessen oder das Verhindern von „man in the middle“ Angriffen.

Diese wiederholten Fragestellungen lassen sich durch Templates beantworten, worin Fragestellungen einmalig umfassend behandelt und Sicherheitsmaßnahmen generisch definiert werden.

Andererseits werden immer wieder neue Architekturen erstellt oder neue Technologien eingeführt welche auf jeden Fall eine manuelle Analyse benötigen. Diese manuellen Prüfungen müssen durchgeführt werden wenn sich die Entwicklung noch in der Design-Phase befindet.

Zu welchen Fragestellungen können Sicherheits-Templates entwickelt werden

Grundsätzlich bietet es sich an wiederkehrende Fragestellungen zu sammeln um dann festzustellen ob Sicherheits-Templates erstellt werden können. Dazu können Dinge zählen wie z.B.: Sichere Verbindung zu Datenbanken, Regelmäßiger Zertifikatstausch (z.B. für TLS-Verbindungen oder Signatur von Tokens), Verschlüsselung von Datenbanken, Nutzung von KeyStores, Anbindung an Hardware-Security-Module, Verwaltung von Benutzern sowie Anbindung von externen Verzeichnisdiensten,Überwachung von Datenbanken, Anbindung an sichere Emailinfrastruktur zur Versendung von vertraulichen Emails mit S/Mime, Anbindung an ein Sicherheits-Monitoring, Nutzung von Cloud-Diensten oder auch Anbindung an ein SOC und dazu Einrichten eines Standardverfahrens zur Behandlung von Sicherheitsvorfällen. Gemein haben diese Template-Vorschläge dass sie eine Anbindung an zentrale Sicherheitssysteme beschreiben, als auch gleich die technische Implementierung mitliefern sollten. Templates sollen Entwicklern direkt helfen und daher müssen diese Vorlagen insbesondere Programmierbeispiele enthalten und Zugriff auf Testsysteme beschreiben.

Risikoanalysen

Typischerweise sind Risikomanagement-Prozesse komplex und benötigen idR. viel Zeit in der Vorbereitung, der Informationsbeschaffung sowie der Überprüfung der Ergebnisse. Agile Teams können keine langen Prozesse abwarten und deshalb muss sich der Risikomanagement-Prozess in die Sprints integrieren. Dazu implementiert man ein Verfahren zur Erstellung von agilen Risikoanalysen sodass je Sprint mehrere Risikoanalysen erstellt werden können. Zusätzlich etabliert man den Risikomanagementgedanken in den Projektteams zum Abruf in jedem Sprint. Siehe dazu übernächster Abschnitt.

Agil Risikoanalysen erstellen

Agile Risikoanalysen kann man folgendermaßen aufbauen: (1) Beschreibung des Changes, (2) Grund für den Change, (3) Betrachtung wesentlicher Risiken und damit möglicher Einfluss auf die Produktion, (4) Vorschlag zur Risiko-Behandlung und Empfehlung für den Product-Owner.

Risikoanalyse-Beispiel:

Change-Beschreibung: Es wird Zugang von einer im Intranet befindlichen Anwendung auf einen Proxyserver in der DMZ benötigt. Die Anwendung überträgt dabei personenbezogene Daten  um ein Formular auf einem Applikationsserver im Internet auszufüllen. Die Firewalls müssten dazu derart geöffnet werden dass Anfragen aus dem Intranet direkt an den Extranet-Proxyserver weiter geleitet werden können.

Grund für den Change: Die Anwendung vervollständigt Adressen von internen Mitarbeitern durch Zugriff auf eine externe Webservices eines Drittunternehmens. Dies ist Teil eines ausgelagerten Abrechnungsprozesses.

Möglicher Einfluss auf die Produktionsumgebung: Direkte Freigabe vom Intranet in die DMZ ermöglicht anderen Anwendungen unautorisiert Zugriffe auf einen Proxyserver. Bislang gibt es keinen Geschäftsfall der diese Zugriffe von Produktionssystemen in das Internet benötigt. Diese Verbindung ist nicht konform zu den Policies.

Risiko-Behandlung: Einsatz von Mutual-Authentication: Der Proxyserver akzeptiert Anfragen von der Anwendung mittels Clientzertifikat und dem Proxyserver vertraut die Anwendung durch ein Host-Zertifikat. Sowohl Clientzertifikat als auch Host-Zertifikat laufen nach einer kurzen Zeitspanne aus und müssen erneuert werden.

Regelmäßige Risikoanalysen in agilen Prozessen durchführen

Man kann sich vorstellen den gesamten Agilen Entwicklungs- und Produktionsprozess in mehrere Ebenen zu zerlegen.

Die erste Ebene wird repräsentiert durch das Netzwerk und die Serverhardware. Hier werden Standard-Sicherheitsmaßnahmen integriert wie Integritätstests, Firewalls zur Segmentierung, Zugriffskontrollen, Sicherheits-Event-Monitoring und Policy-Compliance-Monitoring. Hochgradige Automation ermöglicht die Auswertung und Meldung von Sicherheitsverletzungen an ein  Incident-Response-Team (SIRT).

Auf der zweiten Ebene werden die verschiedenen Umgebungen wie Entwicklung, Integration, Abnahme und Produktion abgebildet. Hier lassen sich Werkzeuge einbauen die automatisch Versionen verwalten, Code kompilieren und neue Versionen verschiedener Entwickler gegeneinander durchtesten und sie ebenso automatisch Sicherheitsanalysen unterziehen, also auf Programmierfehler-Jagd sind. Softwarefehler werden direkt in die nächste höhere Ebene in das Backlog eingemeldet und somit in einem der folgenden Sprints behoben. Das verhindert Patching von Softwarecode in der Produktion, weil einerseits fehlerhafter Code nicht bis in die Produktionsumgebung gelangt, bzw. Fehler in Folgesprints ausgemerzt werden. Man nennt das auch „rolling-forward“ anstatt „rollbacks“.

In der dritten Ebene wird der Agile Prozess dargestellt. Hier findet die menschliche Zuarbeit statt. Es wird eine Anforderungsanalyse erstellt sowie Epics und Stories definiert. In der Designphase können außerdem Sicherheits-Templates heran gezogen werden, welche entweder aus Entwicklungen anderer Projekte stammen oder von der Sicherheits-Organisation aus der vierten Ebene zugeliefert werden. Anschließend werden Sprints durchgeführt und Aufgaben aus dem Backlog abgearbeitet. Es erfolgen regelmäßige Abnahmen durch den Productowner (PO) sowie die Beendigung der Entwicklung durch den PO bei zufriedenstellendem Ergebnis. Bereits in der Epic- und Storydefinition werden agile Risikomanagement-Methoden eingeklinkt. Dazu versetzen sich Entwickler in die Lage eines Angreifers und überlegen wie ihre selbst geschaffenen Funktionen kompromittiert werden könnten. Sie erstellen die Threat-Stories welche später in positive Defense-Stories umgewandelt werden müssen. Threats bzw. Risiken können in einem Risikoregister oder auch Risiko-Backlog gesammelt werden und müssen dann risikoabhängig in den folgenden Sprints bearbeitet werden.

Darüber hinaus können agile Risikoanalysen innerhalb eines Sprints notwendig werden. Diese werden durch Unterstützung der Sicherheits-Organisation (CISO) aus der vierten Ebene erstellt und Ihre Ergebnisse von dem Productowner in den Sprint-Reviews abgenommen.

Priorisierung von Risikoanalysen in agilen Projekten

Sofern ein Risiko-Backlog angelegt wird, müssen in den Sprint-Planungsmeetings die zu behandelnden Risiken schnell bewertet werden können. Die Thread-Stories enthalten i.d.R. keine Bewertung der Risiken sodass sie untereinander nicht direkt verglichen werden können. Eine Methode um zügig zu einer Abwägung zu kommen entwickelte Karl Wiegers mit einer „relativen Gewichtung“. Dazu vergeben gemeinsam der Kunde, der Productowner sowie der Manager relative Punkte von 1 bis 9 (1 steht für den geringsten Wert). Sie bewerten den Vorteil wenn eine Funktion „sicher“ umgesetzt würde, die relative Strafe falls das Produkt die Schwachstelle beibehält, die relativen Kosten bei Umsetzung der gegebenen Maßnahmen und das relative Risiko für die Ausnutzung der gefundenen Schwachstelle. Mit der Formel (Strafe + Vorteil) / (Risiko + Kosten) wird dann die Priorität der Threat-Story ermittelt.

Zusammenfassung

Sicherheitsrisiken erfasst man am besten über die Betrachtung von Einflussvektoren, sogenannte Threats. Diese wirken auf die Sicherheitswerte Vertraulichkeit, Integrität, Nicht-Abstreitbarkeit und natürlich Verfügbarkeit eines Produktes oder Funktion. Agile Entwicklungsumgebungen müssen diese Werte schnell sicherstellen und aufrecht erhalten. Die richtige Kombination von Automation, Verwendung von Sicherheits-Templates und manuellen Risikoanalysen ist wichtig. Die Integration in den agilen Life-Cycle auf verschiedenen Ebenen funktioniert durch:

1. Sichere Umgebungen die typischerweise Sicherheitsmaßnahmen wie Rollentrennung nach Need-to-Know Prinzip, Segmentierung und Sicherheitsmonitoring realisieren.
2. Codeanalyse während der Entwicklung. Testverfahren werden entweder zugekauft  oder durch ein Sicherheits-Team durch umwandeln von Security-Policies zu Testanforderungen umgeschrieben. Erkannte Fehler aus der automatischen Code-Prüfung müssen direkt zu Korrekturen an der Code-Basis führen und damit das Software-Repository für zukünftige Entwicklungen angepasst werden. Automatisierung kann hier helfen indem aus Fehlerberichten direkt Tickets für Softwareentwickler erzeugt werden (also in das Backlog schreiben) die in den folgenden Sprints gelöst werden müssen.
3. Entwickler die sich regelmäßig in die Rolle eines Angreifers versetzen und Threat-Stories entwickeln. Anschließend werden sie in Defense-Stories umformuliert in der Art: „Ich als Entwickler möchte das die Anwendung SQL Injektion Versuche am Frontend abwehrt“. In den Sprint-Planungsmeetings wird vereinbart welche Defense-Stories zu welchem Zeitpunkt (am besten priorisiert nach höchstem Risiko, siehe oben) umgesetzt werden müssen.
4. Manuelle Schnell-Assessments die sowohl in die Requirements- und Design-Phase als auch später einzelne Sprints eingebaut werden. Sie erfassen wesentliche Threats und beschreiben den Zustand vorher, nachher und präsentieren eine Empfehlung für den Productowner zur Abnahme am Ende eines Sprints.

Werden diese organisatorischen Maßnahmen-Ebenen konsequent eingeführt, dann steigt mit dem Funktionsangebot der Anwendungen auch das Sicherheitsniveau, was letztendlich zu erfolgreichen Produkten führt.