it-swarm.com.de

Woher wissen, wann ein Pen-Test abgeschlossen ist?

Insbesondere unter Berücksichtigung von Kundenwebsites, auf denen wir aufgefordert wurden, einen Pen-Test durchzuführen; An welchem ​​Punkt hören wir auf und sagen, dass wir fertig sind?

Wir haben Zugriff auf verschiedene Tools (einige automatisiert, einige manuell); Aber wenn wir sagen "wir haben alle unsere Werkzeuge ausprobiert und konnten keine Fortschritte erzielen", könnte dies so ausgelegt werden, dass wir sagen, dass wir nicht klug genug sind (und es gibt immer einen Hacker da draußen, der klüger sein könnte).

Damit; Wie schützen wir uns vor verärgerten Kunden, die behaupten, wir hätten nicht mit der gebotenen Sorgfalt gearbeitet? Gibt es einen Standard-Berichtsrahmen, in dem wir arbeiten können?

28
PeteCon

Das ist also eine sehr interessante Frage für die Branche im Allgemeinen. Ich würde vorschlagen, dass Sie damit umgehen

  • Nehmen Sie etwas in Ihren Vertrag auf, das die Haftung für Schwachstellen ausschließt, die beim Testen nicht festgestellt wurden. Der Grund dafür ist, dass es im Grunde unmöglich ist, sicher zu sein, dass Sie jedes ausnutzbare Problem auf einer Website oder einem anderen System gefunden haben. Um nur ein Beispiel zu nennen: Denken Sie an alle Websites, die jahrelang anfällig für Shellshock waren. Sollten alle Pen-Test-Unternehmen, die eine dieser Websites berührt haben, dafür verantwortlich sein, ihren Kunden nichts zu sagen?

  • Haben Sie eine Methodik, die sagt, was Sie tun werden. Dies sollte die allgemeinen Testbereiche abdecken, die abgeschlossen werden. Bei Websites sollten Sie sich auf die OWASP Top 10 als Ausgangspunkt stützen. Dies gibt Ihnen einige Gemeinsamkeiten mit dem Kunden in Bezug auf das, was Sie betrachten werden.

  • Stellen Sie sicher, dass Ihr Unternehmen die Grundlagen mit einer Checkliste abdeckt. Wie @rapli oben sagt, dokumentieren Sie alle kleinen Dinge, aber überschreiten Sie nicht die Schwere. Während es wichtig ist sicherzustellen, dass Ihr Test nicht nur eine Checkliste ist, kann die Verwendung einer Checkliste peinliche Fehler vermeiden, bei denen grundlegende Tests übersehen werden.

Das Problem, auf das Sie stoßen könnten/werden, sind unrealistische Erwartungen von Kunden. das ist von Fall zu Fall zu adressieren. Wenn Sie einen Kunden finden, der erwartet, dass seine komplexe Anwendung in 5 Testtagen vollständig überprüft wird, sollten Sie erklären, warum dies kein praktisches Konzept ist :)

34
Rory McCune

Geben Sie im Vertrag an, welche Sicherheitsaspekte Sie untersuchen, und übernehmen Sie nur die Verantwortung für diese. Sie werden nicht immer Schwachstellen finden. Aber ich garantiere Ihnen, dass Sie einige Kleinigkeiten finden werden, und ich schlage vor, dass Sie jedes Detail in den Bericht aufnehmen, HSTS in Überschriften, schwache Chiffren usw. vermissen. Sie sehen also, dass Sie etwas getan haben.

Es gibt einige mir bekannte Berichterstellungstools, die jedoch entweder nicht öffentlich verfügbar oder kostenpflichtig sind.

5
Rápli András

Als Ergänzung zu den anderen Antworten:

Wenn in Ihrem Vertrag Ihr Geltungsbereich und die zu testenden Schwachstellen angegeben sind, können Sie aufschreiben, dass Sie tatsächlich Fälle im Geltungsbereich gegen bekannte, im Vertrag definierte Schwachstellen getestet haben. Etwas wie:

SQL injection:

SQL-Injections are ...

We identified 42 Input fields in the Webpages in Scope. We identified 0 
Input fields vulnerable to SQL injection (with our used method).

Nachteil ist: falls tatsächlich eine SQL-Injection in einem der aufgelisteten Felder möglich ist, die an den Bericht angehängt sind; Sie haben keine 100% ige Sicherheit versprochen, aber versprochen, dass dies keine Sicherheitslücke ist, aber dann haben Sie sicherlich etwas falsch gemacht - deshalb sollten Sie irgendwie angeben, welche Art von Tests Sie verwendet haben, welche Art von SQL-Injections auf dem neuesten Stand der Technik sind In der Einführung zu SQL-Injections werden Sie also nicht dafür verantwortlich gemacht, dass Sie keine Angriffe finden, die in Zukunft gefunden werden.

Dies funktioniert auch für allgemeine Website-Sicherheitsaufgaben:

HTTPS: https is ... recommended to use TLS X.Y ...

We determined the usage of https for all websites in Scope with TLS X.Y.
Certificates expire Dates are set to Date X which is in the recommended
certificate expire time range. Certificates hold an 4096-Bit key which is
acceptable for current usage.

Versuchen Sie auch, Vorlagen für Ihre Berichte zu erstellen, da Sie nicht immer wieder alles über SQL-Injection, HTTPS/TLS usw. neu schreiben möchten, sodass Sie nur die Ergebnisse Ihrer Tests eingeben müssen. Dies stellt auch sicher, dass Sie alle Tests durchgeführt haben und keine verpasst haben, wenn Sie einen Absatz sehen, der nicht geschrieben wurde und nichts gefunden hat oder keine Ergebnisse hat.

1
SchreiberLex