Agentic SOC Summit: Der neue Standard für autonome Abwehr Anmelden

Der umfassende Leitfaden zu Next‑Gen SIEM

Erfahren Sie, wie Sie Ihr SOC mit SIEM-Lösungen der nächsten Generation modernisieren. Entdecken Sie die wichtigsten Funktionen und Vorteile des fortschrittlichen Sicherheitsinformations- und Ereignismanagements.

Laden Sie den Leitfaden jetzt herunter

Der umfassende Leitfaden zu Next‑Gen SIEM

Erfahren Sie, wie Sie Ihr SOC mit SIEM-Lösungen der nächsten Generation modernisieren. Entdecken Sie die wichtigsten Funktionen und Vorteile des fortschrittlichen Sicherheitsinformations- und Ereignismanagements.

Laden Sie den Leitfaden jetzt herunter

Definition von MTTR

Mean Time to Repair (mittlere Reparaturzeit, MTTR) ist eine wichtige Kennzahl und gibt an, wie lange die Wiederherstellung der Funktionsfähigkeit eines Systems nach einem Vorfall im Durchschnitt dauert. Die MTTR wird neben anderen Vorfallkennzahlen genutzt, um die Leistung der DevOps- und ITOps-Teams zu bewerten, die Effektivität von Sicherheitsprozessen und Sicherheitslösungen zu beurteilen sowie die Wartungsfreundlichkeit von Systemen einzuschätzen.

Service Level Agreements (SLAs) mit Drittanbietern enthalten meist Vorgaben für die MTTR, die jedoch nicht garantiert werden, da sich die Zwischenfälle in ihrer Komplexität unterscheiden. Gleichermaßen ist es nicht sinnvoll, die MTTRs verschiedener Unternehmen zu vergleichen, da die mittlere Reparaturzeit im hohen Maße von individuellen Faktoren wie Größe und Art der Infrastruktur sowie Umfang und Kompetenz der IT- und DevOps-Teams abhängt. Jedes Unternehmen muss selbst entscheiden, welche Metriken für seine Zwecke am besten geeignet sind, und wie diese in der eigenen Umgebung eingesetzt werden.

Unterschiede zwischen gängigen Fehlermetriken

Moderne Unternehmenssysteme sind äußerst komplex und Fehler können auf vielfältige Art und Weise auftreten. Deshalb gibt es keine Vorfallmetriken, die sich für alle Unternehmen gleichermaßen eignen. Es gibt jedoch eine große Auswahl von Metriken, die sich mitunter nur im Detail voneinander unterscheiden.

Mean Time to Detect (mittlere Erkennungszeit, MTTD)

Die mittlere Erkennungszeit ist die durchschnittliche Zeit zwischen dem Einsetzen eines Systemfehlers und dessen Erkennung. Die MTTD wird als wichtiger Leistungsindikator genutzt, der die Effektivität der vom DevOps-Team genutzten Tools und Prozesse bewertet.

Zur Berechnung der MTTD wird ein Zeitraum gewählt (z. B. ein Monat), in dem die Zeit zwischen dem Einsetzen von Systemausfällen und deren Erkennung gemessen wird. Um den Durchschnitt zu erhalten, wird die Gesamtzeit durch die Anzahl der Zwischenfälle geteilt. Die MTTD sollte möglichst niedrig sein. Wenn der Zeitraum bis zur Erkennung von Systemausfällen allmählich immer länger wird, sollten die vorhandenen Verwaltungstools und Prozesse zur Incident Response sofort einer Überprüfung unterzogen werden.

Mean Time to Identify (mittlere Identifizierungszeit, MTTI)

Diese Metrik misst die Zahl der Geschäftsstunden zwischen dem Auslösen einer Warnung und dem Zeitpunkt, an dem das Cybersicherheitsteam mit der Untersuchung der Warnung beginnt. Die MTTI gibt einen Überblick darüber, ob Warnsysteme wirksam sind und ob das Cybersicherheitsteam mit genügend Personal ausgestattet ist. Wenn der MTTI-Wert hoch ist oder sich in die falsche Richtung entwickelt, leidet das Cybersicherheitsteam möglicherweise unter Informationsüberlastung.

Mean Time to Recovery (mittlere Wiederherstellungszeit, MTTR)

Die mittlere Wiederherstellungszeit gibt an, wie viele Geschäftsstunden im Durchschnitt zwischen dem Beginn eines Vorfalls und der vollständigen Wiederherstellung der Geschäftsabläufe vergehen. Die Vorfallmetrik gibt Aufschluss über die Effektivität der DevOps- und ITOps-Teams und zeigt Optimierungsmöglichkeiten für Prozesse und Funktionen auf.

Mean Time to Resolve (mittlere Behebungszeit, MTTR)

Die mittlere Behebungszeit gibt an, wie viel Zeit im Mittel zwischen der ersten Warnung bis zur Analyse nach dem Vorfall vergeht – inklusive der Zeit, die aufgewendet wird, um sicherzustellen, dass der Fehler nicht erneut auftritt. Die MTTR wird in Geschäftsstunden gemessen.

Mean Time between Failures (mittlere Betriebsdauer zwischen Ausfällen, MTBF)

Die mittlere Betriebsdauer zwischen Ausfällen ist eine wichtige Leistungsmetrik, die die Zuverlässigkeit und Verfügbarkeit von Systemen misst. IT-Teams nutzen sie, um herauszufinden, welche Systeme oder Komponenten gut funktionieren und welche eventuell repariert oder ausgetauscht werden müssen. Die MTBF ermöglicht ihnen, vorbeugende Wartungsmaßnahmen durchzuführen und die Gesamtzahl der Ausfälle zu reduzieren. Außerdem können sie ihre Arbeit damit besser priorisieren und anhand historischer MTBF-Daten wartungsbedingte Ausfälle sowie Ressourcenzuweisungen besser planen.

Die MTBF ergibt sich aus dem Durchschnitt der Stunden, die zwischen Systemausfällen während des normalen Betriebs in einem bestimmten Zeitraum vergehen.

Mean Time to Failure (mittlere Dauer bis zum Ausfall, MTTF)

Die mittlere Betriebsdauer bis zum Ausfall gibt die Betriebsdauer im Vergleich zu Ausfällen an. Im Gegensatz zur MTBF, die auf die Reparaturfähigkeit ausgerichtet ist, geht es bei der MTTF um Ausfälle, die nicht repariert werden können. Sie wird genutzt, um die Lebensdauer von Systemen vorherzusagen. Die MTTF eignet sich jedoch nicht für jedes System. So sind beispielsweise Systeme mit langen Lebensdauern (z. B. zentrale Systeme von Banken oder viele industrielle Kontrollsysteme) für MTTF-Metriken ungeeignet, da sie eine derart lange Lebensdauer haben, dass sie aufgrund des technischen Fortschritts am Ende durch ein völlig anderes System ersetzt werden. In solchen Fällen ist die Erhebung der mittleren Betriebsdauer bis zum Ausfall überflüssig.

Im Gegenzug dazu stellt sie bei Systemen mit üblicheren Lebensspannen eine gute Methode dar, um herauszufinden, welche Marken am besten abschneiden und welche Umgebungsfaktoren die Lebensdauer eines Produkts am stärksten beeinflussen.

Vorteile der MTTR für DevOps- und ITOps-Teams

Die MTTR soll die Zahl ungeplanter Ausfälle verringern und die Breakout-Time verkürzen. Sie eignet sich jedoch auch, um die Kultur innerhalb des IT-Teams zu verbessern.

Wenn DevOps- und IT-Teams Zwischenfälle beheben können, bevor die Benutzer dadurch beeinträchtigt werden, werden sie als effizient und effektiv wahrgenommen. Dies fördert einen resilienten Systemaufbau, denn wenn das DevOps-Team weiß, dass seine Leistung an der MTTR gemessen wird, entwickelt es Anwendungen, die schneller repariert werden können. Dies sind beispielsweise Anwendungen, die mit separaten Web-Services ausgestattet werden, sodass der Ausfall eines einzelnen Services nicht zum Ausfall der gesamten Anwendung führt. Wird die MTTR richtig umgesetzt, berücksichtigt sie auch die Analyse nach einem Vorfall, die mittels einer Feedback-Schleife dazu genutzt werden sollte, künftige Software-Builds zu verbessern und Anreize für die frühzeitige Behebung von Fehlern im Software-Entwicklungsprozess zu setzen.

Berechnen der mittleren Reparaturzeit

Die Formel zur Berechnung der MTTR ist recht simpel: Addieren Sie einfach den gesamten Zeitaufwand für ungeplante Reparaturen, die in einem bestimmten Zeitraum für ein System anfielen, und teilen Sie das Ergebnis durch die Gesamtanzahl der relevanten Vorfälle.

Weitere Informationen

Wenn beispielsweise ein System vier Mal am Tag ausfällt und Sie für die Reparatur der einzelnen Ausfälle eine Stunde benötigen, würde die MTTR 15 Minuten betragen (60 Minuten / 4 = 15 Minuten).

Doch nicht alle Ausfälle sind gleichwertig. Die Zeit für die Reparatur einer defekten Komponente oder eines kundenseitigen Systems, das zu Spitzenzeiten ausfällt, ist in Bezug auf Umsatzeinbußen, Produktivität oder Markenschäden kostspieliger als die Reparaturzeit für einen unkritischen Ausfall mitten in der Nacht. Mit einem „Fehler-Budget“ können Unternehmen festlegen, dass jede Minute, die für die Reparatur der wichtigsten Systeme aufgewendet wird, genauso viel wert ist wie eine Stunde für die Reparatur sekundärer Systeme. Anhand dieser Unterscheidung lassen sich die wahren Kosten von Ausfällen besser ablesen und es wird klarer, welche Bedeutung die MTTR für das einzelne Unternehmen hat.

Reduzieren der MTTR

Zur Reduzierung der MTTR müssen drei Elemente zusammenkommen.

  1. Das erste ist eine klare Strategie für den Behebungsprozess, der auch eine Analyse nach dem Vorfall enthalten sollte, um die gewonnenen Erkenntnisse zusammenzutragen.
  2. Technologie spielt selbstverständlich eine unverzichtbare Rolle. Daher sollte eine gute Lösung Transparenz, Überwachung und korrigierende Wartungsmaßnahmen bieten, um Probleme zu beseitigen und Abwehrmaßnahmen für künftige Angriffe einzurichten.
  3. Und schließlich müssen auch die Fähigkeiten zur Verfügung stehen, mit denen ein Vorfall behoben werden kann.

Die MTTR kann durch ein höheres Budget oder durch mehr Personal reduziert werden, doch das ist nicht immer realistisch. Stattdessen sollte der Reparaturprozess so weit wie möglich mithilfe von künstlicher Intelligenz (KI) und Machine Learning (ML) automatisiert werden. Dazu gehören Maßnahmen wie schnelle Erkennung, Minimierung von falsch positiven Erkennungen, intelligente Eskalation und automatisierte Behebungsmaßnahmen, um mithilfe von Workflows die MTTR zu verringern.

Es kann sinnvoll sein, sich an der MTTR zu orientieren, um Ausfälle zu minimieren und die DevOps- und IT-Teams zu optimieren. Dies sollte jedoch nicht das endgültige Ziel sein. Schließlich sind Metriken nicht dazu gedacht, einfach Zahlen zu verbessern. Vielmehr sollen sie dazu beitragen, die Systeme ganz praktisch am Laufen zu halten sowie das Unternehmen und seine Kunden zu schützen. Nutzen Sie die MTTR in einer Form, die Ihren Mitarbeitern hilft, die Kunden zu schützen und die Systembetriebszeit zu optimieren.

So verbessern Sie die MTTR mit einer modernen Protokollmanagementlösung

Stärken Sie Ihre Cybersicherheit mit der CrowdStrike Falcon®-Plattform, der führenden KI-nativen Plattform für SIEM und Protokollmanagement. Sie erleben Sicherheitsprotokollierung im Petabyte-Bereich und haben die Wahl zwischen cloudnativer oder selbst gehosteter Bereitstellung. Protokollieren Sie Ihre Daten mit einer leistungsstarken, indexfreien Architektur ohne Engpässe – so sind Bedrohungssuchen mit einer Datenerfassung von über 1 PB pro Tag möglich. Dank Echtzeitsuchfunktionen sind Sie Angreifern einen Schritt voraus und erzielen bei komplexen Abfragen Latenzen von unter einer Sekunde. Sie profitieren von umfassender Transparenz, können Daten konsolidieren, um Silos aufzubrechen, und ermöglichen Ihren Sicherheits-, IT- und DevOps-Teams, Bedrohungen zu erkennen, die Leistung zu überwachen und nahtlose Compliance zu gewährleisten – bei drei Milliarden Ereignissen in weniger als einer Sekunde.

Arfan Sharif ist Product Marketing Lead für das Observability-Portfolio bei CrowdStrike. Er verfügt über mehr als 15 Jahre Erfahrung bei der Umsetzung von Lösungen für Log-Management, ITOps, Beobachtbarkeit, Sicherheit und Benutzerunterstützung für Unternehmen wie Splunk, Genesys und Quest Software. Arfan Sharif hat einen Abschluss in Informatik bei der Buckinghamshire New University und blickt auf eine Karriere in den Bereichen Produktmarketing und Sales Engineering zurück.