Wie läuft ein Penetrationstest ab – und wie wickeln wir das im Live-System ohne Ausfallzeiten ab?

Das A und O gegen Ausfälle ist ein striktes Rate-Limiting für die Scanner. Gebt den Testern eine Grenze von maximal 5 bis 10 Requests pro Sekunde vor. Vor allem bei Suchmasken oder Endpunkten, die schwere DB-Queries triggern, sollten SQL-Injection-Tests ausschließlich manuell und dosiert gefahren werden.

Was vorab ins Lastenheft gehört: 1) Keine DoS/DDoS- oder Brute-Force-Angriffe auf der Live-Umgebung, 2) Kein Löschen oder Modifizieren von Echtdaten in der Datenbank, 3) Testfenster strikt zwischen 01:00 und 06:00 Uhr, 4) Bei kritischen Treffern sofortige Alarmierung, ohne erst auf den Abschlussbericht zu warten.

Bei unserem ersten Pentest hat der Tester das Registrierungsformular automatisiert befeuert und damit unseren SMS-Verifizierungsservice getriggert. Innerhalb von drei Stunden gingen 14.000 SMS raus – und der Provider hat unsere Nummer wegen Spam-Verdachts gesperrt. Vor dem Test externe Benachrichtigungs-, SMS- und Bezahldienste unbedingt in den Sandbox- oder Mock-Modus versetzen!

Braucht der Kunde ein TSE-zertifiziertes Audit oder reicht der Bericht einer Firma mit internationalen Zertifizierungen wie CREST oder OSCP? Das macht sowohl bei der Anbieterauswahl als auch beim Budget einen riesigen Unterschied.

Wir haben für unsere B2B-Plattform in ähnlicher Größenordnung einen Grey-Box-Test machen lassen. Hat insgesamt 5 Arbeitstage gedauert, raus kamen 2 kritische und 4 mittlere Lücken. Weil wir das Testfenster nachts gelegt hatten, blieb die CPU-Last immer unter 40 Prozent und es gab absolut keine Ausfälle.

Falls eure Infrastruktur das hergibt: Zieht euch einen maskierten Klon der Live-Datenbank und baut eine exakte Staging-Umgebung auf. Wenn ihr den Test dort laufen lasst, riskiert ihr im Live-Betrieb absolut gar nichts.

Macht euch nicht verrückt, kein seriöser Sicherheitsberater schießt mutwillig ein Produktivsystem ab. also solange die Absprache stimmt und DoS draußen bleibt, läuft das Ganze völlig reibungslos durch.

Ergänzung: Wurde unten schon gefragt, die Antwort habe ich im zweiten Beitrag geschrieben.

Vor Beginn müssen Geheimhaltungsvereinbarung (NDA) und Letter of Attestation (Einverständniserklärung) zwingend handschriftlich unterzeichnet vorliegen. Klare Haftungsgrenzen und das Recht zum sofortigen Testabbruch durch euch sind aus Sicht des Sicherheitsmanagements unverzichtbar.

Hier ist etwas zu beachten. Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher.

Man sollte der Reihe nach vorgehen. Wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

Ich hoffe, das hilft dir weiter.

Bleibe dran.

Das wusste ich nicht.

Bei mir war es genau umgekehrt, deshalb schreibe ich das. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Aus Erfahrung weiß ich das.

Wir sind auch eine Zeit lang an derselben Stelle hängen geblieben. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.

Nur als Notiz, könnte nützlich sein.

Dieser Rat passt meiner Meinung nach nicht auf jeden. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.

Danke fürs Schreiben, das ist genau richtig. Wenn man Fehlalarme anschreit, meldet sich danach niemand mehr.

Wenn deine Situation anders ist, ändert sich das natürlich.

Ich sehe das anders. Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt.

An deiner Stelle würde ich so vorgehen.

Kannst du das etwas genauer erklären? Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.

Wenn es jemand anders macht, würde mich das auch interessieren.