Bereits bei der Entwicklung einer Webanwendung muss ihre Sicherheit mitgedacht werden: Diese Erkenntnis hat sich mittlerweile herumgesprochen. Zu viele potenzielle Sicherheitslücken stehen sonst einer immer vielfältiger werdenden Landschaft von Angreifern gegenüber.

Wurde das Prinzip der Security by Design auch tatsächlich im Entwicklungsprozess beachtet? Hat es wirklich zu einer sicheren Applikation geführt? Was muss im weiteren Entwicklungsprozess beachtet und nachgebessert werden? Um diese Fragen zu beantworten, ist das Mittel der Wahl seit langem der Penetration Test oder Pentest, auch in der Application Security (AppSec). Ein dediziertes Team, in der Regel von einem externen Dienstleister, versucht Schwachstellen zu finden und auszunutzen. Aus den Ergebnissen wird ein Bericht erstellt, auf dessen Grundlage das auftraggebende Unternehmen weitere Maßnahmen planen kann, beispielsweise Anpassungen im Entwicklungsprozess.

Gut ist, dass Pentests heutzutage häufiger und in mehr verschiedenen Kontexten zum Einsatz kommen als früher. Aber dies zeigt gleichzeitig auch die Schwächen des Pentests: Ein einmaliges Pentest-Projekt ist nun einmal nicht für jedes Szenario und alle Bedürfnisse geeignet. Unter einmaligen Pentests (One-off Pentesting) verstehen wir auch solche Pentests, die zwar wiederholt werden, aber in großen Abständen, beispielsweise einmal jährlich, und mit entsprechend schwerfälligem Berichtswesen. Es stellt sich also die Frage nach einer geeigneten Alternative.

Schwächen des einmaligen Pentests: langwieriges Onboarding, langsames Berichtswesen

Ein Pentest zielt (je nach Scope) direkt auf das Herz eines Unternehmens – seine IT-Infrastruktur und die dort betriebenen und gelagerten geschäftskritischen Systeme und Daten. Diese sind ganz zu Recht üblicherweise durch interne Richtlinien und technische wie organisatorische Sicherheitsmaßnahmen geschützt. Um einen sinnvollen Pentest überhaupt zu ermöglichen, ist daher in der Regel ein aufwendiges Onboarding notwendig. Dieses kann so viel Zeit in Anspruch nehmen, dass die Codebase der Anwendung, die getestet oder mitgetestet werden soll, zum Zeitpunkt des Pentests schon wieder veraltet ist. Oft sind Entwicklungszyklen so schnell, dass der Pentest durch seinen organisatorischen Overhead nicht mithalten kann. Das Resultat: Die Erkenntnisse aus dem Pentest sind gar nicht mehr praxisrelevant. Das führt auch gleich zu einer anderen wichtigen Schwäche einmaliger Pentests: nämlich die Art und Weise, wie ihre Ergebnisse dem auftraggebenden Unternehmen zugänglich gemacht werden. Dies geschieht in der Regel in Form eines statischen PDF-Berichtes. Um die Ergebnisse daraus für den Entwicklungsprozess einer Anwendung nutzbar zu machen, ist ein PDF-Bericht nicht wesentlich nützlicher als ein Bericht auf Papier. Wenn der Bericht dann doch zu Änderungen im nächsten Entwicklungszyklus führt, werden auch diese wieder evaluiert, es wird wieder ein Bericht geschrieben – und bis die Effektivität der Maßnahmen auf diese Art und Weise festgestellt werden kann, vergehen weitere Monate.

Der Pentest als Blackbox und die Gefahren eines routinierten Blicks

Während der Durchführung des Pentests ist dieser zudem oft eine Blackbox für den Kunden: Nur der Zeitraum ist bekannt, aber während des Tests auftretende Probleme oder Zwischenergebnisse werden nicht immer zeitnah besprochen.  Das hängt auch von der Policy und Unternehmenskultur des beauftragten Dienstleisters ab – sind die Pentester während des Tests für den Kunden ansprechbar oder abgekapselt? Das kann von Unternehmen zu Unternehmen stark variieren, nicht immer zur Zufriedenheit des Kunden. Und wenn andererseits die Zusammenarbeit zwischen Pentest-Dienstleister und Kunden bei einem Pentest so gut war, dass sie zur Regel wird, geht dies mit einer anderen Gefahr einher: Verständlicherweise werden beim nächsten und übernächsten Test wieder dieselben Mitarbeitenden des Dienstleisters eingesetzt, falls verfügbar, denn sie kennen die zu testende Anwendung und Umgebung ja schon. Aber hier stellt sich leicht Betriebsblindheit ein. Ein frischer Blick von außen würde unter Umständen Schwachstellen entdecken, die dem routinierten Personal nicht mehr auffallen.

Die Alternative: Pentesting as a Service (PTaaS)

Mit zunehmender Cloudifizierung der IT-Infrastrukturen in Unternehmen gibt es in immer mehr Bereichen die Chance, IT-Services in Anspruch zu nehmen, die herkömmliche Strukturen und Prozesse agiler und effizienter machen. So auch im Pentesting, nämlich beim Pentesting as a Service (PTaaS) als Alternative zum einmaligen Pentest.

Bei PTaaS handelt es sich um regelmäßig durchgeführte manuelle Pentests in Verbindung mit automatisierten Scans. Dann nämlich kann PTaaS kontinuierlich ablaufen und auch kontinuierlich Ergebnisse liefern. Dies wird erreicht durch den Einsatz eines Application-Security-Scanners, dessen Output an gefundenen Schwachstellen automatisch einer kontextabhängigen Risikobewertung unterzogen wird. Bereiche, die als besonders risikoreich bewertet wurden oder die von automatisierten Schwachstellenscannern nicht abgedeckt werden, werden gezielt manuellen Pentests unterzogen.

Ergebnisse in Echtzeit, transparent aufbereitet

Automatisiertes Pentesting löst eine Reihe der oben genannten Probleme herkömmlicher Pentests:

1. Wenn die PTaaS-Lösung einmal läuft, liefert sie kontinuierlich und in Echtzeit Ergebnisse – ab dem ersten Tag. Diese werden automatisiert ermittelt, manuell verifiziert und gegebenenfalls durch weitere manuelle Ergebnisse ergänzt. Entwickler werden automatisch benachrichtigt, sobald auf der PTaaS-Plattform neue Ergebnisse vorliegen, die dann direkt in den aktuellen Entwicklungszyklus einfließen können.
2. Wenn Entwickler basierend auf diesen Ergebnissen Fehler in der Applikation beheben, können sie auf der PTaaS-Plattform einen entsprechenden neuen Test anfordern – und sehen so umgehend, ob die Maßnahmen effektiv waren. Hierzu kann, wenn gewünscht, sogar ein dedizierter Kommunikationskanal zwischen Entwicklern und Pentestern geöffnet werden.
3. Durch die Transparenz einer PTaaS-Plattform mit entsprechendem Dashboard werden auch Probleme und Hemmnisse für das Pentesting sofort klar und können behoben werden, etwa fehlende Anmeldeinformationen. So wird weder Zeit noch Geld beim Dienstleister verschwendet.
4. Und schließlich kann ein großer PtaaS-Dienstleister wie Outpost24 eine viel größere Vielfalt an menschlichen Testern zur Verfügung stellen als ein kleinerer Anbieter. Das verhindert Betriebsblindheit: Einen zusätzlichen Tester hinzuzuziehen, der mit einem unverbrauchten Blick in die toten Winkel der bisherigen Testaktivitäten blickt, ist mit minimalem Aufwand möglich.

PTaaS mit Outpost24

Outpost24 setzt bereits seit langem auf risikobasiertes Schwachstellenmanagement, denn nur mit einem risikobasierten Ansatz können aus dem Überfluss der vorhandenen Daten sinnvolle Entscheidungsgrundlagen entstehen. Auf dieser Basis wurde auch SWAT als PTaaS-Lösung von Outpost24 geschaffen. Sie bietet Ihnen stets den aktuellsten Überblick über Ihre AppSec-Schwachstellen. Durch die Kombination von Gründlichkeit und Genauigkeit manueller Pentests mit automatisiertem, kontinuierlichem Vulnerability Scanning versetzen wir Unternehmen in die Lage, ihre Webanwendungen effizient und sicher zu entwickeln und zu betreiben. Weitere Informationen finden Sie auf unserer SWAT-Produktseite. Nehmen Sie gern Kontakt auf, um ein unverbindliches Beratungsgespräch zu vereinbaren.