Penetration test methodology: PTES, OWASP, OSSTMM, BSI guidelines and TIBER-EU
Comparison of leading penetration testing methodologies: PTES, OWASP Testing Guide, OSSTMM, BSI Guidelines (BSI-CS 115), and TIBER-EU for the financial sector. Including phase models, scope templates, test types, reporting standards, and penetration testing certifications for German companies.
Table of Contents (9 sections)
A penetration test without a methodology is not a penetration test—it is simply a scan performed by a human. Professional penetration tests follow structured methodologies with defined phases, clear scope boundaries, and reproducible results. The choice of method depends on the objective: compliance pentests, adversarial red team exercises, or application-specific web testing require different approaches. This guide explains the leading methodologies and shows which one is suitable for which type of test.
Overview: The Five Main Methodologies
PTES (Penetration Testing Execution Standard):
→ Complete lifecycle methodology (pre-engagement through reporting)
→ Coverage: Network, Web, Social Engineering, Physical
→ Strength: Practice-oriented, developed by penetration testers
→ URL: pentest-standard.org
OWASP Testing Guide (OTG):
→ Focus: Web applications (and APIs)
→ Very detailed: 91+ test cases in 11+ categories
→ Current version: OTG v4.2 (2020), continuously updated
→ URL: owasp.org/www-project-web-security-testing-guide
OSSTMM (Open Source Security Testing Methodology Manual):
→ Focus: All channels (network, human, physical, telecommunications)
→ Scientific approach, measurable security (RAVs)
→ Version: OSSTMM 3 (Institute for Security and Open Methodologies)
→ Strengths: Comprehensiveness, measurability
BSI Penetration Testing Guide:
→ German BSI document (BSI-CS 115 / BSI Study Implementation Concept)
→ Good guide for German clients and KRITIS operators
→ Defines: Test categories, classes, procedures, contractual aspects
→ URL: bsi.bund.de → Publications → BSI-CS 115
TIBER-EU (Threat Intelligence-Based Ethical Red Teaming):
→ ECB framework for systemically important financial institutions
→ Advanced Red Team Assessment with real APT simulation
→ Mandatory for large EU banks, coordinated by national central banksPTES - The 7 Phases
PTES is the most frequently referenced methodology for general penetration testing:
Phase 1: Pre-Engagement Interactions
→ Scope definition: What is being tested?
→ Testing period: When? How long?
→ Letter of Authorization (Rules of Engagement)
→ Agree on emergency contacts
→ Communication channels (encrypted? Signal, PGP?)
→ Define test objectives (business objectives, not just technical objectives)
→ Escalation rule: immediate reporting for CVSSv3 9.0+, no exploitation
Scope Template:
□ Target IP Ranges: 10.0.0.0/8 (INCL.) / 10.99.0.0/24 (EXCL.)
□ Domains: *.example.com (INCL.) / mail.example.com (EXCL.)
□ Testing hours: weekdays 08:00–18:00 / 24/7 / only outside business hours
□ Permitted techniques: Social engineering / Phishing YES/NO
□ Physical access: YES/NO
□ Denial of Service: NO (unless explicitly agreed)
□ Data handling: captured data used only for verification, immediate deletion after testing
Phase 2: Intelligence Gathering (Reconnaissance)
Passive OSINT (without direct contact):
→ DNS enumeration (dnsx, subfinder, amass)
→ WHOIS, Certificate Transparency
→ Google Dorking, Shodan, Censys
→ LinkedIn, OSINT Framework, HUMINT
→ Job Postings: Which technologies are used?
→ theHarvester, Maltego
Active Reconnaissance (direct interaction):
→ Port Scanning (nmap)
→ Service Versions and Banner Grabbing
→ WAF Fingerprinting
Phase 3: Threat Modeling
→ Analyze the attack surface
→ What are the most valuable assets?
→ Which attack vectors are promising?
→ Create a threat model (STRIDE or ad hoc)
→ Prioritization: where is the risk greatest? What would a real attacker do first?
Phase 4: Vulnerability Analysis / Research
→ Identify vulnerabilities (automated + manual)
→ Vulnerability scanning: Nessus, OpenVAS, Nuclei
→ Manual verification (no false-positive noise!)
→ CVE research for identified versions
→ Check for configuration weaknesses
→ Manual testing for logic errors and business logic
Phase 5: Exploitation
→ Exploit vulnerabilities (within scope, with permission!)
→ Goal: Demonstrate exploitability (not just "exists")
→ Proof of Concept: How far can access be escalated?
→ Pivoting and lateral movement within the permitted scope
→ Data exfiltration as proof (using test data, not real data!)
→ Demonstrate persistence (without leaving a real backdoor!)
→ Tools: Metasploit, custom exploits, Burp Repeater
Phase 6: Post-Exploitation
→ After a successful exploit: What can the attacker do?
→ Privilege escalation to the maximum escalation level
→ Proof of domain compromise (e.g., secretsdump)
→ Lateral movement: further penetration into the network
→ Evidence collection: screenshots, logs, hashes
→ Assess the business impact of the access
→ Persistence test: how long would the attacker remain undetected?
→ Data extraction (simulated, no real data!)
Phase 7: Reporting
→ Executive Summary (for management, business impact—non-technical)
→ Technical Report (for IT, with reproduction instructions)
→ Finding Cards: Vulnerability + CVSS + PoC + Recommendation
→ Risk Ratings: CVSS + Business Context
→ Remediation Guide: concrete and prioritized
→ Attestation: formal confirmation of test status
→ Retest RecommendationOWASP Testing Guide - For Web Applications
OWASP Testing Guide v4 - Web Application Focus:
https://owasp.org/www-project-web-security-testing-guide/
Specific to web applications, very detailed (91+ test cases):
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)
→ Tests: 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 in 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 Cookie 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 (new in v4)
→ APIT-01: Testing GraphQL
→ APIT-02: Testing REST APIs
→ JWT Validation, IDOR in APIs, Rate Limiting
OWASP Methodology per Test Case:
Summary: What is being tested + why?
Test Goals: Specific goal of this test
How to Test: Step-by-step instructions
Test Tools: Which tools are helpful?
Remediation: How to fix it?
References: CVEs, sources
WSTG Tools:
OWASP ZAP: Automated + Manual Testing
Burp Suite: De facto standard for manual web testing
sqlmap: SQL injection automation
ffuf: Fuzzing, directory enumeration
nikto: Web server scanner
JWT_Tool: JWT testing
Postman: API testingBSI Penetration Testing Guide - German Perspective
BSI IT-Grundschutz + Penetration Testing Guide:
BSI Study: Implementation Concept for Penetration Tests (BSI-CS 115)
Penetration Test Classes According to BSI (Level of Information):
Class A: Testing based on publicly available information
→ Black-box approach: OSINT information (website, DNS, Shodan)
→ Known vulnerabilities in published components
→ Lowest effort, suitable for initial external assessment
Class B: Testing after familiarization (Basic knowledge)
→ System documentation is provided
→ General system architecture known (Grey-Box)
→ Standard penetration test for regular security reviews
Class C: Detailed testing after intensive familiarization
→ Complete documentation, source code, configuration
→ Most comprehensive testing (White-Box)
→ Highest effort and test depth, for KRITIS and the financial sector
Aggressiveness:
Cautious: No interruption of operations
Medium: Acceptable risk of operational interruption
Aggressive: Maximum exploitation (only with preparation and maintenance windows!)
---
Test categories according to BSI:
Category A: Security Layer
→ Firewall, IDS/IPS, VPN concentrators
→ Security of infrastructure boundaries
Category B: System Level
→ Operating system hardening
→ Patch status, configuration
Category C: Application Level
→ Web apps, APIs
→ OWASP Top 10
Category D: Network Level
→ Segmentation, switch/router configuration
Category E: Social Engineering
→ Phishing, vishing (if within scope)
---
BSI-specific requirements:
□ Written authorization for ALL testing activities
□ Penetration test report according to BSI reporting standard
□ Assessment according to BSI threat catalog
□ Recommendations based on IT-Grundschutz modules
□ For KRITIS operators: BSI coordination may be requiredTIBER-EU - Red Teaming for the Financial Sector
TIBER-EU Framework:
(Threat Intelligence-Based Ethical Red Teaming)
Developed by the European Central Bank (ECB)
Target group: Systemically important financial institutions
→ Banks, insurance companies, payment service providers
→ Regulatory requirement in the EU/EEA (banking supervision)
→ Mandatory for large EU banks
TIBER-EU Specifics:
→ Simulate real threat actors (nation-states, APTs)
→ Threat intelligence MUST be purchased (from a certified TI provider)
→ Very long timeframe: 3–6+ months
→ Full complexity: social engineering, physical access, technical
→ Only senior management (board level) is aware of the test—no advance information for IT/SOC
→ Regulatory authority is actively involved
TIBER-EU Phases:
Phase 1 (Preparation):
→ Generic Threat Landscape Report (prepared by the TI provider)
→ Targeted Threat Intelligence Report (institution-specific)
→ Red Team is briefed specifically on the institution
Phase 2 (Testing):
→ Reconnaissance (no restrictions except legal)
→ Initial Access: Phishing, Physical, Technical
→ Post-Exploitation: up to defined Critical Functions
→ Persistence, Lateral Movement, Privilege Escalation
Phase 3 (Closure):
→ Replay: Red Team explains attack paths to Blue Team
→ Remediation: what needs to be fixed immediately?
→ TIBER Report: Formal document for the regulatory authority
TIBER-DE (Germany Configuration):
→ Coordination: Deutsche Bundesbank
→ Recognized providers must be certified
→ Reporting: to BaFin and the Bundesbank
TIBER vs. Standard Penetration Test:
Penetration Test: 3–10 days, known systems, written authorization
TIBER: 3–6 months, no advance warning to IT, real APT simulation
→ Significantly higher effort and costs (typically €100,000+)
→ But: most realistic assessment of the actual security situation
Certification:
TIBER-EU: Recognized certificate in the EU
CREST: Regulatory requirement in the UK (PCI DSS, FCA), highly regarded in EuropeScope Definition - What Must Be Included in the Contract
Essential Contract Components:
1. Systems to be tested (scope):
→ Explicit: IP ranges, domains, applications
→ In-scope: 192.168.1.0/24, app.company.com, api.company.com
→ Out-of-scope: 192.168.2.0/24, infrastructure-partner.com
→ For Cloud/SaaS: Provider approval required (AWS, Azure, GCP have their own policies!)
2. Permitted testing methods:
→ Black Box / Grey Box / White Box?
→ Social engineering: yes/no?
→ Physical access: yes/no?
→ Denial of Service: NO (unless explicitly agreed upon)
3. Time frame:
→ Business hours? Weekends?
→ Production systems: only during maintenance windows?
→ Maximum test intensity (rate limiting?)
4. Emergency contacts:
→ IT manager: Name, cell phone (not just email!)
→ Management: for escalation
→ Pentester → Client: encrypted (Signal, PGP)
5. Data protection:
→ What data may the pentester document?
→ Retention periods for test data
→ NDA/Confidentiality agreement
→ Right to erasure upon completion
6. Disclaimer:
→ The penetration tester is not liable for outages if the test is conducted correctly
→ Client confirms legality (ownership or authorization)
7. Deliverables:
→ Executive Summary (1–2 pages)
→ Technical Report (with findings, CVSS, PoC, recommendations)
→ Retest (included or subject to a fee?)
→ Delivery: within 10 business days after the test endsTest Types and When to Use Them
Black Box Test:
→ No prior information (like a real external attacker)
→ Scope: often only domain names or IP ranges
→ Advantage: realistic simulation
→ Disadvantage: significant time required for reconnaissance, less depth
→ BSI Equivalent: Class A
Grey Box Test (recommended):
→ Partial information (e.g., standard user account, API documentation)
→ Simulates: compromised employee, insider attacker
→ Advantage: efficient, greater depth than Black Box
→ Best balance for most companies
→ BSI equivalent: Class B
White Box Test:
→ Full information: source code, architecture, admin access
→ Simulates: insider attacker with maximum knowledge
→ Advantage: highest test coverage
→ Disadvantage: less "realistic," but maximum security
→ BSI equivalent: Class C
External Test:
→ From the outside (without network access): Web, APIs, remote access
→ Simulates: Internet-based attacker
→ Most common test type
Internal Test:
→ With network access (physical or VPN)
→ Simulates: Insider, compromised device
→ Tests: Active Directory, network segmentation, lateral movement
Targeted / Assumed Breach:
→ Start: Attacker has already gained a foothold (compromised user)
→ Tests: What can the attacker achieve from here?
→ Focus: Lateral movement, privilege escalationPenetration Testing Documentation and Reporting
Professional Penetration Testing Report (PTES-compliant):
1. Executive Summary (1–3 pages):
→ Scope and testing period
→ Overall result: e.g., "critical vulnerabilities found"
→ Top 3 risks (described in non-technical terms)
→ Recommendation: immediate actions
2. Methodology:
→ Which framework? (PTES, OWASP, BSI)
→ Test type: Black box/Grey box/White box
→ Scope limits: what was NOT tested
3. Findings (per vulnerability):
□ Title: clear, descriptive name
□ CVSSv3.1 Score: Base Score + Vector
□ Business Risk: What happens if exploited?
□ Technical Description: What is the problem?
□ Proof of Concept: How was it demonstrated?
□ Screenshots/Logs as evidence
□ Affected Systems: Which URLs/IPs are affected?
□ Remediation: Specific steps for remediation
□ References: CVEs, OWASP, CWE
4. Remediation Summary:
→ Prioritized list: Critical → High → Medium → Low → Info
→ Dependencies: What needs to be fixed first?
5. Conclusion:
→ Overall security level assessment
→ Comparison to industry average (if possible)
→ Recommendation for next steps (e.g., retest after remediation)
---
Risk-Rating Framework:
CVSS v3.1 Base Score: objective technical score
Environmental Score: adjusted for the specific environment
Temporal Score: are known exploits available?
Business Impact: subjective + context-dependent
Combination for the report:
Critical: CVSS 9.0–10.0 + high business impact
High: CVSS 7.0–8.9 or CVSS < 7.0 + critical context
Medium: CVSS 4.0–6.9 + medium impact
Low: CVSS 0.1–3.9 + low impact
Informational: no direct risk, but best practice
---
Retesting / Remediation Verification:
After remediation by the client:
□ Retest of reported vulnerabilities
□ Confirmation: Is the patch correct and complete?
□ No regression: Are other functions still intact?
□ Attestation Letter: Formal confirmation of remediationPenetration Testing Certifications - What the Most Important Ones Mean
OSCP (Offensive Security Certified Professional):
→ Practical exam: 24-hour lab + 24-hour report
→ Globally recognized industry standard
→ Demonstrates: ability to compromise real systems
OSCE3 (= OSCP + OSEP + OSED):
→ Three exams: Exploitation, Evasion, Development
→ Highest Offensive Security certification
→ Rare → particularly valuable
PNPT (Practical Network Penetration Tester):
→ TCM Security: Junior-friendly, practical
→ Focus: Active Directory, reporting
→ Good for: Beginners
CEH (Certified Ethical Hacker):
→ EC-Council: Multiple-choice exam
→ Lots of theory, little practice
→ Well-known in compliance circles, less so among practitioners
CREST (UK/EU):
→ Regulatory requirement in the UK (PCI DSS, FCA)
→ Highly regarded in Europe
TIBER-EU:
→ ECB framework for financial institutions
→ Advanced Red Team Assessment
→ Mandatory for large EU banksQuestions about this topic?
Our experts advise you free of charge and without obligation.
About the Author
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
