Ein Penetrationstest wird nach Tagen bezahlt. Jeder Tag, an dem die Tester auf ein Konto warten, raten, wie eine Funktion gedacht ist, oder von Ihrer eigenen Firewall blockiert werden, ist ein Tag, der bei der Suche nach Schwachstellen fehlt. Den größten Teil dieser Wartezeit können Sie schon vor dem Start beseitigen.
Entscheiden
Wie lautet die Frage? „Können wir den neuen Bezahlvorgang sicher freigeben?“ und „Was kann uns jemand aus dem Internet antun?“ führen zu unterschiedlichen Tests. Schreiben Sie die Frage in einem Satz auf; der Prüfumfang ergibt sich daraus.
Was gehört zum Prüfumfang und was nicht? Führen Sie die Anwendungen, die Adressen und die Umgebungen auf. Führen Sie auch die Ausschlüsse auf: den Zahlungsanbieter, die Systeme der Muttergesellschaft, den alten Dienst, der schon ausfällt, wenn man ihn nur ansieht.
Welche Umgebung? Am besten eignet sich eine Staging-Umgebung, die der Produktion entspricht: Die Tester können gründlich vorgehen, und nichts Echtes steht auf dem Spiel. Gibt es nur die Produktion, vereinbaren Sie die Zeiten und die Techniken, die ausgeschlossen sind.
Wie viel wissen die Tester? Ein Test mit Konten und Dokumentation findet pro Tag mehr als ein Blindtest. Ein Blindtest beantwortet eine enge Frage: was ein Außenstehender ohne Informationen erreicht. Entscheiden Sie, wofür Sie bezahlen.
Vorbereiten
Konten. Eines für jede Rolle, und zwar in zwei getrennten Mandanten, wenn das Produkt Mandanten hat: Die Zugriffskontrolle zwischen Kunden lässt sich mit einem einzigen Kunden nicht testen. Legen Sie die Konten vor dem Start an, melden Sie sich mit jedem einmal an und prüfen Sie, ob darin realistische Daten liegen.
Dokumentation. API-Spezifikationen, ein Architekturdiagramm, eine Beschreibung der Rollen und der wichtigsten Abläufe. Nicht perfekte Dokumente sind besser als keine.
Zugang. Liegt die Testumgebung hinter einem VPN oder einer Allowlist, richten Sie den Zugang vorab ein und testen Sie ihn. Entscheiden Sie, ob die Web Application Firewall eingeschaltet bleibt. Ist die Anwendung Gegenstand des Tests, lassen Sie die Tester an der Firewall vorbei; ist es die Firewall, bleibt sie eingeschaltet, und Sie sagen es dazu.
Daten. Füllen Sie die Testumgebung mit Daten, die den echten in der Struktur ähneln, nicht im Inhalt. Echte personenbezogene Daten in einer Testumgebung sind ein Befund, bevor der Test begonnen hat.
Backups. Vergewissern Sie sich, dass sich die getestete Umgebung wiederherstellen lässt. Tester arbeiten sorgfältig; Backups sind für den Fall da, dass Sorgfalt nicht ausgereicht hat.
Informieren
Das Betriebsteam und das Monitoring-Team, sofern der Test nicht gerade sie prüfen soll. Geben Sie ihnen die Quelladressen der Tester und die Termine. Sonst endet der erste Tag damit, dass die Tester blockiert sind und ein Sicherheitsvorfall eröffnet ist.
Den Hosting- oder Cloud-Anbieter, wo dessen Richtlinien es verlangen. Die großen Cloud-Anbieter verlangen keine Vorabmeldung für Tests Ihrer eigenen Ressourcen im Rahmen ihrer veröffentlichten Regeln; kleinere Hosting-Unternehmen oft schon.
Dienstleister, deren Systeme berührt werden. Deren Zustimmung muss schriftlich vorliegen.
Eine Ansprechperson, die während der Testzeiten erreichbar ist und Entscheidungen treffen darf: ein Konto verlängern, einen Dienst neu starten, den Test abbrechen.
Unterzeichnen
- die Vertraulichkeitsvereinbarung (NDA), bevor irgendetwas von dem oben Genannten übergeben wird;
- den Vertrag;
- das Genehmigungsschreiben und die Testregeln.
Wozu jedes dieser Dokumente dient, beschreibt der Artikel Was einen Penetrationstest legal macht.
Während des Tests
- Deployen Sie nicht in die getestete Umgebung, ohne die Tester zu informieren. Ein Befund, der über Nacht verschwindet, kostet einen Tag Verwirrung.
- Beheben Sie Befunde nicht mitten im Test, ausgenommen kritische. Wenn Sie doch einen beheben, sagen Sie es.
- Beantworten Sie Fragen schnell. Ein Tester, der fragt, wie eine Funktion gedacht ist, hat meistens etwas gefunden.
- Rechnen Sie damit, dringende Befunde sofort zu erhalten. Eine kritische Schwachstelle wird gemeldet, sobald sie bestätigt ist, nicht erst im Abschlussbericht.
Nach dem Test
- Lesen Sie die Zusammenfassung mit dem Management, die Befunde mit der Entwicklung. Beide Teile sind für unterschiedliche Leser geschrieben.
- Nehmen Sie am Abschlussgespräch teil. Es ist die günstigste Stunde des Projekts.
- Planen Sie die Behebung nach Priorität und sagen Sie den Testern, wann die Korrekturen ausgerollt sind.
- Nutzen Sie den Nachtest. Eine Behebung, die nicht überprüft wurde, ist eine Annahme.
- Behandeln Sie den Bericht vertraulich. Bis die Behebungen umgesetzt sind, ist er eine Anleitung für einen Angriff auf Sie. Für Kunden und Prüfer gibt es das Bestätigungsschreiben.
Die Checkliste
| Vor dem Start | Erledigt |
|---|---|
| Frage und Prüfumfang schriftlich festgehalten, einschließlich der Ausschlüsse | |
| Umgebung gewählt, Testzeitfenster vereinbart | |
| Konten für jede Rolle angelegt, in zwei Mandanten, wenn das Produkt Mandanten hat | |
| Dokumentation übergeben | |
| Netzwerkzugang eingerichtet und getestet | |
| Testdaten vorhanden, keine echten personenbezogenen Daten | |
| Backups überprüft | |
| Betrieb, Monitoring und Anbieter informiert | |
| Ansprechperson benannt | |
| NDA, Vertrag, Genehmigungsschreiben, Testregeln unterzeichnet |
Auf der Seite jeder Leistung steht, was der jeweilige Test von Ihnen braucht.