Lerne den Lebenszyklus der Incident Response kennen

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.

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.

Da Vorfallsmeldungen von unterschiedlichen Quellen stammen können, ist eine Lösung erforderlich, die unterschiedliche Warnmeldungs- und Berichtstools integrieren kann. Sie sorgt dafür, dass Reaktionen nicht kleinteilig und mühsam ausfallen, sondern zusammenhängend und kollaborativ. Eine Lösung wie Jira Service Management erlaubt es Teams, Warnmeldungen in allen Überwachungs-, Protokollierungs- und CI/CD-Tools anzupassen und zu filtern. So können Teams schnell auf Vorfälle reagieren und es kommt seltener zu Alarm-Fatigue.

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.

Jira Service Management erleichtert die Koordination der Incident Response. So können Teams auf ihre bevorzugte Weise kommunizieren (zum Beispiel per Slack oder Videokonferenz) und auch die Kommunikation mit Kunden wird durch Automatisierung und Anpassung vereinfacht. Mehr zur externen Kommunikation erfährst du in Schritt 4.

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. Die Angabe eines Schweregrads hilft nicht nur dabei, die Auswirkungen eines Vorfalls zu bestimmen, sondern schafft auch die Grundlage für Lösungspläne und die externe Kommunikation. In Jira Service Management lösen die Eskalation von Vorfällen und die Angabe von Schweregraden automatisierte Aktionen sowie Benachrichtigungen an Verantwortliche aus, damit diese den Lösungsfortschritt im Blick behalten können.

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. Zudem ist es, wie bereits erwähnt, wichtig, die Kommunikation individuell anzupassen, damit dein Team genau so arbeiten kann, wie es möchte. So können Vorfälle schneller behoben werden. Die individuelle Anpassbarkeit der Kommunikation erlaubt es deinem Team außerdem, genau zu bestimmen, welche Nachricht wann bearbeitet werden soll. Zudem sorgen automatisierte Ticket-Antworten, die direkt an den Kunden gesendet werden, dafür, dass dein Team mehr Zeit für die Lösung von Vorfällen hat.

5. Eskaliere das Problem an die richtigen Vorfallbearbeiter.

Diejenigen, die als erste einen Vorfall bearbeiten, müssen häufig andere Teams hinzuziehen. Das ist zum Beispiel mit den Benachrichtigungsfunktionen von Jira Service Management möglich. Verweise Verantwortliche direkt auf das Vorfall-Ticket, indem du verwandte Tickets gruppierst und wichtige Personen direkt im Ticket kennzeichnest. So kannst du Benachrichtigungen koordinieren und alle über den neusten Stand informieren.

6. Delegiere Rollen für die Incident Response.

Wenn weitere Teammitglieder mit der Bearbeitung beauftragt werden, delegiert der Vorfallmanager eine Rolle an sie. Für diesen Fall ist ein zuvor zusammengestelltes Incident-Response-Playbook hilfreich, in dem alle Rollen und Verantwortlichkeiten klar dargelegt sind. Auf diese Weise sind die Mitglieder des Incident-Response-Teams mit den Rollen vertraut und wissen, wofür sie bei einem Vorfall verantwortlich sind.

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.

Im Idealfall bietet deine Vorfallmanagementlösung eine Zeitleiste für Vorfälle. Dies ist zum Beispiel mit Jira Service Management möglich. Die Lösung ermöglicht es Verantwortlichen, nach Vorfällen auf wichtige Daten zuzugreifen und einen Bericht zu erstellen, der Teams dabei hilft, in Zukunft ähnliche Vorfälle zu verhindern und die Ursache zu finden. Für den unwahrscheinlichen Fall, dass ähnliche Vorfälle erneut auftreten, können zudem Post-Mortem-Analysen als Ressource herangezogen werden.

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.

Ein (nicht linearer) Incident-Response-Prozess besteht aus mehreren dynamischen Elementen. Mit einer Vorfallmanagementlösung wie Jira Service Management behältst du dank integrierter Kollaborations- und Kommunikationstools jeden Schritt im Blick. Bringe Warnmeldungen und Teams an einem Ort zusammen, um schnell flexibel auf Vorfälle zu reagieren und diese zu lösen.