Web-Pentest auf Live-System geplant – wie Testplan schreiben wegen Ausfallrisiko?

Passt höllisch auf automatische Formular-Crawler auf. Wenn so ein Tool über euren Newsletter-Signup oder das Kontaktformular stolpert, haut es euch innerhalb von 10 Minuten 20.000 Fake-Mails in die Warteschlange und euer Mailserver landet ruckzuck auf jeder Blacklist. Sowas sofort excluden.

Richtet den Testern separate Test-Accounts ein und gebt denen fiktives Guthaben. Auf keinen Fall dürfen die mit echten, lagerhaltigen Produkten rumtesten oder Warenkörbe blockieren, sonst sind eure Bestände für echte Kunden gesperrt.

Wir haben vor zwei Jahren live testen lassen. Der Tester hat bei der Suche nach SQLi ein Query mit Sleep-Befehl abgefeuert. Nach 3 Minuten war der Connection-Pool der Datenbank komplett dicht und der Checkout war 20 Minuten lang komplett tot. Habt unbedingt DevOps auf Standby während des Tests!

Wir haben das nachts zwischen 02:00 und 06:00 Uhr machen lassen. Bei sonst 1.000 Orders am Tag kommen nachts vielleicht 15 rein. Selbst wenn da was blockiert hätte, wäre der finanzielle Schaden gleich null gewesen. Macht das niemals tagsüber auf Prod!

Wie genau soll das Payment getestet werden? Buchen die Cent-Beträge über echte Terminals ab oder hängt da ein Fake-Gateway dahinter? Wenn ihr das im Vertrag nicht haarklein definiert, habt ihr am nächsten Tag riesen Theater mit der Buchhaltung.

schreibt unbedingt eine einzige autorisierte Notfallnummer in den Testplan dann sobald irgendwas komisch läuft muss der Pentester bei einem Stop-Anruf von dieser Nummer sofort alle Tools abschalten.

Staging nicht 1:1 wie Live hinzubekommen und dann auf Prod einen Pentest wie 'nen Stresstest durchzuziehen, ist echt so 'ne typische Abenteuerlust unserer Branche. Macht wenigstens 'ne Stunde vorm Test ein volles Backup, damit ihr am nächsten Morgen nicht im absoluten Katastrophenszenario aufwacht.

Im aufzusetzenden Testvertrag müssen die Verantwortlichkeiten beider Parteien klar definiert sein; zudem sollte verbindlich geregelt werden, dass der Auftragnehmer für kommerzielle Schäden haftet, falls das Testteam von den freigegebenen Plänen und Zeitfenstern abweicht.

Letztes Jahr haben wir fast genau dasselbe erlebt. Schaut zuerst welche Daten ihr bei der Entscheidungsfindung zur Hand habt.

Aus Erfahrung weiß ich das.

Beim Umsetzen gibt es drei Dinge zu beachten. Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

Nur weil alle es tun, heißt es nicht, dass es richtig ist. An deiner Stelle würde ich so vorgehen.

Ich stimme zu.

Es gab drei verschiedene Ansichten die sich alle ergänzen. Wenn du zu einem Thema drei verschiedene Antworten bekommst war die Frage falsch gestellt.

Korrigiert mich falls ich falsch liege.

Bleibe dran.

Beim Umsetzen gibt es drei Dinge zu beachten. Wenn man Fehlalarme anschreit, meldet sich danach niemand mehr.

Das ist meine Meinung, ich behaupte nicht dass es absolut richtig ist.

Genau so, und das ist zudem kaum bekannt. Das allein zu versuchen ist der teuerste Weg.

Letztes Jahr haben wir fast genau dasselbe erlebt. Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt.

Ich hoffe, das hilft dir weiter.

Ich habe mich lange damit beschäftigt. Wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

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

Danke fürs Schreiben das ist genau richtig. Dass das Backup im gleichen Netzwerk und mit derselben Identität erreichbar ist, macht es zum Teil des Ziels.

Fehler auf der web pentest testplan-Seite sind meist rückgängig zu machen, aber teuer. Schreibt mir, wenn ihr Fragen habt ich antworte so gut ich kann.