Arten von Penetrationstests: welche Prüfung welche Frage beantwortet
Es gibt nicht den Pentest. Ein Test der externen Infrastruktur beantwortet eine andere Frage als ein Test des Active Directory oder der Cloud-Konfiguration. Diese Seite ordnet die gängigen Testarten, erklärt Black, Grey und White Box und zeigt, wann welche Art sinnvoll ist.
- 7 Testarten von der externen Infrastruktur bis zum physischen Zutritt
- 3 Ansätze Black Box, Grey Box, White Box
- OWASP, PTES, BSI anerkannte Methodiken je Testart
- 1 Frage bestimmt den Zuschnitt: Was wollen Sie wissen?
Sieben Testarten im Vergleich
Jede Testart hat einen Ausgangspunkt, eine typische Fragestellung und eine Methodik, an der sich der Tester orientiert. Die Tabelle hilft, im Erstgespräch die richtige Sprache zu sprechen.
| Testart | Ausgangspunkt des Testers | Typische Fragestellung | Methodischer Bezug |
|---|---|---|---|
| Externe Infrastruktur | Internet, ohne Zugangsdaten. Geprüft werden Firewalls, VPN-Zugänge, Mail- und Webserver, exponierte Dienste. | Wie weit kommt ein Angreifer von außen, ohne dass jemand im Unternehmen einen Fehler macht? | PTES als Rahmen, BSI-Praxis-Leitfaden IS-Penetrationstest |
| Internes Netz | Netzwerkanschluss im Gebäude oder ein simulierter kompromittierter Arbeitsplatz. | Was erreicht ein Angreifer, der bereits drinnen ist: Segmentierung, veraltete Systeme, Freigaben, Wege zu kritischen Servern? | PTES, BSI-Praxis-Leitfaden |
| Webanwendung und API | Anwendung oder Schnittstelle, meist mit Testkonten in verschiedenen Rollen. | Lassen sich Authentifizierung, Berechtigungen, Eingabeverarbeitung oder Session-Handling umgehen oder missbrauchen? | OWASP Testing Guide, OWASP Top 10, OWASP API Security Top 10 |
| Cloud-Konfiguration | Lesender Zugang zur Cloud-Umgebung (Microsoft 365, Azure, AWS, Google Cloud) plus Sicht von außen. | Sind Identitäten, Rollen, Speicher, Netzwerkregeln und Protokollierung so konfiguriert, dass ein Fehler nicht zum Vorfall wird? | Herstellerempfehlungen und Benchmarks, etwa CIS Benchmarks |
| Active Directory | Ein normales Domänenkonto, wie es jeder Mitarbeitende hat. | Gibt es einen Pfad vom Standardnutzer zum Domänen-Administrator? Passwortrichtlinien, Delegationen, Kerberos, veraltete Protokolle. | PTES, etablierte AD-Angriffstechniken nach MITRE ATT&CK |
| Social Engineering und Phishing | Öffentlich verfügbare Informationen über Unternehmen und Mitarbeitende. | Reagieren Mitarbeitende und Meldewege richtig auf gezielte E-Mails, Anrufe oder Nachrichten? Greifen die technischen Filter? | Abgestimmtes Szenario, Schutz der Mitarbeitenden, Einbindung von Datenschutz und Betriebsrat |
| Physischer Zutritt | Gebäude, Empfang, Zutrittssysteme, Arbeitsplätze, Serverraum. | Kommt eine unbefugte Person an Netzwerkdosen, Geräte oder Unterlagen? Werden Besucher und Fremde angesprochen? | Abgestimmtes Szenario mit Notfallkontakt und Legitimationsschreiben |
Black Box, Grey Box, White Box
Der Box-Ansatz legt fest, wie viel der Tester vorab weiß. Er wird pro Testart gewählt und bestimmt Aufwand, Tiefe und Aussagekraft.
| Ansatz | Vorwissen des Testers | Simuliert | Stärke | Grenze |
|---|---|---|---|---|
| Black Box | Nur der Unternehmensname oder die IP-Bereiche. Keine Zugangsdaten, keine Dokumentation. | Einen externen Angreifer ohne Insiderwissen. | Zeigt die tatsächlich sichtbare Angriffsfläche und was Aufklärung darüber preisgibt. | Viel Testzeit fließt in Aufklärung. Schwachstellen hinter dem Login bleiben oft unentdeckt. |
| Grey Box | Teilinformationen: Testkonten, Architekturskizze, Liste der Systeme im Scope. | Einen Angreifer mit gestohlenen Zugangsdaten oder einen Insider mit normalen Rechten. | Bestes Verhältnis von Aufwand und Erkenntnis. Berechtigungsfehler und laterale Bewegung werden sichtbar. | Erfordert Vorbereitung auf Ihrer Seite: Konten, Freigaben, Ansprechpartner. |
| White Box | Voller Einblick: Quellcode, Konfigurationen, Netzpläne, Administratorzugang zum Lesen. | Einen Prüfer, der jeden Winkel kennt. | Höchste Tiefe. Findet Logikfehler und Konfigurationsschwächen, die von außen nie sichtbar wären. | Aufwändiger in Vorbereitung und Analyse. Sagt wenig darüber, was ein realer Angreifer sieht. |
Faustregel: Grey Box für die meisten Fragestellungen, Black Box, wenn die sichtbare Angriffsfläche selbst die Frage ist, White Box vor dem Go-live einer kritischen Anwendung oder bei eigener Softwareentwicklung.
Wann welche Art sinnvoll ist
Der Auslöser bestimmt die Testart. Sechs typische Situationen aus dem Mittelstand und die Prüfung, die dazu passt.
- Go-live
Ein Kundenportal oder eine API geht produktiv
Test der Webanwendung oder API, Grey Box mit Testkonten in allen Rollen, bei eigener Entwicklung ergänzt um White-Box-Anteile. Vor dem Go-live, damit Befunde ohne Zeitdruck behoben werden können.
- Nachweis
Kunde, Versicherer oder Auditor fragt nach einem Test
Externer Infrastrukturtest, oft kombiniert mit der Webanwendung. Er beantwortet die Frage, die in Fragebögen am häufigsten gestellt wird, und liefert einen Bericht mit Datum, Umfang und Retest.
- Ransomware
Sie wollen wissen, wie schlimm ein Einbruch würde
Interner Test plus Active Directory, Grey Box mit einem Standardkonto. Zeigt, ob ein einzelner kompromittierter Arbeitsplatz zur Übernahme der Domäne und damit zum Stillstand des Unternehmens führen kann.
- Cloud
Migration nach Microsoft 365, Azure oder AWS abgeschlossen
Prüfung der Cloud-Konfiguration: Identitäten, bedingter Zugriff, Rollen, Speicherfreigaben, Protokollierung. Fehlkonfiguration ist in der Cloud der häufigste Weg zum Vorfall, nicht die Plattform selbst.
- Menschen
Awareness-Programm läuft, Wirkung unklar
Phishing-Simulation oder Social-Engineering-Test mit abgestimmtem Szenario. Gemessen werden Meldequote und Reaktionszeit der Organisation sowie die Wirksamkeit technischer Filter, nicht das Verhalten Einzelner.
- Standort
Sensible Bereiche, Produktion oder Forschung vor Ort
Physischer Test von Zutritt, Besucherführung und Arbeitsplatzsicherheit. Sinnvoll, wenn der Verlust von Prototypen, Unterlagen oder Netzzugang vor Ort ein realistisches Szenario ist.
In vier Schritten zur passenden Testart
So wählen wir mit Ihnen Testart, Box-Ansatz und Umfang aus, bevor ein Angebot eingeholt wird.
-
Die Frage formulieren
Was soll der Test beantworten? „Kommt jemand von außen rein?“ führt zu einer anderen Prüfung als „Steht die Produktion, wenn ein Laptop kompromittiert ist?“. Ohne klare Frage wird der Umfang vom Budget statt vom Risiko bestimmt.
-
Kronjuwelen und Angriffsfläche benennen
Welche Systeme, Daten und Prozesse kosten im Ernstfall am meisten? Welche davon sind von außen erreichbar, welche nur intern? Daraus ergibt sich, welche Testarten überhaupt relevant sind.
- Inventar der aus dem Internet erreichbaren Systeme als Grundlage
- Abhängigkeiten von Dienstleistern und Cloud-Anbietern notieren
-
Box-Ansatz und Tiefe festlegen
Pro Testart wird entschieden, welches Vorwissen der Tester bekommt und wie tief geprüft wird: nur Nachweis der Schwachstelle oder auch Ausnutzung und Weiterbewegung. Ausgeschlossene Systeme und Denial-of-Service-Tests werden ausdrücklich geregelt.
-
Umfang, Rhythmus und Nachweisziel abstimmen
Welche Systeme sind im Scope, in welchem Zeitfenster, mit welchem Bericht für welche Adressaten? Wenn der Test als Nachweis für ISO 27001, NIS2 oder einen Kunden dienen soll, wird das jetzt festgelegt, nicht nach dem Test.
Social Engineering und physische Tests brauchen einen eigenen Rahmen
Tests, die Menschen einbeziehen, prüfen die Organisation, nicht Einzelne. Diese Punkte gehören vor dem Start geregelt.
- Geschäftsführung gibt das Szenario schriftlich frei, Datenschutz und gegebenenfalls Betriebsrat sind informiert und eingebunden.
- Auswertung erfolgt auf Organisationsebene: Meldequote, Reaktionszeit, Wirksamkeit der Filter. Keine Listen einzelner Personen, keine Sanktionen.
- Vorwände und Szenarien schließen private Themen, Gesundheitsdaten und Drohkulissen aus.
- Physische Tester tragen ein Legitimationsschreiben und haben einen Notfallkontakt, damit eine Ansprache durch Mitarbeitende geordnet aufgelöst werden kann.
- Der Kreis der Mitwisser ist klein, aber definiert: Wer weiß Bescheid, wer darf den Test abbrechen?
- Ergebnisse fließen in Schulung, Meldewege und technische Maßnahmen, mit Rückmeldung an die Belegschaft, was gelernt wurde.
Vertiefung zu Penetrationstests
-
Ablauf eines Penetrationstests
Scoping, Permission to Attack, Aufklärung, Test, Bericht mit CVSS-Schweregraden, Abschlussgespräch und Retest.
-
Pentest oder Schwachstellenscan?
Abgrenzung zu Scan, Red Team und Bug Bounty, Nachweiswert für ISO 27001, NIS2 und Versicherer, sinnvoller Rhythmus.
-
Penetrationstests im Überblick
Testarten, Einordnung, Ablauf, Nachweise und der Selbsttest, ob Ihr Unternehmen bereit für einen Pentest ist.
Zu den Testarten
Welche Testart sollten wir als Erstes beauftragen?
Wenn noch nie getestet wurde, beantwortet ein externer Infrastrukturtest die dringendste Frage: Was sieht und erreicht ein Angreifer aus dem Internet? Betreiben Sie ein Kundenportal oder eine API, gehört die Webanwendung gleich dazu. Danach folgen internes Netz und Active Directory, weil dort im Ransomware-Fall der Schaden entsteht.
Kann man mehrere Testarten in einem Auftrag kombinieren?
Ja, und das ist oft sinnvoll. Ein Test, der außen beginnt und nach einem gelungenen Einstieg innen weitergeht, zeigt den realen Angriffspfad. Wichtig ist, dass jede Testart im Scoping eigene Ziele, Zeitfenster und Freigaben bekommt, damit Aufwand und Ergebnis zuzuordnen bleiben.
Ist ein Grey-Box-Test weniger realistisch als Black Box?
Er ist anders realistisch. Black Box zeigt, was ein Unbekannter ohne Vorwissen erreicht, verbraucht aber Testzeit für Aufklärung, die ein echter Angreifer über Wochen betreiben würde. Grey Box gibt dem Tester das Wissen, das ein Insider oder ein Angreifer mit gestohlenen Zugangsdaten hätte, und liefert in derselben Zeit deutlich mehr Befunde.
Brauchen wir einen Cloud-Pentest, wenn der Anbieter zertifiziert ist?
Die Zertifizierung des Anbieters deckt dessen Anteil ab: Rechenzentrum, Hypervisor, Plattformdienste. Ihre Konfiguration, Ihre Identitäten, Rollen, Speicherfreigaben und Netzwerkregeln liegen in Ihrer Verantwortung. Genau dort entstehen in der Praxis die meisten Cloud-Vorfälle, und genau das prüft ein Test der Cloud-Konfiguration.
Dürfen wir unsere Mitarbeitenden mit Phishing testen?
Ja, mit klarem Rahmen: Information von Betriebsrat und Datenschutz, keine personenbezogene Auswertung Einzelner, keine Sanktionen, ein Ziel, das die Organisation bewertet und nicht Personen. Die Simulation misst, ob Meldewege und technische Filter funktionieren. Bloßstellung zerstört das Vertrauen, das eine Sicherheitskultur braucht.
Edouard Jacques
Welche Testart passt zu Ihrer Frage?
Im kostenlosen Erstgespräch klären wir Anlass, Kronjuwelen und Angriffsfläche und leiten daraus Testart, Box-Ansatz und Umfang ab. Herstellerneutral und ohne eigenes Interesse am Testumfang.
- Einordnung: welche Testart Ihre Frage beantwortet
- Grey, Black oder White Box für Ihre Systeme
- Zuschnitt, der zugleich als Nachweis für Kunden und Auditoren taugt
Danke, wir rufen Sie an.
Sie hören innerhalb eines Werktags von uns, meist deutlich schneller. Wenn Sie lieber gleich einen festen Termin wählen möchten, geht das direkt im Kalender auf jamorie.eu.
Termin selbst wählen