Penetrationstests in der Türkei: Ein 7-Punkte-Unternehmensleitfaden

Ein Penetrationstest ist das technische Gegenstück zur Klausel „Cyber-Sicherheits-Audit" in einem Vertrag. Das Team betritt die Systeme des Kunden wie ein autorisierter Angreifer, dokumentiert die Wege, die ein echter Gegner nehmen könnte, und meldet die Probleme zur Behebung. Der Pentest-Markt in der Türkei ist in den letzten fünf Jahren rasch gereift; aber praktisches Wissen darüber, welche Norm für welchen Sektor verpflichtend ist, wie der richtige Anbieter ausgewählt wird und was ein Bericht enthalten muss, bleibt verstreut.

Dieser Artikel führt durch den 7-Punkte-Unternehmensleitfaden, den eine Organisation in der Türkei vor Beauftragung eines Penetrationstests benötigt. Rechtsrahmen, technische Standards, Lieferantenauswahl und Nach-Test-Workflow in einem Stück. Wir teilen die praktischen Erkenntnisse unseres Cybersicherheitsdienste-Teams aus 40+ Pentest-Projekten der letzten 36 Monate.

1. Regulatorischer Rahmen — wer muss, wer nicht

In der Türkei ist die Verpflichtung zur Durchführung eines Pentests nicht durch ein einzelnes Gesetz definiert, sondern am Schnittpunkt mehrerer Regulatoren. Ihren Sektor in die richtige Kategorie einzuordnen bestimmt sowohl Umfang als auch Budget.

BDDK-regulierte Einrichtungen (Banken, Zahlungs-/E-Geld-Institute): Gemäß BDDK-Informationssystemverordnung Art. 31 + Verordnung über unabhängige Prüfung ist mindestens ein externer Pentest pro Jahr verpflichtend. Das Testteam muss von einer BDDK-zugelassenen Prüfungsfirma kommen oder mindestens ein ISO-27001-zertifizierter unabhängiger Spezialist sein. Der Bericht wird 3 Jahre aufbewahrt und bei BDDK-Audits vorgelegt.

EPDK-regulierte Energieeinrichtungen: Die EPDK-Informationssicherheitsverordnung von 2024 verlangt einen jährlichen Pentest plus einen SCADA/OT-spezifischen Test für Stromverteilungs-, Erzeugungs- und Erdgasunternehmen. SCADA-Tests erfordern spezialisiertes Fachwissen; ein Standard-IT-Pentest-Team reicht nicht aus.

Einrichtungen, die besondere Kategorien personenbezogener Daten gemäß KVKK verarbeiten (Gesundheit, Recht, Betreiber biometrischer Systeme): Die Formulierung „jede für die Datensicherheit erforderliche technische Maßnahme" in KVKK Art. 12 wird in KVKK-Vorstandsmeinungen als regelmäßiger Pentest ausgelegt. Die Verpflichtung ist nicht explizit, aber eine Antwort „Nein" auf „Haben Sie einen jährlichen Pentest durchgeführt?" während eines Audits erhöht das Risiko administrativer Sanktionen erheblich.

TS 13638 (Informationssicherheit — Penetrationstest-Methodik): Der Standard des türkischen Normungsinstituts, häufig in staatlichen Ausschreibungen zitiert. Definiert Pentests der Stufen A/B/C — A am umfassendsten (10+ Ingenieur-Tage), C am leichtesten (1-3 Tage). Wenn Sie an Ausschreibungen des öffentlichen Sektors teilnehmen, müssen Sie diese Stufen kennen.

Einrichtungen außerhalb regulierter Sektoren: keine Verpflichtung, aber realer Druck. Cyber-Versicherungspolicen erfordern einen jährlichen Pentest, große Unternehmenskunden fragen in Lieferantenfragebögen nach dem „letzten Pentest-Datum", und Investor Due Diligence hat es zum Standard gemacht.

2. Standardauswahl — PTES, OWASP, NIST: welcher?

Drei Basis-Pentest-Standards existieren; den richtigen Rahmen in Ihrer Ausschreibung oder Ihrem Lieferantenvertrag zu benennen ist der erste Schritt, der den Umfang klar sperrt.

PTES (Penetration Testing Execution Standard): branchenneutrale allgemeine Pentest-Methodik. Sieben Phasen: Pre-Engagement, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting. Sowohl für Netzwerk- als auch für Anwendungstests geeignet. Die meisten türkischen Pentest-Firmen verwenden standardmäßig PTES.

OWASP (Open Web Application Security Project): Webanwendungs-fokussiert. OWASP Top 10 (die häufigsten 10 Kategorien von Web-Schwachstellen) + OWASP Testing Guide (300+ Testszenarien) + OWASP ASVS (Application Security Verification Standard, 14 Abschnitte × Level 1/2/3). Tiefer als PTES für Web/API-Tests.

NIST SP 800-115 (Technical Guide to Information Security Testing): US-Bundes-Standard; eher für große Netzwerke und Unternehmensinfrastruktur. In der Türkei weniger nachgefragt, aber nützlich für Organisationen mit internationalem Kundenstamm.

Praktische Kombination: Unsere Empfehlung an Unternehmenskunden lautet PTES-Rahmen + OWASP-Inhaltstests. Die Web/API-Teile laufen nach OWASP ASVS Level 2, die Netzwerk-/Infrastrukturteile nach PTES. Dieser Ansatz bietet sowohl Breite als auch Tiefe.

Die zu verwendende Norm muss im Vertrag stehen. „Best Practices werden angewendet" ist unzureichend — bei einem Audit ist die Frage „Wer hat Best Practices definiert?" schwer zu beantworten.

3. Black vs Gray vs White Box — wann welcher

Die drei Testtypen dienen unterschiedlichen Zwecken; den richtigen zu wählen führt zum richtigen Ergebnis.

Black Box: dem Team werden null Vorinformationen gegeben. Nur die Liste der Ziel-URLs/IPs. Externe Angreifer-Simulation — realistisch, aber oberflächlich. Die Aufklärung wird in 2-3 Ingenieur-Tagen abgeschlossen; die meisten Befunde kommen aus der Entdeckungsphase, während tiefe architektonische Mängel übersprungen werden.

Gray Box: Standard-Benutzerrechte werden gewährt, Architekturzusammenfassung wird bereitgestellt, aber kein Code-Zugriff. Die häufigste B2B-Wahl. Kombiniertes internes+externes Bedrohungsmodell — testet, was ein echter Angreifer mit geleakten Benutzerdaten tun könnte. 5-10 Ingenieur-Tage.

White Box: Quellcode + Architekturdiagramm + Admin-Konto bereitgestellt. Tiefgehende Überprüfung — findet 3-5× mehr Probleme als Black Box. 10-20 Ingenieur-Tage. Am besten geeignet für KVKK-Audit-Vorbereitung, ersten Pentest kritischer Infrastruktur, technische M&A-Due-Diligence.

Praktische Auswahlregel:

Unser Red-Team-Simulationsdienst unterscheidet sich vom klassischen Pentest durch das Anvisieren eines spezifischen Ziels (z. B. Exfiltration von Kundendaten); er verwendet jeden Pfad einschließlich Social Engineering. Klassischer Pentest findet Probleme; Red Team testet Ihre Verteidigungsfähigkeit. Sie dienen unterschiedlichen Zwecken und ersetzen einander nicht.

4. Umfangsdefinition — die Pre-Engagement-Phase

Der am häufigsten diskutierte Teil eines Pentest-Projekts ist die Umfangsdefinition. Unzureichender Umfang → kritische Probleme bleiben unentdeckt, weil sie außerhalb des Umfangs liegen; übermäßiger Umfang → das Testen zieht sich hin, die Preise explodieren.

Ein Mindest-Umfangsdefinitionsdokument muss sechs Abschnitte enthalten:

1. Zu testende Vermögenswerte: URL/IP-Liste, API-Endpunkte, Mobil-App-Versionen. Eine konkrete Liste, kein Wildcard ("*.example.com").
2. NICHT zu testende Vermögenswerte (Ausschlüsse): Drittanbieter-SaaS (Google Workspace, Microsoft 365), Produktions-CRM, Backup-Server. Versehentliches Testen birgt Geschäftskontinuitätsrisiken.
3. Testfenster: Zeitbereich (z. B. 02:00-06:00 außerhalb der Geschäftszeiten) + Wochentage. Um die Auswirkungen auf den Produktionsverkehr zu minimieren.
4. NICHT zu testende Payloads: Denial of Service (DoS), Benutzerdaten-Exfiltration, physische Angriffssimulation. Im Vertrag ausdrücklich verboten.
5. Notfallprotokoll: Wer wird bei einem prod-Ausfall während des Tests angerufen, auf welcher Leitung, Kriterien zum Stoppen des Tests.
6. Kommunikationskanäle: tägliche Status-Berichte, Notfallbenachrichtigungsleitung für kritische Funde (in der Regel innerhalb von 4 Stunden).

Dieses Dokument muss vor Testbeginn von beiden Seiten unterzeichnet werden. Nachträgliche Änderungen durchlaufen einen Change-Request-Prozess; mündliche Vereinbarungen sind nicht gültig.

5. Berichtsformat — Beweiskette und Reproduzierbarkeit

Das gemeinsame Merkmal eines guten Pentest-Berichts ist, dass Befunde reproduzierbar sind. „An URL X gibt es SQL Injection" reicht nicht; ein Entwickler muss dieselbe Anfrage senden und dasselbe Ergebnis beobachten können.

Die fünf Hauptabschnitte eines Standard-Pentest-Berichts:

Abschnitt 1 — Executive Summary (1-2 Seiten). Nicht-technische Sprache: wie viele Befunde, wie viele kritisch/hoch/mittel/niedrig, eine Risiko-Score-Übersichtsgrafik, Kommentar zur Geschäftsauswirkung. Wird vom Top-Management gelesen und entschieden.

Abschnitt 2 — Umfang und Methodik. Welche Systeme wurden getestet, welche Norm wurde verwendet (PTES + OWASP Level 2 etc.), welche Werkzeuge (Burp Suite, Nmap, Metasploit, Custom Scripts), Testfenster. Zur Reproduzierbarkeit.

Abschnitt 3 — Findings-Tabelle (nach CVSS-3.1-Score sortiert). Pro Befund: ID + Titel + Risikostufe + betroffenes Asset + CVSS-Score. Zeigt alle Befunde auf einen Blick.

Abschnitt 4 — Detailseite pro Befund:

• Beschreibung (ein Absatz, technische Sprache)
• Auswirkung: Was passiert, wenn diese Lücke ausgenutzt wird? Datenleck? Account-Übernahme? Systemzugang?
• Reproduktionsschritte: vollständige URL + HTTP-Methode + Header + Payload + erwartete Antwort
• PoC (Proof of Concept): Screenshot, HTTP-Verkehr (Burp-Export), Video-Aufnahme
• Empfohlene Behebung: spezifisch. Nicht „Eingabevalidierung durchführen" — „diese Funktion mit dieser Bibliothek auf diese Weise verwenden".
• Referenzen: OWASP/CWE/CVE-Nummer

Abschnitt 5 — Retest-Ergebnisse. Das Retest-Ergebnis nach der Behebung. Welche Befunde geschlossen, welche teilweise geschlossen, welche offen geblieben. Der Pentest-Anbieter muss innerhalb von 30 Tagen einen kostenlosen Retest bereitstellen.

Ein Bericht, der dieser Struktur nicht entspricht, erschwert es unserem Incident-Response-Team, ihn als Referenz nach einem späteren Verstoß zu verwenden. Berichtsqualität beeinflusst direkt die Geschwindigkeit der forensischen Arbeit nach einem Verstoß.

6. Kriterien für die Lieferantenauswahl — 7 Punkte

Sieben konkrete Kriterien, die bei der Auswahl eines Pentest-Anbieters zu berücksichtigen sind:

1. Team-Zertifizierungen: OSCP (Offensive Security Certified Professional) mindestens, OSCE/OSEP/OSWE obere Stufe, eMAPT für Mobile, GIAC-Zertifizierungen. Fordern Sie den Lebenslauf des Ingenieurs an, der tatsächlich testen wird — das Zertifikat des Projektmanagers reicht nicht.
2. Branchenerfahrung: Eine Firma, die Bankentests macht, ist nicht immer richtig für SCADA. Fragen Sie, wie viele Tests der Anbieter in den letzten 12 Monaten in Ihrer Branche durchgeführt hat.
3. Methodik-Dokumentation: Gibt es eine schriftliche Pentest-Methodik? PTES- oder OWASP-basiert? Im Laufe der Jahre aktualisiert?
4. Werkzeuginventar: Burp Suite Professional + Nessus + Metasploit Framework + Cobalt Strike (für Red Team) + Custom Scripts — eine explizite Werkzeugliste sollte verfügbar sein.
5. Versicherung + NDA: Berufshaftpflichtversicherung (mindestens 1 Mio. TL Deckung) + strikter NDA + Haftungsklausel für Dateninzidenten während des Tests.
6. Retest-Politik: Kostenlos innerhalb von 30 Tagen? 60? Wer definiert den Retest-Umfang?
7. Referenz-Checks: nachprüfbare Referenzen der letzten 3 Kunden; idealerweise ein anonymisiertes Pentest-Berichts-Beispiel.

Wenige Anbieter erreichen Grün bei allen sieben; Sie können mit mindestens 5 grün + 2 gelb-Flaggen arbeiten. Ob gelbe Bereiche für Ihr Projekt kritisch sind, beurteilen Sie.

7. Nach dem Pentest — Behebungsschleife und SLA

Der Pentest-Bericht ist ein Anfang, kein Ende. Das eigentliche Engineering passiert in der Behebung. Branchen-Standard-Behebungs-SLAs:

Mitigation ≠ Fix. Mitigation ist kurzfristige Risikoreduzierung (WAF-Regel, IP-Block, temporäres Feature-Toggle); ein Fix ist die dauerhafte Code-/Konfigurationsänderung. Beides ist für einen kritischen Befund erforderlich.

Interne Prozessablage ist während der Behebung kritisch. Öffnen Sie für jeden Befund ein Ticket, weisen Sie einen Verantwortlichen zu, setzen Sie eine Deadline, definieren Sie, wer die Behebung validiert. Unsere Empfehlung: Der Pentest-Anbieter sollte eine 30-minütige kostenlose technische Beratungssitzung für den Behebungsplan anbieten; um die Frage „Wie beheben wir das im Code?" des Entwicklerteams zu beantworten.

Der Retest wird innerhalb von 30 Tagen, kostenlos, vom selben Anbieter durchgeführt. Der Retest-Bericht ist ein Anhang des Originals; drei Spalten — „geschlossene Befunde" + „noch offen" + „neu entdeckt" (Retests decken manchmal neue Probleme auf).

Nach Abschluss der Behebung richtet unser SOC-Team Monitoring-Signale ein — jeder erneute Angriffsversuch gegen die geschlossene Schwachstelle wird sofort erkannt. Dies ist die Verbindung, die den Pentest-Zyklus an den laufenden Sicherheitsbetrieb anbindet.

Entscheidungsmatrix: wie oft pentesten

Die Pentest-Häufigkeit hängt von Sektor, Regulierung und Risikoprofil ab:

Die Entscheidung zu pentesten ist keine Budget-, sondern eine Risiko-Frage. Die durchschnittlichen Kosten eines kritischen Verstoßes (KVKK-Strafe + Kundenverlust + Reputationsschaden) sind 20-50× die jährlichen Pentest-Kosten. Mit dieser Rechnung ist ein Pentest kein „Luxus", sondern eine „kostengünstige Versicherung". Führen Sie die Berechnung für Ihre eigene Organisation durch und präsentieren Sie sie der Geschäftsführung in diesem Rahmen — die Akzeptanzraten steigen merklich.

Nächster Schritt

Wenn Sie einen Pentest für Ihre Organisation planen — für eine jährliche Routine, regulatorische Anforderung oder neuen Produktstart — bewerten Sie die obigen sieben Punkte gegen Ihr eigenes Szenario. Welche Norm passt, welcher Typ (Black/Gray/White) Priorität hat, welches Lieferantenkriterium für Sie kritisch ist — diese werden end-to-end gemeinsam mit dem Team beantwortet.

Sie können ein Pentest-Vorgespräch über unsere Kontaktseite anfragen; in einem kostenlosen 45-Minuten-Gespräch teilen wir einen Umfangsentwurf + Budget-Bereich + Norm-Empfehlung. Nach dem Gespräch entscheiden Sie, ob Sie einen Pentest durchführen und mit welchem Anbieter; unsere Empfehlung ist nur ein Referenzpunkt.

Die nächsten Beiträge, die diese Serie fortsetzen, werden auf unserem Blog angekündigt: „Praktischer Leitfaden zur Red-Team-Simulation" und „SOC-Bereitstellung — eine 90-Tage-Roadmap". Wenn ein Thema für Sie Priorität hat, lassen Sie es in Ihrer Anfrage wissen, dann können wir das relevante technische Material teilen.