Penetrationstests in agilen Umgebungen

Unter einem Penetrationstest verstehen wir die simulierte Cyberattacke gegen einen Prüfgegenstand. Die Befundung (= die dabei identifizierten Schwachstellen) bezieht sich immer auf den konkreten Zeitpunkt der Analyse. Wiederholt man den Test z.B. ein Jahr später, so findet man immer eine veränderte Situation vor:

• Die Angriffswerkzeuge / Hacking-Methoden sind mächtiger und/oder effizienter geworden
• Der Prüfgegenstand selbst hat sich geändert

Neben turnusmäßigen Penetrationstests sind anlassbezogene Penetrationstests von großer Bedeutung, insbesondere bei agilen Entwicklungen wie Applikationen, mobilen Apps etc.

Um Änderungen am Prüfgegenstand gerecht zu werden, wird ein Penetrationstest oft vor jedem Release durchgeführt. So stellt der Penetrationstest ein Quality Gate dar, das vor dem Livegang des neuen Release passiert werden muss. Teilweise ist ein bestandener Penetrationstest sogar ein im Werkvertrag vereinbartes Abnahmekriterium.

Bei agilen Entwicklungen werden hochfrequent neue Releases erstellt. Erhöht man im gleichen Maße die Penetrationstests, so vervielfachen sich mit dem Anstieg der Releases auch die Kosten für das Pentesting  – und die Sicherheit droht am Kostenfaktor zu scheitern.

Folgende Alternativen zu hochfrequenten Penetrationstests sind möglich:

1. Verzicht auf situative Penetrationstests bei agilen Entwicklungen
2. Tests von z. B. nur jedem dritten Release bzw. jedem Release, das vom Product Owner anerkannt wurde
3. Differenzielle Penetrationstests: Prüfung nur jener Komponenten, die seit dem letzten Penetrationstest ergänzt bzw. geändert wurden

Die dritte Alternative scheint attraktiv zu sein. Voraussetzung wäre jedoch, dass feststellbar ist, welche Pfade man in einer Webapplikation besuchen müsste, um genau jene Webseiten und Formulare zu untersuchen, deren Sicherheit von einer konkreten Quelltextänderung betroffen sein kann. Enthält das neue Release eines Webshops z. B. erstmals eine Zahlungsschnittstelle, so wird ausschließlich diese dem Penetrationstest unterzogen. Wird allerdings die Effizienz einer Applikation oder das Interface zur Datenbank optimiert oder eine große Anzahl kleiner Änderungen programmiert, dann kann dies Auswirkungen auf die Sicherheit sämtlicher Applikationsteile haben: Es ergäbe sich wieder ein Volltest.

Alle drei Alternativen scheinen Nachteile zu haben und erwecken zunächst den Eindruck, man könnte in agilen Umgebungen keine guten Penetrationstests durchführen. Dies ist jedoch ein Trugschluss. Ihm liegt der Gedanke zugrunde, dass Schwachstellen „nur“ deswegen aufgespürt werden, um sie zu beheben. Gerade bei Entwicklungen empfehlen wir eine erweiterte Perspektive: Parallel zur Ausbesserung der Schwachstellen müssen auch die internen Prozesse und die Denkweisen der Entwickler verbessert werden. Denn nach der Entwicklung ist vor der Entwicklung. Man muss diese Fragen stellen: „Was lief schief bei uns, dass unser Produkt die Schwachstelle XY hatte? Was haben wir bei der Planung nicht berücksichtigt? Wie können wir besser werden, sodass diese Schwachstelle nie mehr vorkommt?“ Wer nur die Findings in der Schwachstellenliste des Penetrationstests sukzessive mit „behoben“ kennzeichnet, dem entgeht ein wichtiger Nutzen. Es ist bedeutend, das Übel an der Wurzel zu packen, also durch Penetrationstests nachhaltig bei der Entwicklung zu helfen – und genau dieser Nutzen ist völlig unabhängig von der Frequenz der Releases.