Seit dem 17. Januar 2025 müssen Finanzunternehmen ein Testprogramm der digitalen operationalen Resilienz mit entsprechenden Nachweisen etablieren. Ziel ist es, potenzielle Schwachstellen in IKT-Systemen und -Prozessen zu beseitigen, Verbesserungsbedarf zu identifizieren und Sicherheitslücken zu schließen.
Alexandros Manakos, ehemaliger Head of Cyber Security der HSBC, unterstützt Banken und Versicherungen bei DORA-konformen Resilienz-Tests. Für BV connect erklärt er die wichtigsten Testarten.
Testart
| Frequenz | Auslagerungsfähigkeit |
Intern wöchentlich, Internet Facing täglich | Mittel | |
Jährlich | Hoch | |
Alle drei Jahre | Hoch | |
Vor einem Deployment | Niedrig | |
Vor Einsatz, danach regelmäßig | Mittel | |
Jährlich | Mittel bis hoch | |
Jährlich für kritische Dienstleister, generell kontinuierlich | Hoch | |
Risikobasiert | Hoch | |
Jährlich | Gering |
Schwachstellenscans
Ein Basistest, der signaturbasiert bereits bekannte Schwachstellen überprüft. Manakos empfiehlt, sich einen Überblick über alle kritischen Assets und Netzsegmente zu verschaffen – und diese wöchentlich automatisiert zu scannen. Internet Facing Assets hingegen sollten täglich getestet werden.
Sein Tipp: mit eigenen Tests starten und erst danach externe, authentifizierte Scans etablieren. Dabei immer darauf achten, dass der Umfang des Scans vollumfänglich ist – inklusive Clients, Servern und Netzsegmenten. Werden Schwachstellenscans ausgelagert, sollte das Augenmerk besonders auf Verträgen, SLAs und Reportings liegen.
Penetrationstests
Beauftragte Angreifer:innen testen kritische Applikationen manuell auf Schwachstellen. Bei dieser Testart sollten mehrere etablierte Anbieter rotierend genutzt werden – die Fähigkeit der Penetrationstester:innen muss durch Zertifizierungen und Seniorität erkennbar sein.
Manakos rät, sich bestätigen zu lassen, wer die Tests wirklich durchführt und spezifische Vorgaben zu machen. Die vorgestellten Personen sollen die Tests vornehmen und nicht an unerfahrene Mitarbeitende abgeben. Die Ergebnisse der Penetrationstests müssen dann in das Risikomanagement des Unternehmens einfließen.
Ein signifikanter Kosten- und Aufwandstreiber ist die Einstufung der Asset-Kritikalität. Sie bestimmt, ob ein (kritisches) Asset durch einen manuellen Penetrationstest geprüft werden muss oder nicht. Die Zahl der kritischen Assets kann schnell steigen, was wiederum zu unzähligen manuellen Penetrationstests führt. Hier ist besonderes darauf zu achten, eine smarte und risikobasierte Lösung zu finden.
Threat Led Penetration-Tests (TLPT)
Der umfangreichste Test: Die Angriffssimulation mit der Deutschen Bundesbank, beaufsichtigt durch die BaFin. Manakos: „Das ganze Projekt hat ein Jahr lang gedauert. Die Fähigkeit der Anbieter und Red Teamer ist absolut entscheidend. Meine durchgeführten TLPT haben gezeigt, dass eine sehr gute Vorbereitung inklusive Kenntnis über das TIBER-DE Rahmenwerk das Budget schonen und kritische Situationen vermeiden können.“
Die TLPT gehören zu den erweiterten Testarten und ahmen einen realen Angriff in der produktiven Umgebung nach. Das bedeutet, dass jeder kleine Fehler zu einer Katastrophe führen kann. Wer einen TLPT durchführen muss, erhält von der BaFin einen Identifikationsbescheid.
Quellcodeprüfungen
Selbst entwickelte Codes werden überprüft. Entwickler:innen reagieren darauf oftmals sensibel. Daher rät Manakos zu Hackathons oder ähnlichen Events. Durch die Gamification mit Preisen würde für eine dauerhaft gute Codequalität gesorgt werden.
Die Tests sollten zudem risikobasiert ablaufen: Zuerst werden Internet Facing Codes, dann kritische interne Codes und später weniger kritische Codes geprüft. Die dazugehörigen Schulungen lassen sich einfach auslagern und verringern den internen Aufwand.
Open Source Code-Analysen
Der Open Source Code wird überprüft, wobei die Integrität des Codes zu schützen ist. So können frühzeitig Schwachstellen erkannt und behoben werden. Unternehmen sollten festlegen, wie sie mit kritischen Findings im Open Source Code umgehen: Wann darf der Code eingesetzt werden? Der Aufwand für einen Change ist sehr hoch, wenn alle notwendigen Themen eingebunden werden.
Aus Erfahrung berichtet Manakos, dass es zu zahlreichen Findings bei einer Auslagerung kommen kann. Es komme darauf an, diese anschließend in die eigenen Systeme zu übertragen.
2nd Line Oversight Reviews
Die Second Line of Defense, die für Informationssicherheit zuständig ist, führt eigene Prüfungen innerhalb des Unternehmens durch. Die Überprüfung durch die 2nd Line kann z. B. in Anlehnung an internationale Standards wie NIST CSF (National Institute of Standards and Technology Cyber Security Framework) oder ISO 27001 erfolgen. „Der Fokus sollte auf realen Risiken liegen und es ist ratsam, Externe einzuplanen, falls es zu Engpässen kommt“, beschreibt Manakos weiter.
Wenn die Reviews in Teilen ausgelagert werden, sind die spezifischen Fähigkeiten der Prüfer:innen sicherzustellen.
Third Party Security Audits
Kritische externe Dienstleister werden auf ihre Informationssicherheit überprüft. Dabei sollten die Dienstleister nicht nur nach Wichtigkeit, sondern auch nach Parametern wie Personal Identifiable Information (PII) kategorisiert werden.
Die Expertise der prüfenden Personen sollte dem Fachgebiet entsprechen, da die Dienstleister von Druckereien bis zu spezifischen IT-Services reichen können.
Gap-Analysen
Es handelt sich um eine unabhängige Überprüfung nach vorgegebenen Standards, wobei der Reifegrad der operationalen Resilienz im Unternehmen berücksichtigt wird. Im Optimalfall findet die erste Analyse intern statt. Ist das entsprechende Fachwissen nicht vollumfänglich vorhanden, sollte die Gap-Analyse ausgelagert werden.
Ein jährlicher Überblick über z. B. NIST CSF-Reifegraddarstellungen ist ratsam. Bei Gap-Analysen stellt die Auswahl von geeigneten Prüfer:innen ebenso einen entscheidenden Faktor dar.
BCM-Tests
Im Business Continuity Management (BCM) werden zum Beispiel Geschäftsfortführungspläne, Telefonketten und der Katastrophen-Fall auf den Prüfstand gestellt. Manakos erinnert daran, auch die externen Dienstleister im Unternehmen bei den Tests einzubinden.
Insofern Tools für Telefonketten eingesetzt werden, sollten diese seriös sein und entsprechende Nachweise erbringen. Darüber hinaus muss entschieden werden, ob nur Führungskräfte oder auch Mitarbeitende informiert werden sollen.
Ein Schritt zu mehr Sicherheit
Das Testprogramm zur digitalen operationellen Resilienz legt das Augenmerk auf Schwachstellen – und sorgt so gleichzeitig für mehr Sicherheit. Neben den genannten Testarten sind zahlreiche weitere zwingend notwendig. Jedes Finanzunternehmen muss für sich entscheiden, wie das Programm aussieht und welche Tests sinnvoll ausgelagert werden können.
Deep Dive
Es gibt keine Schonfrist mehr: DORA ist jetzt anzuwenden. Unsere Podcast-Folge von „BV durch die Bank“ gibt Antworten auf spannende Fragen wie: Wie weit ist die Finanzbranche bereits? Welche Herausforderungen bestehen weiterhin? Wie geht es in den nächsten Monaten weiter?
Zur Person
 | Alexandros Manakos, CEO Apollon Security GmbH I Ex-CISO HSBC sieht Cybersicherheit nicht als Verhinderer, sondern vielmehr als Ermöglicher. Der Cyber Security-Experte hat über 24 Jahre Praxiserfahrung in operativer und leitender Funktion in der Informationssicherheit, Cybersicherheit sowie dem Datenschutz. Als ehemaliger Head of Cyber Security und CISO der HSBC, unterstützt er heute mit Apollon Security diverse Unternehmen, unter anderem bei DORA-Projekten und Resilienz-Tests. Zudem ist er als Vorstandsmitglied im ISC2 Germany Chapter e.V. tätig, welches das Verständnis und die Bedeutung der Informationssicherheit fördert. |