Penetrationstest-Methodik: PTES, OWASP, OSSTMM, BSI-Leitfaden und TIBER-EU
Vergleich der führenden Penetrationstest-Methodiken: PTES, OWASP Testing Guide, OSSTMM, BSI-Leitfaden (BSI-CS 115) und TIBER-EU für den Finanzsektor. Mit Phasen-Modellen, Scope-Templates, Testtypen, Reporting-Standards und Pentest-Zertifizierungen für deutsche Unternehmen.
Inhaltsverzeichnis (9 Abschnitte)
Ein Penetrationstest ohne Methodik ist kein Penetrationstest - es ist ein Scanvorgang mit menschlicher Begleitung. Professionelle Penetrationstests folgen strukturierten Methoden mit definierten Phasen, klaren Scope-Grenzen und reproduzierbaren Ergebnissen. Die Wahl der Methode hängt vom Ziel ab: Compliance-Pentest, adversariale Red-Team-Übung oder applikationsspezifisches Web-Testing erfordern unterschiedliche Ansätze. Dieser Guide erklärt die führenden Methodiken und zeigt, welche für welchen Testtyp geeignet ist.
Überblick: Die fünf Hauptmethodiken
PTES (Penetration Testing Execution Standard):
→ Vollständige Lifecycle-Methodik (Pre-Engagement bis Reporting)
→ Abdeckung: Netzwerk, Web, Social Engineering, Physical
→ Stärke: Praxis-orientiert, von Pentestern entwickelt
→ URL: pentest-standard.org
OWASP Testing Guide (OTG):
→ Fokus: Web-Applikationen (und APIs)
→ Sehr detailliert: 91+ Testfälle in 11+ Kategorien
→ Aktuelle Version: OTG v4.2 (2020), laufend aktualisiert
→ URL: owasp.org/www-project-web-security-testing-guide
OSSTMM (Open Source Security Testing Methodology Manual):
→ Fokus: Alle Kanäle (Netzwerk, Mensch, Physisch, Telekommunikation)
→ Wissenschaftlicher Ansatz, messbare Sicherheit (RAVs)
→ Version: OSSTMM 3 (Institute for Security and Open Methodologies)
→ Stärke: Vollständigkeit, Messbarkeit
BSI-Leitfaden Penetrationstest:
→ Deutsches BSI-Dokument (BSI-CS 115 / BSI-Studie Durchführungskonzept)
→ Gute Orientierung für deutsche Auftraggeber und KRITIS-Betreiber
→ Definiert: Testkategorien, Klassen, Vorgehensweisen, Vertragsaspekte
→ URL: bsi.bund.de → Publikationen → BSI-CS 115
TIBER-EU (Threat Intelligence-Based Ethical Red Teaming):
→ ECB-Framework für systemrelevante Finanzinstitute
→ Advanced Red Team Assessment mit echter APT-Simulation
→ Pflicht für große EU-Banken, Koordination durch nationale ZentralbankenPTES - Die 7 Phasen
PTES ist die am häufigsten referenzierte Methodik für allgemeine Penetrationstests:
Phase 1: Pre-Engagement Interactions
→ Scope-Definition: Was wird getestet?
→ Testzeitraum: Wann? Wie lange?
→ Erlaubnisschreiben (Rules of Engagement / Letter of Authorization)
→ Notfallkontakte vereinbaren
→ Kommunikationskanäle (verschlüsselt? Signal, PGP?)
→ Testziele definieren (Geschäftsziele, nicht nur technische Ziele)
→ Eskalationsregel: bei CVSSv3 9.0+ sofortige Meldung, keine Exploitation
Scope-Template:
□ Ziel-IP-Ranges: 10.0.0.0/8 (INKL.) / 10.99.0.0/24 (EXKL.)
□ Domains: *.example.com (INKL.) / mail.example.com (EXKL.)
□ Testzeiten: werktags 08:00-18:00 / 24/7 / nur außerhalb Geschäftszeiten
□ Erlaubte Techniken: Social Engineering / Phishing JA/NEIN
□ Physischer Zugang: JA/NEIN
□ Denial of Service: NEIN (außer explizit vereinbart)
□ Datenhandling: erbeutete Daten nur für Nachweis, sofortige Löschung nach Test
Phase 2: Intelligence Gathering (Reconnaissance)
Passive OSINT (ohne direkten Kontakt):
→ DNS-Enumeration (dnsx, subfinder, amass)
→ WHOIS, Certificate Transparency
→ Google Dorking, Shodan, Censys
→ LinkedIn, OSINT-Framework, HUMINT
→ Job-Postings: welche Technologien werden eingesetzt?
→ theHarvester, Maltego
Aktive Reconnaissance (direkte Interaktion):
→ Port-Scanning (nmap)
→ Service-Versionen und Banner-Grabbing
→ WAF-Fingerprinting
Phase 3: Threat Modeling
→ Attack Surface analysieren
→ Was sind die wertvollsten Assets?
→ Welche Angriffsvektoren sind vielversprechend?
→ Bedrohungsmodell erstellen (STRIDE oder ad-hoc)
→ Priorisierung: wo ist das Risiko am größten? Was würde ein echter Angreifer zuerst tun?
Phase 4: Vulnerability Analysis / Research
→ Schwachstellen identifizieren (automatisiert + manuell)
→ Vulnerability-Scanning: Nessus, OpenVAS, Nuclei
→ Manuelle Verifizierung (kein False-Positive-Rauschen!)
→ CVE-Research für identifizierte Versionen
→ Konfigurationsschwächen prüfen
→ Manuelle Tests für Logik-Fehler und Business Logic
Phase 5: Exploitation
→ Schwachstellen ausnutzen (im Scope, mit Erlaubnis!)
→ Ziel: Nachweis der Ausnutzbarkeit (nicht nur "existiert")
→ Proof of Concept: wie weit kann der Zugriff eskaliert werden?
→ Pivot und Lateral Movement im erlaubten Scope
→ Daten-Exfiltration als Nachweis (mit Testdaten, keine echten!)
→ Persistenz demonstrieren (ohne echte Backdoor zu hinterlassen!)
→ Werkzeuge: Metasploit, eigene Exploits, Burp Repeater
Phase 6: Post-Exploitation
→ Nach erfolglichem Exploit: Was kann der Angreifer?
→ Privilege Escalation bis zur maximalen Eskalationsstufe
→ Domain-Compromise Nachweis (z.B. secretsdump)
→ Lateral Movement: weiteres Vordringen im Netzwerk
→ Evidence-Collection: Screenshots, Logs, Hashes
→ Business-Impact des Zugriffs bewerten
→ Persistenz-Test: wie lange würde Angreifer unentdeckt bleiben?
→ Daten-Extraktion (simuliert, keine echten Daten!)
Phase 7: Reporting
→ Executive Summary (für Management, Business-Impact nicht technisch)
→ Technischer Bericht (für IT, mit Reproduce-Anleitung)
→ Finding Cards: Schwachstelle + CVSS + PoC + Empfehlung
→ Risk-Ratings: CVSS + Business-Kontext
→ Remediation-Leitfaden: konkret und priorisiert
→ Attestation: formale Bestätigung des Teststatus
→ Retest-EmpfehlungOWASP Testing Guide - Für Web-Applikationen
OWASP Testing Guide v4 - Web Application Focus:
https://owasp.org/www-project-web-security-testing-guide/
Spezifisch für Web-Applikationen, sehr detailliert (91+ Testfälle):
OTG-INFO: Information Gathering (10 Tests)
→ INFO-001/01: Fingerprint Web Server
→ INFO-002/02: Fingerprint Application Framework
→ INFO-005: Review Web Content for Information Leakage
→ INFO-007/07: Map Application Architecture
→ INFO-009/09: Fingerprint Web Application Framework
OTG-CONFIG/CONF: Configuration and Deployment Management (12 Tests)
→ CONFIG-001/01: Test Network Infrastructure Configuration
→ CONFIG-002/02: Test Application Platform Configuration
→ CONFIG-006/06: Test HTTP Methods
→ CONFIG-007/07: Test HTTP Strict Transport Security
→ CONF-08: Test File Extensions Handling
OTG-IDENT: Identity Management (5 Tests)
→ Testet: Account-Enumeration, Username Policy, etc.
OTG-AUTHN/AUTH: Authentication Testing (10 Tests)
→ AUTH-001/01: Testing for Credentials Transported over Encrypted Channel
→ AUTH-002/02: Testing for Default Credentials
→ AUTH-004/04: Testing for Bypassing Authentication Schema
→ AUTH-006/06: Testing for Browser Cache Weakness (JWT im LocalStorage!)
→ AUTH-007: Testing for Weak Password Policy
→ AUTH-010: Testing Multi-Factor Authentication
OTG-AUTHZ: Authorization Testing (5 Tests)
→ AUTHZ-001: Testing Directory Traversal (Path Traversal)
→ AUTHZ-002: Testing for Bypassing Authorization Schema
→ AUTHZ-004: Testing for Insecure Direct Object References (IDOR)
OTG-SESS: Session Management Testing (8 Tests)
→ SESS-001/01: Testing for Bypassing Session Management Schema
→ SESS-002/02: Testing for Cookies Attributes
→ SESS-005/05: Testing for CSRF
→ SESS-006/06: Testing for Logout Functionality
→ SESS-009: Testing for Session Token Entropy
OTG-INPVAL/INPV: Input Validation Testing (19 Tests)
→ INPVAL-001/INPV-01: Testing for Reflected XSS
→ INPVAL-002/INPV-02: Testing for Stored XSS
→ INPVAL-005/INPV-05: Testing for SQL Injection
→ INPVAL-007/INPV-07: Testing for XML Injection
→ INPVAL-018: Testing for Server-Side Request Forgery (SSRF)
→ INPV-10: Testing for IMAP/SMTP Injection
→ INPV-11: Testing for Code Injection
→ INPV-17: Testing for HTTP Splitting/Smuggling
OTG-ERR: Error Handling (2 Tests)
OTG-CRYPST: Weak Cryptography (4 Tests)
OTG-BUSLOGIC: Business Logic Testing (9 Tests)
OTG-CLIENT: Client Side Testing (11 Tests)
OTG-APIT: API Testing (neu in v4)
→ APIT-01: Testing GraphQL
→ APIT-02: Testing REST APIs
→ JWT-Validierung, IDOR in APIs, Rate-Limiting
OWASP-Methode pro Testfall:
Summary: Was wird getestet + warum?
Test Goals: Spezifisches Ziel dieses Tests
How to Test: Schritt-für-Schritt-Anleitung
Test Tools: Welche Tools helfen?
Remediation: Wie beheben?
References: CVEs, Quellen
WSTG-Tools:
OWASP ZAP: Automated + Manual Testing
Burp Suite: De-facto-Standard für manuelles Web-Testing
sqlmap: SQL-Injection-Automation
ffuf: Fuzzing, Directory-Enumeration
nikto: Web-Server-Scanner
JWT_Tool: JWT-Testing
Postman: API-TestingBSI-Penetrationstest-Leitfaden - Deutsche Perspektive
BSI IT-Grundschutz + Penetrationstest-Leitfaden:
BSI-Studie Durchführungskonzept für Penetrationstests (BSI-CS 115)
Penetrationstest-Klassen nach BSI (Informationstiefe):
Klasse A: Prüfung auf Basis öffentlich verfügbarer Informationen
→ Black-Box-Ansatz: OSINT-Informationen (Webseite, DNS, Shodan)
→ Bekannte Schwachstellen in veröffentlichten Komponenten
→ Niedrigster Aufwand, geeignet für externe Erstbewertung
Klasse B: Prüfung nach Einarbeitung (Grobkenntnis)
→ Systemdokumentation wird übergeben
→ Grober Systemaufbau bekannt (Grey-Box)
→ Standard-Penetrationstest für regelmäßige Sicherheitsüberprüfung
Klasse C: Detailprüfung nach intensiver Einarbeitung
→ Vollständige Dokumentation, Source Code, Konfiguration
→ Umfangreichste Prüfung (White-Box)
→ Höchster Aufwand und Testtiefe, für KRITIS und Finanzsektor
Aggressivität:
Vorsichtig: Keine Unterbrechung des Betriebs
Mittel: Akzeptiertes Risiko für Betriebsunterbrechung
Aggressiv: Maximale Ausnutzung (nur mit Vorbereitung und Wartungsfenster!)
---
Prüfungskategorien nach BSI:
Kategorie A: Security Layer
→ Firewall, IDS/IPS, VPN-Konzentratoren
→ Sicherheit der Infrastruktur-Grenzen
Kategorie B: Systemebene
→ Betriebssystem-Härtung
→ Patch-Status, Konfiguration
Kategorie C: Applikationsebene
→ Web-Apps, APIs
→ OWASP Top 10
Kategorie D: Netzwerkebene
→ Segmentierung, Switch/Router-Konfiguration
Kategorie E: Social Engineering
→ Phishing, Vishing (wenn in Scope)
---
BSI-spezifische Anforderungen:
□ Schriftliche Genehmigung für ALLE Testaktivitäten
□ Pentest-Bericht nach BSI-Berichtsstandard
□ Bewertung nach BSI-Gefährdungskatalog
□ Empfehlungen nach IT-Grundschutz-Bausteinen
□ Bei KRITIS-Betreibern: möglicherweise BSI-Koordination nötigTIBER-EU - Red Teaming für den Finanzsektor
TIBER-EU Framework:
(Threat Intelligence-Based Ethical Red Teaming)
Entwickelt von der Europäischen Zentralbank (EZB)
Zielgruppe: Systemrelevante Finanzinstitute
→ Banken, Versicherungen, Zahlungsdienstleister
→ Regulatorische Anforderung in EU/EWR (Bankenaufsicht)
→ Pflicht für große EU-Banken
TIBER-EU Besonderheiten:
→ Echte Bedrohungsakteure simulieren (Nation-States, APT)
→ Threat Intelligence MUSS eingekauft werden (zertifizierter TI-Provider)
→ Sehr langer Zeithorizont: 3-6+ Monate
→ Volle Komplexität: Social Engineering, Physical Access, Technical
→ Nur Führung (Board-Level) kennt Test - kein Vorab-Info für IT/SOC
→ Aufsichtsbehörde ist aktiv eingebunden
TIBER-EU Phasen:
Phase 1 (Preparation):
→ Generic Threat Landscape Report (vom TI-Provider erstellt)
→ Targeted Threat Intelligence Report (institutsspezifisch)
→ Red Team wird spezifisch auf das Institut gebrieft
Phase 2 (Testing):
→ Reconnaissance (ohne Einschränkungen außer Legal)
→ Initial Access: Phishing, Physical, Technical
→ Post-Exploitation: bis zu definierten Critical Functions
→ Persistenz, Lateral Movement, Privilege Escalation
Phase 3 (Closure):
→ Replay: Red Team erklärt Angriffspfade an Blue Team
→ Remediation: was muss sofort behoben werden?
→ TIBER Report: Formales Dokument für die Aufsichtsbehörde
TIBER-DE (Deutschland-Konfiguration):
→ Koordination: Deutsche Bundesbank
→ Anerkannte Provider müssen zertifiziert sein
→ Reporting: an BaFin und Bundesbank
TIBER vs. Standard Pentest:
Pentest: 3-10 Tage, bekannte Systeme, schriftliche Genehmigung
TIBER: 3-6 Monate, keine Vorwarnung für IT, echte APT-Simulation
→ Ungleich höherer Aufwand und Kosten (100.000€+ typisch)
→ Aber: realistischste Bewertung der echten Sicherheitslage
Zertifizierung:
TIBER-EU: Anerkanntes Zertifikat in der EU
CREST: Regulatorische Anforderung in UK (PCI DSS, FCA), hoch angesehen in EuropaScope-Definition - Was in den Vertrag muss
Unverzichtbare Vertragsbestandteile:
1. Zu testende Systeme (Scope):
→ Explizit: IP-Bereiche, Domains, Applikationen
→ In-Scope: 192.168.1.0/24, app.firma.de, api.firma.de
→ Out-of-Scope: 192.168.2.0/24, infrastruktur-partner.de
→ Bei Cloud/SaaS: Genehmigung des Providers nötig (AWS, Azure, GCP haben eigene Policies!)
2. Erlaubte Testmethoden:
→ Black Box / Grey Box / White Box?
→ Social Engineering: ja/nein?
→ Physischer Zugang: ja/nein?
→ Denial of Service: NEIN (außer explizit vereinbart)
3. Zeitfenster:
→ Arbeitszeiten? Wochenende?
→ Produktionssysteme: nur mit Wartungsfenster?
→ Maximale Test-Intensität (Rate Limiting?)
4. Notfallkontakte:
→ IT-Verantwortlicher: Name, Handy (nicht nur E-Mail!)
→ Geschäftsführung: für Eskalation
→ Pentester → Auftraggeber: verschlüsselt (Signal, PGP)
5. Datenschutz:
→ Welche Daten darf Pentester dokumentieren?
→ Aufbewahrungsfristen für Testdaten
→ NDA/Vertraulichkeitsvereinbarung
→ Recht auf Löschung nach Abschluss
6. Haftungsausschluss:
→ Pentester haftet nicht für Ausfälle bei korrekter Durchführung
→ Auftraggeber bestätigt Rechtmäßigkeit (Eigentümer oder Genehmigung)
7. Deliverables:
→ Executive Summary (1-2 Seiten)
→ Technischer Bericht (mit Findings, CVSS, PoC, Empfehlung)
→ Retest (inklusive oder kostenpflichtig?)
→ Abgabe: binnen 10 Werktagen nach TestendeTesttypen und wann welcher passt
Black Box Test:
→ Keine Vorabinformationen (wie echter externer Angreifer)
→ Scope: oft nur Domainnamen oder IP-Bereiche
→ Vorteil: realistische Simulation
→ Nachteil: viel Zeit für Reconnaissance, weniger Tiefe
→ BSI-Entsprechung: Klasse A
Grey Box Test (empfohlen):
→ Teil-Informationen (z.B. Standard-User-Account, API-Dokumentation)
→ Simuliert: kompromittierter Mitarbeiter, Insider-Angreifer
→ Vorteil: effizient, mehr Tiefe als Black Box
→ Beste Balance für die meisten Unternehmen
→ BSI-Entsprechung: Klasse B
White Box Test:
→ Volle Information: Quellcode, Architektur, Admin-Zugänge
→ Simuliert: Insider-Angreifer mit maximalem Wissen
→ Vorteil: höchste Testabdeckung
→ Nachteil: weniger "realistisch", aber maximale Sicherheit
→ BSI-Entsprechung: Klasse C
External Test:
→ Von außen (ohne Netzwerkzugang): Web, APIs, Fernzugänge
→ Simuliert: Internet-basierter Angreifer
→ Häufigster Testtyp
Internal Test:
→ Mit Netzwerkzugang (physisch oder VPN)
→ Simuliert: Insider, kompromittiertes Gerät
→ Tests: Active Directory, Netzwerk-Segmentierung, laterale Bewegung
Targeted / Assumed Breach:
→ Start: Angreifer hat bereits Fuß gefasst (kompromittierter User)
→ Testet: Was kann Angreifer von hier aus erreichen?
→ Fokus: Lateral Movement, Privilege EscalationPentest-Dokumentation und Reporting
Professioneller Pentest-Bericht (PTES-konform):
1. Executive Summary (1-3 Seiten):
→ Scope und Testzeitraum
→ Gesamtergebnis: z.B. "kritische Schwachstellen gefunden"
→ Top 3 Risiken (nicht-technisch beschrieben)
→ Empfehlung: sofortige Maßnahmen
2. Methodology:
→ Welches Framework? (PTES, OWASP, BSI)
→ Testtyp: Blackbox/Greybox/Whitebox
→ Scope-Grenzen: was wurde NICHT getestet
3. Findings (pro Schwachstelle):
□ Title: klarer, beschreibender Name
□ CVSSv3.1 Score: Base Score + Vektor
□ Business Risk: was passiert wenn ausgenutzt?
□ Technical Description: was ist das Problem?
□ Proof of Concept: wie wurde es nachgewiesen?
□ Screenshots/Logs als Beweise
□ Affected Systems: welche URLs/IPs betroffen?
□ Remediation: konkrete Schritte zur Behebung
□ References: CVEs, OWASP, CWE
4. Remediation Summary:
→ Priorisierte Liste: Kritisch → Hoch → Mittel → Niedrig → Info
→ Abhängigkeiten: was muss zuerst behoben werden?
5. Conclusion:
→ Gesamtbewertung Sicherheitsniveau
→ Vergleich zu Branchendurchschnitt (wenn möglich)
→ Empfehlung nächste Schritte (z.B. erneuter Test nach Behebung)
---
Risk-Rating Framework:
CVSS v3.1 Base Score: objektiver technischer Score
Environmental Score: angepasst für die spezifische Umgebung
Temporal Score: bekannte Exploits verfügbar?
Business Impact: subjektiv + kontextabhängig
Kombination für den Bericht:
Kritisch: CVSS 9.0-10.0 + hoher Business Impact
Hoch: CVSS 7.0-8.9 oder CVSS < 7.0 + kritischer Kontext
Mittel: CVSS 4.0-6.9 + mittlerer Impact
Niedrig: CVSS 0.1-3.9 + geringer Impact
Informational: kein direktes Risiko, aber Best Practice
---
Retesting / Remediation Verification:
Nach Behebung durch Auftraggeber:
□ Erneuter Test der gemeldeten Schwachstellen
□ Bestätigung: Patch korrekt und vollständig?
□ Keine Regression: andere Funktionen noch intakt?
□ Attestation Letter: formale Bestätigung der BehebungPentest-Zertifizierungen - Was die wichtigsten bedeuten
OSCP (Offensive Security Certified Professional):
→ Praktische Prüfung: 24h Lab + 24h Bericht
→ Weltweit anerkannter Industriestandard
→ Zeigt: kann echte Systeme kompromittieren
OSCE3 (= OSCP + OSEP + OSED):
→ Drei Prüfungen: Exploitation, Evasion, Development
→ Höchstes Offensive Security Zertifikat
→ Selten → besonders wertvoll
PNPT (Practical Network Penetration Tester):
→ TCM Security: Junior-freundlich, praktisch
→ Fokus: Active Directory, Reporting
→ Gut für: Einsteiger
CEH (Certified Ethical Hacker):
→ EC-Council: Multiple-Choice-Prüfung
→ Viel Theorie, wenig Praxis
→ Bekannt in Compliance-Kreisen, weniger bei Praktikern
CREST (UK/EU):
→ Regulatorische Anforderung in UK (PCI DSS, FCA)
→ Hoch angesehen in Europa
TIBER-EU:
→ ECB-Framework für Finanzinstitute
→ Advanced Red Team Assessment
→ Pflicht für große EU-BankenFragen zu diesem Thema?
Unsere Experten beraten Sie kostenlos und unverbindlich.
Über den Autor
M.Sc. IT-Sicherheit mit über 5 Jahren Erfahrung in offensiver Sicherheitsanalyse. Leitet die Durchführung von Penetrationstests mit Spezialisierung auf Web-Applikationen, Netzwerk-Infrastruktur, Reverse Engineering und Hardware-Sicherheit. Verantwortlich für mehrere Responsible Disclosures.
OSCP+ OSCP OSWP OSWA
