Ein Penetrationstest ist ein erprobtes Vorgehen, um das Angriffspotenzial auf ein IT-Netz, ein einzelnes IT-System oder eine Anwendung festzustellen, indem der Weg, den Angreifende gehen würden, simuliert und nachvollzogen wird, um eventuell noch vorhandene Schwachstellen zu finden.
Auf einen Blick
Nach OWASP kann ein Penetrationstest in der Praxis nur eine kleine repräsentative Stichprobe der möglichen Sicherheitsrisiken in einem System erkennen.
Die Ergebnisse gelten nur zum Zeitpunkt des Tests, und dass sämtliche vorhandenen Fehler gefunden werden, ist nicht gewährleistet.
Bedrohungsorientierte Penetrationstests (TLPT) nach DORA betreffen nur Finanzunternehmen, die die zuständige Behörde dafür ermittelt.
Was ist ein Penetrationstest?
Nach dem BSI-Leitfaden zum IS-Penetrationstest werden bei einem Penetrationstest die Erfolgsaussichten eines vorsätzlichen Angriffs auf einen Informationsverbund oder ein einzelnes IT-System eingeschätzt. Daraus werden notwendige ergänzende Sicherheitsmaßnahmen abgeleitet oder die Wirksamkeit bereits umgesetzter Sicherheitsmaßnahmen überprüft. Die IS-Revision auf Basis von IT-Grundschutz soll überprüfen, ob die vorher festgelegten Sicherheitsmaßnahmen wie vereinbart umgesetzt sind; der Penetrationstest geht einen Schritt weiter und sucht gezielt nach Wegen, diese eingesetzten Sicherheitsmaßnahmen zu umgehen. Der Test soll so dimensioniert werden, dass Schwachstellen zwar nachgewiesen, aber nur dann aktiv ausgenutzt werden, wenn es nicht vermeidbar ist und die Exploits ausreichend getestet wurden. Nach OWASP kann ein Penetrationstest in der Praxis nur eine kleine repräsentative Stichprobe der möglichen Sicherheitsrisiken in einem System erkennen.
Ein Versicherer kann sein Kundenportal in vereinbartem Umfang auf ausnutzbare Schwachstellen prüfen lassen, während Artikel 26 DORA für bestimmte, von der zuständigen Behörde ermittelte Finanzunternehmen zusätzlich bedrohungsorientierte Penetrationstests vorsieht. Im Testprogramm eines Finanzunternehmens nennt Artikel 25 Absatz 1 DORA Penetrationstests neben Schwachstellenbewertung und -scans, Quellcodeprüfungen soweit durchführbar und weiteren angemessenen Tests.
Wie läuft ein Penetrationstest ab?
Nach dem BSI-Leitfaden sollte der Vertrag zu einem Penetrationstest Rahmenbedingungen wie Prüfzeitraum, Prüfobjekt und Prüftiefe spezifizieren, und Prüfer sollten nur mit schriftlichem Auftrag testen. Zu den Prüftiefen zählen unter anderem ein technisches Sicherheitsaudit und ein nicht invasiver Schwachstellenscan, bei dem der Prüfer zusätzlich zum technischen Sicherheitsaudit mit eigenen Geräten im Netz nach Schwachstellen sucht. Ein bedrohungsorientierter Penetrationstest schließt nach Artikel 26 DORA mehrere oder alle kritischen oder wichtigen Funktionen eines Finanzunternehmens ein und läuft an Live-Produktionssystemen, die diese Funktionen unterstützen.
Bei einem Blackbox-Test stehen den Prüfern lediglich die Adressinformationen des Ziels zur Verfügung, bei einem Whitebox-Test dagegen umfangreiche Informationen über die Systeme. Die OWASP beschreibt den Penetrationstest einer Anwendung als Test aus der Ferne ohne Kenntnis der inneren Abläufe, also nahe am Blackbox-Test; der Tester handelt wie ein Angreifer und versucht, Schwachstellen zu finden und auszunutzen, erhält dabei aber in vielen Fällen ein oder mehrere gültige Konten. Blackbox- und Whitebox-Test unterscheiden sich damit im Informationsstand der Prüfer.
Penetrationstest im Vergleich
Ein nicht invasiver Schwachstellenscan ist nach dem BSI-Leitfaden eine Prüftiefe, bei der Schwachstellenscanner eingesetzt, die Schwachstellen aber nicht ausgenutzt werden; beim Penetrationstest wird nach dem BSI der Weg, den Angreifende gehen würden, nachvollzogen. Red Teaming im Sinne des bedrohungsorientierten Penetrationstests nach Artikel 3 Nummer 17 DORA bildet dagegen Taktik, Techniken und Verfahren realer Angreifer nach und ermöglicht einen kontrollierten, maßgeschneiderten, erkenntnisgestützten Test der kritischen Live-Produktionssysteme des Finanzunternehmens.
Wann ist ein Penetrationstest sinnvoll?
| Merkmal | Worauf es ankommt |
|---|---|
| Informationsstand der Prüfer | Das BSI empfiehlt grundsätzlich Whitebox-Tests, weil bei einem Blackbox-Test aufgrund nicht vorliegender Informationen Schwachstellen übersehen werden können. |
| TLPT nach DORA | Von der zuständigen Behörde ermittelte Finanzunternehmen, die weder die in Artikel 16 Absatz 1 Unterabsatz 1 genannten Unternehmen noch Kleinstunternehmen sind, führen nach Artikel 26 Absatz 1 DORA grundsätzlich mindestens alle drei Jahre erweiterte Tests anhand von TLPT durch; die zuständige Behörde kann die Häufigkeit auf Grundlage des Risikoprofils verringern oder erhöhen. |
| Ermittlung durch die Behörde | Die zuständigen Behörden ermitteln die Finanzunternehmen, die TLPT durchzuführen haben, unter Berücksichtigung der in Artikel 4 Absatz 2 aufgeführten Kriterien. |
Schutz im Ernstfall
Vorbeugen
- Ein unter DORA fallender Versicherer, der kein Kleinstunternehmen ist, erstellt, pflegt und überprüft nach Artikel 24 DORA unter Berücksichtigung der in Artikel 4 Absatz 2 aufgeführten Kriterien ein solides und umfassendes Programm für das Testen der digitalen operationalen Resilienz.
- Ist er kein Kleinstunternehmen, stellt er dabei sicher, dass die Tests von unabhängigen, internen oder externen Parteien durchgeführt werden und dass bei allen IKT-Systemen und -Anwendungen, die kritische oder wichtige Funktionen unterstützen, mindestens einmal jährlich angemessene Tests stattfinden.
- Prüfer wählen: Nach dem BSI-Leitfaden müssen IS-Penetrationstests immer von fachlich qualifizierten Personen durchgeführt werden, die unabhängig von den untersuchten Bereichen sind und nicht an Konzeption, Aufbau oder Betrieb des untersuchten Informationsverbundes mitgewirkt haben.
Was tun im Ernstfall
- Den Bericht auf Empfehlungen prüfen: Nach dem BSI-Leitfaden sollten darin auch Empfehlungen enthalten sein, welche Maßnahmen die gefundenen Schwächen beseitigen.
- Ein unter DORA fallender Versicherer, der kein Kleinstunternehmen ist, legt nach Artikel 24 DORA Verfahren und Leitlinien zur Priorisierung, Klassifizierung und Behebung der bei den Tests zutage getretenen Probleme fest.
Beispiele aus der Praxis
- Eine Organisation plant einen Test ihrer Produktivsysteme und schließt destruktive Tests aus, also Tests, bei denen die Zielsysteme zu Schaden kommen könnten.
- Ein Team nutzt den Penetrationstest als einen Baustein seines Testprogramms; OWASP hält ihn nicht für die primäre und nicht für die alleinige Testtechnik.
- Ein Versicherer könnte etwa sein Kundenportal in vereinbartem Umfang testen lassen und die Qualitätssicherung fortführen, denn ein Penetrationstest ersetzt sie nicht: Er betrachtet keine funktionalen Aspekte und erfolgt nur stichprobenartig.