Penetrationstest vorbereiten: 12 unverzichtbare Tipps

Ein Penetrationstest ist beauftragt – doch was muss das Unternehmen vor dem ersten Testtag vorbereiten? Die gute Nachricht: Sie benötigen keine perfekt dokumentierte IT-Landschaft. Entscheidend sind ein klarer Prüfauftrag, erreichbare Zielsysteme, abgestimmte Testregeln und verlässliche Ansprechpartner. Mit dieser Checkliste vermeiden Sie unnötige Verzögerungen und sorgen dafür, dass der Pentest die für Ihr Unternehmen relevanten Sicherheitsfragen beantwortet.

Warum die Vorbereitung über den Nutzen des Pentests entscheidet

Ein Pentest ist mehr als das Starten eines Schwachstellenscanners. Er untersucht innerhalb eines vereinbarten Rahmens, ob technische Schwachstellen, Fehlkonfigurationen oder unzureichende Berechtigungen praktisch ausgenutzt werden können. Je nach Auftrag werden auch mehrere Schwachstellen zu einem realistischen Angriffspfad kombiniert.

Wenn zu Beginn unklar ist, welche Systeme geprüft werden dürfen, fehlen im schlimmsten Fall wichtige Anwendungen im Test. Sind Zugänge nicht rechtzeitig eingerichtet oder blockieren Sicherheitskomponenten die Testverbindung, geht wertvolle Prüfzeit verloren. Ebenso wichtig: Aktive Sicherheitsprüfungen können Systeme belasten. Deshalb gehört die Abstimmung von Risiken und Abbruchkriterien zu einer professionellen Vorbereitung.

Die folgenden zwölf Punkte dienen als praktische Checkliste für IT-Leitung, Informationssicherheitsverantwortliche und Projektteams.

Die 12-Punkte-Checkliste zur Pentest-Vorbereitung

1. Sicherheitsziel und Fragestellung festlegen

Beginnen Sie nicht mit einer IP-Liste, sondern mit der Frage: Was soll der Test nachweisen oder widerlegen? Mögliche Ziele sind die Bewertung der externen Angriffsfläche, die Prüfung der Trennung zwischen Netzwerkzonen oder die Untersuchung, ob ein reguläres Benutzerkonto unberechtigte Rechte erlangen kann.

Ein präzises Ziel hilft, Prüfzeit dort einzusetzen, wo das Geschäftsrisiko am größten ist. „Unsere IT soll sicher sein“ ist dafür zu unspezifisch. Besser: „Kann ein Angreifer aus dem Gästenetz auf interne Verwaltungsserver zugreifen?“

2. Den Scope eindeutig abgrenzen

Der Scope beschreibt, was getestet werden darf. Halten Sie IP-Adressen, Subnetze, Domains, Anwendungen, API-Endpunkte, Cloud-Ressourcen und relevante Mandanten fest. Dokumentieren Sie auch ausdrücklich ausgeschlossene Systeme.

Gerade bei Cloud-Diensten, gemeinsam genutzten Plattformen oder extern betriebenen Anwendungen muss vorab geklärt sein, wer die Prüfung autorisieren darf. Eine technische Erreichbarkeit allein ist keine Testfreigabe. Unklare Eigentums- und Freigabeverhältnisse gehören vor Testbeginn aufgelöst.

3. Die tatsächliche Angriffsfläche zusammentragen

Eine bekannte Domain ist selten die gesamte Angriffsfläche. Denken Sie auch an VPN-Gateways, Entwicklungs- und Testumgebungen, Subdomains, Partnerzugänge, APIs und öffentlich erreichbare Administrationsoberflächen.

Sie müssen nicht alle unbekannten Systeme selbst entdecken. Eine erste Bestandsaufnahme hilft aber, kritische Assets und blinde Flecken zu erkennen. Bei einem internen Pentest zählen zusätzlich Netzsegmente, Vertrauensstellungen und Übergänge zwischen Sicherheitszonen.

4. Testart und Informationsstand abstimmen

Bei einem Black-Box-Test liegen zunächst nur wenige Informationen vor. Bei einem Grey-Box-Test erhält der Pentester ausgewählte Zugänge oder Architekturinformationen. Ein White-Box-Test kann zusätzlich Konfigurationen oder Quellcode einbeziehen.

Keine Variante ist pauschal die beste. Wer beispielsweise die Rechteprüfung eines Kundenportals untersuchen lassen möchte, sollte geeignete Testkonten bereitstellen. Soll die von außen sichtbare Angriffsfläche bewertet werden, kann ein nicht authentifizierter Test sinnvoll sein. Beide Perspektiven lassen sich kombinieren.

5. Rules of Engagement schriftlich vereinbaren

Die Rules of Engagement (RoE) sind die verbindlichen Spielregeln der Prüfung. Sie legen fest, wann und mit welchen Methoden getestet werden darf, welche Systeme geschützt werden müssen und welche Aktionen nur nach zusätzlicher Freigabe zulässig sind.

Klären Sie insbesondere den Umgang mit Denial-of-Service-Tests, Passwortangriffen, Social Engineering, produktiven Daten, Privilege Escalation und dem Nachweis möglicher Datenabflüsse. Ebenso gehören Eskalationswege, Abbruchkriterien sowie der Umgang mit unerwartet kritischen Schwachstellen dazu. Nichts davon sollte stillschweigend vorausgesetzt werden.

6. Produktivsysteme und Betriebsrisiken berücksichtigen

Nicht jeder Pentest erfordert ein Wartungsfenster. Dennoch sollten geschäftskritische Systeme, sensible Schnittstellen und Zeiten hoher Auslastung bekannt sein. Bei Produktionsanlagen, medizinischen Systemen oder Legacy-Anwendungen sind gegebenenfalls zusätzliche Schutzmaßnahmen nötig.

Prüfen Sie, ob Backups und Wiederherstellungswege im Bedarfsfall funktionieren. Stimmen Sie für riskantere Prüfschritte geeignete Zeitfenster oder weniger invasive Nachweisverfahren ab. Ziel ist eine belastbare Sicherheitsbewertung bei kontrolliertem Betriebsrisiko – nicht maximale Angriffslast um jeden Preis.

7. Testzugänge und Rollen vorbereiten

Für authentifizierte Web- oder API-Pentests sind Testkonten häufig entscheidend. Stellen Sie nach Möglichkeit mehrere Rollen bereit: zum Beispiel Benutzer, Teamleitung und Administrator sowie – bei mandantenfähigen Anwendungen – Konten aus getrennten Mandanten.

Klären Sie Mehrfaktor-Authentifizierung, Passwortwechsel, Account-Lockouts und den sicheren Versand von Zugangsdaten vorab. Verwenden Sie bevorzugt eigens angelegte, zeitlich begrenzte Konten mit passenden Testdaten. Dadurch lassen sich Berechtigungsfehler prüfen, ohne echte Benutzerdaten unnötig zu gefährden.

8. Netzwerkzugang und Sicherheitskontrollen abstimmen

Ein interner Pentest benötigt häufig einen definierten Zugang, etwa über ein separates Testgerät, einen VPN-Zugang oder einen abgesprochenen Standort im Netzwerk. Dokumentieren Sie, aus welcher Zone der Pentester startet und welche Zielzonen erreichbar sein sollten.

Auch Firewalls, WAFs, IDS/IPS und Cloud-Schutzmechanismen sind relevant. Werden Test-IP-Adressen pauschal auf eine Ausnahmeliste gesetzt, kann das die Aussagekraft eines Tests verändern. Vereinbaren Sie daher bewusst, ob Sicherheitskontrollen mitgeprüft oder bestimmte Blockaden für einzelne Prüfschritte kontrolliert umgangen werden sollen.

9. Besondere Zonenübergänge explizit beschreiben

Bei segmentierten Netzwerken reicht die Aussage „Firewall testen“ nicht aus. Formulieren Sie konkrete Verbindungen und Erwartungen.

Pro Zonenübergang sollte klar sein: Welcher Ausgangspunkt wird verwendet? Welche Systeme dürfen erreichbar sein? Welche Kommunikationswege sind vorgesehen? Und was wäre ein sicherheitskritischer Verstoß gegen die Segmentierungsabsicht?

Erst dann lässt sich bewerten, ob eine Regel technisch funktioniert und ob unerwünschte Angriffspfade bestehen. Weitere Informationen finden Sie bei yatesh zum Infrastruktur-Penetrationstest.

10. Ansprechpartner und Notfallkommunikation bestimmen

Definieren Sie eine fachliche und eine technische Kontaktperson. Für produktive Umgebungen sollte zusätzlich eine während des Testfensters erreichbare Notfallnummer vorliegen.

Wer entscheidet, wenn ein Test angehalten werden muss? Wen informiert der Pentester bei einem kritischen Fund?

Regeln Sie außerdem, ob das Security Operations Center über den Test informiert wird oder ob die Erkennungsfähigkeit bewusst mitbeobachtet werden soll. Solche Entscheidungen beeinflussen die Durchführung und müssen zur Zielsetzung passen.

11. Bericht, Vertraulichkeit und Übergabe klären

Ein guter Pentest-Bericht muss für unterschiedliche Zielgruppen nutzbar sein: Das Management benötigt eine klare Risikoeinschätzung; Administratoren und Entwickler benötigen nachvollziehbare technische Nachweise und konkrete Handlungsempfehlungen.

Vereinbaren Sie im Voraus Berichtsformat, Sprache, Verteilung, verschlüsselten Übermittlungsweg und Aufbewahrung der Prüfdaten.

Klären Sie auch, ob Zwischenergebnisse, eine Liste der getesteten Assets sowie eine Abschlussbesprechung erwartet werden. So vermeiden Sie, dass wichtige Informationen erst nach Ende des Projekts angefragt werden.

12. Behebung und Retest direkt mitplanen

Der größte Nutzen entsteht nicht durch das bloße Finden von Schwachstellen, sondern durch ihre Beseitigung. Reservieren Sie deshalb Verantwortlichkeiten und Kapazitäten für die Nachbearbeitung. Priorisieren Sie Maßnahmen nach realistischen Auswirkungen und Ausnutzbarkeit statt ausschließlich nach einem numerischen Score.

Planen Sie eine Ergebnisbesprechung und – für behobene Befunde – einen gezielten Retest ein. Dabei wird überprüft, ob die konkrete Schwachstelle geschlossen wurde.

Ein Retest ersetzt allerdings keinen vollständigen neuen Pentest, wenn sich Architektur oder Angriffsfläche wesentlich verändert haben.

Welche Unterlagen sollte das Unternehmen bereithalten?

Für das technische Kick-off reicht häufig ein schlankes Paket. Hilfreich sind:

• Eine aktuelle Liste der freigegebenen Zielsysteme und ihrer Eigentümer.

• Eine einfache Netzwerk- oder Architekturübersicht mit relevanten Sicherheitszonen.

• Testkonten und gegebenenfalls technische Zugänge, sofern sie für die vereinbarte Testart benötigt werden.

• Bekannte kritische Betriebszeiten, Besonderheiten und Ausschlüsse.

• Kontaktdaten, Eskalationswege, Testfenster und dokumentierte Rules of Engagement.

• Eine abgestimmte Erwartung an Bericht, sichere Datenübergabe und Retest.

Fehlt eine dieser Informationen, muss ein Projekt nicht zwangsläufig scheitern. Entscheidend ist, offene Punkte im Kick-off transparent zu erfassen und vor aktiven Prüfungen die notwendigen Freigaben zu klären.

Häufige Fehler bei der Vorbereitung

Unklarer Scope: Es ist nicht erkennbar, welche Subdomains, Netzwerkbereiche oder Anwendungen freigegeben sind. Das führt zu Rückfragen und möglicherweise zu ungetesteten Systemen.

Nur ein einziges Testkonto: Autorisierungs- und Mandantentrennungsfehler lassen sich dadurch oft nur eingeschränkt untersuchen.

Unbeabsichtigte Sicherheitsausnahmen: Werden Schutzmechanismen vorab deaktiviert, entspricht das Prüfergebnis möglicherweise nicht mehr der tatsächlichen Betriebsumgebung.

Kein Verantwortlicher für Findings: Selbst ein sehr guter Bericht reduziert kein Risiko, wenn niemand Maßnahmen nachverfolgt.

Fazit: Ein guter Pentest beginnt vor dem ersten Scan

Wer einen Penetrationstest vorbereitet, sollte nicht zuerst nach Tools fragen. Wichtiger sind ein konkretes Sicherheitsziel, klar freigegebene Assets, realistische Testregeln und die Bereitschaft, aus den Ergebnissen Maßnahmen abzuleiten. Damit wird aus einer punktuellen technischen Prüfung eine brauchbare Entscheidungsgrundlage für die IT-Sicherheit.

Sie planen einen Penetrationstest und sind beim Prüfumfang noch unsicher?

yatesh unterstützt bei der Abgrenzung relevanter Systeme und Angriffspfade – von extern erreichbaren Diensten über Active Directory bis zu komplexen Netzwerkzonen.

Lesen Sie auch, welche Faktoren die Kosten eines Penetrationstests bestimmen, oder vereinbaren Sie ein unverbindliches Erstgespräch.

Weiterführende Fachquellen

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment – Planung, Durchführung und Auswertung technischer Sicherheitsprüfungen.

• OWASP Web Security Testing Guide – strukturierte Testmethoden für Webanwendungen und Schnittstellen.