Ein guter Penetrationstest beantwortet eine konkrete Risikofrage in einem schriftlich freigegebenen Scope. Er ist kein automatisierter Schwachstellenscan, keine Erfolgsgarantie gegen Angriffe und kein pauschaler Compliance-Nachweis. Entscheidend sind Testziel, Befugnis, realistische Testtiefe, sichere Durchführung und die nachweisbare Behebung der Findings.
Wann ist ein Penetrationstest sinnvoll?
Ein Pentest ist besonders nützlich, wenn eine Organisation prüfen will, ob ausgewählte Angriffswege praktisch ausnutzbar sind, zum Beispiel:
- vor dem produktiven Start einer geschäftskritischen Anwendung,
- nach wesentlichen Architektur-, Identitäts- oder Netzwerkänderungen,
- nach einer auffälligen Schwachstelle oder einem Vorfall,
- zur Wirksamkeitsprüfung von Segmentierung und Zugriffsschutz,
- als risikobasierter Bestandteil eines Prüf- oder Assurance-Programms.
Ein Scan findet bekannte technische Muster in großer Breite. Ein Pentest verbindet Werkzeuge mit manueller Analyse und kontrollierter Ausnutzung. Eine Red-Team-Übung prüft darüber hinaus Erkennung und Reaktion gegen ein vereinbartes Angriffsziel. Diese Formate sollten nicht unter derselben Leistungsbeschreibung eingekauft werden.
Black, Grey oder White Box?
| Ansatz | Ausgangsinformation | Geeignet für |
|---|---|---|
| Black Box | wenige Informationen | externe Sicht und unbekannte Angriffswege, aber begrenzte Abdeckung |
| Grey Box | ausgewählte Konten, Rollen oder Architekturinformationen | realistische, effiziente Prüfung definierter Nutzer- und Angreiferpfade |
| White Box | umfassende Dokumentation, Konfiguration oder Quellcode | tiefe Abdeckung und gezielte Prüfung komplexer Kontrollen |
Mehr Geheimhaltung macht einen Test nicht automatisch realistischer. Wenn das Ziel eine breite Sicherheitsbewertung ist, liefert ein Grey- oder White-Box-Ansatz häufig mehr verwertbare Evidenz pro Testtag.
Scope und Rules of Engagement
Vor Beginn müssen Auftraggeber, Systemverantwortliche und Testende mindestens festlegen:
- Systeme, Domains, APIs, Mandanten, Standorte und Konten im Scope,
- ausdrücklich ausgeschlossene Systeme und Techniken,
- Testfenster, Lastgrenzen und Abbruchkriterien,
- erlaubte Ausnutzung, Persistenz, Social Engineering und Datenzugriffe,
- Umgang mit Produktionsdaten und personenbezogenen Daten,
- Kontakt- und Eskalationswege während des Tests,
- Beweissicherung, Verschlüsselung, Aufbewahrung und Löschung,
- Freigaben von Cloud-, Hosting- oder sonstigen Dritten,
- Haftung, Vertraulichkeit und Vorgehen bei kritischen Funden.
Schriftliche Autorisierung schützt nicht nur die Testenden. Sie verhindert, dass ein technisch erfolgreicher Test den Betrieb stört, Daten unzulässig verarbeitet oder Systeme außerhalb der Verfügungsbefugnis trifft.
Ablauf eines belastbaren Pentests
1. Ziel und Bedrohungsmodell
Formulieren Sie die Entscheidung, die das Ergebnis unterstützen soll. „Webshop testen“ ist zu weit. Besser: „Kann ein nicht privilegierter Kunde auf Daten anderer Mandanten zugreifen oder administrative Funktionen erreichen?“ Relevante Rollen, Daten und Vertrauensgrenzen bestimmen die Tests.
2. Aufklärung und Angriffsflächenanalyse
Die Testenden erfassen erreichbare Dienste, Technologien, Eingabepunkte und Abhängigkeiten im vereinbarten Umfang. Offene Quellen dürfen nur genutzt werden, soweit Auftrag und Recht dies erlauben.
3. Schwachstellenanalyse und kontrollierte Validierung
Automatisierte Ergebnisse werden manuell verifiziert. Ausnutzung erfolgt nur so weit, wie sie für Wirkungsnachweis und vereinbarte Angriffskette erforderlich ist. Kritische Befunde werden über den Sofortkanal gemeldet, nicht erst im Abschlussbericht versteckt.
4. Bereinigung und Bericht
Testkonten, Daten, Dateien und Änderungen werden nach den Rules of Engagement bereinigt. Der Bericht sollte Management und Technik bedienen:
- Scope, Zeitraum, Methode und Einschränkungen,
- nachvollziehbare Angriffspfade und Evidenz,
- technische Schwere und geschäftliche Auswirkung,
- reproduzierbare Behebungsempfehlung,
- bestätigte Annahmen und nicht geprüfte Bereiche,
- priorisierte Zusammenfassung für Risikoverantwortliche.
CVSS kann die technische Einordnung unterstützen, ersetzt aber nicht die organisationsspezifische Risikobewertung.
5. Behebung und Re-Test
Der Eigentümer akzeptiert, mindert, vermeidet oder überträgt das Risiko nach dem internen Verfahren. Behebungsfristen richten sich nach Ausnutzbarkeit, Exposition, Schutzbedarf und Abhängigkeiten — nicht nach einer universellen 30-Tage-Regel. Ein Re-Test prüft gezielt, ob die Ursache wirksam behoben wurde und keine neue Schwachstelle entstanden ist.
Was verlangen NIS2 und BSIG wirklich?
§ 30 BSIG nennt sichere Beschaffung, Entwicklung und Wartung einschließlich Schwachstellenmanagement sowie Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen. Der Paragraf schreibt keinen allgemeinen jährlichen Penetrationstest vor. Ein Pentest kann jedoch eine angemessene Wirksamkeitsprüfung sein, wenn Risiko, System und Testziel dazu passen.
Betreiber kritischer Anlagen haben zusätzliche Nachweis- und Prüfpflichten. DORA enthält für ausgewählte Finanzunternehmen ein eigenes Threat-Led Penetration Testing. Diese sektoralen Anforderungen dürfen nicht auf alle NIS2-Einrichtungen übertragen werden.
BSI-, NIST- und OWASP-Leitfäden sind methodische Orientierung, keine zusätzliche deutsche Rechtsnorm. Auch eine Zertifizierung der Testperson entbindet den Auftraggeber nicht von Scope-, Datenschutz- und Risikoentscheidungen.
Anbieter und Angebot vergleichen
Fordern Sie vergleichbare Angebote auf Basis desselben Scopes an. Prüfen Sie:
- Erfahrung mit der Technologie und dem Bedrohungsmodell,
- Unabhängigkeit und Interessenkonflikte,
- benannte Testende und Qualitätssicherung,
- Methode, Testtiefe und ausgeschlossene Techniken,
- Sofortmeldung kritischer Findings,
- Berichtsmuster und Re-Test-Regelung,
- sichere Evidenzverarbeitung und Löschung,
- Haftpflichtdeckung und Unterauftragnehmer.
Pauschale Marktpreise sind wenig belastbar. Aufwandstreiber sind Angriffsfläche, Rollen, Mandanten, Komplexität, Testtiefe, Produktionsrisiko, Reisebedarf, Berichtssprache und Re-Test. Ein günstiger Festpreis mit unklarem Scope ist selten ein vergleichbarer Leistungsnachweis.
Kompakte Abnahmekriterien
Ein Pentest ist erst abgeschlossen, wenn:
- die freigegebenen Ziele und Einschränkungen dokumentiert sind,
- kritische Funde zeitnah eskaliert wurden,
- der Bericht reproduzierbare Evidenz enthält,
- Systeme und Testdaten bereinigt sind,
- jedes Finding einen Eigentümer und eine Risikoentscheidung hat,
- der Re-Test-Umfang feststeht,
- Bericht und Rohdaten gemäß Vereinbarung geschützt oder gelöscht werden.
Unsere Cyber-Security-Beratung unterstützt bei Bedarfsanalyse, Scope, Anbietersteuerung, Risikobewertung und der Überführung von Findings in prüfbare Maßnahmen.
Quellen und Prüfung
Robert Lozo, mag. iur., ist Partner bei Vision Compliance mit Schwerpunkt EU-Regulierung. Er berät Organisationen zu DSGVO, NIS2, EU AI Act und Finanzregulierung und liefert auditfähige Dokumentation und Compliance-Fahrpläne für regulierte Branchen.