Geschrieben von Uwe Sievers
Permanente Angriffe sowie regelmäßige Vorfälle sind in der IT alltäglich. Ohne Incident Response Management ist dagegen kaum anzukommen. Verschiedene Anforderungen sind dabei zu erfüllen.
Störungen und Vorfälle gehören in der IT zum Alltag. Deshalb haben größere Unternehmen fast immer ein Störfallmanagement etabliert, das auch als Incident Response Management bezeichnet wird. Dabei orientieren sie sich häufig an ITIL- und ITSM-Verfahren oder ISO-Normen. Das Hauptziel eines Incident- Response-Prozesses ist die zügige und optimale Problemlösung.
Was jedoch überhaupt als Störung betrachtet wird, kann sich je nach Konzept und Unternehmen unterscheiden. Allgemein kann eine Störung als ein Ereignis gesehen werden, das zu einer Unterbrechung eines IT-Dienstes oder zu dessen Qualitätsbeeinträchtigung führt. Oftmals werden Störungen je nach Schweregrad kategorisiert, etwa in Standardvorfall und gravierender Vorfall. Hier sollten jedoch nicht zu viele Kategorien gebildet werden, da eine Eskalation gewöhnlich im Rahmen des Notfallmanagements erfolgt. Das heißt, ab einer gewissen Auswirkung wird aus der Störung ein Notfall beziehungsweise eine Krise, wie in diesem Beitrag zum Thema Krisenstab erläutert.
Ein gut funktionierender Incident-Response-Prozess läuft schnell und vorhersehbar ab. Der Weg von der Erkennung zur Reaktion sollte kurz sein und die Kommunikation klar, damit bei einer Eskalation schnell die richtigen Personen informiert werden können. Für eine optimale Bearbeitungsgeschwindigkeit ist zudem eine einfache Struktur entscheidend. Der Prozess sollte so einfach gestaltet sein, dass Mitarbeiter und Mitarbeiterinnen ihn auch unter Stress problemlos befolgen können.
Das Störfallmanagement von Sicherheitsproblemen wird jedoch häufig gesondert priorisiert, denn diese Vorfälle können gravierende Folgeschäden verursachen. Sie sind deshalb nicht nur wichtig, sondern auch dringend. Solche Ereignisse werden manchmal auch personell vom klassischen IT-Störfallmanagement abgetrennt und stattdessen durch ein Computer Security Incident Response Team (CSIRT) bearbeitet. Das gewährleistet zum Beispiel eine schnellere Erkennung von False Positives, also falschen Alarmen.
Zumeist ist es sinnvoll, jedes Ereignis einer Person zuzuordnen, die sich darum maßgeblich kümmert und die Rolle des Vorfallmanagers übernimmt. Diese Rolle erhält normalerweise eine Person, in deren Aufgabenbereich die Störung eingetreten ist. Ein Vorfallmanager führt die Beteiligten durch die notwendigen Schritte, um den Vorfall von der Erkennung bis zur Lösung zu geleiten.
Die einzelnen Schritte des Incident-Response-Prozesses lassen sich typischerweise in drei Phasen unterteilen: Es beginnt mit der Erkennung, worauf eine Analyse folgt, mit dem Ziel, eine Lösung zu entwickeln, und endet schließlich mit der Behebung. Ganz zu Ende ist der Vorgang dann allerdings noch nicht, denn ein wichtiger Aspekt ist die Auswertung des Vorfalls, um eine Wiederholung für die Zukunft möglichst zu vermeiden.
Die erste Phase beginnt gewöhnlich mit einer Störfallmeldung. In der IT-Security erfolgt dies häufig voll automatisiert durch entsprechende Monitoring-Systeme. Zu den notwendigen Maßnahmen dieser Phase zählt die Bewertung des Schweregrades und damit die Einordnung in eine entsprechende Kategorie. Auch das leisten viele Security-Monitoring-Systeme. Schon in dieser Phase wird für das Ereignis ein Vorfallmanager festgelegt. Er wird dann für die zweite Phase, die Analyse beziehungsweise Lösungsfindung, geeignete Personen hinzuziehen und gegebenenfalls über eine weitere Eskalation entscheiden. Ist eine Lösung gefunden, etwa ein Patch oder die Änderung einer Firewall-Regel, muss diese zunächst getestet werden. Sämtliche Schritte dieser Phase sollten dokumentiert werden, denn falls sich die Lösung als nicht zweckdienlich erweist, können leichter Varianten erprobt werden. Spätestens wenn die Behebung des Problems in der dritten Phase erfolgt ist, müssen alle betroffenen Personen oder Unternehmensbereiche informiert werden. Sollte die Behebung länger dauern, ist es sinnvoll, kontinuierlich über den Verlauf zu informieren. Im Anschluss wird die Nachbearbeitung des Vorfalls eingeleitet. Eine Diskussionsrunde mit Entwicklern oder Administratoren ist dabei ein hilfreiches Verfahren, denn gemeinsam lässt sich häufig besser klären, wie ähnliche Fälle zukünftig vermieden werden können. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hält eine Checkliste bereit, die bei der Bewältigung von Vorfällen sehr nützlich sein kann.
