Close

Der Weg zu einem besseren Vorfallmanagement beginnt hier

Lerne den Lebenszyklus der Incident Response kennen

Wenn du dich längere Zeit in Gesellschaft von Experten für das Sicherheits- und Vorfallmanagement befindest, wirst du ein bestimmtes Muster erkennen. Die klügsten Leute in diesen Branchen denken in Zyklen, nicht linear.

Woran liegt das? Und was bedeutet das überhaupt? Es bedeutet, dass jeder Vorfall und Ausfall kein isoliertes Ereignis mit einem Anfangs- und Endpunkt ist (auch wenn es so erscheinen mag). Und dass man aus Vorfällen prima lernen kann.

Nur weil ein Service wieder "betriebsbereit" ist, heißt das nicht, dass die Arbeit deines Teams erledigt ist. Nach einem Vorfall solltest du Pläne für zukünftige Roadmaps erstellen, die Art und Weise ändern, wie du dich auf zukünftige Vorfälle vorbereitest, und Neues entdecken, das du zur Vermeidung weiterer Vorfälle entwickeln kannst. Es ist ein nie endender Verbesserungszyklus, und um über die verschiedenen Phasen nachzudenken, gibt es verschiedene Möglichkeiten. Diese hängen davon ab, welcher Denkschule du angehörst.

Was ist ein Incident-Response-Lebenszyklus?

Die Incident Response ist der Prozess eines Unternehmens, bei dem auf IT-Bedrohungen wie Cyberangriffe, Sicherheitsverletzungen und Serverausfälle reagiert wird.

Der Incident-Response-Lebenszyklus ist ein detailliertes Framework deines Unternehmens für die Identifizierung und Behebung eines Serviceausfalls oder einer Sicherheitsbedrohung.

Incident-Response-Lebenszyklus von Atlassian

Lebenszyklusdiagramm für die Incident Response von Atlassian

1. Erkenne den Vorfall.

Unsere Vorfallerkennung beginnt typischerweise mit Überwachungs- und Benachrichtigungstools. Manchmal hören wir jedoch zuerst von Kunden oder Teammitgliedern von einem Vorfall.

2. Richte Kommunikationskanäle für das Team ein.

Ein wichtiger erster Schritt besteht darin, die Kommunikationskanäle des Incident-Response-Teams einzurichten. Das erklärte Ziel hierbei ist, die Teamkommunikation an bekannten Orten wie einem speziellen Slack-Channel und einer Videokonferenzschaltung zu zentralisieren.

3. Bewerte die Auswirkungen und gib einen Schweregrad an.

Jetzt wird es Zeit, die Auswirkungen des Vorfalls zu beurteilen. So kann das Team entscheiden, wer noch kontaktiert werden muss und was Kunden und Stakeholdern kommuniziert werden soll.

4. Kommuniziere mit Kunden.

Wir möchten intern und extern möglichst früh mit Stakeholdern kommunizieren. Eine schnelle und präzise Kommunikation hilft dabei, Vertrauen bei den Kunden und dem Rest des Unternehmens aufzubauen.

5. Eskaliere das Problem an die richtigen Vorfallbearbeiter.

Diejenigen, die als erste einen Vorfall bearbeiten, müssen häufig andere Teams hinzuziehen und verwenden dazu ein Benachrichtigungstool wie Opsgenie.

6. Delegiere Rollen für die Incident Response.

Wenn weitere Teammitglieder mit der Bearbeitung beauftragt werden, delegiert der Vorfallmanager eine Rolle an sie.

7. Behebe den Vorfall.

Ein Vorfall gilt als behoben, wenn die aktuellen oder drohenden geschäftlichen Auswirkungen beseitigt sind. An diesem Punkt endet der Prozess für Notfallmaßnahmen. Das Team kann nun mögliche Bereinigungsaufgaben durchführen und sich der Post-Mortem-Analyse widmen.

Der Incident-Response-Lebenszyklus gemäß NIST

Ein weiterer Incident-Response-Lebenszyklus nach Industriestandard stammt vom National Institute of Standards and Technology (oder NIST). NIST ist eine Bundesbehörde der USA, die Standards und Praktiken zu Themen wie Incident Response und Cybersicherheit festlegt.

Wie gesagt, steht NIST für National Institute of Standards and Technology. Die Behörde bezeichnet sich stolz als "eines der ältesten Labors für Naturwissenschaft im Land". Sie befasst sich mit sämtlichen Aspekten von Technologie, einschließlich Cybersicherheit. In diesem Bereich avancierte sie mit ihren Schritten für die Incident Response zu einer der zwei brancheneigenen Instanzen für die Incident Response.

Wie Atlassian glaubt auch NIST, dass sich nicht jeder Vorfall verhindern lässt. Deshalb solltest du gut vorbereitet sein:

"Vorbeugende Aktivitäten, die auf den Ergebnissen von Risikobewertungen beruhen, können zwar die Anzahl der Vorfälle verringern, aber nicht alle Vorfälle lassen sich verhindern. Aus diesem Grund muss eine Incident-Response-Möglichkeit her, um Vorfälle schnell zu erkennen, Verluste und Schäden zu minimieren, die ausgenutzten Schwachstellen zu beheben und die IT-Services wiederherzustellen." – NIST

Der Incident-Response-Lebenszyklus gemäß NIST unterteilt die Incident Response in vier Hauptphasen: Vorbereitung; Erkennung und Analyse; Eindämmung, Beseitigung und Wiederherstellung; und Aktivitäten nach dem Ereignis.

Phase 1: Vorbereitung

Die Vorbereitungsphase umfasst die Maßnahmen, die ein Unternehmen ergreift, um sich auf die Incident Response vorzubereiten. Das sind beispielsweise die Einrichtung der richtigen Tools und Ressourcen und die Schulung des Teams. Diese Phase umfasst Tätigkeiten, mit denen Vorfälle verhindert werden sollen.

Phase 2: Erkennung und Analyse

Die genaue Erkennung und Bewertung von Vorfällen ist laut NIST für viele Unternehmen häufig der schwierigste Aspekt der Incident Response.

Phase 3: Eindämmung, Beseitigung und Wiederherstellung

Diese Phase konzentriert sich darauf, die Auswirkungen des Vorfalls so gering wie möglich zu halten und Serviceunterbrechungen abzuschwächen.

Phase 4: Aktivitäten nach dem Ereignis

Einer der wichtigsten Bestandteile der Incident Response, der gern vergessen wird, ist der, dass man daraus lernt und sich verbessert. In dieser Phase werden der Vorfall selbst und die Bemühungen bei der Incident Response analysiert. Dabei sollen die Wahrscheinlichkeit für ein erneutes Auftreten des Vorfalls begrenzt und Möglichkeiten zur Verbesserung der zukünftigen Incident-Response-Aktivitäten identifiziert werden.

Incident Response für moderne DevOps-Teams

In den letzten zehn Jahren hat die DevOps-Bewegung Teams dabei geholfen, ihre Vorgehensweise beim Entwickeln, Bereitstellen und Betreiben von Software zu überarbeiten. Hierzu gehören auch neue Methoden, wie diese Teams auf Vorfälle reagieren.

Der DevOps-Ansatz für die Verwaltung von Vorfällen unterscheidet sich nicht wesentlich von den bisherigen Schritten für ein effektives Vorfallmanagement. Beim DevOps-Vorfallmanagement kommt es jedoch vor allem darauf an, dass das Entwicklerteam – und der Bereitschaftsdienst – gleich am Anfang einbezogen und Aufgaben basierend auf Fachkenntnissen, und nicht auf der Berufsbezeichnung, zugewiesen werden.

Incident Response und kontinuierliche Verbesserung

Wir haben am Anfang des Artikels über das Denken in Zyklen und lineares Denken gesprochen. Du wirst feststellen, dass all diese Ansätze für das Vorfallmanagement etwas gemeinsam haben: Sie sind nicht linear. Jeder von ihnen besteht aus den gleichen grundlegenden Komponenten: Möglichkeiten zur Definition, Erkennung und Identifizierung von Vorfällen; Möglichkeiten, schnell zu reagieren und Maßnahmen zur Abschwächung von Vorfällen zu ergreifen; und Möglichkeiten zur Analyse von Vorfällen, um die Erkennung und Reaktion in Zukunft zu verbessern. Es hat aber keinen Sinn, einen alten Vorfall nur aus Jux und Tollerei zu analysieren. Du kannst die Zeit nicht zurückdrehen und ändern, was passiert ist. Du lernst aus dem Vorfall, um die zukünftige Erkennung und Reaktion zu verbessern. Durch ständiges, kontinuierliches Lernen und Verbessern schließen Teams diesen Kreis.

Weiter geht's
Playbook