Vorbereitung auf einen Penetrationstest
Ein Penetrationstest ist nur so gut wie sein Umfang. Mit wenigen Tagen Vorbereitung erhalten Sie einen deutlich wertvolleren Bericht.
Bei einem Penetrationstest beauftragen Sie ein versiertes Team damit, Ihr Produkt nach vereinbarten Regeln anzugreifen und über die Funde zu berichten. Kunden und Auditoren verlangen oft danach – und es ist einer der besten Wege, Probleme zu entdecken, für die das eigene Team betriebsblind geworden ist. Wie viel Sie daraus mitnehmen, hängt maßgeblich von der Vorbereitung ab.
Den Umfang festlegen
Legen Sie genau fest, was die Tester angreifen dürfen: die Web-App, die mobilen Apps, die API, die Admin-Tools, das Cloud-Konto. Nennen Sie die Umgebungen und Domains. Was nicht auf der Liste steht, wird nicht getestet. Nehmen Sie deshalb auch die Bereiche auf, die Kunden wichtig sind, nicht nur jene, bei denen Sie sich sicher fühlen. Wird eine Komponente von einem Drittanbieter betrieben, prüfen Sie vorher, ob Sie diese einbeziehen dürfen.
Die Testregeln vereinbaren
Halten Sie das Testfenster fest, die IP-Adressen der Tester, was tabu ist (Denial of Service, Social Engineering, echte Kundendaten) und wen man anruft, wenn etwas ausfällt. Prüfen Sie die Richtlinien Ihres Hosting-Providers für Sicherheitstests und melden Sie den Test an, falls erforderlich. Informieren Sie das Team, das Ihre Alarme überwacht, damit ein echter Vorfall nicht fälschlicherweise für Teil des Tests gehalten wird.
Umgebung und Konten vorbereiten
Eine Staging-Umgebung zu testen ist meist sicherer – vorausgesetzt, sie entspricht exakt der Produktion: derselbe Code, dieselbe Konfiguration, dieselben Sicherheitseinstellungen. Erstellen Sie Testkonten für jede Rolle, darunter Konten in zwei separaten Kundenorganisationen. So können die Tester prüfen, ob ein Kunde die Daten eines anderen einsehen kann. Bei Produkten mit vielen Kunden ist das oft die wichtigste Erkenntnis.
Teilen Sie Dokumentation, API-Spezifikationen und Zugangsdaten, außer Sie wünschen ausdrücklich einen reinen Blick von außen. Tester, die mit dem Wissen eines Insiders starten, nutzen ihre Zeit für echte Schwachstellen, statt mühsam Grundlagen zu erforschen.
Nach Schweregrad und Reichweite beheben
Der Bericht stuft die Funde nach Schweregrad ein. Beheben Sie kritische und hohe Schwachstellen zuerst, aber achten Sie auch auf deren potenzielle Reichweite: Ein mittleres Problem auf der Login-Seite kann schwerer wiegen als ein hohes in einem internen Tool. Dokumentieren Sie jede Behebung kurz, da Auditoren und Kunden oft nachfragen, wie mit Befunden umgegangen wurde.
Einen Retest anfordern
Die meisten Tester bieten einen Retest der behobenen Schwachstellen an oder haben ihn inklusive. Nutzen Sie das. Ein Retest bestätigt, dass die Korrekturen greifen, und liefert Ihnen einen aktualisierten Bericht mit geschlossenen Punkten – genau das wollen Kunden sehen.
Das richtige Dokument teilen
Kunden benötigen selten den vollständigen Bericht, da dieser detailliert beschreibt, wie Ihr Produkt angegriffen werden kann. Bitten Sie die Tester um ein Testat (Letter of Attestation): eine kurze Zusammenfassung von Umfang, Zeitraum und Ergebnissen, die Sie unbesorgt weitergeben können. Den vollständigen Bericht sollten nur Personen erhalten, die ihn zwingend einsehen müssen.
Kurz zusammengefasst
Ein klarer Umfang, schriftliche Regeln, eine produktionsnahe Umgebung, Testkonten für jede Rolle und ein Retest nach den Korrekturen. Wenn Sie dies vorbereiten, wird der Bericht zu einem klaren Handlungsplan statt zu einer bösen Überraschung.