Die Frage ist nicht, ob ein Vorfall eintreten wird, sondern wann. Systeme werden abstürzen. Software wird versagen. Dienstleister werden selbst Ausfälle erleiden. Die Vorbereitung auf solche Probleme gehört zu euren Aufgaben – Schweregrade zählen dabei zu den notwendigen Werkzeugen.
Vorfälle wirken sich unterschiedlich stark auf Unternehmen und Kunden aus. Mit Schweregraden klassifiziert ihr die Auswirkungen und steuert eure Reaktion. Bei korrekter Nutzung von Schweregraden …
Dieser Artikel erläutert die Schweregrade von Vorfällen, deren Anwendung und den Unterschied zu Prioritätsstufen.
Splunk IT Service Intelligence (ITSI) ist eine AIOps-, Analyse- und IT-Management-Lösung, die Teams dabei unterstützt, Vorfälle vorherzusagen, bevor sie sich auf Kunden auswirken.
Unter Einsatz von KI und maschinellem Lernen korreliert ITSI Daten aus Überwachungsquellen und liefert eine einheitliche Echtzeitansicht relevanter IT- und Geschäftsdienste, reduziert die Alarmmenge und verhindert proaktiv Ausfälle.
Schweregrade zählen zu den zentralen Bestandteilen des Vorfallmanagements und messen die akuten Auswirkungen eines Ereignisses auf das Unternehmen. Ob interne Probleme wie Geräte- oder Software-Ausfälle oder externe wie Sicherheitsverletzungen oder Lieferantenausfälle: Jeder Zwischenfall beeinträchtigt die Fähigkeit, Kunden zu bedienen. Der Schweregrad spiegelt diese Auswirkung wider.
(Mit diesen SIEM-Funktionen lassen sich Sicherheitsvorfälle besser handhaben.)
Je nach Organisation bestehen die Schweregrade normalerweise aus drei, vier oder fünf Abstufungen. Dabei markiert eins bzw. SEV 1 den höchsten und die höchste Zahl (3, 4 oder 5) den niedrigsten Schweregrad.
Eine allgemeingültige Definition für Schweregrade gibt es nicht. Die Definition richtet sich nach den Prioritäten der Organisation und ihrer Nutzer. Manchen Firmen reichen drei Stufen völlig aus. Für andere eignen sich hingegen fünf Abstufungen besser. Es folgen die Definitionen für fünf Stufen:
Beschreibung der Schweregrade | |
SEV 1 | Ein kritischer Vorfall, der viele Nutzer in der Produktion betrifft. |
SEV 2 | Ein erhebliches Problem, das eine begrenzte Nutzeranzahl im Produktivbetrieb betrifft. |
SEV 3 | Ein Vorfall, der Fehler, kleinere Nutzerprobleme oder eine hohe Systemlast verursacht. |
SEV 4 | Ein kleineres Problem, das den Dienst beeinträchtigt, aber keinen ernsthaften Einfluss auf die User hat. |
SEV 5 | Ein geringfügiger Mangel, der kleine Probleme verursacht. |
Beim Auftreten eines Zwischenfalls müssen Teams wissen:
Bei einem Ausfall, der alle User betrifft, lautet eine typische Reaktion: „Alle Mann an Deck!“ Doch wenn sich alle auf ein einzelnes Problem konzentrieren, ist das unproduktiv. Dies ist meistens kontraproduktiv und führt zu doppelter Arbeit, Verwirrung und sogar zu widersprüchlichen Maßnahmen. Die Definition eines Schweregrads mit den zugehörigen Prozessen ermöglicht eine bessere Reaktion. (Noch besser: Benennt einen „Einsatzleiter“, damit von Anfang an klar ist, wer die Entscheidungen trifft.)
Die Definition von Schweregraden gehört auf jeden Fall in euren Incident-Management-Plan. Diese Fragen lassen sich meist im Vorfeld klären und sparen dem Team Zeit, da bei der Einstufung eines Vorfalls sofort jeder weiß, was zu tun ist.
(Die Best Practices bei der Untersuchung von Vorfällen findet ihr hier.)
Mithilfe unserer obigen Fragen sehen wir uns nun die möglichen Antworten für einen SEV-1-Vorfall an:
Bei einem SEV-5-Vorfall fallen die Antworten ganz anders aus:
Schweregrade sind eine gemeinsame Referenz für alle, die an der Reaktion auf Vorfälle beteiligt sind. Mit einer zugewiesenen Stufe und klar definierten Verfahren können die zuständigen Teams mit der Problemlösung beginnen. Ohne diese Vorgaben geht Zeit für die Klärung der Vorgehensweise verloren – oder es entstehen neue Probleme.
(Erfahrt, wie Splunk-Lösungen die gesamte Incident-Management-Praxis unterstützen.)
Auf den ersten Blick scheinen Schweregrad und Priorität identisch zu sein. Bei einem SEV-1-Vorfall liegt es nahe, dass dieser vor einem SEV-2-Problem behoben wird. Worin liegt also der Unterschied zwischen Schweregrad und Priorität?
Priorität und Schweregrad stimmen oft perfekt überein. Ein Ausfall, der alle User an der Nutzung eines Dienstes hindert, hat sowohl hohe Priorität als auch SEV 1. Dieses Beispiel zeigt die Übereinstimmung technischer Probleme mit geschäftlichen Prioritäten.Manchmal stimmen diese Prioritäten jedoch nicht überein:
Auch wenn diese unterschiedlichen Einstufungen im Widerspruch stehen können, sind beide wichtige Kommunikationsmittel. Der Schweregrad zeigt den Beteiligten, wie ernsthaft ein Problem ist. Die Priorität weist dem Technikteam die nächste Aufgabe zu.
(Verfolgt weitere Incident-Respone-Metriken.)
Die Schweregrade von Vorfällen sind ein einfaches Konzept. Einfach bedeutet jedoch leider nicht leicht umzusetzen. Ihr könnt sie nicht aus einem Blogbeitrag oder einem Whitepaper kopieren und sofort anwenden. Ihr müsst sie an eure Organisation anpassen und dabei mehrere Faktoren berücksichtigen, zum Beispiel:
Diese Best Practices helfen Organisationen dennoch bei der Definition und Einhaltung von Schweregradstufen für Vorfälle.
Best Practice: Führt unternehmensweit einheitliche Stufen und Beschreibungen ein.
Die Verwendung verschiedener Schweregradstufen für unterschiedliche Anwendungen oder Software-Stacks erscheint besonders in großen Organisationen sinnvoll. Dies erschwert jedoch einen der größten Vorteile der Schweregradstufen: die klare Kommunikation bei Zwischenfällen. Unterschiedliche Stufen oder Definitionen erschweren den Beteiligten das Verständnis eines Vorfalls. Dies kann sogar Ingenieure und Entwickler verwirren, die an verschiedenen Anwendungen arbeiten.
Best Practice: Verwendet so wenige Schweregradstufen wie möglich. Nicht mehr und nicht weniger.
Zu viele Stufen führen schnell zu Verwirrung. Schweregradstufen existieren unter anderem, damit bei einem Vorfall sofort eine Einstufung erfolgen und die Arbeit beginnen kann. Zu viele Stufen verlangsamen diesen Prozess. Zu wenige Stufen führen zur Vermischung unterschiedlicher Vorfälle. Feine (oder auch deutlichere) Unterschiede zwischen Vorfällen verschwinden, wenn sie in die gleiche Schublade gezwängt werden.
Wie findet ihr die richtige Balance? Setzt euch zusammen und entwickelt mit allen Beteiligten einen Plan. Geht vergangene Vorfälle durch und prüft, ob und wie sie in den vorgeschlagenen Rahmen passen Analysiert die bisherige Ursachenforschung. Probiert es aus und schreckt nicht vor Anpassungen zurück.
Best Practice: Vereinfacht die Zuweisung von Schweregradstufen
Ohne schnelle Zuweisung der korrekten Schweregradstufe entgehen eurer Firma die Vorteile des Systems. Die Regeln für die Zuweisung müssen nicht nur einfach, sondern selbsterklärend sein. Diskussionen über den Schweregrad eines Vorfalls kosten wertvolle Zeit.
Nach der erfolgten Einstufung beginnt die Arbeit.Erstellt also Regeln, die auf messbaren Auswirkungen basieren, etwa:
Nach dieser Einführung versteht ihr die Schweregradstufen und deren Anwendung. Bei diesen Schweregraden handelt es sich um Kommunikationsmittel, mit denen ihr die Auswirkungen eines Problems mitteilen und schnell die richtigen Teams mit der Lösung des Problems beauftragen könnt. Schweregrad und Priorität von Vorfällen hängen zwar zusammen, unterscheiden sich aber grundlegend.
(Aktuelle Sicherheitsthemen findet ihr auf Cybersecurity- und InfoSec-Konferenzen.)
Ihr habt einen Fehler entdeckt oder eine Anregung? Bitte lasst es uns wissen und schreibt eine E-Mail an ssg-blogs@splunk.com.
Dieser Beitrag spiegelt nicht zwingend die Position, Strategie oder Meinung von Splunk wider.
Weltweit führende Unternehmen verlassen sich auf Splunk, ein Cisco-Unternehmen, um mit unserer Plattform für einheitliche Sicherheit und Observability, die auf branchenführender KI basiert, kontinuierlich ihre digitale Resilienz zu stärken.
Unsere Kunden vertrauen auf die preisgekrönten Security- und Observability-Lösungen von Splunk, um ihre komplexen digitalen Umgebungen ungeachtet ihrer Größenordnung zuverlässig zu sichern und verbessern.