Development Agility IT-Sicherheit

Leichtgewichtig: Security in agilen Entwicklungsprojekten

Durch digitale Innovationen dringt die IT in alle Branchen und Lebensbereiche vor. Qualität und insbesondere IT-Sicherheit werden in Softwareentwicklungsprojekten dabei oft bewusst oder unbewusst vernachlässigt. Bei bekannten Beispielen aus dem IoT-Bereich mussten sogar Produkte aufgrund von Sicherheitslücken vom Markt genommen werden. Bei genauer Betrachtung sind häufig offensichtliche und einfach zu vermeidende Fehler in der Entwicklung die Ursache. Moderne agile Softwareentwicklung und IT-Sicherheit scheinen im Widerspruch zu stehen. Mit einem leichtgewichtigen Ansatz und effizienten Techniken kann es jedoch gelingen, nachhaltige IT-Innovationen zu entwickeln.

Sabine Rathmeyer

Professorin für Wirtschaftsinformatik und Cyber Security

Dagmar Stefanie Moser

Author

25.04.2020
Lesezeit: 14 Minuten
96 Views

Nicht zuletzt durch die Globalisierung stehen Wachstum, Wohlstand und internationale Wettbewerbsfähigkeit in engem Zusammenhang mit technologischer Innovationsfähigkeit. In den vergangenen Jahren hat sich ein immer schneller wachsender Innovationswettbewerb entwickelt, der Start-ups, kleine und mittlere Unternehmen und sogar Großunternehmen mit traditionellen Geschäftsmodellen herausfordert. Der daraus resultierende Druck, innovative Produkte in immer kürzeren Zyklen auf den Markt zu bringen, birgt jedoch eine Reihe von Risiken. Intelligente Kühlschränke, Auswertung von Gesundheitsdaten, Smarte Lösungen in der Logistik und vieles mehr – immer häufiger entstehen Produkte aus oftmals auch 3rd Party-Kompositionen verschiedener Hard- und Softwarekomponenten.

Security und Innovation – Awareness

Inzwischen sind Nachrichten über Sicherheitslücken und Angriffe auf diese intelligenten neuen Lösungen an der Tagesordnung. Beispiele, die bereits in 2017 in die Presse gerieten und die folgenden 1 ½ Jahre weiter für Schlagzeilen sorgten, sind Kinder-Smartwatches. Die innovative Idee, Kinder per GPS- oder Mobilfunk-Funktion zu überwachen und damit vor möglichen Gefahren zu schützen, wurde unter anderem durch die Sicherheitslücke, Personen und deren Umgebung heimlich abzuhören und damit die Uhr ohne große Probleme in eine Wanze zu verwandeln [Sch19], infrage gestellt. Wie in dem genannten Beispiel mangelt es häufig grundsätzlich an dem Bewusstsein, dass hier Schwachstellen übersehen werden können, die sich erst im Endprodukt zeigen. Die eigene Verantwortlichkeit muss stärker in den Fokus gelangen. Vor allem dadurch, dass inzwischen auch Behörden bezüglich der sich häufenden Sicherheitsvorfälle alarmiert sind, können die Folgen für das Unternehmen äußerst unangenehm werden. Es gibt mittlerweile eine Reihe von Gesetzen, Leitlinien und Standards (u. a. [BSI13], [BSI19]), an denen sich Unternehmen bei der Entwicklung von IT-Systemen für einen durchschnittlichen Schutzbedarf orientieren können beziehungsweise deren Vorgaben eingehalten werden müssen. Dies gilt insbesondere auch für den Fall, dass 3rd Party-Komponenten eingebaut werden.

Im Folgenden zeigen wir, wie mit einem leichtgewichtigen Ansatz und effizienten Techniken und Methoden, die Sicherheit in IT-Innovationsprojekten von Anfang an verbessert werden kann.

Sichere Softwareentwicklung in einem agilen Entwicklungsprozess

Die Berücksichtigung von Security galt lange Zeit als nachgelagerte Aufgabe in Softwareprojekten – oder wurde gerne an zentrale Infrastrukturen wie Firewalls delegiert. Dadurch wird jedoch nicht nur eine große Chance verpasst, frühzeitig die richtigen Weichen für sicherere Software zu stellen, sondern auch akzeptiert, dass oft mit hohem Zeit- und Kostenaufwand größere Korrekturen an wesentlichen Komponenten oder an der Architektur durchgeführt werden müssen. Insbesondere in Innovationsprojekten ist das fatal, weil kurze Entwicklungszeiten und geringe Kosten hier eine besondere Bedeutung haben. Schnell kann ein erstes sogenanntes Minimum Viable Product (MVP) um ein Vielfaches teurer werden und später verfügbar sein, weil kurz vor dem Rollout noch Compliance- und Security-Anforderungen umgesetzt und schwerwiegende Sicherheitslücken geschlossen werden müssen. Sichere Softwareentwicklung bedeutet, Security von Beginn an und in jedem Schritt zu integrieren. Dies gilt grundsätzlich unabhängig vom verwendeten Softwareentwicklungsprozess. Tabelle 1 stellt die Sicherheitsaktivitäten dar, die auch in einem agilen Entwicklungsprozess berücksichtigt werden sollten.

Tabelle 1: Sicherheit in jedem Entwicklungsschritt

Statt Security auf einen separaten Sprint zu schieben, sollten Security-Aktivitäten zusammen mit der schrittweisen Umsetzung von Geschäftsanforderung als Bestandteil eines normalen Sprints erfolgen. Damit können abstrakte Sicherheitsanforderungen schrittweise konkretisiert, umgesetzt und validiert werden. Die direkte Rückkopplung am Ende des Sprints zeigt sofort, ob Security-Maßnahmen effektiv waren, und bietet die Möglichkeit der kontinuierlichen Verbesserung. Auch die Automatisierung beim agilen Vorgehen unterstützt die Umsetzung und Validierung von Sicherheitsmaßnahmen erheblich, wenn Security durch automatisierte Testfälle und die Einbindung entsprechender Codeanalyse-Tools automatisch berücksichtigt werden. Aufwendige Quality Gates sind dann nicht mehr notwendig.
Abbildung 1 zeigt einen SCRUM basierten Entwicklungsprozess, der um wesentliche Security-Aktivitäten (blau) ergänzt wurde.

Abb. 1: Secure Agile (SCRUM basiert)

Unternehmensspezifische Vorgaben auf Basis des aktuellen Sicherheitskonzepts, gültiger Gesetze, Regularien und Standards können als Rahmenwerk für alle IT-Projekte dienen. Die Erarbeitung und Aktualisierung dieses Rahmenwerks stellen eine wertvolle Grundlage dar, die es den Projekten ermöglicht, erste Compliance- und Security-Anforderungen bereits zu Beginn des Projekts zu identifizieren. Die Festlegung des individuellen Schutzbedarfs für das Projekt (Risiko-Profil) ist wichtig, um die Anforderungen weiter zu konkretisieren sowie die Risikobewertung einzelner Anforderungen und damit deren Priorisierung zu unterstützen. Priorisierte Sicherheitsrisiken und Sicherheitsanforderungen sollten sowohl im Planning als auch in der Definition of Done berücksichtigt werden.

Zum Security-Know-how von Architekten und Entwicklern gehört das Wissen um die Anwendung von Secure Design Principles und Secure Coding Guidelines. Hilfreiche Unterstützung liefern hier anerkannte Best Practices wie die OWASP Top 10 [OWASPTT]. Die Bedrohungsanalyse mittels Bedrohungsmodell stellt eine effiziente Technik dar, um die individuellen Bedrohungen der Anwendung bereits beim Architekturentwurf zu identifizieren und so sicheres Design von Beginn an auf dem Radar zu haben. Dies gilt insbesondere auch für verwendete 3rd Party-Komponenten. Das Bedrohungsmodell sollte mit Weiterentwicklung der Architektur Schritt für Schritt aktualisiert werden. Aus den identifizierten und bewerteten Bedrohungen lassen sich weitere Sicherheitsanforderungen definieren oder konkretisieren. Die wiederum können bei entsprechender Priorität in einem der nächsten Sprints umgesetzt werden. So kann man abstrakte Anforderungen Schritt für Schritt konkretisieren und validieren. Durch automatisierte Tests auf Basis konkreter Sicherheitsanforderungen und Akzeptanzkriterien können Sicherheitsmaßnahmen kontinuierlich validiert und verbessert werden. Das schafft Transparenz über die aktuelle Sicherheitslage der Anwendung und ermöglicht eine sehr bewusste Entscheidung für oder gegen die Umsetzung bestimmter Sicherheitsmaßnahmen. Der Einsatz statischer und dynamischer Codeanalyse-Tools kann die Überprüfung des Codes auf bekannte Design-Fehler deutlich beschleunigen. Auch der Aufwand, in eine „sichere“, automatisierte Pipeline von der Entwicklung zum Betrieb zu investieren, zahlt sich mit jedem weiteren Sprint aus.

Leichtgewichtiger Ansatz für Innovationsprojekte

IT-Innovationsprojekte folgen meist einem geschäftsorientierten Ansatz, wie dem Lean-Start-up-Vorgehen. Dabei stehen die Konkretisierung einer Business-Idee, die möglichst frühzeitige Validierung der Idee beim Kunden und deren kontinuierliche Verbesserung und Konkretisierung im Vordergrund. Abbildung 2 skizziert diesen Prozess. Die eigentliche IT-Entwicklung als Teil dieses Prozesses folgt meist einem agilen Vorgehen wie SCRUM.

Abb. 2: Compliance und Security im Lean-Start-up-Prozess

Auch wenn vor allem in den ersten Iterationen sehr zielgerichtet und mit minimalem Zeit- und Kostenaufwand die Geschäftsidee gefunden und validiert werden soll, darf der Zeitpunkt nicht verpasst werden, wo Compliance und Security beginnen, eine Rolle zu spielen. Spätestens mit dem MVP muss die IT-Anwendung den gültigen Qualitätsund Sicherheitsstandards, die auch für die Produktivumgebung gelten, gerecht werden. Die wesentlichen Compliance- und Sicherheitsanforderungen von Beginn an zu kennen, ist in jedem Fall sinnvoll. Diese Anforderungen könnten im Einzelfall auch das Produkt oder einzelne Features beeinflussen, weil sie zum Beispiel nur mit hohem Aufwand in Sicherheitsmaßnahmen umzusetzen sind oder aber auch ein Alleinstellungsmerkmal und damit einen Wettbewerbsvorteil darstellen. Nur wer die Anforderungen und die damit verbundenen Risiken frühzeitig kennt, kann bewusst entscheiden, welche Risiken wie adressiert werden sollen. Ähnlich sieht es mit der Bedrohungsanalyse aus. Auch hier ist es ein Vorteil, die mit der angedachten Lösung einhergehenden Bedrohungen frühzeitig zu kennen und zu bewerten. Bedrohungen mit einem hohen Bedrohungsniveau können bei der Architekturentwicklung schrittweise berücksichtigt werden. Dies erspart aufwendige Umbauten kurz vor dem Rollout. Auch ein MVP sollte die hoch priorisierten Compliance- und Security-Anforderungen adressiert haben und auf einer soliden Architektur aufbauen, die keine grundsätzlichen Design-Fehler enthält. Weiterhin sollten das Projektteam und das Management Transparenz über mögliche Bedrohungen haben. Als hoch bewertete Sicherheitsrisiken sollten nicht nur dem Management bekannt, sondern auch in einem MVP adäquat adressiert sein. Der Reputations- oder finanzielle Schaden, der durch einen Sicherheitsvorfall entstehen kann, ist grundsätzlich nicht geringer, nur weil es sich um ein MVP handelt. Im Gegenteil: Innovationen haben häufig eine besondere Aufmerksamkeit. Im Folgenden wollen wir anhand eines einfachen Beispiels zeigen, wie man in drei Schritten die wesentlichen Bedrohungen identifiziert und daraus konkrete, umsetzbare und testbare Sicherheitsanforderungen ableitet.

Beispiel Smartwatch – ein GPS-Tracker für Kinder

Das Produkt besteht vereinfacht aus drei Komponenten:

der Uhr (GPS-Tracker),
einem Webserver (bestehend aus Frontend, Backend und API), der mit der Uhr kommuniziert und die Daten speichert,
einer mobilen App, die auf einem Smartphone, Tablet oder Browser läuft und über die die Uhr konfiguriert und abgefragt werden kann.

Benutzer: Kind, Eltern
Anwendungsfälle:

Smartwatch über die mobile App konfigurieren,
Standort der Uhr erfragen,
Funktionen der Uhr aktivieren oder deaktivieren.

Schritt 1: Sicherheitsziele formulieren

Aus der DSGVO und der Tatsache, dass das Hauptziel der Smartwatch der Schutz des Kinds ist, lassen sich folgende Sicherheitsziele zum Schutz der personenbezogenen Daten sowie vor dem Missbrauch durch Dritte ableiten:

Vertraulichkeit und Integrität der personenbezogenen Daten (Name, GPS-Koordinaten, Mobilnummer)1,
Verfügbarkeit der Abfrage des Standorts von mindestens 95 Prozent (7x24) bei vorhandener Internet-Connectivity,
Authentizität der Abfrage und Konfiguration der Smartwatch.

¹) Aus der DSGVO ergeben sich noch weitere Anforderungen, wie die Datenschutzerklärung und die Löschung der Daten, auf die hier nicht weiter eingegangen wird.

Schritt 2: Bedrohungen identifizieren und bewerten

Ein Bedrohungsmodell hilft, Bedrohungen zu identifizieren. Das Modell stellt die Komponenten und Schnittstellen der Architektur sowie die wesentlichen Datenflüsse und Prozesse der Anwendung dar. Zusätzlich werden sogenannte Vertrauensgrenzen skizziert, die eine Änderung der Vertrauensebene andeuten. Häufig lassen sich Bedrohungen an Vertrauensgrenzen lokalisieren.
Abbildung 3 zeigt ein Bedrohungsmodell für das Smartwatch-Beispiel. Das Diagramm ist ähnlich zu dem eines Datenflussdiagramms aufgebaut. Es enthält Benutzer, Prozesse, Datenflüsse, Datenspeicher und Vertrauensgrenzen (rot gestrichelte Linie).

Abb. 3: IoT-Sicherheit am Beispiel Smartwatch

Zusätzlich sind beispielhaft drei Bedrohungen eingezeichnet. Ziel der Bedrohungsanalyse ist es, anhand des Modells Bedrohungen zu identifizieren, diese dann zu bewerten und entsprechende Maßnahmen abzuleiten. Für die Bewertung gibt es verschiedene Methoden, zum Beispiel DREAD von Microsoft [Infosec14] oder OWASP Risk Rating [OWASPRR]. Sie berücksichtigen unterschiedliche Faktoren, die das Schadensausmaß, die Ausnutzbarkeit der Schwachstelle und mögliche Angreifer betreffen. Im Beispiel wurden drei Bedrohungen (siehe Tabelle 2) identifiziert und mit einem hohen Bedrohungsniveau bewertet, weil sie einerseits verbreitet und leicht ausnutzbar sind, und andererseits die zuvor definierten Sicherheitsziele verletzen.

Tabelle 2: Beispielhafte Bedrohungen

Schritt 3: Security Stories und Akzeptanzkriterien ableiten

Aus der Bedrohungsanalyse lassen sich weitere Sicherheitsanforderungen ableiten und die zuvor formulierten Ziele in umsetzbare und testbare Anforderungen herunterbrechen.

Aufruf der API (als Security Story)
Als Benutzer einer Smartwatch möchte ich, dass die Smartwatch nur von authentifizierten und autorisierten Personen aufgerufen wird, damit Dritte die Smartwatch nicht steuern oder abfragen können.

Akzeptanzkriterien:

Stelle sicher, dass die Kommunikation zwischen dem Webserver und dem Smartphone Ende-zu-Ende verschlüsselt erfolgt.
Stelle sicher, dass die Kommunikation zwischen dem Webserver und dem Browser TLS 1.3 verschlüsselt erfolgt.
Stelle sicher, dass nur authentifizierte Benutzer auf den Webserver zugreifen dürfen.
…

Abhören der GPS-Daten
(als Security Story)
Als Benutzer einer Smartwatch möchte ich, dass die Smartwatch meine Daten verschlüsselt an den Webserver überträgt, damit Dritte die Daten auf dem Übertragungsweg nicht abhören und für ihre Zwecke missbrauchen können.

Akzeptanzkriterien:

Stelle sicher, dass die zu übertragenden Daten Ende-zu-Ende verschlüsselt sind.
Stelle sicher, dass die Smartwatch die Lokationsdaten bei fehlender Mobilfunkverbindung verschlüsselt zwischenspeichert.
Stelle sicher, dass die Smartwatch nur Daten an den Webserver mit dem DNS-Namen xyz überträgt und dass die DNS-Abfrage abgesichert ist (z. B. DNSSEC).
…

Die oben beispielhaft dokumentierten Security Stories und Akzeptanzkriterien sollen das Prinzip darstellen, wie man aus erkannten Bedrohungen konkrete Anforderungen formulieren kann. Sie stellen nur einen ausgewählten Ausschnitt dar. Formuliert man Sicherheitsanforderungen aus der Perspektive des Angreifers, spricht man von einer Evil Story. Dieses Vorgehen bietet sich für seltenere, individuelle Bedrohungsszenarien an. Sinnvoll ist es auch, eine Charakterisierung des Angreifers über eine Persona zu entwickeln. Dies hilft bei der Detaillierung der Evil Story.

Zugriff auf andere Uhren (als Evil Story)
Als Angreifer eines Smartwatch-Herstellers möchte ich auf Daten beliebiger Uhren des Herstellers zugreifen, damit ich die Daten entwenden und die Reputation des Herstellers schädigen kann.

Akzeptanzkriterien:

Beliebige Uhren sind Geräte des Herstellers, die Daten an den Webserver mit DNS-Namen xyz versenden.
Der Angreifer eines Smartwatch-Herstellers ermittelt die IDs der Uhren ohne größere Entwicklungsaufwände, zum Beispiel durch den Einsatz von Fuzzing-Tools.
Der Angreifer kann die Smartwatch unter Kenntnis der ID ansteuern, ohne dass eine weitere Autorisierung erforderlich ist.
…

Auf Basis dieser hier beispielhaft formulierten Security und Evil Stories können Sicherheitsanforderungen zusammen mit funktionalen Anforderungen in einem Sprint umgesetzt und getestet werden. Akzeptanzkriterien bieten die Basis für eine Testautomatisierung von Beginn an.

Fazit

Sicherheitsaktivitäten lassen sich auch in einem agilen IT-Innovationsprojekt effektiv umsetzen. Eine wichtige Voraussetzung dabei ist die Security Awareness im Projektteam. Wenn Security als integraler Bestandteil des Entwicklungsprozesses begriffen wird, kann es einen signifikanten Beitrag zur Qualität und damit auch zum Erfolg einer IT-Innovation leisten. Neben einem definierten Secure Development Lifecycle sind unternehmensspezifische Vorgaben, Best Practices und leichtgewichtige Methoden von unschätzbarem Wert. Betrachtet man die eingangs erwähnten und vielfach aktuellen Probleme, denen sich die Hersteller innovativer Produkte und Dienstleistungen stellen müssen, so muss auch ein besonderes Augenmerk auf die Sicherheit der verwendeten 3rd Party-Komponenten gelegt werden. Somit müssen die Aussagen der Hersteller bezüglich möglicher Schwachstellen einzelner Komponenten frühzeitig betrachtet und geeignet validiert werden. Auch wenn der Druck, sichere IT-Innovationen zu entwickeln, scheinbar noch nicht groß genug ist, ist gerade in der agilen Softwareentwicklung ein enormer Sicherheitsgewinn mit vergleichsweise geringem Aufwand erreichbar.