DORA Säule 5: Informationsaustausch und Threat Intelligence

Problem in der Praxis

In vielen Finanzunternehmen wird Threat Intelligence mit dem Abonnieren von Feeds verwechselt. Es gibt Indikatorenlisten, Newsletter und Plattformzugänge, aber keinen Prozess, der daraus Entscheidungen ableitet. Die Information landet im Postfach eines Analysten und versickert dort.

Gleichzeitig herrscht Unsicherheit, was unter DORA erlaubt ist: Darf ich Indikatoren mit Wettbewerbern teilen? Was passiert mit personenbezogenen Daten? Aus dieser Unsicherheit entsteht oft Stillstand. Man bleibt passiver Konsument, weil der aktive Beitrag als zu riskant gilt.

Hinzu kommt eine Verwechslung zweier DORA-Mechanismen. Die freiwillige Meldung erheblicher Cyberbedrohungen an die zuständige Behörde gehört zur Vorfallbehandlung (Kapitel III). Der freiwillige Austausch von Bedrohungsinformationen zwischen Finanzunternehmen ist Säule 5 (Art. 45). Beides ist freiwillig, adressiert aber verschiedene Empfänger und Zwecke. Wer das vermischt, baut die falschen Prozesse.

CISO-Einordnung

Der CISO sollte Säule 5 nicht als isoliertes Compliance-Thema lesen, sondern als Verstärker der anderen Säulen. Threat Intelligence ist nur dann wertvoll, wenn sie in den IKT-Risikomanagementrahmen (Säule 1), in die Vorfallbehandlung (Säule 2) und in das Testprogramm (Säule 3) zurückfließt.

DORA setzt für Säule 5 einen Rahmen, der Vertrauen, Vertraulichkeit und Rechtskonformität voraussetzt. Der Austausch findet innerhalb vertrauenswürdiger Gemeinschaften von Finanzunternehmen statt, soll die Vertraulichkeit der geteilten Information wahren und muss datenschutzrechtliche Vorgaben (insbesondere die DSGVO) beachten. Die verbindlichen Bedingungen ergeben sich aus Art. 45 der Verordnung (EU) 2022/2554; für Detailausgestaltung und nationale Durchführung ist der Originaltext heranzuziehen.

Hilfreich ist der Bezug zu international etablierten Wirkungslogiken. Das NIST Cybersecurity Framework ordnet die Verwertung von Bedrohungsinformationen vor allem der Funktion Detect zu: Threat Intelligence reichert die Analyse von Ereignissen und Anomalien an und verbessert die Erkennung. Die Funktion Govern liefert die Klammer darüber: Rollen, Richtlinien und Aufsicht, die festlegen, wer was teilen darf und wie Erkenntnisse in Steuerung übersetzt werden. Diese Zuordnung ist nicht normativ für DORA, hilft aber, Säule 5 operativ einzuhängen.

Umsetzungsperspektive

Aus CISO-Sicht beginnt die Umsetzung nicht mit der Auswahl einer Plattform, sondern mit dem Verarbeitungszweck. Sinnvoll ist ein schlanker Kern:

• Use Cases zuerst: Welche Entscheidungen soll Threat Intelligence verbessern (Patch-Priorisierung, Blocklisten, Detektionsregeln, Lageeinschätzung)?
• Aufnahme und Bewertung: ein definierter Weg, wie eingehende Informationen bewertet, angereichert und mit eigener Telemetrie abgeglichen werden.
• Verarbeitung in Detect/Respond: Überführung relevanter Erkenntnisse in Erkennungsregeln und Reaktionsprozesse.
• Beitrag nach außen: klare Regeln, was, in welcher Granularität und an welche Gemeinschaft aktiv geteilt wird.
• Governance: Verantwortlichkeit des Leitungsorgans, dokumentierte Freigabewege, Datenschutz- und Vertraulichkeitsklauseln.

Bewährt hat sich, klein anzufangen: Teilnahme an einer etablierten, vertrauenswürdigen Gemeinschaft, zunächst als Konsument, dann schrittweise als Beitragender. Ein verbreiteter Ordnungsrahmen für die Sensibilität geteilter Information ist das Traffic Light Protocol (TLP).

Typische Fehler

1. Threat Intelligence wird als Feed-Abo behandelt, nicht als Entscheidungsprozess.
2. Säule 5 (Austausch zwischen Finanzunternehmen) und die freiwillige Bedrohungsmeldung an die Behörde (Säule 2) werden verwechselt.
3. Es wird konsumiert, aber nie beigetragen, sodass die Gemeinschaft auf Dauer an Wert verliert.
4. Datenschutz- und Vertraulichkeitsfragen werden erst nach dem ersten Austausch geklärt.
5. Eingehende Erkenntnisse werden nicht in Erkennung, Tests und Risikobewertung zurückgespielt.

Risiken und Trade-offs

Der Austausch erzeugt Spannungen, die der CISO bewusst steuern muss. Wer aktiv teilt, kann ungewollt sensible Informationen über eigene Vorfälle, Schwachstellen oder Kunden offenlegen. Wer zu restriktiv agiert, trägt nichts bei und schwächt die gemeinsame Frühwarnung.

Ein zweites Spannungsfeld ist die Datenqualität. Ungefilterte Indikatoren erzeugen Fehlalarme und binden Analystenkapazität. Zu starke Filterung kann relevante Frühwarnungen aussortieren.

Drittens besteht ein Vertrauens- und Reputationsrisiko: Austauschgemeinschaften funktionieren nur, solange Vertraulichkeit gewahrt bleibt. Ein einziger unkontrollierter Weitergabevorfall kann die Teilnahme dauerhaft beschädigen. Schließlich ist Freiwilligkeit ein Trade-off an sich: Sie schafft Flexibilität, aber keine Verlässlichkeit, dass andere ebenfalls teilen.

Entscheidungspunkte

• Nimmt das Unternehmen am freiwilligen Austausch teil, und mit welchem konkreten Nutzenziel?
• Tritt es zunächst nur als Konsument auf oder auch als aktiver Beitragender?
• Welcher Austauschgemeinschaft schließt es sich an, und erfüllt diese die Vertrauens- und Vertraulichkeitsanforderungen?
• Wer im Leitungsorgan verantwortet die Freigabe geteilter Information?
• Wie werden Datenschutz und Vertraulichkeit vertraglich und prozessual abgesichert?
• Wie wird gemessen, ob der Austausch Erkennung und Reaktion messbar verbessert?

Praktische Empfehlungen

1. Definieren Sie zuerst die Use Cases: Welche Sicherheitsentscheidung soll Threat Intelligence verbessern?
2. Trennen Sie sauber zwischen Säule-5-Austausch (zwischen Finanzunternehmen) und freiwilliger Bedrohungsmeldung an die Behörde.
3. Klären Sie Datenschutz, Vertraulichkeit und Freigabewege, bevor Sie das erste Mal aktiv teilen.
4. Verankern Sie die Verarbeitung eingehender Erkenntnisse fest in Erkennung (Detect), Reaktion und Risikobewertung.
5. Starten Sie als Konsument in einer vertrauenswürdigen Gemeinschaft und werden Sie schrittweise zum Beitragenden.
6. Messen Sie den Nutzen an konkreten Ergebnissen, nicht an der Zahl abonnierter Feeds.

Relevante Normreferenzen

• DORA, Verordnung (EU) 2022/2554, Kapitel VI, Art. 45: freiwilliger Austausch von Cyber-Bedrohungsinformationen und -erkenntnissen zwischen Finanzunternehmen. Veröffentlicht im ABl. L 333 vom 27.12.2022; anwendbar seit 17.01.2025.
• DORA, Kapitel III (Behandlung und Meldung IKT-bezogener Vorfälle): enthält die davon zu unterscheidende freiwillige Meldung erheblicher Cyberbedrohungen an die zuständige Behörde.
• NIST Cybersecurity Framework: Funktionen Detect (Anreicherung der Ereignisanalyse durch Bedrohungsinformationen) und Govern (Steuerung, Rollen, Richtlinien) als nicht-normativer Wirkungsbezug.
• ISO/IEC 27001: ISMS als Umsetzungsrahmen für die operative Verarbeitung von Bedrohungsinformationen (allgemeine Referenz, kein DORA-Ersatz).