Herausforderung und Chance: Sicherheit in agilen Softwareentwicklungsprojekten

Das Thema Informationssicherheit wird in der Softwareentwicklung immer noch zu wenig berücksichtigt, während es in der Infrastruktur und im Management bereits etabliert ist. Insbesondere in agilen Softwareentwicklungsprojekten scheint das Thema keinen Platz zu haben. Häufige Hindernisse sind:

• Sicherheitsanforderungen sind noch zu unkonkret
• Sicherheit bringt keinen direkten Business-Nutzen
• Sicherheit ist nicht im Entwicklungsprozess verankert, sondern wird auf eine spätere Phase verschoben

In der Konsequenz werden Sicherheitsanforderungen zu spät adressiert und separat von funktionalen Anforderungen behandelt. Dies führt zu verpassten Chancen und weiteren Problemen: Architektur muss nachträglich geändert werden und Synergien zu Geschäftsanforderungen können nicht realisiert werden.

So kann man Security in einem agilen Projekt integrieren – ein erster wirkungsvoller Schritt!

Das folgende Diagramm zeigt einen Scrum-basierten Prozess, der um wesentliche Security-Aktivitäten ergänzt wurde: Das Backlog enthält neben anderen Qualitätsanforderungen auch Sicherheitsanforderungen, die in der Sprint-Planung berücksichtigt und im Sprint umgesetzt und getestet werden. Die Definition of Done berücksichtigt wichtige Qualitätsaspekte, wie das Review der Sicherheitsarchitektur oder die Dokumentation und Adressierung von identifizierten Bedrohungen.

Darüber hinaus gibt es weitere Security Aktivitäten, die in einem sicheren, agilen Entwicklungsprojekt berücksichtigt werden sollten, wie die Einhaltung von Secure Design Patterns, der Einsatz von Code Analyse Tools, Penetration Tests und das sichere Deployment. In diesem Artikel möchte ich mich aber auf die Bedrohungsmodellierung und die Sicherheitsanforderungen fokussieren und anhand eines einfachen Beispiels detaillierter darauf eingehen.

Ein einfaches Beispiel: Online Shop für Stadtführungen

Im Folgenden möchte ich anhand eines einfachen Beispiels zeigen, wie man wesentliche Security Aktivitäten wie die Bedrohungsmodellierung anwenden kann und daraus konkrete und testbare Sicherheitsanforderungen formulieren kann.

Bei meinem Beispiel handelt es sich um einen Onlineshop, bei dem Internet-Nutzer aus einem Angebot an Stadtführungen auswählen und eine Stadtführung buchen können. In einem Gästebuch können die Kunden nach der Stadtführung ihre Eindrücke für andere Interessierte dokumentieren. Die Bezahlung erfolgt ausschließlich auf Rechnung und ist – der Einfachheit halber – nicht Bestandteil der Anwendung.

Folgendes Diagramm zeigt die primären Use Cases:

Als ersten Schritt überlegen wir uns, welche schützenswerten Daten und Prozesse unsere Anwendung hat und formulieren daraus erste High-Level-Sicherheitsanforderungen. Hier einige Beispiele:

• Die Vertraulichkeit und Integrität der Kundendaten (DSGVO) muss gewährleistet werden.
• Hinweis: Aus der DSGVO ergeben sich noch weitere Anforderungen wie die Datenschutzerklärung und die Löschung der Daten.
• Stadtführungen sollen 7×24 Stunden gebucht werden können. Es wird eine 95% Verfügbarkeit gefordert.
• Die Integrität der Stadtführungsangebote und der zugehörigen Details (Lokationen, Preise, …) muss gewährleistet sein.

Diese Anforderungen werden in das Backlog aufgenommen und im Refinement weiter konkretisiert. Sie können genauso wie funktionale Anforderungen als User Stories oder Akzeptanzkriterien zu User Stories formuliert werden. Wichtig ist, dass die Abhängigkeiten zwischen Security Anforderungen und funktionalen Anforderungen beim Backlog Grooming und Sprint Planning berücksichtigt werden, um eine effiziente Umsetzung zu ermöglichen.

Nach den Anforderungen ist der Systementwurf ein nächster wichtiger Schritt und eine Chance, Security von Anfang an zu berücksichtigen. Die Anwendungsarchitektur und die gewählten technischen Komponenten müssen die Umsetzung der Sicherheitsanforderungen ermöglichen. Darüber hinaus können auf Basis der technischen Architektur bisher nicht erkannte Bedrohungsszenarien identifiziert und analysiert werden. Ein sehr effizientes Werkzeug ist hier die Bedrohungsmodellierung. Ein Bedrohungsmodell wird meist als Datenflussdiagramm erstellt. Der Hauptfokus liegt darauf, auf Basis eines groben Architekturmodells die wesentlichen Abläufe und Datenflüsse darzustellen.

Gegenüber dem Datenflussdiagramm enthält das Bedrohungsmodell ein zusätzliches Element: die sogenannte Vertrauensgrenze. Eine Vertrauensgrenze markiert eine Änderung der Vertrauensebenen. Beispiele dafür sind System- oder Benutzerschnittstellen.

Das folgende Diagramm stellt ein Bedrohungsmodell zu unserem Online Shop für Stadtführungen dar. Es zeigt die Akteure, die wesentlichen Prozesse und Datenflüsse sowie eine Datenbank, die die Details zu den Stadtführungen, die Kundendaten, die Abrechnungsdaten und das Gästebuch speichert. Alle Elemente des Diagramms sind durch eine eindeutige Nummer benannt. Die Nummerierung dient in erster Linie der späteren Zuordnung von identifizierten Bedrohungen zum Modell. Die wichtigen Vertrauensgrenzen sind rot markiert.

Hinweis: Das Modell verzichtet auf Datenflüsse, die aus Security Sicht nicht relevant sind. Auch auf technische Details wurde im Modell verzichtet, um das Diagramm noch lesbar zu gestalten. Letztere müssen jedoch separat dokumentiert und berücksichtigt werden.

In einem agilen Entwicklungsprojekt sollte ein erstes Bedrohungsmodell erstellt werden, sobald die grundsätzliche Architektur und die wesentlichen Features der Anwendung bestimmt sind. Review und Diskussion des Modells sind Bestandteil der Definition of Done.

Dem Datenfluss folgend gibt das Bedrohungsmodell einen Ablauf vor, nach dem es durchlaufen und analysiert werden kann. Dabei werden bei jedem Schritt mögliche Bedrohungen identifiziert. Schon in unserem kleinen Beispiel kann man einige Bedrohungen identifizieren. Im Rahmen dieses Artikels möchte ich mich auf ein paar naheliegende Bedrohungsszenarien beschränken:

In unserem Beispiel bewerten wir die oben genannten Bedrohungen als hohes Sicherheitsrisiko, weil sie einerseits verbreitet und leicht ausnutzbar sind, und andererseits die definierten „Kronjuwelen“ unserer Anwendung betreffen:

• Integrität der Stadtführungsangebote,
• Vertraulichkeit der Kundendaten,
• Verfügbarkeit des Online Webshops.

Für die Identifizierung der Bedrohungen auf Basis des Bedrohungsmodells kann man einfach anzuwendende Verfahren wie STRIDE von Microsoft zur Hilfe nehmen. STRIDE stellt eine Kategorisierung der wichtigsten Bedrohungen (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privileges) dar. Auch für die Bewertung der Bedrohungen gibt es einfach anzuwendende Verfahren, die bei der Bestimmung des Bedrohungslevels unterstützen (z.B. Microsoft DREAD, OWASP Risk Rating). Sie berücksichtigen unterschiedliche Faktoren, die das Schadensausmaß, die Ausnutzbarkeit der Schwachstelle und mögliche Angreifer betreffen.

Die nachfolgenden Beispiele sollen zeigen, wie man aus den erkannten Bedrohungen konkrete Security Stories formulieren kann:

Security Story 1

Als Kunde des Webshops möchte ich, dass meine persönlichen Daten vor dem Zugriff Dritter geschützt werden, damit sie nicht für deren Zwecke missbraucht werden können.

Akzeptanzkriterien zu 1

• Stelle sicher, dass die Übertragung der Daten vom Browser des Kunden zum Webserver TLS 1.3 verschlüsselt erfolgt.
• Stelle sicher, dass nur authentifizierte und autorisierte Benutzer über den Webshop auf die Kundendaten zugreifen dürfen.
• Stelle sicher, dass der Zugriff auf die Datenbank nur für authentifizierte und autorisierte Benutzer möglich ist.
• Stelle sicher, dass die Kommunikation zwischen den Anwendungskomponenten einschließlich API und Datenbank eine Authentifizierung erfordert.

Security Story 2

Als Eigentümer des Webshops möchte ich, dass nur ich selbst mein Stadtführungsangebot einstellen und ändern kann, damit mein Angebot nicht durch Dritte manipuliert werden kann.

Akzeptanzkriterien zu 2

• Stelle sicher, dass der Shop-Eigentümer sich über einen Namen und ein Passwort authentifizieren muss.
• Stelle sicher, dass das vom Shop-Eigentümer gewählte Passwort mindestens 12 Zeichen lang ist.
• Stelle sicher, dass das Passwort beim Anmelden und Setzen des Passwortes gegen eine Liste bekannter, gebrochener Passwörter geprüft wird. Es werden nur nicht gebrochene Passwörter akzeptiert.
• Stelle sicher, dass der Shop-Eigentümer sein Passwort auf eigenen Wunsch ändern kann.
• Stelle sicher, dass der Shop-Eigentümer eine E-Mail bekommt, wenn seine Login Daten geändert wurden.
• Stelle sicher, dass das Passwort salted hash verschlüsselt gespeichert wird.
• Stelle sicher, dass der Session Token ungültig wird, sobald die Session beendet oder abgelaufen ist.
• Stelle sicher, dass Session Tokens nicht in URL Parametern oder Fehlermeldungen angezeigt werden.

Die Beispiele stellen nur eine kleine Auswahl an Stories und Akzeptanzkriterien dar, um das grundsätzliche Prinzip zu zeigen. Sie sind in keiner Weise vollständig.

Fazit

Sicherheitsaktivitäten lassen sich auch in einem agilen Entwicklungsprojekt effektiv umsetzen. Wie bei jedem neuen Vorgehen wird es am Anfang “holpern“, aber durch die systematische Integration in den agilen Prozess wird es mit jedem Sprint besser.

Die Bedrohungsmodellierung ist ein sehr effizientes Werkzeug, das das Projektteam dabei unterstützt, Bedrohungen systematisch zu analysieren und Gegenmaßnahmen im Rahmen der agilen Entwicklung kontinuierlich umzusetzen und zu testen. Durch die Dokumentation der Bedrohungen sowie der durchgeführten Maßnahmen gewinnt man Transparenz über die Sicherheit der Anwendung, die nicht zuletzt bei einem möglichen Sicherheitsvorfall sehr wertvoll ist.

Auch wenn der Druck, sichere Software zu entwickeln, noch nicht allzu hoch erscheint, ist gerade hier ein enormer Sicherheitsgewinn mit vergleichsweise geringem Aufwand erreichbar. Moderne und nachhaltige Softwareentwicklung erfordert Qualität und Sicherheit. Notwendige Voraussetzungen sind Security Know-How im Team, Unterstützung vom Management, sowie eine strukturierte, systematische Vorgehensweise und brauchbare Tools.

Erfahren Sie mehr über Secure Software Engineering auf der Website der Autorin: https://www.blueheads.de/