Incident Response

Was ist Incident Response?

Nach NIST SP 800-61 Revision 3 ist Incident Response ein kritischer Teil des Cybersicherheits-Risikomanagements und sollte organisationsweit in die Abläufe integriert werden. Finanzunternehmen bestimmen nach Artikel 17 Absatz 1 DORA einen Prozess für die Behandlung IKT-bezogener Vorfälle, um sie zu erkennen, zu behandeln und zu melden. Ein möglicher Ablauf, der keine feste Regel ist: Nach dem BSI-Kriterienkatalog C5 für Cloud-Anbieter gehört zu den Funktionen eines SIEM-Systems die Echtzeit-Alarmierung, um das Incident-Response-Team über kritische Ereignisse zu informieren, und die spätere Meldung neuer, für ein Ereignis relevanter Informationen. Ein SOC erkennt Sicherheitsvorfälle und kann je nach Aufgabenverteilung auch Maßnahmen zur Eindämmung einleiten.

Ein unter DORA fallender Versicherer prüft Hinweise auf Sicherheitsvorfälle, dämmt bestätigte Vorfälle ein und stellt betroffene Dienste wieder her, während er schwerwiegende IKT-bezogene Vorfälle nach Artikel 19 DORA der zuständigen Behörde meldet. Zur Abgrenzung: Die Meldepflicht für erhebliche Sicherheitsvorfälle in § 32 BSIG gilt nach § 28 Absatz 6 Nummer 1 BSIG nicht für Finanzunternehmen nach Artikel 2 Absatz 2 DORA.

Wie läuft Incident Response ab?

Nach dem BSI-Baustein DER.2.1 müssen die Zuständigen bei einem Sicherheitsvorfall zunächst das Problem eingrenzen und die Ursache finden, damit er erfolgreich behoben werden kann. Parallel dazu sollte entschieden werden, ob es wichtiger ist, den entstandenen Schaden einzudämmen oder den Vorfall aufzuklären.

Die aktuelle Revision 3 von NIST SP 800-61 ersetzt die Revision 2 und ordnet Incident Response den Funktionen von NIST CSF 2.0 zu: Detect, Respond und Recover bilden die Incident Response selbst, während die Vorbereitung durch Govern, Identify und Protect nicht dazu zählt. Das frühere Phasenmodell der Revision 2 wird in Revision 3 in einer Tabelle den entsprechenden CSF-Funktionen zugeordnet, die das Dokument verwendet. Revision 3 begründet ihren geänderten Umfang damit, dass sich die Einzelheiten der Maßnahmen so häufig ändern und so stark zwischen Technologien, Umgebungen und Organisationen variieren, dass sie sich nicht mehr in einer einzigen statischen Veröffentlichung festhalten lassen.

Incident Response im Vergleich

Incident Management meint im Baustein DER.2.1 die Störungs- und Fehlerbehebung, Incident Response dagegen die Behandlung von Sicherheitsvorfällen aus Sicht der Informationstechnik. Das Einstufungsverfahren für Sicherheitsvorfälle sollte zwischen Sicherheitsmanagement und der Störungs- und Fehlerbehebung abgestimmt sein; beide Verfahren sind also aufeinander bezogen, aber nicht dasselbe. Fällt etwa ein Kundenportal aus, stellt der IT-Betrieb im Rahmen des Incident Managements die Verfügbarkeit wieder her, während ein Sicherheitsteam bei einem Sicherheitsvorfall die Ursache sucht und weitere Schäden begrenzt.

Während ein SOC Vorfälle erkennt und je nach Aufgabenverteilung auch eingreifen kann, ist Incident Response das Verfahren zur Behandlung erkannter Vorfälle. In großen Unternehmen konzentrieren sich SOCs nach ENISA mitunter nur auf Überwachung und Erkennung und übergeben die Bearbeitung an ein separates CSIRT, in kleineren Organisationen gelten CSIRT und SOC dagegen oft als gleichbedeutend.

Wann wird Incident Response ausgelöst?

Nach dem Baustein DER.2.1 beginnt die Bearbeitung eines Sicherheitsvorfalls, sobald ein Vorfall erkannt ist, und setzt die Anforderungen an die Detektion aus dem Baustein DER.1 voraus. Ob ein Vorfall zusätzlich eine Meldung an die Behörde auslöst, ist eine zweite Frage: Finanzunternehmen klassifizieren IKT-bezogene Vorfälle nach Artikel 18 DORA und melden schwerwiegende IKT-bezogene Vorfälle nach Artikel 19 Absatz 1 DORA der zuständigen Behörde. Dabei gilt DORA nach Artikel 2 Absatz 3 Buchstabe b nicht für Versicherungs- und Rückversicherungsunternehmen im Sinne von Artikel 4 der Richtlinie 2009/138/EG; Versicherungs- und Rückversicherungsunternehmen als solche zählen nach Artikel 2 Absatz 1 Buchstabe n DORA zu den Unternehmen, für die die Verordnung gilt. Diese Ausnahme betrifft die Geltung der Verordnung insgesamt und damit auch die Meldepflicht.

Schutz im Ernstfall

Vorbeugen

• Die Sicherheitsvorfallsbehandlung muss ihre Verfahren und Regelungen dokumentieren, so verlangt es eine Grundschutz-Checkliste des BSI zur Incident Response (REA.1.1.1).
• Nach einem analysierten Sicherheitsvorfall sollte untersucht werden, ob die Prozesse und Abläufe der Behandlung von Sicherheitsvorfällen geändert oder weiterentwickelt werden müssen (Baustein DER.2.1).
• Bei der Behandlung von Sicherheitsvorfällen müssen nach dem Baustein DER.2.1 die Meldepflichten für Behörden und regulierte Branchen berücksichtigt werden.

Was tun im Ernstfall

• Nach einem Sicherheitsvorfall die betroffenen Komponenten vom Netz nehmen und alle erforderlichen Daten sichern, die Aufschluss über Art und Ursache des Problems geben könnten (Baustein DER.2.1).
• Das unter DORA fallende Finanzunternehmen klassifiziert den Vorfall nach Artikel 18 DORA und stellt damit fest, ob es sich um einen schwerwiegenden IKT-bezogenen Vorfall handelt.
• Stuft das Finanzunternehmen den Vorfall als schwerwiegenden IKT-bezogenen Vorfall ein, meldet es ihn nach Artikel 19 Absatz 1 DORA der zuständigen Behörde; hat der schwerwiegende Vorfall Auswirkungen auf die finanziellen Interessen von Kunden, unterrichtet es diese nach Artikel 19 Absatz 3 DORA unverzüglich, sobald es davon Kenntnis erlangt hat, über den Vorfall und die Maßnahmen, die ergriffen wurden, um die nachteiligen Auswirkungen zu mindern.
• Nach Artikel 19 Absatz 4 DORA legt das Finanzunternehmen der zuständigen Behörde eine Erstmeldung, eine Zwischenmeldung und eine Abschlussmeldung vor.
• Unverzüglich die speziellen Pläne aktivieren, die Eindämmungsmaßnahmen, Prozesse und Technologien für alle Arten IKT-bezogener Vorfälle ermöglichen und weitere Schäden vermeiden, sowie die maßgeschneiderten Verfahren zur Reaktion und Wiederherstellung gemäß Artikel 12 (Artikel 11 Absatz 2 Buchstabe c DORA).