Feuerprobe für Finanzunternehmen: IKT‑Vorfallmanagement auf dem Prüfstand von DORA

Eine steigende Flut von Cyberangriffen trifft vor allem Finanzinstitute – hier gibt es für Cyberkriminelle schließlich besonders viel zu holen. Das Vertrauen in existierende präventive und detektive Sicherheitsmaßnahmen wird auf die Probe gestellt, da trotz aller Vorsicht Vorfälle im Zusammenhang mit Informations- und Kommunikationstechnologie (IKT) eskalieren können. Mit Blick auf die Welle unvermeidbarer Zwischenfälle stellt sich die Frage: Gibt es überhaupt eine effektive Lösung? Inmitten dieser Unsicherheit fordert der Digital Operational Resilience Act (DORA) einen radikalen Umzug ­–­ weit über die etablierten Regularien wie VAIT, BAIT, ZAIT und KAIT hinaus.

von Jens Bläser, Armin Reinhardt und Oliver Abele, Deloitte

Während die Behandlung von (Security) Incidents in diesen Vorgaben bereits gefordert war, müssen schwerwiegende IKT-Vorfälle nun auch an die Aufsicht gemeldet werden. Aktuell definiert das BSI spezifische Kriterien dafür, wann welche IKT-Vorfälle gemeldet werden müssen. Zudem werden Fristen und der inhaltliche Aufbau derartiger Meldungen vorgegeben.

Insbesondere die Erstmeldung mit einer Frist von maximal 24 Stunden nach Erfassung eines Vorfalls kann neben der eigentlichen Behebung des Vorfalls eine Herausforderung für Finanzinstitute darstellen.”

Lassen Sie uns einen Einblick in das Verfahren für eine angemessene technische und organisatorische Implementierung der DORA-Anforderungen geben, um schwerwiegende IKT-Vorfälle fristgerecht und möglichst effizient identifizieren, klassifizieren und melden zu können. Dabei werden verschiedene Optimierungspotenziale bzw. Reifegrade der Umsetzung beschrieben.

Neue Anforderungen an das Incident Management

Klassifizierung von IKT-Vorfällen als „schwerwiegend” oder „nicht schwerwiegend“. Lediglich als schwerwiegend klassifizierte IKT-Vorfälle müssen an die Aufsicht gemeldet werden. Die Bewertung findet über ein zweistufiges Verfahren statt: Zuerst muss geprüft werden, ob eine kritische oder wichtige Funktion gemäß DORA betroffen ist.

Ein konkretes Vorgehen zur Identifikation von kritischen oder wichtigen Funktionen muss jedes Finanzinstitut selbst festlegen. Erfahrungsgemäß werden häufig die Ergebnisse der Business Impact Analyse (BIA) in die Ermittlung einbezogen. Ist eine kritische oder wichtige Funktion betroffen, muss in der nächsten Stufe geprüft werden, ob es sich um einen „unautorisierten böswilligen Zugriff auf das Netzwerk oder Informationssysteme handelt“. Ist dies der Fall, wird der IKT-Vorfall direkt als schwerwiegend eingestuft.

Ist dies nicht der Fall, müssen die zusätzlichen Klassifizierungskriterien bewertet werden. Dabei müssen zwei der folgenden sieben Klassifizierungskriterien die vorgegebenen Schwellenwerte überschreiten, damit der Vorfall als schwerwiegend eingestuft wird:

• Kritikalität der betroffenen Dienste
• Wirtschaftliche Auswirkung
• Verluste von Daten
• Geografische Ausbreitung
• Dauer und Ausfallzeit
• Reputationsschäden
• Kunden, finanzielle Gegenparteien und Transaktionen

Die dazugehörigen Schwellenwerte können aus dem Regulatory Technical Standard (RTS) zur Festlegung der Kriterien für die Klassifizierung von IKT-bezogenen Vorfällen entnommen werden.

Um den neuen Anforderungen gerecht zu werden, bauen viele Finanzinstitute auf bereits bestehenden Prozessen zum Incident- und Informationssicherheitsvorfallmanagement auf, die nach den aktuellen regulatorischen Vorgaben etabliert wurden.”

Durch den DORA kommen jedoch weitere Anforderungen hinzu, die berücksichtigt werden müssen:

• Die Meldung von IKT-Vorfällen muss durch eine interne Funktion oder einen Dienstleister übernommen werden. Dazu muss eine Schnittstelle zwischen Incident- und Informationssicherheitsvorfallmanagement zur Kommunikationsfunktion eingerichtet werden.
• Die Implementierung des Klassifizierungsprozesses in den bestehenden Incident Management Workflow. Eine wesentliche Herausforderung besteht hierbei in der Sammlung der für den Klassifizierungsprozess benötigten Informationen, was in der Regel durch ein Zusammenspiel diverser Rollen (bspw. Informationssicherheitsbeauftragte, Prozess-Owner, Unternehmensarchitekturmanagement etc.) erfolgt.
• Falls eine zentrale Funktion für alle Unternehmen einer Konzerngruppe meldet, müssen Schnittstellen zwischen den Einzelunternehmen beachtet werden. Zudem können bestimmte Vorfälle nur für einzelne Gesellschaften schwerwiegend sein. In der technischen Erhebung sollten demnach die Werte der Einzelunternehmen dargestellt werden.

Technische Implementierung der Klassifizierungskriterien

Die Betroffenheit kritischer oder wichtiger Funktionen steht in engem Zusammenhang mit der Business Impact Analyse (BIA), in der die Auswirkungen eines möglichen Prozessausfalls bewertet werden. Ein potenzieller Ansatz für die technische Implementierung ist demnach die Aufnahme der Prozesse im Informationsverbund (Register aller IKT-Assets), anschließend können diese als „kritische oder wichtige Funktion” geflaggt werden. Über die Verknüpfung der IKT-Assets im Informationsverbund kann direkt identifiziert werden, ob ein Incident (ggf. auch mittelbar) eine kritische oder wichtige Funktion beeinträchtigt. Die Verknüpfungen der IKT-Assets sind bestenfalls im Incident Management Tool hinterlegt, sodass bereits bei der Erfassung automatisch identifiziert wird, ob eine kritische oder wichtige Funktion betroffen ist.

Für die Erfassung des Kriteriums „Geografische Ausbreitung” muss angegeben werden, ob ein Ausfall der betroffenen Prozesse zwei oder mehr Länder aus der Europäischen Union (EU) betreffen. Dabei ist es nicht relevant, ob Prozesse mit Kunden in mehreren Ländern der EU oder interne Prozesse von mehreren Niederlassungen des Finanzinstituts in der EU betroffen sind. Länder außerhalb der EU werden bei der Bewertung dieses Kriteriums nicht beachtet. Im ersten Schritt sollten hierfür alle Prozesse ausgeschlossen werden, die keinen Einfluss in mindestens zwei Ländern der EU haben. Diese Einstufung sollte regelmäßig (z.B. jährlich bei der Überprüfung der Prozesse) oder bei der Expansion in andere Mitgliedsstaaten geprüft werden. Nachdem die betroffenen Mitgliedsstaaten je Prozess identifiziert wurden, sollten diese entsprechend dokumentiert und technisch hinterlegt werden, sodass bei der Bewertung der Klassifizierungskriterien direkt darauf zugegriffen werden kann.

Im nächsten Schritt der Kategorie „Kunden, finanzielle Gegenparteien und Transaktionen” prüfen Unternehmen, welche Prozesse Kunden, finanzielle Gegenparteien oder Transaktionen bedienen. Das Ergebnis der Analyse (Kriterium kann erfüllt sein oder kann nicht erfüllt sein) kann als Merkmal im Informationsverbund hinterlegt werden.

Ein Schritt Richtung Automatisierung wäre eine technische Erfassung von Transaktionen, Kunden und finanziellen Gegenparteien z.B. über die Auslastungen im Kapazitätsmanagement des IT-Betriebs. Dabei werden die durchschnittlichen Werte aus dem Kapazitätsmanagement im Informationsverbund dargestellt.”

Damit die Aktualität der Daten für eine Schätzung ausreicht, ist eine wöchentliche Aktualisierung sinnvoll. Bei einer monatlichen Aktualisierung sollte eine Verifizierung der Daten durchgeführt werden. Aufbauend darauf können Vergangenheitswerte zusätzlich zu der durchschnittlichen Betrachtung ergänzt werden, um die Integrität der Daten zu erhöhen.

In der Kategorie „Wirtschaftliche Auswirkungen” treffen Unternehmen eine Indikation über den finanziellen Schaden, den der Ausfall des kritischen Prozesses nach sich ziehen würde. Diese Einschätzung kann nach Eintreten eines schwerwiegenden IKT-Vorfalls durch die Auswertung des tatsächlichen Schadens ergänzt werden. Als weiteres Optimierungspotenzial können die wirtschaftlichen Auswirkungen pro Tag auf Basis der (IT-) Notfallpläne berechnet werden. So kann, in Kombination mit dem Kriterium „Dauer und Ausfallzeit”, eine Schätzung der gesamten wirtschaftlichen Auswirkungen erstellt und toolseitig hinterlegt werden.

Bei den qualitativen Kriterien stellt sich eine technische Erfassung deutlich komplexer dar, da mehrere Kennzahlen als Basis für eine Entscheidung dienen. Das Thema Berichterstattung im Rahmen des Kriteriums „Reputationsschaden” kann beispielsweise mithilfe von (inzwischen oftmals KI-gestützten) Softwarelösungen umgesetzt werden. Diese durchsuchen das Internet nach negativer Berichterstattung über das eigene Unternehmen und liefern entsprechende Hinweise an die zuständige Abteilung. Letztere validiert das Ergebnis und trifft die finale Einschätzung, inwieweit ein Reputationsschaden vorliegt.

Das Kriterium „Verlust von Daten” erfordert oft eine einzelfallbezogene Bewertung dessen, ob Integrität, Vertraulichkeit oder Verfügbarkeit von Daten durch den IKT-Vorfall beeinträchtigt sind – was eine technische Lösung erschwert. Ein möglicher Ansatz ist, die Beschreibung des Vorfalls auf bestimmte Schlüsselwörter hin zu scannen (z.B. Phishing oder Löschen von Daten). Eine Validierung durch das Informationssicherheitsmanagement wird jedoch weiterhin notwendig sein.

Die Bewertung des Kriteriums „Dauer und Ausfallzeit” sollte sich am Notfallplan orientieren, der unter anderem die Wiederherstellungszeit (Recovery Time Objective, RTO) des Prozesses beschreibt. Entsprechend sollte diese auch initial für die Bewertung des Kriteriums herangezogen und vom zuständigen Incident-Manager verifiziert werden.

Zur Erleichterung und Automatisierung der Kommunikation empfiehlt sich auch toolseitig eine Markierung schwerwiegender IKT-Vorfälle, sodass die Kommunikationsfunktion automatisch benachrichtigt wird.”

Mögliche Optimierungspotenziale liegen darin, dynamische Klassifizierungskriterien mit vordefinierten Schwellenwerten zu definieren, bei deren Überschreitung die Kommunikationsfunktion informiert wird. Auch könnte ein System integriert werden, welches die Markierung wiederkehrender Ereignisse mit kritischen Dienstunterbrechungen sowie deren monatlichen Vergleich ermöglicht, um kumulative Auswirkungen wie die Kundenzahl, wirtschaftliche Verluste und die geografische Verteilung zu prüfen. Wenn mindestens zwei Kriterien erfüllt sind, wird eine Validierung durch den Incident Manager und eine Meldung an die Kommunikationsabteilung eingeleitet. Darüber hinaus sollte die Kommunikationsabteilung Zugang zu allen wesentlichen Informationen über den Vorfall erhalten, um eine umfassende Bewertung gewährleisten zu können.

Implementierung der Meldungsfunktion

Der Regulatory Technical Standard (RTS) zur Meldung von schwerwiegenden IKT-Vorfällen enthält ein Template, das bereits Aufschluss über die notwendigen Mindestfelder sowie, in einigen Fällen, zu potenziellen Antwortmöglichkeiten gibt. Die Umsetzung kann dann mithilfe von Excel-Listen erfolgen, welche das dreistufige Meldeverfahren (Erst-, Zwischen- und Abschlussmeldung) abbildet und vordefinierte Antwortmöglichkeiten implementiert. Für einen höheren Automatisierungsgrad kann eine dedizierte Software eingesetzt werden, die mit dem Incident Management System verbunden ist. Über die technische Schnittstelle werden Informationen automatisch vom Ticketsystem in die Meldung übernommen. Darüber hinaus sind alle Meldungen hier leicht zugänglich und transparent einsehbar.

Die Meldung findet über das MVP-Portal der BaFin statt. Ab dem 17. Januar 2025 wird hier ein Formular zur Verfügung stehen, welches für die Meldung ausgefüllt werden muss. Zu einem späteren Zeitpunkt soll es zusätzlich möglich sein, über eine SOAP-Web-Schnittstelle die Meldung oder einen Dateiupload einzureichen. Das Dateiformat für einen Dateiupload wurde noch nicht festgelegt.

Fazit

Für Finanzinstitute bedeutet die Einführung der DORA-Verordnung eine erhöhte Komplexität im Umgang mit IKT-Vorfällen. Der Klassifizierungsprozess von solchen Vorfällen sowie strikte Meldepflichten erfordern eine enge Zusammenarbeit zwischen allen beteiligten Funktionen. Die Implementierung einer technischen Lösung hilft dabei, Prozesse zur Kommunikation effizienter zu gestalten und das Risiko einer verzögerten Meldung zu verringern. Sie stellt ein effizientes Vorgehen sicher und erhöht die Integrität, da Inkonsistenzen verringert und fehlerhafte Eingaben mithilfe von automatisierten Integritätsprüfungen vermieden werden können.Jens Bläser, Armin Reinhardt und Oliver Abele, Deloitte