DORA Incident Reporting: 4-Stunden-Meldung mit Logs

Wenn ein OpenSearch-Monitor um 02:13 UTC erhöhte 5xx-Fehler einer Zahlungs-API meldet, beginnt noch nicht automatisch eine DORA-Meldefrist. Relevant sind zwei Zeitpunkte: die erste interne Kenntnis und die formale Einstufung des Vorfalls als major ICT-related incident.

DORA gilt seit dem 17. Januar 2025 für Finanzunternehmen in der EU. Die Verordnung regelt ICT risk management, ICT third-party risk, digital operational resilience testing, ICT-related incident reporting, information sharing und die Aufsicht über kritische ICT-Drittanbieter. Die initial notification muss so früh wie möglich erfolgen, spätestens vier Stunden nach der Klassifizierung als major ICT-related incident und spätestens 24 Stunden nach Kenntnis des Vorfalls. Wenn Logs, Dashboard-Links, Provider-Kontakte und Rollen erst während der Analyse zusammengesucht werden, verlierst Du einen großen Teil dieses Zeitfensters. Wenn Rollen, DORA-Grundbegriffe und Evidenzpflichten im Team noch nicht einheitlich sind, kann eine DORA-Schulung zu IT-Security und Resilienz eine gemeinsame Arbeitsgrundlage schaffen.

Warum DORA Incident Reporting eine IT-Betriebsaufgabe ist

DORA incident reporting ist kein PDF-Prozess am Ende eines Security-Incidents. Die Meldung entsteht aus operativen Daten: Alert-Zeitpunkt, betroffene Services, Nutzerauswirkung, technische Indikatoren, Eskalationsentscheidungen, Provider-Informationen und Containment-Schritte. Die Delegierte Verordnung (EU) 2025/301 definiert Inhalte und Fristen für initial notification, intermediate report und final report. Die Durchführungsverordnung (EU) 2025/302 liefert Standardformulare, Templates und Verfahren für Meldungen zu major ICT-related incidents sowie freiwillige Meldungen zu significant cyber threats.

Die 4-Stunden-Frist nach Klassifizierung erzeugt eine konkrete Betriebsanforderung: SOC, Administratoren, Incident Manager und Compliance-Verantwortliche müssen dieselbe Vorfallkette sehen. Diese Kette besteht aus Roh-Logs, OpenSearch-Alerts, Ticket-Einträgen, Timeline-Ereignissen, Provider-Daten aus dem Informationsregister und einem DORA incident runbook. Für Teams, die Monitoring-Architekturen und Log-Pipelines betreiben, sind Monitoring- und Logging-Schulungen ein passender Einstieg in Log-Normalisierung, Alert-Routing und Dashboard-Betrieb.

Die DORA-Timeline: Was Du sofort erfassen musst

Trenne in Deiner Timeline strikt zwischen technischer Erkennung, interner Kenntnis und formaler Klassifizierung. Diese Trennung ist entscheidend, weil die DORA 4-hour initial notification an die Klassifizierung als major ICT-related incident anknüpft und zusätzlich die 24-Stunden-Grenze nach Kenntnis des Vorfalls gilt.

• First detection: Zeitpunkt des ersten Alerts, Log-Treffers, Kundenhinweises oder Provider-Tickets.
• First internal awareness: Zeitpunkt, an dem SOC, Service Desk, Bereitschaft oder Provider-Management den Vorfall intern wahrnimmt.
• Major classification: Zeitpunkt, zu dem die autorisierte Rolle den Vorfall nach Deinen DORA-Kriterien als major ICT-related incident einstuft.
• Escalation: Zeitpunkt der Einbindung von Incident Manager, CISO, IT-Betrieb, Compliance, Legal, Datenschutz und Management.
• Mitigation: konkrete technische Schritte wie Firewall-Block, Account-Deaktivierung, Rollback, Rate-Limit, Snapshot, Traffic-Umleitung oder Provider-Eskalation.
• Notification decision: Entscheidung über die initial notification, verantwortliche Person, verwendetes Template und Versandkanal.

Lege in Deiner Incident-Richtlinie fest, wer klassifizieren darf und wer den Start der Meldefrist protokolliert. Ein praktikables Modell benennt einen Incident Manager als operative Rolle, eine CISO-Vertretung als Security-Entscheider und einen DORA Reporting Owner für die Meldelogik. Die Stellvertretungen müssen im Bereitschaftsplan stehen; sonst blockiert ein Urlaub oder Feiertag die Klassifizierung.

Was ein DORA-fähiger Incident Record enthalten sollte

Ein DORA-fähiger Incident Record ist ein strukturierter Datensatz, kein Freitext-Ticket mit Screenshots. Speichere die relevanten Felder in Deinem ITSM-System, SOAR-Tool oder Incident-Repository und verlinke unveränderbare oder versionierte Evidenzorte. Kopierte Dashboard-Screenshots altern schnell, weil Filter, Zeitbereich und Index-Version fehlen.

Verknüpfe den Incident Record mit Deinem DORA-Informationsregister. Seit dem 17. Januar 2025 müssen Finanzunternehmen ein Register für vertragliche Vereinbarungen mit ICT third-party service providers auf Einzel-, teilkonsolidierter und konsolidierter Basis führen, soweit diese Ebenen einschlägig sind. Für einen Incident Record sind Provider-Name, Vertragsservice, Kritikalität, SLA, Standort, Subdienstleister, technische Schnittstelle und Exit-relevante Informationen relevant.

OpenSearch für Triage, Alerting und Evidenz nutzen

Im Kontext von DORA bedeutet OpenSearch-Logging eine nachvollziehbare Log- und Evidenzkette mit OpenSearch, OpenSearch Dashboards, Alerting und Security Analytics. OpenSearch Dashboards liefert eine gemeinsame Sicht für SOC, Administratoren, Incident Manager und Compliance-Stakeholder. Diese Sicht muss rollenbasiert geschützt sein, Transport Layer Security (TLS) für Cluster- und Client-Kommunikation nutzen, Index-Retention dokumentieren und Snapshots für Wiederherstellung und Beweissicherung verwenden.

OpenSearch Alerting unterstützt Dashboards, Monitore, Schwellenwerte, Trigger und Actions. Ein Monitor kann beispielsweise 5xx-Fehler pro Service über 15 Minuten aggregieren, einen Trigger bei Überschreitung eines Schwellenwerts auslösen und eine Action an E-Mail, Slack-kompatible Webhooks, Microsoft-Teams-Webhooks, generische Webhooks oder ein ITSM-System senden. OpenSearch Security Analytics arbeitet mit Log Types, Detectors, Rules, Findings und Alerts. Dieser Ablauf führt von Rohdaten wie CloudTrail, Windows Event Logs, Suricata-Alerts oder Nginx-Access-Logs zu verwertbaren Incident-Signalen. Eine OpenSearch-Schulung zu Dashboards, Betrieb und Migration vertieft Dashboards, Alerting, TLS, Rollen, Snapshots, Recovery und Security Analytics anhand betrieblicher Szenarien.

GET logs-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        { "range": { "@timestamp": { "gte": "now-30m" } } },
        { "term": { "event.dataset": "nginx.access" } },
        { "range": { "http.response.status_code": { "gte": 500 } } }
      ]
    }
  },
  "aggs": {
    "by_service": { "terms": { "field": "service.name.keyword" } }
  }
}

Baue Dashboards nicht nach Tool-Teams, sondern nach den fünf DORA-Fragen eines Incidents: Wann begann der Vorfall? Was ist betroffen? Wie groß ist die Auswirkung? Was wurde bereits getan? Welche Evidenz belegt die Aussagen? Ein Dashboard benötigt dafür Panels für Beginn und Dauer, betroffene Services, Anzahl fehlgeschlagener Transaktionen, Login-Anomalien, Netzwerkausfälle, Provider-Status, offene Containment-Aktionen und Evidenz-Links. Jede Visualisierung muss den Zeitbereich und die Datenquelle eindeutig anzeigen, damit der Incident Record später nicht aus Annahmen rekonstruiert wird.

Runbooks: vom ersten Alert zur DORA Initial Notification

Ein DORA incident runbook muss unter Zeitdruck nutzbar sein. Begrenze die Hauptcheckliste auf die Schritte, die vor der initial notification tatsächlich Informationen erzeugen. Detailanweisungen für einzelne Plattformen gehören in verlinkte Unter-Runbooks.

1. Alert im ITSM- oder SOAR-System bestätigen und Alert-ID in der Timeline speichern.
2. Signal validieren: Query erneut ausführen, Zeitbereich prüfen, betroffenen Service Owner kontaktieren.
3. Evidenz sichern: Dashboard-Link, Query-ID, Roh-Log-Export, Snapshot-ID oder Forensik-Pfad eintragen.
4. Betroffene Assets identifizieren: CMDB, Kubernetes-Inventar, Cloud-Tags, DNS, IAM und Netzwerkzonen abgleichen.
5. Business Impact bewerten: Zahlungsverkehr, Kundenportal, Reporting, Handelssystem, interne Abwicklung oder Provider-Anbindung prüfen.
6. Schweregrad klassifizieren und Major-ICT-Entscheidung durch die autorisierte Rolle protokollieren.
7. Compliance, Legal, Datenschutz und Management nach definierter Schwelle einbinden.
8. Initial notification mit den verfügbaren Fakten, offenen Punkten und Evidenzreferenzen vorbereiten.

Binde Legal ein, wenn Vertragsauslegung, Haftungsfragen oder Kommunikationsfreigaben betroffen sind. Binde Datenschutz ein, wenn personenbezogene Daten kompromittiert, unberechtigt offengelegt oder unzulässig verändert wurden. Binde ICT-Provider ein, wenn deren Service, Subdienstleister, Netzwerkpfad, Hosting-Umgebung oder Managed-Security-Leistung Teil der Störung ist. Für rechtliche Schnittstellen rund um Verträge und Meldeprozesse sind Vergaberecht und IT-Recht thematisch relevant.

Provider-Abhängigkeiten und das DORA-Informationsregister

Viele ICT-Incidents betreffen Cloud-Plattformen, SaaS-Anwendungen, Netzwerk-Carrier, Hosting-Anbieter, Managed-Security-Provider oder Outsourcing-Partner. Der Incident Manager braucht deshalb keine allgemeine Lieferantenliste, sondern eine direkt nutzbare Zuordnung zwischen Service, Provider, Vertrag und technischer Abhängigkeit.

Ergänze Deinen Incident Record um Felder für Provider-Kontakt, 24/7-Eskalation, Vertragsnummer, vereinbarte Services, kritische oder wichtige Funktion, SLA, Datenstandort, Subdienstleister, Exit-Informationen und interne Evidenzverantwortliche. Teste in einem Dry-Run, ob der Bereitschaftsdienst innerhalb weniger Minuten den zuständigen Provider-Kontakt, den Vertragseigner und die relevante Log-Quelle findet. Wenn diese drei Angaben fehlen, entsteht die initial notification aus unvollständigen Annahmen.

Dry-Runs, TLPT und Lessons Learned

Plane Tabletop-Übungen und technische Dry-Runs für das 4-Stunden-Szenario. Verwende historische Alerts, gespeicherte OpenSearch-Queries, simulierte Provider-Ausfälle und Test-Tickets. Die Übung ist bestanden, wenn Dein Team Detection, Awareness, Klassifizierung, Provider-Zuordnung, Evidenzreferenzen und Meldeentscheidung vollständig in der Timeline dokumentiert.

DORA verlangt von bestimmten, durch zuständige Behörden identifizierten Finanzunternehmen fortgeschrittene bedrohungsorientierte Penetrationstests (Threat-Led Penetration Testing, TLPT) mindestens alle drei Jahre. Saubere Incident-Logs, technische Timelines und nachvollziehbare Dashboards unterstützen die Vorbereitung solcher Tests, weil sie Erkennungswege, Eskalationsketten und Schwachstellen in der Beweissicherung sichtbar machen. Für Security-Operations-Teams ergänzen IT-Security-Schulungen die Arbeit an Angriffserkennung, Incident Response und technischen Kontrollen.

Schließe jeden Dry-Run mit konkreten Änderungen ab: neue OpenSearch-Regel, korrigierter Schwellenwert, zusätzliches Dashboard-Panel, eindeutiger Provider-Kontakt, gekürztes Runbook, dokumentierter Snapshot-Pfad oder geänderte Eskalationsmatrix. Übertrage dieselbe Auswertung auf echte Incidents. Nach den DORA-RTS ist der intermediate report grundsätzlich spätestens 72 Stunden nach der initial notification einzureichen; der final report folgt spätestens einen Monat nach dem intermediate report oder nach dem letzten aktualisierten intermediate report. Eine lückenlose Timeline reduziert Nacharbeit in beiden Berichten.

Konkreter nächster Schritt

Starte mit einem einzigen kritischen Service, zum Beispiel Zahlungs-API, Kundenportal oder Identity-Plattform. Erstelle einen Incident Record mit den genannten Feldern, baue ein OpenSearch-Dashboard für die fünf DORA-Fragen, hinterlege Provider-Daten aus dem Informationsregister und schreibe ein Runbook mit maximal zwei Seiten. Führe danach einen 90-Minuten-Dry-Run mit SOC, Betrieb, Service Owner, Compliance und Provider Owner durch. Miss dabei die Zeit von first detection bis zur klassifizierten Major-Entscheidung und prüfe, ob die initial notification ohne zusätzliche Recherche vorbereitet werden kann.