Blackbox, Greybox und Whitebox bezeichnen den Wissensstand der Tester zu Testbeginn – von null Vorinformation über Testkonten bis zu vollem Einblick in Quellcode und Architektur.
Die Begriffe Blackbox, Greybox und Whitebox beschreiben, wie viel die Tester über das Prüfobjekt wissen, bevor sie beginnen. Sie stammen aus dem Softwaretest und sind heute Standardvokabular im Scoping jedes Penetrationstests. Die Wahl der Perspektive bestimmt, welche Frage der Test beantwortet, wie realistisch er ist und wie effizient die verfügbare Zeit genutzt wird.
Wichtig für Entscheider: Mehr Vorwissen bedeutet nicht weniger Realismus, sondern mehr Tiefe. Ein echter Angreifer hat unbegrenzt Zeit für Aufklärung; ein Testteam hat zwei Wochen. Vorwissen gleicht diesen Unterschied aus.
Die drei Perspektiven im Vergleich
| Perspektive | Wissensstand | Stärke | Schwäche |
|---|---|---|---|
| Blackbox | Nur Name oder URL des Ziels; keine Zugangsdaten, keine Dokumente | Zeigt die Außensicht eines opportunistischen Angreifers; prüft Reconnaissance und exponierte Dienste | Viel Zeit fließt in Aufklärung; Schwachstellen hinter der Anmeldung bleiben unentdeckt |
| Greybox | Testkonten verschiedener Rollen, Architekturüberblick, Schnittstellenbeschreibung | Bestes Verhältnis von Zeit und Tiefe; prüft Berechtigungen, Geschäftslogik und Trennung zwischen Mandanten oder Rollen | Erfordert Vorbereitung auf Kundenseite (Konten, Testdaten) |
| Whitebox | Quellcode, Konfigurationen, Netzpläne, Administratorzugang | Findet auch tief liegende Fehler in Logik, Kryptografie und Konfiguration; ideal vor Produktivgang | Aufwendig; sagt wenig darüber aus, was ein Angreifer von außen tatsächlich sieht |
Beim Red Teaming ist die Perspektive in der Regel Blackbox – das Team startet wie ein echter Angreifer ohne Insiderwissen. Assumed Breach entspricht einer Greybox-Variante: Das Team erhält einen definierten Startpunkt, aber keine weiteren Informationen.
Bedeutung für Unternehmen
Die Perspektive wirkt direkt auf Kosten und Aussagekraft. Ein Blackbox-Test einer Webanwendung prüft in zwei Wochen vor allem die Anmeldeseite; ein Greybox-Test mit zwei Testkonten prüft in derselben Zeit, ob Kunde A die Daten von Kunde B sehen kann – ein Befund, der in der Praxis weit häufiger und folgenreicher ist. Für Anwendungen mit Kundendaten empfehlen wir daher Greybox als Standard.
Ein typischer Fehler ist, Blackbox als „härteren“ und damit besseren Test zu bewerten. Tatsächlich ist er für viele Fragestellungen der weniger aussagekräftige, weil er die Zeit des Teams in Aufklärung bindet, die ein Angreifer ohnehin leisten würde. Ein zweiter Fehler ist Whitebox ohne Fokus: Quellcode in großem Umfang lässt sich in einem Testfenster nicht vollständig sichten; es braucht eine Priorisierung auf kritische Module.
Praxis-Hinweise
- Wählen Sie die Perspektive nach der Frage: Außensicht (Blackbox), Berechtigungen und Logik (Greybox), Code-Qualität vor Produktivgang (Whitebox).
- Stellen Sie für Greybox-Tests Konten aller relevanten Rollen bereit – inklusive eines Kontos mit minimalen Rechten.
- Kombinieren Sie Perspektiven: Ein kurzer Blackbox-Abschnitt zu Beginn zeigt, was ohne Vorwissen auffindbar ist; danach wechselt das Team zu Greybox.
- Dokumentieren Sie die gewählte Perspektive im Bericht; sie ist für die Einordnung der Ergebnisse durch Revision und Aufsicht unerlässlich.