Ein Penetrationstest Schritt für Schritt

Ein kritisches System wird produktiv geschaltet, ein externes Audit steht bevor oder die Geschäftsführung fragt nach belastbaren Nachweisen für die Wirksamkeit der Schutzmaßnahmen. In solchen Situationen reicht es nicht, nur Schwachstellenscanner laufen zu lassen. Ein Penetrationstest prüft gezielt, ob und unter welchen kontrollierten Bedingungen technische oder organisatorische Schwächen tatsächlich ein Risiko für dein Unternehmen darstellen.

Ein Penetrationstest ist kein unkontrollierter Angriff und kein Wettbewerb zwischen Administration und Testteam. Er ist eine vereinbarte Sicherheitsprüfung mit dem Ziel, reale Risiken sichtbar zu machen und priorisiert zu beheben. Jede technische Prüfung braucht eine ausdrückliche schriftliche Beauftragung, klar definierte Ziele und einen verbindlichen Scope. Ohne Auftrag sind Zugriffsversuche auf fremde Systeme unzulässig und können strafbar sein. Dieser Artikel ordnet die üblichen Phasen allgemein ein und ersetzt keine Rechtsberatung.

1. Ziele, Scope und Beauftragung festlegen

Die Qualität eines Penetrationstests entscheidet sich bereits vor der ersten technischen Untersuchung. Wenn nicht klar ist, welche Systeme, Anwendungen, Schnittstellen und organisatorischen Prozesse geprüft werden dürfen, entstehen entweder gefährliche Lücken im Test oder unnötige Betriebsrisiken.

Zu Beginn klärst du deshalb, welches Sicherheitsziel im Vordergrund steht. Denkbare Ziele sind beispielsweise:

• Prüfung einer neuen Webanwendung vor dem Go Live
• Bewertung der extern erreichbaren Angriffsfläche
• Überprüfung der Segmentierung zwischen Netzen
• Bewertung von Berechtigungen in einer besonders schutzwürdigen Umgebung
• Prüfung, ob Mitarbeitende Social Engineering Versuche erkennen und korrekt melden
• Validierung, ob Überwachung, Alarmierung und Incident Response greifen

Der Scope beschreibt präzise, was eingeschlossen und was ausgeschlossen ist. Dazu gehören Domains, IP Bereiche, Anwendungen, Mandanten, Schnittstellen, Standorte und Zeitfenster. Ebenso wichtig sind Ausschlüsse: produktionskritische Altsysteme, medizinische Geräte, Systeme mit engen Wartungsfenstern oder Dienste, bei denen Lastspitzen erhebliche Folgen hätten.

Die schriftliche Beauftragung sollte Verantwortlichkeiten und Eskalationswege benennen. Sie regelt insbesondere, wer auf Seiten des Unternehmens Entscheidungen trifft, wer im Notfall erreichbar ist und wann der Test sofort unterbrochen werden muss. Häufig wird dies in Regeln zur Durchführung, oft als Rules of Engagement bezeichnet, zusammengefasst.

Zu klärender Punkt	Warum er wichtig ist
Testziel und Schutzbedarf	Verhindert Tests ohne verwertbaren Sicherheitsbezug
Systeme und Zeitfenster	Schützt den Betrieb und schafft Verlässlichkeit
Erlaubte Testmethoden	Vermeidet unerwünschte Auswirkungen
Ansprechpartner und Eskalation	Ermöglicht schnelles Handeln bei Auffälligkeiten
Umgang mit Daten und Nachweisen	Schützt vertrauliche Informationen
Abbruchkriterien	Reduziert das Risiko von Betriebsstörungen

Ein guter Scope ist nicht einfach möglichst groß. Er ist so konkret, dass das Testteam sinnvoll prüfen kann und du die Ergebnisse später nachvollziehbar auf Verantwortliche, Systeme und Maßnahmen übertragen kannst.

2. Vorbereitung und Schutz des Betriebs

Vor dem Test werden technische und organisatorische Voraussetzungen abgestimmt. Dazu zählt, ob das Security Operations Center, der Helpdesk oder nur einzelne Führungskräfte informiert werden. Diese Entscheidung hängt vom Ziel ab. Soll die Erkennung durch das SIEM und die Reaktion des Incident Response Teams bewertet werden, darf die Vorabinformation sehr begrenzt sein. Soll dagegen eine Anwendung besonders tief geprüft werden, helfen feste technische Ansprechpartner bei der sicheren Einordnung von Auffälligkeiten.

Wichtig ist eine belastbare Ausgangslage. Dokumentiere vorab relevante Systemstände, aktuelle Konfigurationen und verfügbare Wiederherstellungswege. Prüfe, ob Backups funktionieren und ob für kritische Dienste ein Notfallverfahren existiert. Ein Penetrationstest soll Schwachstellen aufdecken, nicht die Wiederanlaufplanung ersetzen.

Auch Datenschutz und Vertraulichkeit gehören in diese Phase. Testende können auf personenbezogene Daten, Geschäftsgeheimnisse oder Zugangsinformationen stoßen. Deshalb legst du fest, welche Daten erhoben werden dürfen, wie Nachweise geschützt werden und wie lange sie aufbewahrt werden. Sensible Inhalte sollten im Bericht minimiert, pseudonymisiert oder nur über sichere Kanäle bereitgestellt werden.

3. Aufklärung der Angriffsfläche verstehen

In der Aufklärungsphase verschafft sich das Testteam ein Bild der vereinbarten Umgebung. Aus defensiver Sicht beantwortet diese Phase eine zentrale Frage: Welche Informationen und Systeme sind für Außenstehende oder berechtigte interne Nutzende sichtbar?

Dabei geht es etwa um öffentlich erreichbare Dienste, technische Hinweise in Webanwendungen, veraltete Komponenten, Konfigurationsfehler, unklare Zuständigkeiten oder unbeabsichtigt veröffentlichte Informationen. Die Ergebnisse helfen dir, deine Angriffsfläche zu reduzieren.

Für die Verteidigung ist besonders wertvoll, zwischen erwarteter und tatsächlich sichtbarer Angriffsfläche zu vergleichen. Wenn beispielsweise ein nicht mehr benötigter Dienst erreichbar ist, eine Testumgebung öffentlich zugänglich bleibt oder Dokumente zu viele technische Details enthalten, ist das ein konkreter Ansatzpunkt für das Schwachstellenmanagement.

Diese Phase zeigt auch, ob grundlegende Hygiene funktioniert:

• Sind nicht benötigte Dienste abgeschaltet?
• Werden Systeme, Domains und Zertifikate zentral inventarisiert?
• Gibt es klare Prozesse für Änderungen und Stilllegungen?
• Sind öffentliche Informationen auf das notwendige Maß begrenzt?
• Werden externe Lieferanten und Schnittstellen regelmäßig bewertet?

4. Kontrollierte technische Validierung

Nach der Aufklärung prüft das Testteam, ob identifizierte Schwächen unter den vereinbarten Rahmenbedingungen tatsächlich relevant sind. Der Unterschied zum automatisierten Schwachstellenscan ist entscheidend: Scanner finden Hinweise, ein Penetrationstest bewertet Zusammenhänge, Auswirkungen und mögliche Fehlalarme.

Die Validierung erfolgt kontrolliert und möglichst schonend. Das Testteam dokumentiert Voraussetzungen, Beobachtungen und Auswirkungen, ohne unnötige Veränderungen an Systemen vorzunehmen. Besonders sensible Aktionen, etwa bei produktionsnahen Anwendungen oder kritischen Berechtigungen, erfordern eine vorherige Freigabe oder werden vollständig ausgeschlossen.

Aus Sicht der Verteidigung interessieren dabei nicht nur einzelne technische Schwachstellen. Entscheidend sind Angriffspfade. Eine mittlere Fehlkonfiguration kann beispielsweise erst in Verbindung mit zu weitreichenden Berechtigungen, fehlender MFA oder unzureichender Netzwerksegmentierung ein hohes Risiko erzeugen.

Typische Prüfbereiche sind:

• Identitäts- und Berechtigungskonzepte nach dem Prinzip Least Privilege
• Schutz von Administrationszugängen durch MFA und sichere Freigabeprozesse
• sichere Konfiguration von Webanwendungen und Schnittstellen
• Patchstände und Umgang mit bekannten Schwachstellen
• Trennung von Entwicklungs-, Test- und Produktionsumgebungen
• Protokollierung sicherheitsrelevanter Ereignisse
• Wirksamkeit von Erkennung und Reaktion bei auffälligem Verhalten

Ein professioneller Test vermeidet riskante Belastungen, soweit sie nicht ausdrücklich vereinbart sind. Eine Verfügbarkeitsprüfung ist etwas anderes als ein Penetrationstest und muss gesondert geplant werden.

5. Beobachtung, Kommunikation und Eskalation

Während der Durchführung braucht es klare Kommunikationswege. Wenn Sicherheitsalarme ausgelöst werden, muss feststehen, ob und wie das Testteam identifiziert werden kann. Gleichzeitig sollte diese Abstimmung nicht dazu führen, dass Warnungen pauschal ignoriert werden. Jeder Alarm verdient zunächst eine fachliche Bewertung.

Für dein Security Team liefert der Test wertvolle Erkenntnisse: Wurden relevante Ereignisse im SIEM erfasst? Waren die Protokolle vollständig? Erkannten Mitarbeitende verdächtige Kontaktversuche? Wurde der Incident Response Prozess eingehalten? Solche Beobachtungen zeigen oft Lücken, die rein technische Tests nicht sichtbar machen.

Treten unerwartete Auswirkungen auf, greifen die vereinbarten Abbruch- und Eskalationskriterien. Dazu können erhöhte Fehlerraten, Leistungseinbrüche, Hinweise auf Datengefährdung oder die Berührung nicht freigegebener Systeme gehören. Sicherheit entsteht hier durch Transparenz und verantwortungsvolle Entscheidungen, nicht durch möglichst spektakuläre Ergebnisse.

6. Auswertung und Risikobewertung

Nach Abschluss der Prüfung werden die Befunde konsolidiert, geprüft und priorisiert. Ein guter Bericht trennt klar zwischen Beobachtung, nachgewiesener Auswirkung und Annahmen. Er beschreibt nicht nur, dass eine Schwachstelle vorhanden ist, sondern auch, welches Schutzgut betroffen sein kann und welche Voraussetzungen für ein Risiko erfüllt sein müssen.

Zur technischen Einordnung kann CVSS helfen. Der Common Vulnerability Scoring System Wert ist jedoch nur ein Baustein. Für deine Priorisierung brauchst du zusätzlich den Geschäftskontext:

• Wie kritisch ist das betroffene System?
• Sind vertrauliche Daten, Integrität oder Verfügbarkeit gefährdet?
• Ist die Schwachstelle von außen erreichbar?
• Gibt es kompensierende Kontrollen?
• Wie wahrscheinlich ist eine Ausnutzung im konkreten Umfeld?
• Welche Abhängigkeiten bestehen zu anderen Systemen?

Ein Befund mit mittlerem CVSS Wert kann bei einem zentralen Identitätssystem dringender sein als ein höher bewerteter Fehler in einer isolierten Testumgebung. Deshalb sollte die Risikobewertung gemeinsam mit IT Betrieb, Entwicklung, Datenschutz und Fachverantwortlichen erfolgen.

7. Bericht in Maßnahmen übersetzen

Der Bericht ist kein Abschlussdokument für die Ablage, sondern der Startpunkt für Verbesserungen. Er sollte eine Managementzusammenfassung enthalten, technische Befunde nachvollziehbar erläutern und konkrete, defensive Maßnahmen empfehlen. Verantwortliche müssen erkennen können, was sie tun sollen, warum es wichtig ist und wie die Wirksamkeit später geprüft wird.

Bewährt hat sich ein Maßnahmenplan mit Verantwortlichkeit, Priorität, Zieltermin und Status. Gruppiere dabei ähnliche Ursachen. Wenn mehrere Befunde auf unklare Berechtigungskonzepte zurückgehen, reicht es nicht, nur einzelne Konten anzupassen. Du solltest Rollenmodelle, Rezertifizierungen und Freigabeprozesse überprüfen.

Passende IT-Security-Seminare und Termine findest du bei uns auf cmt.de.

8. Nachbesserung und Retest planen

Erst die Überprüfung der Maßnahmen schließt den Kreislauf. Nachbesserungen können neue Fehler erzeugen, wenn sie unter Zeitdruck erfolgen oder nur Symptome behandeln. Plane deshalb einen Retest für kritische Befunde ein. Dabei wird gezielt geprüft, ob die vereinbarte Maßnahme wirksam ist und keine vergleichbare Schwäche bestehen bleibt.

Ein Penetrationstest liefert immer eine Momentaufnahme. Neue Anwendungen, Konfigurationsänderungen, Personalwechsel und veröffentlichte Sicherheitslücken verändern die Risikolage laufend. Verknüpfe die Ergebnisse daher mit Patchmanagement, Secure Development, Security Awareness, Logging und einem kontinuierlichen Schwachstellenmanagement. So wird aus einem einzelnen Test ein belastbarer Beitrag zu deiner Sicherheitsstrategie.