Agil und sicher entwickeln

Software Engineer bei Zühlke Schweiz. Er ist Certified Information System Security Professional (CISSP), Certified ScrumMaster und hat einen Master-Abschluss in Information Security Agile Entwicklungsmethoden haben in modernen und komplexen Software-Projekten Fuss gefasst. Die leichtgewichtigen Methoden mit bewusst kleinem Managementaufwand versprechen eine höhere Produktivität, kürzere Release-Zyklen und qualitativ bessere Software. Der entscheidende Vorteil von Entwicklungsmethoden wie Scrum ist jedoch die bewusst hohe Transparenz. Damit lässt sich schnell und iterativ immer wieder aufzeigen, was im Projekt gut läuft, aber auch, was noch zu verbessern ist.

Unabhängig von der gewählten Entwicklungsmethode haben die Bedrohungsszenarien auf die immer stärker vernetzten Applikationen - und die dahinter stehenden Daten - in den letzten Jahren massiv zugenommen. Cyber-Kriminalität ist Realität und wird in den nächsten Jahren sogar noch stark zunehmen. Es gibt kaum Unternehmen, die ihre Business-Modelle nicht auf dem Internet aufbauen und damit bei einem Zwischenfall schnell in ihrer Existenz bedroht sind. Gängige Sicherheitslösungen sind meist darauf ausgerichtet, kritische Löcher von qualitativ mangelhafter oder nicht gewarteter Software notdürftig zu stopfen. Diese Symptombekämpfung mag zwar funktionieren, hinkt jedoch fast immer einen Schritt hinterher. Das Problem sollte an seiner Wurzel behandelt werden - direkt bei der Entwicklung der Software. Die Erfahrung zeigt zudem, dass Sicherheit nicht kurz vor oder während der Inbetriebnahme in die Software integriert werden kann, wie dies oft versucht wird. Sie muss von Anfang an mitberücksichtigt werden. Erste Ansätze («Building Security In», Garry McGraw, 2006; Microsoft SDL) zeigen, wie Sicherheit auch in Software-Entwicklungsprozessen integriert werden kann. Doch es fehlt vielerorts noch am Verständnis für deren Wichtigkeit. Einer der Gründe dafür ist, dass der direkte Nutzen der Investition meist nicht sofort sichtbar wird. Die Integration von Sicherheit in Software sollte stattdessen als eine Art Versicherung gesehen werden. Denn auch die Sicherheit muss als Trade-off in einem gesunden Kosten-Nutzen-Verhältnis zum Business stehen.

In der agilen Software-Entwicklung ist es die Aufgabe des Teams, optimale Vorgehensweisen oder Tools innerhalb des schlanken Prozesses zu entwickeln und stetig zu optimieren. Zum Thema Sicherheit als integraler Bestandteil in agilen Entwicklungsmethoden sind jedoch kaum Informationen verfügbar. Die folgende Aufstellung zeigt, mit welchen Methoden ein agiler Prozess wie Scrum um den Aspekt der Sicherheit erweitert werden kann. Iterative Bedrohungsmodellierung: Bei traditionellen Entwicklungsmethoden werden bei Projektstart umfassende Risikoanalysen erstellt und mögliche Gegenmassnahmen identifiziert. In Scrum soll ein Bedrohungsmodell mit dazugehöriger Risikoanalyse iterativ entwickelt und mit jeder neu dazukommenden Anforderung verfeinert werden. Durch die Analyse der neuen Anforderung und der damit verbundenen Datenströme sollen mögliche Bedrohungen aufgedeckt und Gegenmassnahmen identifiziert werden. Sicherheitsanforderungen: Wie normale Anforderungen (meist User Stories genannt) sollen auch Sicherheitsanforderungen im Product Backlog aufgenommen und vom Product Owner priorisiert werden. Die meisten Sicherheitsanforderungen haben jedoch direkte Auswirkungen auf die Backlog-Einträge und können nicht wie sonst üblich in einem Durchgang erfüllt werden. Damit wird auch klar, dass die Kosten rasant steigen, sobald eine solche Sicherheitsanforderung erst am Ende des Projekts mit einfliesst. Meist müssen dann diverse bereits umgesetzte Features nochmals neu beurteilt und angepasst werden. Abuser Stories: Anforderungen im Product Backlog spiegeln sehr genau wider, was die Software tun soll. Es gibt aber kaum Anforderungen, die beschreiben, wie sich die Software nicht verhalten soll oder wer keinen Zugriff auf bestimmte Funktionen oder Ressourcen haben darf. Für diese Situationen werden sogenannte Abuser Stories aus Sicht eines Angreifers verfasst. Dabei ist es empfehlenswert, auf das Know-how eines Sicherheitsexperten - aus dem Team oder von extern - zurückzugreifen. Die Abuser Stories werden ebenfalls im Product Backlog wie herkömmliche Anforderungen gepflegt und helfen zusätzlich, das Bedrohungsmodell zu verfeinern. Definition of Done: Mit der Definition of Done (DoD) definiert das Entwicklungsteam, was erreicht werden muss, damit eine Anforderung aus dem Backlog als erledigt gilt. Typischerweise sind dies Kriterien wie: «implementiert», «die Akzeptanzkriterien des Product Owner sind erreicht», «Unit Tests sind fehlerfrei» oder «der Code Review ist gemacht». Die DoD wird individuell von jedem Team selbst definiert, genau dort sollen auch die Sicherheitsanforderungen integriert werden. Die DoD könnte so durch weitere Kriterien erweitert werden, zum Beispiel, dass ein statisches Analyse-Tool keine Sicherheitsmängel innerhalb des Source Codes finden darf, automatisierte oder manuelle Penetration-Tests keine neue Sicherheitslücken hervorbringen, die Zugriffsberechtigungen für die Anforderung definiert, implementiert, getestet und abgenommen worden sind oder dass eine Dokumentation des neuen Features geschrieben und abgenommen wurde.

Weiter sollten für das Setup von Entwicklungsteam und -umgebung folgende Aspekte berücksichtigt werden: Awareness schaffen, Know-how aufbauen: Qualitativ gute Software wird von guten Entwicklern erschaffen. Genauso verhält es sich bei der Software-Sicherheit. Im Team braucht es erfahrene Sicherheitsexperten, die ihr Know-how auch weitergeben können. Heute braucht ein guter Entwickler nicht nur Kenntnisse in Programmier-sprache, Prozessvorgehen oder Entwicklungs-Tools, sondern auch solide Fachkenntnisse in Software-Sicherheit. SQL Injection, Cross Site Scripting, Broken Session Management und andere Schwachstellen dürfen keine Fremdwörter sein. Dieses Know-how muss gezielt durch Ausbildung und Awareness-Programme aufgebaut und gefestigt werden. Automatisierter Code Review: Heutige Software-Sicherheits-Tools können anhand riesiger Regelwerke Source Code nach bekannten Schwachstellen und typischen Programmierfehlern durchsuchen. Solche Tools sollen unbedingt eingesetzt werden. Sie lassen sich einfach in automatisierte Builds integrieren. Die damit erzeugten Auswertungen dienen dazu - ganz im agilen Sinn - eine erhöhte Transparenz zu schaffen. Neu gefundene und ungelöste Sicherheitslücken werden dem Kunden im Sprint Review präsentiert und ermöglichen ihm, fundierte Entscheide für die zukünftige Entwicklung zu fällen. Zudem sind diese Werkzeuge auch ideal, um Entwickler mit wenig Know-how zu sensibilisieren. Denn die Werkzeuge zeigen auf, wo Schwachstellen liegen, welche Probleme auftreten und wie diese typischerweise behoben werden können. Für Sicherheitsexperten mag die agile Software-Entwicklung chaotisch und unkontrolliert wirken, während die agilen Evangelisten die Software-Sicherheit womöglich für schwerfällig und einschränkend halten. Doch mit etwas Flexibilität, Anpassung und gegenseitigem Verständnis gibt es Wege, auch im agilen Entwicklungsprozess Software sicher zu entwickeln.