Eine sichere und messbare Testumgebung für autorisierte Penetrationstests

1. Ziel und Genehmigung des Tests von Anfang an klären

Definieren Sie zuerst die zu beantwortende Frage: Können zwei Kunden die Datensätze des jeweils anderen sehen? Lassen sich Administratoraktionen nachvollziehen? Ist die Verwaltungsoberfläche einer Filiale unnötig erreichbar? Eng gefasste, messbare Fragen verbinden den Befund des Testteams mit einer konkreten Aufgabe für Entwickler oder Netzadministratoren. Scanbericht, Quellcodeprüfung und Penetrationstest haben unterschiedliche Umfänge. Führen Sie sie in Beschaffungsunterlagen nicht als identische Leistung auf.

NIST SP 800-115 behandelt die Planung von Sicherheitsbewertungen, die Analyse von Befunden und Verbesserungsmaßnahmen. Anhang B bietet eine Ausgangsvorlage für Einsatzregeln. [1] Die schriftliche Genehmigung muss Systemeigentümer, betroffene Ressourcen, Zeitfenster, erlaubte Tätigkeiten, ausgeschlossene Bereiche, Regeln zur Datenverarbeitung und die zum Abbruch berechtigte Person festhalten. Bei Cloud- oder Drittanbieterdiensten sind deren geltende Testrichtlinien zusätzlich zu prüfen.

2. Das Schulungslabor von der Produktion trennen

Ein kontrolliertes Labor kann aus Testgeräten, Zielanwendung und Beobachtungskomponenten bestehen. Separate virtuelle Netze und Zugriffsregeln sollten Übergänge in Produktionssysteme verhindern. Externe Verbindungen sind auf die erforderlichen Dienste zu begrenzen; auch der Verwaltungszugriff sollte getrennt sein. Die Bezeichnung einer virtuellen Maschine oder ein anderer IP-Bereich beweisen für sich allein keine funktionierende Isolation. Erlaubte und zu blockierende Wege müssen geprüft werden.

Für Schulungen können Anwendungen mit absichtlich eingebauten Schwachstellen eingesetzt werden. OWASP Juice Shop ist ein solches Schulungsprojekt. [2] Ein solches Ziel mit Kundendaten zu befüllen oder auf einem öffentlich erreichbaren Produktionsserver bereitzustellen, ist kein geeigneter Laboraufbau. Erstellen Sie eine von Ihnen verwaltete Umgebung mit begrenztem Zugriff. Im Training erworbene Fähigkeiten berechtigen nicht zum Testen fremder Systeme. Auch dieser Leitfaden enthält keine Testanleitung für externe Systeme.

3. Daten und Identitäten müssen zum Labor gehören

Arbeiten Sie mit synthetischen Kunden-, Bestell- und Benutzerdatensätzen. Sind echte Daten erforderlich, verwenden Sie ein vom datenschutzrechtlich Verantwortlichen genehmigtes Verfahren und eng begrenzte Zugriffsrechte. Nutzen Sie, wo möglich, Maskierung oder Datenminimierung. Produktive API-Schlüssel, Kennwörter und Zahlungsinformationen dürfen nicht in die Testkopie übernommen werden. Für Testkonten müssen Eigentümer, Rolle und Zeitpunkt der Schließung feststehen.

Zur Prüfung von Berechtigungen werden Konten mit unterschiedlichen Rollen und verschiedenen Beispielkunden benötigt. Der OWASP-Ansatz für Autorisierungstests hilft, die erwarteten Rechte zwischen Rollen und Vorgängen in einer klaren Matrix zu erfassen. [3] Soll eine Rolle beispielsweise nur den eigenen Datensatz lesen dürfen, werden Testergebnis und zugehöriger Eintrag im Anwendungsprotokoll gemeinsam dokumentiert. Ziel ist nicht, die Daten einer realen Person zu erlangen, sondern mit kontrollierten Daten zu prüfen, ob die definierte Grenze wirksam ist.

4. Einen reproduzierbaren Ausgangszustand und eine Beobachtungsstruktur schaffen

Nehmen Sie Anwendungsversion, Konfiguration, Testdaten und Netzregeln in die Ausgangsdokumentation auf. Es muss klar sein, wie die Umgebung nach einem Versuch in einen sauberen Zustand zurückgeführt wird. Ein Snapshot kann dabei helfen, setzt jedoch möglicherweise verbundene externe Dienste oder externe Datenspeicher nicht automatisch zurück. Der Rücksetzplan muss sämtliche Abhängigkeiten des getesteten Systems berücksichtigen.

Nutzen Sie zeitlich synchronisierte Protokolle, Vorgangsaufzeichnungen und bei Bedarf Bildschirmnachweise mit reduzierten sensiblen Inhalten. Nachweisdateien dürfen nur dem berechtigten Team zugänglich sein; Aufbewahrungsdauer und Löschverantwortung sind festzulegen. Wählen Sie zudem praktische Abbruchkriterien: Bei einer unerwarteten Produktionsverbindung, Daten außerhalb des Testumfangs oder nicht akzeptierten Auswirkungen auf einen Dienst wird die Tätigkeit gestoppt und die verantwortliche Person informiert. Beobachtung verbessert sowohl die Sicherheit des Versuchs als auch seine spätere Nachvollziehbarkeit.

5. Befund, Korrektur und erneuter Test bilden eine Kette

Der OWASP Web Security Testing Guide verbindet Sicherheitstests mit dem Entwicklungslebenszyklus. Ein einzelnes Werkzeug deckt nicht alle Sicherheitsprobleme ab. [4] Beschreiben Sie im Bericht nicht nur den Schweregrad, sondern den betroffenen Geschäftsablauf, Voraussetzungen, beobachtetes Ergebnis und empfohlene Kontrolle. Eine Zusammenfassung für Führungskräfte sollte Entscheidungen erleichtern; der technische Anhang muss dem berechtigten Team eine erneute Bewertung des Befunds ermöglichen.

Stellen Sie nach der Korrektur dieselbe Frage an die neue Version und prüfen Sie zugleich, ob der normale Benutzerablauf weiterhin funktioniert. Verantwortliche Person, Zieldatum und Abnahmekriterium für jeden Befund verhindern, dass der Bericht lediglich archiviert wird. Ein erfolgreicher Labortest bedeutet nicht, dass sämtliche Produktionsrisiken beseitigt sind. Berichten Sie über Unterschiede zwischen den Umgebungen. Bei der Bewertung von Netz- und Zugriffsdesign mit MyFi Business können die Anforderungen der Testumgebung an Anbindung, Isolation und technische Koordination gesondert festgelegt werden.

6. Vor Beginn der Arbeiten prüfen

Die technische Arbeit sollte erst beginnen, wenn die folgenden Unterlagen bereitstehen. Ändert sich ein Punkt, müssen der Verantwortliche für den Testumfang und das ausführende Team dieselbe aktuelle Dokumentation verwenden.

• Liegen schriftliche Genehmigung, Ressourcenliste, Zeitfenster und Abbruchverantwortlicher vor?
• Wurden die Bedingungen von Drittanbietern und Cloud-Diensten geprüft?
• Ist der Zugriff des Labors auf die Produktion und nicht benötigte externe Ziele begrenzt?
• Sind synthetische Daten, getrennte Testkonten und die Ausgangskonfiguration vorbereitet?
• Sind Zuständigkeiten für Nachweiszugriff, Aufbewahrung, Bereinigung und Rücksetzung geklärt?
• Sind Bericht, Korrektur und erneuter Test ausdrücklich im Leistungsumfang enthalten?