Einführung

Agile Penetrationstests bzw. agile Pentests sind nicht als Neuerfindung von Penetrationtests zu verstehen, sondern wenden die agilen Prinzipien darauf an. Außerdem soll es dafür sorgen, dass die Tests bereits in der agilen Entwicklung durchgeführt werden, um ein maximales Sicherheitsniveau zu erreichen und gleichzeitig Kostenrahmen einzuhalten. Zu verhindern ist es vor allem, dass Sicherheitsanforderungen den agilen Entwicklungsprozess stören, weswegen agiles Pentesting nahtlos in den Entwicklungsprozess integriert werden muss. Das Ziel muss sein, dass sich die Penetrationstester aktiv in den Entwicklungsprozess einbringen.

Was bringen agile Penetrationstests?

Sicherheitslücken sind im Prinzip auch nur Bugs, die bestimmte Auswirkungen in Bezug auf die Sicherheitsaspekte der Applikation haben. Wie bei anderen klassischen Bugs auch, lassen sich diese während der Entwicklung am einfachsten und wirtschaftlichsten lösen. Werden also agile Penetrationstests und die sich daraus ergebenden Anforderungen umgesetzt, erhält man eine sicherere Software und spart im gleichen Zug auch noch Geld, da die Fehlerbehebung einfacher umzusetzen ist – eine Win-Win-Situation sozusagen 😉

Sicherheit und das Product Backlog

Agile Penetrationstests sind weit mehr, als die einfache Durchführung von technischen Tests. Um sichere Anwendungen zu entwickeln, müssen Sicherheitsanforderungen bereits beim Software-Entwurf berücksichtigt werden. Das beinhaltet wichtige Aspekte wie die Authentifizierung, das Berechtigungsmanagement, die Benutzerverwaltung, aber auch Eingabe- und Ausgabe-Filter sowie sicherheitsrelevantes Logging und weitere Punkte.

Damit sichergestellt wird, dass diese Punkte auch sauber umgesetzt werden, müssen diese Anforderungen bereits ins Product Backlog eingetragen werden.

Böse Geschichten: Evil User Stories

Genauso wie normale User Stories, die den eigentlichen Funktionsumfang der Applikation abdecken, müssen auch Evil User Stories definiert werden. Dabei geht es darum festzulegen, was ein Angreifer böses innerhalb einer Applikation tun könnte.

Das OWASP-Projekt hat beispielsweise folgende vier Evil User Stories definiert, die schon einen großen Teil abdecken. Diese sind von mir frei übersetzt und wurden ursprünglich auf OWASP veröffentlicht.

• Beispiel 1: Als ein Hacker kann ich manipulierte Daten in URLs übertragen, damit ich auf Daten und Funktionen zugreifen kann, für die ich nicht berechtigt bin.
• Beispiel 2: Als ein Hacker kann ich manipulierte Daten als Teil das Request-Bodies (z.B. bei POST-Anfragen) übertragen, damit ich auf Daten und Funktionen zugreifen kann, für die ich nicht berechtigt bin.
• Beispiel 3: Als ein Hacker kann ich manipulierte Daten in HTTP-Headern senden, damit ich auf Daten und Funktionen zugreifen kann, für die ich nicht berechtigt bin.
• Beispiel 4: Als ein Hacker kann ich alle Daten lesen und bearbeiten, die Ihre Anwendung annimmt bzw. ausgibt.

Dies ist natürlich sehr generisch und auf HTTP-basierte Applikationen zugeschnitten, aber das deckt schon sehr viel von dem ab, was als Angreifer getan werden kann. Dies kann man jetzt noch beliebig erweitern: so könnte man nach dem Security-by-Design-Konzept sagen, dass ein Angreifer auch den Applikationsserver direkt angreifen könnte und deswegen eine sichere Konfiguration bzw. ein Härtungs-Guide mitgegeben werden muss.

Die GAU-User-Story

Da dies aber schnell ins uferlose ausartet möchte ich vorschlagen, dass Sie zumindest noch eine weitere Evil User Story definieren: Die des Worst-Case.

Diese ist je nach Applikation unterschiedlich. Entwickeln Sie Software für die Steuerung von Kraftwerken oder anderen Industrieanlagen, ist es relevant, dass niemand unautorisiert Ihre Anwendung bedienen kann um damit Schaden in der echten Welt anzurichten. Wenn Sie Buchhaltungssoftware, oder Software für rechtssichere Archivierung entwickeln wird die Integrität der Daten sehr wichtig sein, so dass keine Manipulationen an den Daten durchgeführt werden können. Für andere Anwendungen wäre es eine Katastrophe, wenn Daten unbefugt ausgelesen werden können.

Definieren Sie für sich das Szenario, das für Ihre Applikation und die Anwender den größten Schaden anrichten kann und behandeln Sie dieses als Ihre wichtigste Evil User Story.

Vor dem Sprint

Damit die Sicherheitsanforderungen sauber umgesetzt werden, ist es empfehlenswert, dass der spätere Pentester bereits bei den Sprint Planning Meetings anwesend ist.

Dadurch wird zum einem sichergestellt, dass wichtige Sicherheitsfunktionen mit in das Sprint Backlog integriert werden. Außerdem kann der Auditor gleich von vorneherein sagen, welche Funktionen am ehesten angreifbar sind und worauf dringend geachtet werden muss.

Zum anderen hilft es dem Penetrationstester, dass er von Anfang an versteht, wofür Funktionen da sind und wie diese zu nutzen sind. Dies verringert die Zeit die er benötigt, um sich in der Anwendung zurechtzufinden, was die späteren Tests bedeutend umfänglicher gestaltet und gleichzeitig die Effizienz erhöht.

Tests nach den Sprints – der eigentliche Pentest

Sind alle Anforderungen umgesetzt, kommen nun die eigentlichen Sicherheitstests, also der Penetrationstest dran. Genau wie normale Softwaretests werden diese nach den Sprints durchgeführt. Die Tests konzentrieren sich dabei vor allem auf die abgearbeiteten Features des Sprint Backlogs.

Die Prüfungen sollten dabei im Rahmen eines „White-Box“-Tests umgesetzt werden, das bedeutet, dass der Penetrationstester Zugriff auf alle relevanten Informationen hat, inklusive Zugriff zum Quelltext und im Idealfall auch zum Server.

White-Box Tests haben den Vorteil, dass dem Prüfer alle relevanten Informationen zur Verfügung stehen. Dies macht die Tests bedeutend effizienter und spart damit auch wieder Ressourcen. Außerdem steigen die Chancen, dass Schwachstellen identifiziert werden, da manche Lücken nur schwer in Rahmen von Black-Box Tests gefunden werden können.

Die Ergebnisse der agilen Penetrationstests müssen dann eingearbeitet und nach der Behebung neu geprüft werden. Dies erfolgt am besten im gleichen Rahmen, wie auch normale Bugs behoben werden. Für bestimmte Prüfungen, z.B. auf Berechtigungen lassen sich teilweise automatisierte Tests schreiben. Diese können dann in Test-Suites integriert werden, damit wichtige Prüfungen permanent im Rahmen der normalen Software-Tests mitgetestet werden. Wie dies am besten funktionieren kann, werden wir in einem anderen Blog-Artikel behandeln.

Fazit

Agiles Pentesting ist bedeutend mehr, als einfach nur Prüfungen während der Entwicklung durchzuführen. Es reicht nicht, nach jedem Sprint einfach einen Penetrationstest zu machen. Die Penetrationstester müssen das Konzept der agilen Entwicklung verstanden haben, um die Tests überhaupt effizient durchführen zu können. Außerdem muss sichergestellt werden, dass der Pentester das Projekt über einen langen Zeitraum begleitet, da nur so sichergestellt werden kann, dass alle Funktionen getestet werden. Sonst würde nach jedem Sprint ein vollumfänglicher Penetrationstest durchgeführt werden, oder sehr viel Zeit in die immer neue Einarbeitung von Auditoren gesteckt werden. Beides ist nicht zu empfehlen.

Um wirklich sichere Anwendungen zu schreiben muss Sicherheit von Anfang an berücksichtigt werden. Das fängt schon bei der Software-Architektur an und geht über regelmäßige Prüfungen. Auch Schulungen für Entwickler helfen Schwachstellen von vornherein zu verhindern. Agile Penetrationstests integrieren sich in den Entwicklungsprozess. Das sorgt dafür, dass die Softwaresicherheit einen sehr hohen Stellenwert hat und das Sicherheitsniveau ein höheres Level erreicht. Schließlich ist ein Pentest am Ende der Entwicklung nur eine Aufzählung von Schwachstellen, die aufwändig und teuer in der eigentlich schon fertigen Anwendung behoben werden müssen. Durch agiles Pentesting werden alle relevanten Faktoren bereits in der Entwicklung berücksichtigt und Schwachstellen nicht erst an den Kunden geliefert. Gerne unterstützen wir Sie bei der Integration von agilen Penetrationstests im Rahmen unserer Beratungsleistungen. Wir werden in den nächsten Wochen und Monaten noch mehr zu diesem Thema schreiben – dann auch wieder mit mehr Technik 😉