DORA-Kernthemen meistern: Ein Deep Dive in Incident Management
DORA
In der ersten Linie ist DORA ein umfassender IKT-Risikomanagement-Rahmen. Ziel ist es, dass alle Finanzunternehmen sicherstellen müssen, dass sie allen Arten von IKT-bezogenen Störungen und Bedrohungen standhalten, auf sie reagieren und sich von ihnen erholen können.
DORA ist so aufgebaut, dass alle Themen-Schwerpunkte, alle Säulen, gegenseitig in anderen Säulen angesprochen werden. Alles ist miteinander verflochten. Es gibt Querverweise quer durch das Gesetz und dazugehörenden technischen Regulierungsstandards, technischen Durchführungsstandards und Guidelines.
Auch das Thema Incident Management findet sich in allen 5 Säulen wieder.
Kernelemente in DORA mit Fokus auf Anforderungen für Incident Management
Mit IKT-Risikomanagement werden die Grundlagen für die technischen Anforderungen wie Identifizierung, Schutz und Prävention, Erkennung, Reaktion und Wiederherstellung, Backup Policies definiert. Ebenso die Grundlagen für IKT- Geschäftsfortführungsleitlinien und IKT-Reaktions- und Wiederherstellungsplänen. Aber auch Lernprozesse und Kommunikationsstrategie wird dort behandelt.
DORA verpflichtet die Unternehmen die Prozesse regelmäßig auf Wirksamkeit zu testen. Die Finanzunternehmen werden geprüft, ob die Prozesse erprobt sind. Man soll nicht nur passiv abwarten bis etwas passiert, sondern auch aktiv agieren.
Im Bereich Behandlung und Meldung von IKT-Vorfällen, soll ein Prozess für die Behandlung IKT-bezogener Vorfälle dokumentiert, etabliert und regelmäßig getestet werden. In diesem Kapitel finden wir auch Vorgaben für Incident Management und Meldewesen. Und wichtiger Bestandteil dieser Säule sind die technischen Regulierungsstandards und die technischen Durchführungsstandards. Diese Dokumente definieren die Vorgaben für Klassifizierung des Vorfalls und Berichtswesen.
Die dritte Säule – das Testen der digitalen operationalen Resilienz – schreibt vor, dass alle Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, regelmäßig getestet werden müssen. Des Weiteren müssen ausgewählte Finanzunternehmen die weiterführende bedrohungsorientierte Penetrationtests – die TLPT – durchführen. Ziel ist es, die Schwachstellen, Defizite und Lücken in der digitalen operationellen Widerstandsfähigkeit zu ermitteln, die Bereitschaft zur Bewältigung von IKT-bezogenen Vorfällen zu bewerten und umgehend Korrekturmaßnahmen zu ergreifen.
Der Bereich IKT-Drittparteienrisiko beschäftigt sich mit den Themen wie Vertragsbeziehungen mit IKT-Drittanbieter, und die EU-Überwachungsrahmen für kritische IKT-Drittdienstleister. Hier finden wir aber auch Vorgaben für Incident Management. Und zwar ist vorgeschrieben, wenn Drittparteien betroffen sind, müssen sie mit Finanzunternehmen bei der Vorfall-Behandlung kooperieren.
Und die fünfte Säule, in der es um den Informationsaustausch zwischen die Finanzunternehmen geht, wird die Möglichkeit erarbeitet für Sektorübergreifende Krisenmanagement- und Notfallübungen mit Cyberbezug, zur Verbesserung der Kommunikation und Stärkung der Resilienz im Finanzsektor.
Prozess der Bearbeitung von IKT-bezogenen Vorfällen
Wie sieht der Prozess der Erkennung, Behandlung und Meldung von IKT-Vorfällen gemäß DORA aus? Was geschieht, nachdem ein Vorfall eingetreten ist?
Zuerst muss der Vorfall überhaupt erkannt werden. Laut Statistik ist der Angreifer oft viele Monate vor der Erkennung des Angriffs in das System eingedrungen.
Das Ziel von DORA ist es bestimmte Maßnahmen einzurichten, um den Angriff möglichst schnell zu erkennen. Je früher man merkt, dass man angegriffen worden ist, dass jemand in mein System eingedrungen ist, desto größer ist die Chance den Schaden zu minimieren und die eigenen Daten zu retten.
Der nächste Schritt ist die Reaktion und Behandlung von dem Vorfall. Nachdem der Vorfall abgeschlossen ist, sieht DORA bestimmte Lernaufgaben, Lernprozesse vor.
Lösen muss man alle Vorfälle. Sollte der Vorfall im Laufe des Prozesses als schwerwiegend klassifiziert werden, muss man parallel sich auch um die Meldung kümmern. Freiwillig kann man auch bedeutenden Cyberbedrohungen melden.
Erkennung
Im Grunde sind die Erkennungsmechanismen eine Grundlage für angemessene Reaktionsmaßnahmen.
Gemäß Artikel 10 sieht DORA vor, dass die Finanzunternehmen bestimmte Mechanismen einsetzen müssen, um anomale Aktivitäten umgehend zu erkennen und potenzielle einzelne wesentliche Schwachstellen zu ermitteln.
Die Erkennungsmechanismen müssen mehrere Kontrollebenen ermöglichen und Alarmschwellen und Alarmkriterien festlegen, um Reaktionsprozesse bei IKT-bezogenen Vorfällen auszulösen und einzuleiten.
Ein Finanzunternehmen soll ausreichende Ressourcen und Kapazitäten für Überwachung von Nutzeraktivitäten, IKT-Anomalien, IKT-bezogenen Vorfälle, inklusive Cyberangriffe, bereitstellen.
Und natürlich – wie auch mit anderen Prozessen – soll man diese regelmäßig auf Wirksamkeit testen und die Durchläufe erproben.
Reaktion und Behandlung
Im Bereich Reaktion und Behandlung erfordert DORA, gem. Artikel 11, die Etablierung einer umfassenden IKT-Geschäftsfortführungsleitlinie. Inhaltlich beinhaltet es Themen wie:
- die angemessene Reaktion auf alle IKT-bezogenen Vorfälle zur Schadenbegrenzung, verbunden mit der Wiederaufnahme von Tätigkeiten und dem Vorrang von Wiederherstellungsmaßnahmen;
- die Aktivierung von Plänen mit Eindämmungsmaßnahmen, Prozessen und Technologien bei IKT-bezogenen Vorfällen sowie
- die zwingende Einschätzung der vorläufigen Auswirkungen, Schäden und Verlusten; und
- die Festlegung von Kommunikations- und Krisenmanagementmaßnahmen.
DORA sieht ebenfalls die Etablierung einer Krisenmanagementfunktion vor. Diese soll bei der Aktivierung von IKT-Geschäfts-fortführungs-plänen oder IKT-Reaktions- und Wiederherstellungsplänen unter anderem klare Verfahren für die Abwicklung interner und externer Krisenkommunikation (Art. 14 DORA) festlegen.
Artikel 17 konkretisiert die Reaktions- und Vorfallbehandlungsthematiken und fordert die Etablierung eines Prozesses für die Behandlung IKT-bezogenen Vorfälle. Im Konkret heißt es, dass
- die Frühwarnindikatoren sollen einsetzt werden,
- Funktionen und Zuständigkeiten müssen zugewiesen werden,
- Info muss an höhere Führungsebene und Geschäftsleitung gegeben werden,
- Kommunikationsstrategie muss etabliert sein, und
- der Verfahren für Reaktionsmaßnahmen soll dokumentiert sein.
Und auch hier – alle Prozesse und Pläne müssen regelmäßig getestet und erprobt werden.
Lernprozesse
Ist ein Vorfall behoben, folgt ein Lernprozess (gem. Art 13 DORA). Bei den Vorfällen, mit denen kritischen oder wichtigen Funktionen betroffen sind, muss man
- nachträgliche Prüfungen und Ursachenuntersuchung des IKT-bezogenen Vorfalls durchführen.
- Änderungen sind in Prozessen einzuführen und den Behörden ggf, auf Aufforderung, mitzuteilen.
In den nachträglichen Untersuchungen befasst man sich mit den Themen wie:
- Die Schnelligkeit bei der Reaktion
- Die Qualität der forensischen Analysen
- Die Wirksamkeit der internen Eskalation
- Die Wirksamkeit interner und externer Kommunikation
Wie erwähnt, die Reaktionszeiten und die Qualität der forensischen Analysen werden nach der Klärung des Vorfalls separat untersucht. Die Qualität der Reaktion wird besser sein, wenn man sich gut vorbereitet hat. Die Annahme in DORA ist nicht, OB ein Incident passiert, sondern WANN es passiert.
Klassifizierung und Meldung des Vorfalls
Wie bereits erwähnt, alle Vorfälle müssen klassifiziert werden.
Bei den Vorfällen, die man als schwerwiegend einstuft, müssen zusätzlich Erst-, Zwischen- und Abschlussberichte den zuständigen Behörden nach festgelegten Zeiten vorgelegt werden.
Und natürlich müssen eigene Kunden informiert werden.
Klassifizierung des Vorfalls
Die Klassifizierung des Vorfalls basiert auf DORA Artikel 18 und auf einer technischen Regulierungsstandard: RTS zur Klassifizierung von schwerwiegenden IKT-bezogenen Vorfällen und erheblichen Cyberbedrohungen (EU 2024/1772).
Die Klassifizierung läuft folgend ab (alle Artikel weisen auf die oben genannte RTS):
1. Nach der Entdeckung des Vorfalls untersucht man als erstes die Kritikalität der Betroffenen Dienste (Art 6).
Mit Kriterium a) bewertet man, ob die IKT-Dienste oder Netzwerk- und Informationssysteme, die kritische oder wichtige Funktionen unterstützen, beeinträchtigt sind (Art 6(a)).
Mit Kriterium b), ob die Finanzdienstleistungen, die eine Zulassung oder Registrierung bedürfen, oder von den zuständigen Behörden beaufsichtigt werden, beeinträchtigt sind (Art 6(b)).
Und mit Kriterium c) bewertet man, ob es um einen erfolgreichen, böswilligen und unbefugten Zugriff auf die Netzwerk- und Informationssysteme geht (Art 6(c)), und die zu dem Verlust von Daten führen kann.
2. Ist keins von den Kriterien erfüllt, ist der Vorfall nicht als schwerwiegend zu klassifizieren.
3. Ist die Wesentlichkeitsschwelle des Kriteriums c) erfüllt (Art 9(5)(b), Art 8(1)(a)), ist der Vorfall als schwerwiegend einzustufen.
4. Sind das Kriterium a) und/oder das Kriterium b) betroffen, so sind weitere Kriterien, bezogen auf die jeweilige Wesentlichkeitsschwelle, zu prüfen (Art 8(1)(b) und Art 9).
- Kunden, finanzielle Gegenparteien und Transaktionen (Art 1, Art 9(1))
- Reputationsschaden (Art 2, Art 9(2))
- Dauer und Ausfallzeiten (Art 3, Art 9(3))
- Geografische Ausbreitung (Art 4, Art 9(4))
- Verlust von Daten (Art 5, Art 9(5))
- Wirtschaftliche Auswirkungen (Art 7, Art 9(6) (Für die Kalkulation von Kosten und Verluste gibt es eine separate Leitlinie: Joint Guidelines on the estimation of aggregated costs and losses caused by major ICT-related incidents (ESAs final report JC 2024 34).
Sind 2 oder mehr weiteren Kriterien erfüllt, gilt der Vorfall als schwerwiegend.
Meldepflichten des schwerwiegenden Vorfalls
Die als schwerwiegend klassifizierten Vorfälle muss man an die zuständigen Behörden melden.
Die Meldepflichten sind sehr kurz gehalten. Die Erstmeldung muss so schnell wie möglich erfolgen, spätestens jedoch 4 Stunden, nachdem der Vorfall als schwerwiegend eingestuft wurde, und spätestens 24 Stunden, nachdem das Finanzinstitut von dem Vorfall Kenntnis erhalten hat. Wird ein Vorfall zu einem späteren Zeitpunkt als schwerwiegend eingestuft, muss das Finanzinstitut die Erstmeldung innerhalb von 4 Stunden nach der Einstufung übermitteln.
Ein Zwischenbericht muss spätestens innerhalb von 72 Stunden nach Übermittlung der ersten Meldung vorgelegt werden.
Und der Abschlussbericht spätestens einen Monat nach Vorlage des letzten aktualisierten Zwischenberichts. Sollte der Vorfall bis dahin nicht behoben sein, kann der Abschlussbericht natürlich auch zu einem späteren Zeitpunkt vorgelegt werden.
DORA Artikeln 19 und 20 legt die Grundregeln für Meldefristen und Inhalte für Meldungen fest. Für die detaillierten Vorgaben gibt es eine separate Standard: RTS and ITS on incident reporting (ESAs final report JS 2024 33).
Im Falle eines IKT-Vorfalls ist es wichtig, schnell und angemessen zu reagieren. Aus diesem Grund legt DORA großen Wert auf die vorbereitenden Maßnahmen. Man muss sein IKT-Netz kennen und Maßnahmen ergreifen, um einen Vorfall schnell zu erkennen und darauf zu reagieren.
Wie kann SEC Consult unterstützen?
Im Falle eines Cyber-Sicherheitsvorfalles bleibt keine Zeit, um geeignete Richtlinien und Verfahren zu implementieren. Im Rahmen des SEC Defence Service bieten wir Vorbereitungs- und Strategieworkshops sowie Krisenplanspiele zur Simulation von Cyberangriffen an. Diese Trainings umfassen die strategische, taktische und operative Ebene. Ein wichtiger Teil der Vorbereitung ist auch die Bewertung Ihrer Organisation mit einem Maturity Assessment. Der Schwerpunkt liegt dabei auf der Bewertung der Verteidigungsfähigkeit Ihrer Organisation.
Im Ernstfall steht Ihnen unser Team innerhalb kürzester Zeit zur Verfügung. Sicherheitsexperten aus den Bereichen Incident Response, Forensik sowie technische und organisatorische Informationssicherheit leiten umgehend die notwendigen Sofortmaßnahmen ein. Schadensbegrenzung, die Verhinderung eines erneuten Angriffs und die schnelle Wiederaufnahme des Normalbetriebs stehen dabei im Vordergrund.
NB: Alle referierten Final Reports der ESAs wurden am 17. Juli 2024 veröffentlicht. Im nächsten Schritt werden sie von der Europäischen Kommission angenommen und vom Europäischen Parlament und dem Rat geprüft. Und schließlich werden sie im Amtsblatt der EU veröffentlicht.
