Ab dem 17. Januar 2025 findet der Digital Operational Resilience Act (DORA) Anwendung. Sein Ziel ist, die operationale Resilienz von Finanzunternehmen zu erhöhen. Die europäischen Aufsichtsbehörden EBA, ESMA und EIOPA veröffentlichten Mitte Januar die ersten finalen Entwürfe der technischen Regulierungs- (RTS) und Implementierungsstandards (ITS). Für das zweite Entwurfspaket findet von Dezember 2023 bis März 2024 die öffentliche Konsultation statt. Am 23.01.2024 fand eine Anhörung statt, an der ich teilgenommen habe.
Nachfolgend gehe ich auf zwei Themen ein, die für Mehrmandanten-IKT-Drittdienstleister (IKT-DDL) wie PASS besonders relevant sind: Regulierungsstandard zur Vergabe von Unteraufträgen für IKT-Dienstleistungen und Regulierungsstandard für bedrohungsorientierte Penetrationstests (TLPT).
1. Regulierungsstandard zur Vergabe von Unteraufträgen für IKT-Dienstleistungen
DORA beschreibt in Artikel 30 Absatz 2 generelle Elemente, die zwischen Finanzunternehmen (FU) und IKT-Drittdienstleistern (IKT-DDL) geschlossene Verträge enthalten müssen. Dem schließen sich in Absatz 3 Elemente für Verträge über die Nutzung kritischer und wichtiger Funktionen an. Der von den Aufsichtsbehörden hierzu vorgelegte technische Regulierungsstandard (RTS) geht darüber hinaus auf den Lebenszyklus der Nutzung ausgelagerter IKT-Dienstleistungen ein und unterteilt die Anforderungen in vier Phasen:
Finanzunternehmen sind vor Abschluss eines Auslagerungsvertrags über die Nutzung kritischer und wichtiger Funktionen zur Durchführung einer Ex-Ante-Risikobewertung verpflichtet. Dabei sind im Rahmen einer Due Diligence alle für die Risikoabschätzung notwendigen Informationen abzufragen. Hierzu gehören u.a. folgende Punkte:
- Die Fähigkeiten des IKT-DDL zur Leistungserbringung, seine Fachkenntnisse, das Vorhandensein angemessener finanzieller, personeller und technischer Ressourcen, Informationssicherheitsstandards, eine geeignete Organisationsstruktur usw.
- Ist der Dienstleister in der Lage, einschlägige technologische Entwicklungen zu überwachen und sich führende IKT-Sicherheitspraktiken anzueignen? Kann er diese umsetzen, um auch dauerhaft über einen wirksamen und soliden Rahmen für die digitale betriebliche Widerstandsfähigkeit zu verfügen und somit den Geschäftsbetrieb aufrechterhalten zu können?
- Transparenz über die Orte der Leistungserbringung sowie Weiterverlagerungen an Sub-Dienstleister. Kann der IKT-DDL sicherstellen, dass Prüfungen durch das Finanzinstitut, beauftragte Dritte und zuständige Behörden auch vor Ort und über die gesamte Unterauftragnehmerkette durchgeführt werden können?
Über eine solche initiale Risikobewertung hinaus fordern die Aufsichtsbehörden eine regelmäßige Neubewertung der IKT-Dienstleister hinsichtlich eingetretener Änderungen.
Über die in DORA Artikel 30 bereits aufgeführten Vertragselemente hinaus präzisiert der Regulierungsentwurf u.a. die notwendigen Vereinbarungen zum Recht auf Informationszugang, Einsichtnahme, Prüfung und IKT-Tests. Soweit es erforderlich ist, sind gemeinsame Audits und/oder IKT-Tests zu vereinbaren, einschließlich bedrohungsorientierter Penetrationstests (TLPT).
Hinsichtlich Tests weisen die Aufsichtsbehörden darauf hin, dass diese gemeinsam mit anderen Finanzunternehmen oder Firmen, die IKT-Dienstleistungen desselben IKT-Drittanbieters in Anspruch nehmen, organisiert werden können (sogenanntes Pooled Testing, siehe auch den zweiten Teil dieses Beitrags). Für die Durchführung kommen dann auch von diesen beauftragte Dritte infrage.
Es wird darauf hingewiesen, dass das Finanzinstitut sich nicht ausschließlich auf Zertifizierungen oder Berichte von Drittanbietern oder internen Audits des IKT-DDL verlassen darf. Gleichzeitig werden Kriterien genannt, unter denen die Verwendung solcher Nachweise jedoch zulässig ist.
Das Finanzunternehmen muss die laufende Überwachung des IKT-DDL sicherstellen und ihn zur Berichterstattung über die gesamte Untervergabekette verpflichten. Dazu gehören u.a.:
- Die Leistungsbewertung durch Gegenüberstellung von KPIs (IST) mit vertraglich vereinbarten Werten (SOLL).
- Berichte über die Einhaltung von Anforderungen an die Vertraulichkeit, Verfügbarkeit, Integrität und Authentizität von Daten und Informationen sowie über Zwischenfälle einschließlich IKT-bezogener Vorfälle und betrieblicher oder sicherheitsrelevanter Zahlungsvorfälle.
- Berichte über Maßnahmen und Tests zur Aufrechterhaltung des Geschäftsbetriebs.
Seitens der Aufsichtsbehörden wird empfohlen, Maßnahmen für den Fall der Nichteinhaltung von Dienstleistungsvereinbarungen festzulegen, bei denen es sich nicht zwingend um Vertragsstrafen handeln muss.
Ein weiterer wichtiger Punkt ist eine vertraglich vereinbarte Informationspflicht bei wesentlichen Änderungen und die daraus resultierende Neubewertung des Vertragsverhältnisses durch das Finanzunternehmen.
Bereits bei Abschluss einer Vereinbarung über die Nutzung kritischer und wichtiger Funktionen eines IKT-DDL ist vom Finanzunternehmen ein Ausstiegsplan zu erstellen, regelmäßig zu überprüfen und zu erproben. Das FU stellt sicher, dass der Ausstiegsplan realistisch und durchführbar ist, auf plausiblen Szenarien und vernünftigen Annahmen beruht und einen Umsetzungszeitplan enthält, der mit den in den einschlägigen vertraglichen Vereinbarungen festgelegten Ausstiegs- und Kündigungsbedingungen vereinbar ist.
Als zu berücksichtigende Kriterien für die Beendigung eines Vertrags werden u.a. genannt:
- Unvorhergesehene und anhaltende Dienstunterbrechungen
- Eine unangemessene oder fehlgeschlagene Leistungserbringung
- Die unerwartete Beendigung einer einschlägigen vertraglichen Vereinbarung
- Unterauftragsvergabe, die laut Vertrag nicht zulässig ist
- Wesentliche Änderungen trotz Einspruch oder ohne Information darüber
Standardisierung der Due Diligence wäre wünschenswert
Die Anforderungen des Regulierungsstandards für Verträge von Finanzunternehmen mit IKT-Drittdienstleistern sind detailliert und in sich stimmig. Aus Sicht des Mehrmandantendienstleisters PASS enthalten sie wenig Neues. Unser Standard-Vertragswerk kann zusammen mit unseren etablierten Prozessen zur Servicemessung und -überwachung (SLAs, KPIs, Service Reporting etc.) bereits heute als DORA-konform angesehen werden. Optimierbar sind an einigen Stellen bestenfalls die Terminologie oder auch Präzisierungen, was eine Überprüfung der Konformität erleichtern dürfte.
Wünschenswert wäre aus unserer Sicht eine Standardisierung der Due Diligence bei den Finanzunternehmen analog zu den standardisierten Fragebögen zur IT-Dienstleisterbewertung, die regelmäßig im Rahmen des aufsichtlichen Überprüfungsprozesses (SREP) von der Bundesbank angefordert werden.
DORA-Konformität unserer Verträge mit Finanzunternehmen
Einhergehend mit der Präzisierung der DORA-Regulierungsstandards wurden diese Vertragsvorlagen nun erneut umfangreich überarbeitet. Dabei erwies sich eine Excel-Liste der BaFin als wertvolle Hilfestellung. Diese enthält 76 Punkte aus DORA selbst sowie aus zwei relevanten technischen Regulierungsstandards (RTS), deren Umsetzung in einem Vertragswerk überprüft und "abgehakt" werden kann.
Zur Vereinfachung von Vertragsprüfungen stellt PASS seinen Kunden eine Version dieser BaFin-Liste zur Verfügung, in der zu jedem der 76 Punkte angegeben ist, an welcher Stelle des aktuellen Vertragswerks bzw. wodurch die genannte Anforderung erfüllt wird.
Um auch ältere Bestandsverträge mit überschaubarem Aufwand DORA-konform zu machen, hat PASS gemeinsam mit seinen Rechtsanwälten einen Nachtrag erstellt, in dem zu jedem dieser 76 Punkte entweder eine vorrangig geltende Vereinbarung oder ein Verweis auf Ziffern der im Nachtrag ebenfalls enthaltenen Anlagen angegeben ist. Durch diesen pragmatischen Lösungsvorschlag, der mögliche Unsicherheiten auf Kundenseite reduzieren soll, können die meisten älteren Verträge Konformität zu DORA erreichen, ohne dass es eines komplett neuen Vertrags bedarf. Kunden müssen sich im Nachgang von ihren Anwälten die DORA-Compliance und damit Rechtssicherheit attestieren lassen, dieser Aufwand reduziert sich jedoch dadurch, dass nicht betroffene Klauseln (z.B. Service-/Leistungsdetails, kommerzielle Parameter) unberührt bleiben.
Update vom 16.10.2024
IT-Governance, IT-Risikomanagement und IT-Compliance
2. Regulierungsstandard für bedrohungsorientierte Penetrationstests (TLPT)
In DORA ist Abschnitt IV, das sind die Kapitel 24 bis 27, dem Testen der digitalen operationalen Resilienz gewidmet. Finanzunternehmen müssen nach dem Grundsatz der Verhältnismäßigkeit ein Programm für das Testen der digitalen operationalen Resilienz etablieren, das integraler Bestandteil ihres IKT-Risikomanagementrahmens ist. Dabei geht es in Artikel 25 zunächst um das Testen von IKT-Tools und -Systemen. Genannt wird dabei das branchenübliche Portfolio an Testverfahren: Vulnerability Assessments und Schwachstellen-Scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Gap-Analysen, Überprüfungen der physischen Sicherheit, Scans von Softwarelösungen, Quellcodeprüfungen und – so weit durchführbar – szenariobasierte Tests, Kompatibilitätstests, Belastungstests, End-to-End-Tests und Penetrationstests.
Artikel 26 geht darüber hinaus und fordert für einige Finanzunternehmen erweiterte Tests, sogenannte bedrohungsorientierte Penetrationstests (TLPT – Threat-Led Penetration Testing). Diese werden in Artikel 3 (17) definiert als ein Rahmen, der Taktik, Techniken und Verfahren realer Angreifer, die als echte Cyberbedrohung empfunden werden, nachbildet und einen kontrollierten, maßgeschneiderten, erkenntnisgestützten Test der kritischen Live-Produktionssysteme des Finanzunternehmens ermöglicht.
Der Regulierungsentwurf (RTS) beschreibt einen zweistufigen Ansatz. Der Standardfall betrifft alle Finanzunternehmen, die in zentralen Teilsektoren der Finanzbranche tätig sind, eine systemische Rolle spielen und festgelegte Kriterien erfüllen bzw. Schwellenwerte überschreiten. Dabei behält sich die zuständige Behörde (auch TLPT-Behörde genannt) ein Opt-out für Unternehmen vor, bei denen beispielsweise der IKT-Reifegrad nicht ausreicht, um Tests an laufenden Produktionssystemen durchzuführen.
Neben diesem Standardfall kann die TLPT-Behörde fallweise festlegen, dass ausgewählte Finanzunternehmen einen bedrohungsorientierten Penetrationstest durchführen müssen, bei denen es nach dem zuvor beschriebenen Standardfall nicht notwendig wäre. Diese Entscheidung soll nach einer Bewertung durchgeführt werden, für die in Kapitel II des RTS einige Aspekte, jedoch keine exakten Kriterien oder Schwellenwerte genannt werden. Aufgeführte Beispiele dafür sind die Bedrohungslage des Finanzunternehmens, der Grad seiner Abhängigkeit von kritischen oder wichtigen Funktionen von IKT-Systemen und Prozessen sowie die Komplexität seiner IKT-Architektur.
Der RTS erwähnt einige der Begleiteffekte von bedrohungsorientierten Penetrationstests: Denial-of-Service-Vorfälle, unerwartete Systemabstürze, Schäden an kritischen produktiven Systemen oder der Verlust, die Veränderung oder die Offenlegung von Daten. Es wird deutlich gemacht, dass die Verantwortung für die Durchführung des Tests und das damit verbundene Risikomanagement ausschließlich bei dem Finanzunternehmen liegt, das den Test durchführt. Gleichzeitig wird auf die Notwendigkeit robuster Risikomanagementmaßnahmen durch das FU hingewiesen, von denen einige im RTS in Kapitel III, Artikel 5 dargestellt werden.
Gemäß DORA Artikel 26 ermitteln und bewerten die Finanzunternehmen selbst alle relevanten zugrunde liegenden IKT-Systeme, -Prozesse und -Technologien, die kritische oder wichtige Funktionen und IKT-Dienstleistungen unterstützen, einschließlich derer, die an IKT-Drittdienstleister ausgelagert oder per Vertrag vergeben wurden. Auf dieser Grundlage legen die FU den Umfang eines TLPT fest, was von den zuständigen Behörden jedoch validiert werden muss.
Sind IKT-Drittdienstleister (IKT-DDL) in den Testumfang einbezogen, muss das Finanzunternehmen gemäß DORA, Artikel 26 alle erforderlichen Maßnahmen und Vorkehrungen ergreifen, um ihre Einbindung in den Test sicherzustellen und trägt jederzeit die volle Verantwortung dafür.
DORA erwähnt bereits in Artikel 26 die Möglichkeit, dass durch die Einbindung eines IKT-Drittdienstleisters in einen TLPT, für den das Finanzunternehmen verantwortlich ist, auch die Qualität bzw. Sicherheit von Leistungen des Dienstleisters für andere Kunden eingeschränkt werden kann; auch für solche Kunden, die nicht von DORA betroffen sind. Um dieses Risiko zu mindern, können das FU und der IKT-DDL vereinbaren, dass der IKT-DDL einen externen Tester mit der Durchführung eines gebündelten TLPT für mehrere der FU beauftragt, für die er vergleichbare Dienstleistungen erbringt.
Ein gebündelter Test bedarf der Zustimmung durch die verantwortliche Behörde. Dabei soll gemäß Regulierungsentwurf die Zahl der Finanzunternehmen, die sich daran beteiligen, unter Berücksichtigung der Komplexität und der Art der betreffenden Dienstleistungen angemessen austariert werden.
Kapitel III des RTS enthält Details der Methodik eines bedrohungsorientierten Penetrationstests. Sie lehnt sich eng an das im TIBER-EU-Rahmen skizzierte Prüfverfahren an. Dabei wird jedoch ausdrücklich auf Unterschiede zwischen den Verfahren hingewiesen und deutlich gemacht, dass nur die DORA-TLPT-Anforderungen rechtlich bindend sind.
Bei der personellen Besetzung für einen TLPT wird zwischen fünf Teams unterschieden, die jeweils durch eine Farbe repräsentiert werden:
- Grau: Beim TLPT-Cyberteam (oder TCT) handelt es sich um das Personal innerhalb der TLPT-Behörde, in dem alle operativen TLPT-bezogenen Angelegenheiten behandelt werden.
- Weiß: Das Kontrollteam verwaltet den TLPT aus der Sicht des Finanzunternehmens, das ihn durchführt und dafür verantwortlich ist. Dies umfasst alle Aspekte von der Beschaffung der externen Anbieter über die Risikobewertung bis hin zum operativen Management der täglichen Testaktivitäten, dem Risikomanagement. Der Leiter des Kontrollteams sollte über das notwendige Mandat innerhalb der Finanzinstitution verfügen, um alle Aspekte des Tests zu leiten, ohne jedoch die Geheimhaltung des Tests zu gefährden.
- Blau: Das blaue Team besteht aus denjenigen Mitarbeitern, die das Finanzunternehmen gegen simulierte oder reale Cyber-Bedrohungen verteidigen, ohne zu wissen, dass sie getestet werden.
- Rot: Das rote Team repräsentiert die Angreifer. Dabei kann es sich sowohl um interne als auch externe Tester handeln. Kapitel IV des RTS enthält detaillierte Kriterien für den Einsatz interner Tester des Finanzunternehmens. Unterstützt wird das rote Team durch einen oder mehrere Anbieter von Bedrohungsdaten. Ihre Aufgabe ist, ähnlich der eines Hackers, die Informationsbeschaffung.
Der zeitliche Verlauf eines TLPT wird wie folgt beschrieben (Details sind im RTS, Kapitel III, Abschnitt II zu finden):
- Die TLPT-Behörde benachrichtigt das Finanzunternehmen über die notwendige Durchführung eines TLPT.
- Für die anschließende Vorbereitungsphase wird im RTS eine voraussichtliche Dauer von sechs Monaten angegeben.
- Danach steht die Testphase an. Sie erfordert zunächst eine Bedrohungsanalyse, anschließend die Planung und Durchführung des Tests durch das rote Team. Die Dauer des eigentlichen Tests wird mit mehr als zwölf Wochen angegeben.
- In der Abschlussphase werden die Testberichte des roten und des blauen Teams erstellt und eine Zusammenfassung des TLPT. Danach gibt es Rückmeldungen der verschiedenen Teams und es wird ein Sanierungsplan erarbeitet. Innerhalb von zwölf Wochen nach Abschluss der aktiven Testphase legt das Kontrollteam den zusammenfassenden Testbericht der TLPT-Behörde zur Genehmigung vor. Für die Dauer der gesamten Abschlussphase werden vier Monate geschätzt.
- Am Ende des Tests stellt die TLPT-Behörde dem Finanzinstitut eine Bescheinigung aus.
Ein Push aus der Komfortzone
Bedrohungsorientierte Penetrationstests sind ohne Zweifel ein wirksames, wenn auch aufwendiges und kostspieliges Instrumentarium, um Schwächen in der Widerstandsfähigkeit von Finanzunternehmen gegenüber Cyberbedrohungen zu erkennen. Dabei bringen sie Finanzunternehmen wie auch IKT-Drittdienstleister eindeutig aus der Komfortzone. Finanzunternehmen werden zur Einhaltung gesetzlicher Vorgaben dazu gezwungen, die Verfügbarkeit ihrer eigenen IKT-Infrastruktur zu bedrohen und die Schutzziele der Daten ihrer Kunden zu gefährden – und dafür selbst die Verantwortung zu übernehmen.
Werden zu einem Mehrmandantendienstleister ausgelagerte Funktionen mitgetestet, gehört dieser gemäß der Methodik zum blauen Team und darf somit nicht über den Test informiert werden. Dies impliziert immer das Risiko, dass auch andere Kunden des Dienstleisters beeinträchtigt werden, wofür das testende Finanzunternehmen verantwortlich wäre.
Es ist aus unserer Sicht unbedingt empfehlenswert, dass ein Mehrmandantendienstleister wie PASS beim TLPT seiner Kunden sowohl im blauen Team als auch im weißen Team angemessen vertreten ist, damit der Test einerseits wirksam sein kann (da das blaue Team des Dienstleisters nicht auf den Test vorbereitet ist) und andererseits die Risiken so weit wie möglich gemindert werden können (da Vertreter des Dienstleisters im weißen Team Vorkehrungen für eine Begrenzung mindestens der Kollateralschäden treffen können). Dies ist herausfordernd. Ist die TLPT-Behörde der Meinung, dass mehrere Kunden des IKT-DDL dem Test unterzogen werden müssen, sollten zudem alle Aktivitäten gebündelt werden und das Konzept des Pooled Testing zur Anwendung kommen.
Lesen Sie mehr zum Thema: DORA – alle wichtigen Informationen auf einen Blick.
Bildquelle: Shutterstock
