Penetrationstests für agile Software im Wochentakt. Geht das?

Die agilen Softwareentwicklungsmodelle sind zum defacto Standard geworden, werden an einschlägigen Hochschulen gelehrt und in der Praxis nach Möglichkeiten umgesetzt. Wer Software nicht mit agilen Prozessen entwickelt, liegt auf den Brettern und ist bereits angezählt. So scheint es zumindest.

Folglich ist es nicht die Frage, ob Penetrationstests im agilen Umfeld machbar sind, sondern ob wir es schaffen, effektive Kontrollen in die neuen, hippen, rapiden Vorgehensweisen zu integrieren.

Viele Features, viele Bugs

Mit klassischen Softwareentwicklungsprozessen wie Wasserfall oder Rational Unified Process (RUP) müssen Penetrationstester jeweils mehr Zeit investieren, um die zahlreichen Änderungen zu verstehen und zu durchleuchten.

Und das führte dann schlimmstenfalls zu einer erneuten Runde im Entwicklungsprozess, um die Fehler auszumerzen. Also zu einer weiteren Verzögerung bevor die neuen Funktionalitäten den Kunden endlich erreichen.

Agile For The Win

Die agilen Methoden verfolgen das primäre Ziel, dass der Endbenutzer möglichst bald einen unmittelbaren Nutzen verzeichnen kann. So werden je nach Umsetzung des Prozesses innert zwei bis vier Wochen neue Funktionalitäten zur Verfügung gestellt. Zu diesem Zweck werden die Arbeiten in kleine Aufgaben geteilt, nach Wunsch des Kunden priorisiert und dann im genannten Zyklus entwickelt und in der Produktion eingebaut. Ein solcher Turnus wird typischerweise als Sprint bezeichnet.


Der Vorteil liegt auf der Hand: Der Kunde ist stetig involviert und kann so die Prioritäten gemäss seinen Anforderungen justieren und auch auf kurzfristige Veränderungen im Markt, relativ rasch reagieren.

Vertrauen ist gut, Kontrolle ist besser

«Veränderung» und «Sicherheit» haben seit jeher eine schwierige Beziehung und so stellt sich die Frage, ob, wie, wo und wann wir in den sehr kurzen Projektzyklen sinnvolle Kontrollen einbauen können, um eben auch die Sicherheit der Software und der damit bearbeiteten Daten gewährleisten zu können.

Heilung durch Selbsterkenntnis

Im Zwei-Wochen-Takt einen Penetrationstest durchzuführen, da sind wir uns einig, ist weder effizient noch finanzierbar.

«Security ist ein Prozess», hören wir die Evangelisten unserer Branche sagen. Leider sind wir selbst sehr schlecht darin, einen Service anzubieten, der jederzeit ein aktuelles Attest abgeben könnte. Wir führen Standortbestimmungen und Zertifizierungen durch. Die Resultate sind eine Momentaufnahme, die binnen Tagen oder Wochen mindestens teilweise hinfällig werden.


Ein echter On-Demand Service wäre eine Hotline für den Entwickler, zu dem Zeitpunkt verfügbar, wo die Expertise benötigt wird.

Braucht es noch Reports?

Die Softwareentwicklung wird mit Werkzeugen unterstützt. Tickets werden durch Workflows geschoben und diese notifizieren die involvierten Teammitglieder über den Fortschritt einzelner Arbeitspakete. Es wäre logisch, dass die Resultate eines Tests auch in eben solche Tickets einfliessen würden.

Ist also ein Bericht noch zeitgemäss? Für einen Quartalsrapport oder ein Jahresbericht zu Handen der Geschäftsleitung. Vielleicht. Vielleicht auch in Form eines Statements für Endkunden. Aber die Entwickler werden wenig Freude an einem traditionellen Report haben, da er schlicht nicht in ihre Gewohnheiten passt.


Dennoch ist es für einen unabhängigen Tester sehr schwierig, eine Schwachstelle einem einzigen Ticket zuzuordnen. Manchmal entstehen Schwachstellen in Konstellation mehrerer Neuerungen oder erst in Konstellation mit der Installation in der produktiven Umgebung. Es braucht also jemanden, der hier die Brücke schlägt.

Abenteuer ist nur schlechte Planung

Den richtigen Zeitpunkt für einen Test zu finden, ist bei agilen Vorgehensweisen mit definierten Release Terminen, keine grosse Sache. Wenn ein Team aber nach einem rollenden Konzept wie beispielsweise Kanban arbeitet, dann wird kontinuierlich released. Insofern muss der Tester viel Flexibilität an den Tag legen.

Ein Team, welches auf Abruf arbeitet, könnte die spontanen Anfragen bearbeiten. Die Dauer der Arbeiten könnte im Vorfeld anhand der geplanten Features geschätzt und reserviert werden.

Reduce to the Max

Es bedarf einer Triage, welche Features wirklich sicherheitsrelevant sein könnten und es braucht eine Erklärung, wie die Features verwendet werden sollten. Dazu gehört auch zu definieren, was die notwendigen Privilegien beziehungsweise Vorbedingungen dafür sind, bekannte Fehlverhalten und Success Cases.

Es würde sich also anbieten, dass im Projektteam eine Person für die Erklärung der Features zuständig ist, die Dokumentation aktuell gehalten wird und idealerweise der Tester nicht dauernd wechselt, weil sonst viel Vorwissen über den Rest der Anwendung und die Geschäftsziele nicht in die Angriffsszenarien des Penetrationstest einfliessen.

Vorbereitungen ist alles

Es ist wichtig, solide Grundvoraussetzungen für die Tests zu schaffen. Dazu gehört, dass der Tester versteht, wie die finale Produktionsumgebung aussieht. Darüber hinaus wird definiert wie man Zugriff auf das Ticketing, die Dokumentation oder sogar den Quellcode bekommt. Es wird ein Set von Testbenutzern benötigt. Zudem braucht es gültige Testdaten und oftmals auch die eine oder andere Ausnahme, um einen Test effizient durchführen zu können. Dazu gehören beispielsweise auch iOS oder Android Apps, die für das Testing optimiert sind.


Aus den Gesprächen mit verschiedenen Firmen, die agile Modelle verfolgen, lässt sich ableiten, dass die Ausprägung und Maturität der Arbeitsweisen enorm variiert. So ist es oft der Fall, dass die automatische Erstellung einer voll funktionsfähigen Testumgebungen inklusive Abfüllung mit guten Testdaten, selten umgesetzt ist.

Reality Check

Automatisierung ist einer der Schlüssel zu sicherer Software. Das heisst, es werden automatisch Testumgebungen erstellt und abgefüllt. Zudem wird mit Scannern für den Quellcode und für grundlegende Funktionalitäten gearbeitet. Damit erreicht man eine Basisabdeckung und gewinnt so Zeit, kritischere Features über mehrere Sprints zu sammeln und dann in einem Lauf testen zu lassen.

Ausbildung ist ein anderer wichtiger Aspekt im Bereich der Softwareentwicklung. Konkret ist hier die Spezialisierung eines Team-Mitglieds auf Software- und Infrastruktursicherheit anzustreben. Der sogenannte Security Champion ist Ansprechpartner für das Team, trägt die Verantwortung für die Sicherheit der entwickelten Komponenten und sammelt bzw. koordiniert Penetrationstests mit externen Stellen. Er ist auch dafür zuständig, die Erkenntnisse aus den Tests zu beurteilen und allfällige Gegenmassnahmen zu koordinieren.

Fazit

Die Bedingung für eine erfolgreiche Umsetzung von Penetrationstests bei jedem Softwarerelease ist, dass kaum Aufwand für die Vorbereitung und Abstimmung entsteht. Das bedeutet im Umkehrschluss, dass eine Organisation einen überdurchschnittlichen Grad an Automatisierung an den Tag legen muss. Dies ist nach meiner Erfahrung noch eher selten der Fall und dadurch kippt das Gewicht vom Penetrationstest zum Vorbereitungsaufwand und die Tests werden unwirtschaftlich.

Zudem birgt die isolierte Analyse einzelner Neuerungen die Gefahr, dass Schwachstellen, verursacht durch das Gesamtkonstrukt der Software oder der Infrastruktur, nicht erkannt werden.


Folglich rate ich in den meisten Fällen noch davon ab, manuelle Penetrationstests an jeden Releasetermin eines agilen Projektes zu koppeln.

Ergo, Stand heute, sind die meisten Firmen nach wie vor mit vierteljährlichen oder halbjährlichen «Managed Pentest» eindeutig besser bedient.

Der Autor

Cyrill Brunschwiler ist seit über 20 Jahren in der Rolle des Hackers unterwegs. Er hat in seinen Anfängen Cyber Training Ranges entwickelt sowie Rätsel für hacking-lab.com erstellt. Seit 2005 hat er unzählige Projekte mit unabhängiger Expertise in den Bereichen Penetration Testing, Red Teaming, Incident Response und digitale Forensik, durchgeführt. Cyrill ist seit 2014 Geschäftsführer der Compass Security Schweiz AG. Er hält einen MSc in Information Security und Assurance von der Royal Holloway Universität in London und ist Lehrbeauftragter an der Ostschweizer Fachhochschule OST.