IT-Incident - IT-Störfall

unerwartetes Ereignis, Störung

---

Ein Incident ist ein unerwartetes Ereignis, das die normale Funktionalität, Sicherheit oder den Betrieb eines Systems, einer Organisation oder eines Prozesses stört oder beeinträchtigt. Incidents können verschiedene Formen annehmen, wie z.B. technische Störungen, Sicherheitsverletzungen, menschliche Fehler, Naturkatastrophen oder andere Zwischenfälle.

IT-Incident

In der Informationstechnologie (IT) bezieht sich der Begriff "IT-Incident" oft auf eine IT-Störung oder einen Vorfall, der die normale Funktionalität oder Leistungen von IT-Services beeinträchtigt.

Dies kann beispielsweise eine Server-Ausfallzeit, Netzwerkausfälle, Datenverluste oder Probleme mit Softwareanwendungen umfassen. Incidents werden oft in einem IT Service Management (ITSM) Framework wie ITIL (Information Technology Infrastructure Library) behandelt, um sicherzustellen, dass sie effizient erfasst, klassifiziert, bearbeitet und gelöst werden.

Abbildung (Quelle = Internet)

Incidents können auch außerhalb des IT-Bereichs auftreten. Zum Beispiel können in Unternehmen Incidents in Form von Sicherheitsvorfällen, Unfällen am Arbeitsplatz, Rechtsstreitigkeiten oder anderen Betriebsstörungen auftreten. Die genaue Definition eines Incidents hängt von der spezifischen Kontext und dem Anwendungsbereich ab.

Klassifizierung von IT-Incidents

IT-Vorfälle (Incidents) können je nach ihrer Art und ihrem Ausmaß auf verschiedene Weisen klassifiziert werden. Eine gängige Methode zur Klassifizierung von IT-Incidents ist die Verwendung von ncident-Kategorien und -Prioritäten. Hier sind einige Schritte zur Klassifizierung von IT-Incidents:

1. Incident-Kategorien:

   1. Sicherheitsvorfälle: Dazu gehören Verstöße gegen die Informationssicherheit, wie Malware-Infektionen, Datenlecks und Cyberangriffe.

   2. IT-Service-Störungen (SaaS): Dies bezieht sich auf Störungen der IT-Lösung, wie Fehlermeldungen, langsame Antwortzeiten, Abbrüche.

   3. Benutzerprobleme: Hierbei handelt es sich um Anfragen und Probleme, die von Endbenutzern gemeldet werden, wie vergessene Passwörter und Anforderungen zur Anpassung von Zugriffsrechten.

   4. Netzwerkstörung: Dies bezieht sich auf Störungen mit der Netzwerkinfrastruktur, wie Verbindungsprobleme, Latenz und Ausfälle.

   5. Software-Störung: Hierzu gehören Fehler in Anwendungssoftware, Betriebssystemen und anderen Softwarekomponenten.

   6. Hardware-Störung: Dies umfasst Störungen an Computern, Servern, Netzwerken, Druckern und anderen physischen Geräten.

   7. Andere-Störungen:

2. Incident-Prioritäten:

   • Kritisch - Critical Incident: Vorfälle, die einen schwerwiegenden Ausfall oder eine erhebliche Bedrohung für die Sicherheit darstellen und sofortige Aufmerksamkeit erfordern.

   • Hoch - Major Incident: Wichtige Vorfälle, die schnelle Maßnahmen erfordern, um Geschäftsprozesse wiederherzustellen oder Sicherheitsprobleme zu beheben.

   • Mittel - Incident: Vorfälle, die mittlere Auswirkungen haben und innerhalb eines angemessenen Zeitrahmens behandelt werden sollten.

   • Niedrig - Minor Incindet: Vorfälle mit geringer Auswirkung, die nachrangig behandelt werden können.

3. Eskalationsstufen: Festlegen von Eskalationsstufen, die angeben, wie ein Vorfall behandelt werden sollte, falls er nicht in angemessener Zeit gelöst wird. Dies kann von der Weiterleitung an höhere Supportebenen bis zur Benachrichtigung von Managern oder Vorgesetzten reichen. Es ist wichtig, dass der Eskalationsprozess gut dokumentiert und in den Incident-Management-Prozess integriert ist. Dies gewährleistet eine klare Kommunikation, Priorisierung und Nachverfolgung von Incidents, um sicherzustellen, dass sie effizient behandelt werden und die Auswirkungen auf den Geschäftsbetrieb minimiert werden. Typische Eskalationsstufen, die in vielen Incident-Management-Prozessen verwendet werden sind:

   1. Erste Ebene (Level 1 Support): Dies ist die erste Anlaufstelle für gemeldete Incidents. Hier werden einfache und häufig auftretende Probleme gelöst. Das Level 1 Supportteam besteht oft aus Helpdesk-Mitarbeitern oder IT-Servicedesk-Mitarbeitern. Sie können den Incident lösen oder ihn an höhere Supportebenen eskalieren, wenn nötig.

   2. Zweite Ebene (Level 2 Support): Wenn der Incident komplexer ist und nicht auf der ersten Ebene gelöst werden kann, wird er an die zweite Ebene des Supports weitergeleitet. Dieses Team besteht aus spezialisierten Technikern und Systemadministratoren. Sie haben in der Regel tiefgreifendere Kenntnisse und Ressourcen, um komplexere Probleme zu bewältigen.

   3. Dritte Ebene (Level 3 Support): Die dritte Ebene des Supports besteht aus Experten, die hochspezialisiertes Wissen über bestimmte Systeme oder Anwendungen haben. Wenn ein Incident noch immer nicht gelöst ist, kann er an diese Ebene eskaliert werden. Hier können auch Hersteller oder externe Dienstleister einbezogen werden, wenn es sich um eine komplexe Systemintegration oder ein spezifisches Produkt handelt.

   4. Management-Eskalation: Wenn ein Incident besonders kritisch ist oder eine erhebliche Auswirkung auf den Geschäftsbetrieb hat, kann er auf Managementebene eskaliert werden. Dies kann das IT-Management, den CIO (Chief Information Officer) oder andere Führungskräfte der IT-Abteilung umfassen. Die Management-Eskalation dient dazu, Aufmerksamkeit und Ressourcen auf das Problem zu lenken und sicherzustellen, dass angemessene Maßnahmen ergriffen werden.

   5. Eskalation an externe Dienstleister oder Lieferanten: Wenn der Incident auf ein von einem Drittanbieter geliefertes Produkt oder einen von einem Drittanbieter betriebenen Dienst zurückzuführen ist, kann eine Eskalation an den Lieferanten erforderlich sein. Dies dient dazu, den Lieferanten zur Lösung des Problems zu bewegen und sicherzustellen, dass Service-Level-Vereinbarungen (SLAs) eingehalten werden.

4. Dokumentation-Stufen: Die Dokumentation spielt eine entscheidende Rolle im IT-Incident-Management-Prozess, da sie dazu dient, die Informationen und Aktivitäten im Zusammenhang mit einem Incident zu erfassen, zu verfolgen und zu verwalten. Es gibt verschiedene Stufen (Level of Information LoI) und Detaillierungsgrade (Level of Detail LoD) der Dokumentation, die im Incident-Management-Prozess üblicherweise vorkommen. Die genaue Art der Dokumentation kann je nach den Richtlinien und Verfahren Ihrer Organisation variieren. Eine umfassende und genaue Dokumentation ist jedoch entscheidend, um die Effektivität des Incident-Management-Prozesses sicherzustellen, eine Wissensdatenbank aufzubauen und die Einhaltung von SLAs (Service-Level Agreements) zu gewährleisten.

   • Hoch - Die Details des Vorfalls müssen genau dokumentiert werden, einschließlich Zeitpunkt des Eintreffens, Art des Vorfalls, betroffene Systeme oder Benutzer und alle durchgeführten Maßnahmen zur Behebung des Vorfalls. Diese Informationen werden für die interne Beabreitung und Analysen benötigt
   • Mittel - Die Details des Vorfalls müssen in Form vom Gedankenstützen erfasst werden, so dass sich beteiligte Stakeholder auskennen und mit den bereitgestellten Information und Nachrichten was anfangen können.
   • Niedrig - Die Details des Vorfalls können in Form vom Gedankenstützen und strichwortartig erfasst werden, so dass sich beteiligte Fachleute auskennen.

Die genaue Klassifizierungsmethode kann je nach den spezifischen Anforderungen und Prozessen Ihrer Organisation variieren. Es ist wichtig sicherzustellen, dass die Klassifizierung und Priorisierung von IT-Incidents effizient erfolgen, um sicherzustellen, dass Ressourcen optimal eingesetzt werden und wichtige Probleme Vorrang haben.

Incident-Dringlichkeit (Dringlichkeits-Kategorien)

Für die Incident-Dringlichkeit stehen folgende Kategorie zur Verfügung.

Kategorie	Beschreibung
Hoch (H)	Der vom Incident verursachte Schaden nimmt schnell zu. Die Prozessaufgaben, die von Anwender nicht erfüllt werden können, sind sehr zeitkritisch. Durch schnelles Handeln kann verhindert werden, dass aus einem Minor Incident ein Major Incident wird. Mehrere Benutzer mit VIP-Status sind betroffen.
Mittel (M)	Der von dem Incident verursachte Schaden nimmt im Verlauf der Zeit substantiell zu. Die Aufgaben, die von Anwendern nicht erfüllt werden können, sind nur mäßig zeitkritisch. Ein einzelner Benutzer mit VIP-Status ist betroffen.
Niedrig (N)	Der von dem Incident verursachte Schaden nimmt im Verlauf der Zeit nur unwesentlich zu. Die Aufgaben, die von den Anwendern nicht erfüllt werden können, sind nicht zeitkritisch.

Incident-Auswirkung (Auswirkungs-Kategorien)

Um die Incident-Auswirkung stehen folgende Kategorie zur Verfügung.

Kategorie	Beschreibung
Hoch (H)	Eine große Anzahl von Mitarbeitern ist betroffen und/oder kann ihre Aufgaben nicht erfüllen. Eine große Anzahl von Kunden ist betroffen und/oder ist in irgendeiner Weise akuten Nachteilen ausgesetzt. Der finanzielle Schaden durch den Incident ist voraussichtlich höher als 50.000 EUR. Eine Beschädigung der Reputation des Unternehmens in großem Umfang ist wahrscheinlich. Es besteht Gefahr für Leib und Leben.
Mittel (M)	Eine mäßige Anzahl von Mitarbeitern ist betroffen und/oder kann ihre Aufgaben nicht wie vorgesehen erfüllen. Eine mäßige Anzahl von Kunden ist betroffen und/oder erfährt Einschränkungen beim Komfort. Der finanzielle Schaden durch den Incident liegt voraussichtlich zwischen 5.000 EUR und 50.000 EUR. Eine Beschädigung der Reputation des Unternehmens in mäßigem Umfang ist wahrscheinlich.
Niedrig (N)	Eine minimale Anzahl von Mitarbeitern ist betroffen und/oder kann ihre Aufgaben erfüllen, jedoch nur mit zusätzlichem Aufwand. Eine minimale Anzahl von Kunden ist betroffen und/oder erfährt Einschränkungen beim Komfort, jedoch nur in geringem Umfang. Der finanzielle Schaden durch den Incident ist voraussichtlich weniger als (zum Beispiel) 5.000 EUR. Eine Beschädigung der Reputation des Unternehmens ist nur in minimalem Umfang zu erwarten.

Incident Priority Matrix

Wenn Klassen zur Bestimmung von Dringlichkeit und Auswirkung definiert sind, kann eine Dringlichkeits-Auswirkungs-Matrix ("Urgency-Impact Matrix" oder auch "Incident Priority Matrix" genannt) verwendet werden, um Klassen von Prioritäten festzulegen, wie im folgenden Beispiel:

Auswirkung		H	M	N
Urgency	H	1	2	3
	M	2	3	4
	L	3	4	5

Tabelle Urgency-Impact Matrix

Prioritäts-Code	Beschreibung	Reaktionszeit-Vorgabe	Lösungszeit-Vorgabe
1	Kritisch	Sofort	1 Stunde
2	Hoch	10 Minuten	4 Stunden
3	Mittel	1 Stunde	8 Stunden
4	Niedrig	4 Stunden	24 Stunden
5	Sehr niedrig	1 Tag	1 Woche

Tabelle Incident Priority Codes

Kriterien für die Behandlung eines Incidents als Major Incident

Major Incidents erfordern die Etablierung eines Major Incident Teams und werden durch den Prozess Behebung von Major Incidents behandelt.