Incident Response einfach erklärt
Der englische Begriff setzt sich aus „Incident“ für Vorfall und „Response“ für Reaktion zusammen. Gemeint ist nicht jede technische Störung. Fällt eine Festplatte aus, wird sie getauscht und die Arbeit geht weiter. Bei einem Sicherheitsvorfall dagegen hat jemand unbefugt gehandelt oder handelt womöglich noch: ein fremder Zugriff auf ein Postfach, unbekannte Programme auf einem Server, Dateien, die eine Ransomware verschlüsselt hat.
Dieser Unterschied ändert das Vorgehen. Ein betroffener Rechner, der in der ersten Aufregung gelöscht und neu installiert wird, verrät hinterher nicht mehr, auf welchem Weg der Angriff kam. Bleibt dieser Weg unbekannt, steht er womöglich weiter offen. Incident Response gibt deshalb eine Reihenfolge vor, die auch unter Druck trägt.
Wie eine geordnete Reaktion aufgebaut ist
Die US-Standardisierungsbehörde NIST hat ihre Empfehlungen zur Vorfallbehandlung im April 2025 als SP 800-61 Revision 3 neu gefasst. Sie ordnet die Reaktion auf Vorfälle nun in die Funktionen ihres Cybersecurity Framework 2.0 ein, also in das gesamte Risikomanagement von der Vorsorge bis zur Wiederherstellung. Im IT-Grundschutz-Kompendium des BSI (Edition 2023) ist dem Thema der Baustein DER.2.1 „Behandlung von Sicherheitsvorfällen“ gewidmet. Im Alltag eines kleineren Betriebs lässt sich das auf sechs Fragen herunterbrechen:
- Was liegt schon bereit? Wer zuständig ist und wen man anruft, steht fest, bevor ein Vorfall eintritt.
- Was ist passiert? Eine Meldung wird geprüft: Fehlalarm, Störung oder Angriff? Und wie weit reicht er?
- Wie stoppen wir die Ausbreitung? Zugänge der Angreifer werden gekappt, befallene Geräte abgeschottet, missbrauchte Anmeldedaten ungültig gemacht.
- Was muss weg? Hintertüren, Schadprogramme und alles, was die Angreifer eingerichtet haben, wird beseitigt und die ausgenutzte Lücke behoben.
- Wann darf der Betrieb wieder anlaufen? Erst wenn klar ist, dass die Systeme sauber sind; Daten kommen bei Bedarf aus einem Backup, das vor dem Angriff entstanden ist.
- Was lernen wir daraus? Lücken in Technik, Abläufen und Notfallplan werden geschlossen.
Wer im Ernstfall beteiligt ist
Ein Sicherheitsvorfall ist nicht allein Sache der IT. Der erste Hinweis kommt etwa von Mitarbeitenden, von Kunden, vom Virenschutz oder von einem Dienst für Managed Detection and Response, der Warnmeldungen laufend auswertet. Die Geschäftsführung entscheidet, ob Systeme abgeschaltet werden, auch wenn dann die Auftragsannahme stillsteht. Der IT-Dienstleister kennt die Umgebung und setzt technische Maßnahmen um. Spezialisierte Fachleute für die Vorfallbehandlung analysieren den Angriff und sichern Spuren so, dass sie später als Beleg dienen können.
Hinzu kommen weitere Stellen. Ihre Ansprechperson für den Datenschutz klärt, ob personenbezogene Daten betroffen sind und eine Meldung nach Art. 33 DSGVO nötig wird; Einzelheiten erklärt der Begriff DSGVO. Wer eine Cyberversicherung hat, sollte deren Vorgaben für den Schadenfall kennen. Und jemand muss entscheiden, was Kunden, Lieferanten und Mitarbeitende erfahren. Diese Hinweise ersetzen keine Rechtsberatung.
Was ein Notfallplan enthalten sollte
Vorbereitung kann die Reaktion spürbar beschleunigen, weil Telefonnummern und Zuständigkeiten im Ernstfall nicht erst gesucht werden müssen. In einem Betrieb mit einigen Dutzend Arbeitsplätzen muss ein Notfallplan nicht umfangreich sein, sollte aber diese Punkte enthalten:
- eine Kontaktliste auf Papier, denn E-Mail und Dateiablage sind im Ernstfall womöglich nicht nutzbar
- Namen derer, die über Abschaltungen und Kommunikation entscheiden dürfen
- eine Übersicht der wichtigen Systeme mit der Reihenfolge, in der sie wieder anlaufen sollen
- Angaben, wo die Datensicherungen liegen und wie man an Notfallzugänge kommt
Eine aktuelle Systemübersicht ist dafür die Grundlage. Wie sie entsteht und gepflegt wird, beschreibt unsere Seite zur IT-Dokumentation. Wie sich ein Ausfall über Stunden oder Tage planen lässt, erklärt der Begriff Disaster Recovery.
Eine Erpresser-Mail ohne verschlüsselte Dateien
Ein denkbarer Fall: Ein Hersteller von Werbetechnik mit 35 Beschäftigten erhält eine E-Mail von Unbekannten. Sie behaupten, Kundenlisten und Kalkulationen kopiert zu haben, und drohen mit der Veröffentlichung. Im Betrieb läuft alles normal, keine Datei ist verschlüsselt.
Die Geschäftsführung antwortet nicht auf die Mail und greift zum Notfallplan. Fachleute für die Vorfallbehandlung prüfen zuerst, ob die Behauptung stimmt: Die Protokolle der Firewall zeigen an zwei Abenden ungewöhnlich große Übertragungen vom Dateiserver nach außen. Als Einfallstor stellt sich das Konto eines ausgeschiedenen Mitarbeiters heraus, das noch aktiv war und sich über den Fernzugang ohne zweiten Faktor nutzen ließ.
Das Konto wird gesperrt, der Fernzugang vorübergehend geschlossen, alle Administratorkennwörter werden neu gesetzt. Wer sich im Betrieb um den Datenschutz kümmert, prüft die Meldung an die Aufsichtsbehörde, und die Geschäftsführung entscheidet, welche Kunden sie informiert. In der Nachbereitung wird der Fernzugang an eine Multi-Faktor-Authentifizierung gebunden, und das Sperren von Konten gehört nun fest zum Austritt von Beschäftigten.
Notfallhilfe und Wiederaufbau
Analyse und Forensik nach einem Angriff liegen bei unserem Partner für offensive IT-Sicherheit, der Rootsektor IT-Security GmbH. Einen Eindruck vom dortigen Vorgehen gibt die Seite Incident Response bei Rootsektor (externe Website). Wie wir zusammenarbeiten, erläutert unsere Seite zu Partnern und Herstellerunabhängigkeit.
Müssen Systeme nach einem Angriff neu aufgebaut werden, stellen wir sie in Abstimmung mit Rootsektor aus Ihren Sicherungen wieder her. Wie die Datensicherung für Unternehmen aufgebaut sein sollte, damit das gelingt, beschreiben wir im Bereich Backup. Vorbeugende Bausteine wie Firewall und Endpoint-Schutz finden Sie unter IT-Sicherheit für Unternehmen.