Ein guter Penetrationstest beginnt nicht mit dem ersten Scan, sondern mit einem klaren Prüfziel, einem schriftlich vereinbarten Scope und eindeutigen Regeln für Durchführung und Eskalation. Erst wenn Auftrag, Methode und Bericht aufeinander abgestimmt sind, lassen sich Findings verlässlich prüfen und in konkrete Maßnahmen übersetzen.
Was ein Penetrationstest leisten kann – und was nicht
Ein Penetrationstest untersucht vereinbarte Systeme unter festgelegten Bedingungen, um Schwachstellen und deren mögliche Auswirkungen zu erkennen. Das Ergebnis gilt für den geprüften Umfang und den Prüfzeitpunkt. Es ist keine Garantie, dass alle Schwachstellen gefunden wurden: Aussagekraft und Tiefe hängen unter anderem von Scope, verfügbaren Zugängen, Zeit und gewählter Methodik ab. OWASP empfiehlt deshalb, Einschränkungen und Prüfbedingungen im Bericht klar zu dokumentieren (OWASP WSTG: Reporting Structure).
As an Amazon Associate I earn from qualifying purchases.
Für die Beauftragung heißt das: Formulieren Sie eine konkrete Frage, die der Test beantworten soll, statt pauschal „die Sicherheit“ prüfen zu lassen. Beispiele sind die Wirksamkeit von Zugriffskontrollen in einer Webanwendung oder die Frage, ob ein bestimmter externer Dienst innerhalb des vereinbarten Scopes erreichbar und ausnutzbar ist.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Auftrag und Scope vorab festlegen
Der Scope beschreibt, welche Systeme und Funktionen der Test umfasst und wo seine Grenzen liegen. OWASP weist darauf hin, dass nicht erfasste Assets nicht getestet werden und aktive Erkundung innerhalb der vereinbarten Grenzen bleiben muss (OWASP WSTG: Information Gathering Overview).
#1 Best Overall
Halten Sie die folgenden Punkte schriftlich fest, bevor die technische Prüfung beginnt:
- Prüfziel und Prüfgegenstand: betroffene Anwendungen, Hosts, Endpunkte oder andere Systeme sowie die Frage, die der Test klären soll.
- Grenzen und Ausschlüsse: nicht freigegebene Systeme, technische Einschränkungen und Bereiche, die ausdrücklich nicht getestet werden dürfen.
- Zugänge und Voraussetzungen: bereitgestellte Konten, Rollen, Testdaten und gegebenenfalls eine Prüfumgebung.
- Testart und Bedingungen: etwa der verfügbare Informationszugang, das vereinbarte Zeitfenster und die zulässige Prüftiefe.
- Verantwortlichkeiten: Ansprechpartner auf beiden Seiten sowie der Eskalations- und Abbruchweg, falls eine Prüfung unerwartete Auswirkungen hat.
- Ergebnis und Nacharbeit: erwartete Berichtsinhalte und die Vereinbarung, ob und wie Korrekturen retestet werden.
Die BSI-Checkliste strukturiert die Arbeit in Einarbeitungs-, Test- und Berichtsphase und nennt unter anderem Prüfzeitraum, Prüfbedingungen, Verantwortlichkeiten, Meilensteine und die Vorbereitung der Prüfumgebung. Sie stammt aus November 2016 und ist als Prozesshilfe zu verstehen; aktuelle rechtliche und organisatorische Anforderungen müssen fallbezogen geprüft werden (BSI: Leitfaden Penetrationstest).
Eine passende Methodik und ein passendes Prüfteam auswählen
Die Methodik soll den Auftrag strukturieren, nicht ihn ersetzen. OWASP beschreibt den PTES-Ablauf mit sieben Phasen: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation und Reporting. Die Phasen geben eine Orientierung für den Gesamtprozess; sie sind keine starre Checkliste, die für jeden Prüfgegenstand identisch abgearbeitet werden muss (OWASP WSTG: Penetration Testing Methodologies).
Für Anwendungstests kann ein produktspezifischer Leitfaden wie der OWASP Web Security Testing Guide konkrete Prüffelder und Techniken liefern. Ein Prozessmodell wie PTES wiederum hilft, den Gesamtauftrag zu strukturieren. OWASP führt daneben weitere Referenzen, darunter NIST SP 800-115 und PCI-Penetrationstest-Leitlinien; sie unterscheiden sich in Zweck und Detailgrad. Wählen Sie nach Prüfgegenstand, Ziel, gewünschter Tiefe und Nutzen des Berichts, nicht allein nach dem Namen eines Standards.
Stimmen Sie die Prüftiefe auf Architektur, Datenempfindlichkeit, Bedrohungsmodell, Risikotoleranz und Entwicklungspraktiken ab. Ein internes Werkzeug und ein kundenorientiertes Finanzsystem brauchen nicht zwangsläufig dieselben Schwerpunkte oder denselben Aufwand (OWASP WSTG: Introduction).
Auch die Auswahl des Prüfenden sollte zur konkreten Aufgabe passen. Das BSI bietet Informationen zur Zertifizierung von Penetrationstestern und ordnet sie als Hilfe bei der Auswahl fachlich zuverlässiger Dienstleister ein. Eine Zertifizierung belegt jedoch nicht automatisch, dass Erfahrung, Unabhängigkeit, Testkompetenz und Berichtsqualität für Ihren konkreten Auftrag ausreichen. Prüfen Sie diese Passung anhand des Prüfgegenstands und der vereinbarten Leistungen (BSI: Certification as an IT Information Security Penetration Tester).
Durchführung: Freigaben, Kommunikation und Grenzen einhalten
Vor dem Start müssen die Beteiligten wissen, wann getestet wird, welche Auswirkungen erwartet werden können und wer bei Problemen Entscheidungen trifft. Interne Stellen sollten, soweit für den Auftrag nötig, eingebunden oder informiert sein. Das hilft, reguläre Testaktivitäten von einem echten Betriebs- oder Sicherheitsvorfall zu unterscheiden.
OWASP beschreibt passive Informationsgewinnung und aktive Enumeration als mögliche Teile der Analyse der Angriffsfläche. Welche Techniken eingesetzt werden, richtet sich nach dem Auftrag; aktive Erkundung bleibt an den vereinbarten Scope gebunden. Falls ein benötigtes System, ein Zugang oder eine Freigabe fehlt, sollte das geklärt werden, bevor der Test über die vereinbarte Grenze hinausgeht.
Best Value
Pentest-Berichte prüfen und Findings priorisieren
Ein brauchbarer Bericht verbindet zwei Perspektiven: Verantwortliche müssen die geschäftliche Bedeutung und den Handlungsbedarf verstehen; technische Teams brauchen genügend Details, um einen Befund nachzuvollziehen und zu beheben. OWASP empfiehlt, Auftrag, Scope, Einschränkungen, Zeitplan und Ergebnisse zusammenzufassen. Im technischen Teil sollten Reproduktion, Ursache, Risiko und konkrete Abhilfe erkennbar sein (OWASP WSTG: Reporting Structure).
Arbeiten Sie die Auswertung in dieser Reihenfolge durch:
- Auftrag abgleichen: Stimmen geprüfte Ziele, Scope, Testzeitraum und Einschränkungen mit der Vereinbarung überein?
- Befunde verifizieren: Sind Nachweise belastbar und lässt sich der Befund nachvollziehen? Falsche Befunde können das Vertrauen in den Bericht untergraben.
- Ursache und Auswirkung erfassen: Welche Funktion ist betroffen, wodurch entsteht das Problem und welche Folgen sind unter den konkreten Bedingungen plausibel?
- Priorität im eigenen Kontext bestimmen: Berücksichtigen Sie Schweregrad, tatsächliche Exponierung, Geschäftsfolgen und Behebbarkeit. Ein Severity-Wert oder CVSS kann beim Vergleich helfen, ersetzt aber keine organisationsspezifische Risikobewertung.
- Maßnahmen zuweisen: Legen Sie Verantwortliche und Fristen fest und dokumentieren Sie, welche Abhilfe umgesetzt werden soll.
- Retests festhalten: Wenn vereinbart, prüfen Sie nach der Korrektur erneut und dokumentieren Sie den Status des früheren Befunds.
Die Management-Zusammenfassung sollte Ziel, wesentliche Auswirkungen und strategische Empfehlungen verständlich vermitteln. Der technische Teil braucht dagegen reproduzierbare Angaben und umsetzbare Abhilfehinweise. Die Systemverantwortlichen entscheiden anschließend, wie Findings im jeweiligen Geschäfts- und Risikokontext behandelt werden (OWASP WSTG: Introduction).
Recommended Free Tools
Worauf es bei der Beauftragung ankommt
Vergleichen Sie Angebote oder interne Prüfpläne anhand derselben Kriterien, damit Preis oder Methodennamen nicht die inhaltliche Passung verdecken:
- Prüfgegenstand und Ziel: Passt die geplante Erfahrung zu Anwendung, Infrastruktur, mobiler App, Firmware oder Prozess und zur konkreten Fragestellung?
- Scope und Zugang: Sind Informationszugang, Konten, Quellcode oder Testumgebung klar beschrieben?
- Technische Tiefe: Werden Schwachstellen nur gesucht oder innerhalb der Freigaben auch nachvollziehbar validiert?
- Bericht und Nacharbeit: Sind Reproduzierbarkeit, Abhilfehinweise, Management-Zusammenfassung und Retest-Regelung ausreichend konkret?
- Zusammenarbeit und Kompetenz: Sind Unabhängigkeit, Kommunikation, organisatorische Verlässlichkeit und Erfahrung mit dem konkreten Prüfgegenstand nachvollziehbar?
Vertrags-, Rechts- und Datenschutzfragen hängen vom Auftrag, den betroffenen Systemen und Daten sowie beteiligten Dritten ab. Klären Sie Freigaben und Verantwortlichkeiten daher für den konkreten Fall; allgemeine Methodikleitfäden ersetzen diese Prüfung nicht.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
