Ein Penetrationstest beantwortet die Frage, die im Scope steht, und sonst nichts. Lautet der Scope "Testen Sie unsere Webanwendung", erhalten Sie einen Bericht über das, was die Tester in der verfügbaren Zeit am interessantesten fanden. Das muss nicht das sein, was Sie wissen wollten.
Die Lösung ist Vorbereitung. Legen Sie Fragestellung, Regeln, Zugänge, Datenumgang und die Definition von "fertig" fest, bevor Sie Angebote einholen.
Beginnen Sie mit der Frage, nicht mit dem Ziel
Eine Liste von IP-Adressen und URLs ist eine Zielliste, kein Testziel. Das Ziel ist die Entscheidung, die der Test unterstützen soll. NIST SP 800-115 nennt mehrere Zwecke technischer Sicherheitstests, etwa das Finden von Schwachstellen in einem System oder Netzwerk und die Überprüfung der Einhaltung einer Richtlinie oder anderer Anforderungen. Das sind unterschiedliche Aufgaben, und sie erfordern unterschiedliche Tests.
Formulieren Sie das Testziel als Satz, den auch ein nicht technischer Auftraggeber versteht. Einige Beispiele:
- Kann ein angemeldeter Kunde im neuen Portal die Rechnungen eines anderen Kunden einsehen?
- Kann ein Angreifer ohne Konto die Admin-Oberfläche des Buchungssystems erreichen?
- Erfüllt die Anwendung die Anforderungen an die Zugriffskontrolle, die der Sicherheitsfragebogen unseres Kunden zitiert?
Jedes dieser Ziele bedingt einen anderen Scope, andere Konten und einen anderen Bericht. Wenn Sie es nicht in einem Satz formulieren können, sind Sie noch nicht bereit für den Einkauf. Ein kurzes Scoping-Gespräch mit den Testern oder einem Berater, etwa unserem Beratungsteam, lohnt sich vor der Angebotseinholung.
Wählen Sie eine Referenz für "getestet"
"Vollständig getestet" sagt nichts aus, solange nicht feststeht, wogegen getestet wurde. Für Webanwendungen bieten zwei OWASP-Projekte ein gemeinsames Vokabular.
Der OWASP Application Security Verification Standard (ASVS) ist eine Grundlage für das Testen technischer Sicherheitsmaßnahmen von Webanwendungen und gibt Entwicklern eine Liste von Anforderungen für sichere Entwicklung an die Hand. Die Projektseite nennt 5.0.0 als aktuelle stabile Version. Jede Anforderung hat eine nummerierte Kennung, und das Projekt empfiehlt, sie zusammen mit der Version zu zitieren, zum Beispiel v5.0.0-1.2.5. Die Version ist wichtig, weil sich Kennungen zwischen Releases ändern können.
Der OWASP Web Security Testing Guide beschreibt, wie getestet wird. Laut Projektseite ist v4.2 das aktuelle Release, 5.0 befindet sich noch in Entwicklung. Nennen Sie im Vertrag die erwartete Version, sonst geht jede Seite von einer anderen aus.
Legen Sie anschließend fest, welche Teile des ASVS im Scope liegen, und zwar nach Kapitel und Abschnitt, wie sie in der gewählten Version stehen. Die Kennung v5.0.0-1.2.5 verweist zum Beispiel auf die 5. Anforderung im Abschnitt "Injection Prevention" des Kapitels "Encoding and Sanitization". Wählen Sie die Abschnitte, die zu Ihrem Testziel passen, und verlangen Sie, dass Findings den Anforderungskennungen zugeordnet werden. Das vereinfacht Nachtests und die Nacharbeit durch die Entwickler erheblich.
Rules of Engagement
Die Rules of Engagement sind die schriftlichen Grenzen dessen, was die Tester tun dürfen. Es handelt sich um unsere Empfehlungen und nicht um Vorgaben der Quellen, aber jedes Scope-Dokument sollte diese Punkte klären:
| Punkt | Festzulegen |
|---|---|
| Umgebung | Produktion, Staging oder beides. Staging ist sicherer, aber nur aussagekräftig, wenn es der Produktionskonfiguration entspricht. |
| Zeitfenster | Daten und Uhrzeiten, und ob außerhalb der Geschäftszeiten getestet werden darf. |
| Quelladressen | Die IPs, die die Tester verwenden, damit Ihr Monitoring-Team sie von einem echten Angreifer unterscheiden kann. |
| Ausgeschlossene Techniken | Denial of Service, Social Engineering und physischer Zugang sind häufige Ausschlüsse. Halten Sie sie in jedem Fall schriftlich fest. |
| Abbruchbedingungen | Was die Tester zum Innehalten veranlasst: ein Ausfall, Zugriff auf unerwartete personenbezogene Daten, ein kritisches Finding. |
| Ansprechpartner | Zwei namentlich benannte Personen auf jeder Seite, mit Telefonnummern, die auch nachts erreichbar sind. |
Entscheiden Sie vorab, ob Ihr SOC über den Test informiert wird. Wird es informiert, testen Sie den Prozess, bleibt der Test verdeckt, testen Sie die Erkennung. Beides ist legitim, aber Sie sollten die Wahl bewusst treffen.
Testkonten und Datenumgang
Stellen Sie Konten bereit, denn ein Tester ohne Login kann nicht prüfen, was dahinter liegt. Richten Sie ein Konto pro Rolle der Anwendung ein, dazu zwei Konten in derselben Rolle, die zu verschiedenen Kunden oder Mandanten gehören. Ohne dieses Paar lässt sich nicht prüfen, ob ein Benutzer auf die Daten eines anderen zugreifen kann.
Legen Sie die Konten im Voraus an, testen Sie, ob der Login funktioniert, und klären Sie, wie mit Multi-Faktor-Authentifizierung umgegangen wird.
Vereinbaren Sie den Datenumgang im Vertrag:
- Verwenden Sie im Staging möglichst synthetische Daten. Falls die Produktion im Scope liegt, legen Sie fest, welche echten Datensätze die Tester einsehen dürfen und welche nicht.
- Legen Sie fest, wo Belege wie Screenshots, Request-Logs und extrahierte Daten gespeichert werden, wer darauf zugreifen kann und wie lange die Tester sie aufbewahren.
- Verlangen Sie, dass der Bericht selbst verschlüsselt übermittelt wird. Er ist eine Liste Ihrer Schwachstellen.
- Legen Sie die Regel für sensible Funde fest: Stoßen Tester auf personenbezogene Daten, brechen sie ab, dokumentieren die Fundstelle ohne den Inhalt zu kopieren und rufen Ihren Ansprechpartner an.
Erfolgskriterien und Berichterstattung
"Keine kritischen Findings" ist kein Erfolgskriterium. Es belohnt einen oberflächlichen Test. Definieren Sie "fertig" als Abdeckung plus Qualität des Ergebnisses: Die vereinbarten Anforderungen wurden geprüft, und jedes Finding enthält genug Details, um es zu reproduzieren und zu beheben.
NIST beschreibt seinen Leitfaden als Hilfe bei der Analyse von Findings und der Entwicklung von Gegenmaßnahmen, ebenso wie bei der Durchführung der Tests. Verlangen Sie dasselbe. Jedes Finding sollte Schritte zur Reproduktion, die betroffene Komponente, eine Schweregradbewertung mit angegebener Methode, damit Sie sie selbst nachprüfen können, und eine konkrete Empfehlung zur Behebung enthalten. Nehmen Sie einen Nachtest behobener Findings ins Angebot auf und vereinbaren Sie, wer den Bericht wann abnimmt.
Wenn Sie bei einem Anbieter wie unserem Penetrationstest-Service einkaufen, halten Sie diese Punkte im Leistungsverzeichnis fest und nicht nur im Kick-off-Gespräch.
Wo Sie anfangen
- Formulieren Sie das Testziel in einem Satz und lassen Sie es vom Fachverantwortlichen bestätigen.
- Listen Sie die Anwendungen, Umgebungen und Rollen im Scope auf und benennen Sie ausdrücklich, was nicht zum Scope gehört.
- Wählen Sie die Referenz: die ASVS-Kapitel und -Abschnitte im Scope sowie eine Version des Web Security Testing Guide, jeweils mit Versionsnummern.
- Füllen Sie die Tabelle der Rules of Engagement aus, einschließlich Ansprechpartnern, Zeitfenster und Quelladressen.
- Legen Sie Testkonten an und prüfen Sie sie, darunter zwei Konten in derselben Rolle für verschiedene Mandanten, und legen Sie die Regeln für den Datenumgang fest.
- Schreiben Sie die Erfolgskriterien in den Vertrag: Format der Findings, Methode zur Schweregradbewertung, Zuordnung zu Anforderungskennungen und ein Nachtest.
