Warum die mittlere Reparaturzeit nicht immer eine nützliche Sicherheitsmetrik ist

Sicherheitsteams haben traditionell verwendet mittlere Reparaturzeit (MTTR), um zu messen, wie effektiv sie mit Sicherheitsvorfällen umgehen. Unterschiede in der Schwere des Vorfalls, der Teamagilität und der Systemkomplexität können diese Sicherheitsmetrik jedoch weniger nützlich machen, sagt Courtney Nash, Lead Research Analyst bei Verica und Hauptautorin des Open Incident Database (VOID)-Bericht.

MTTR stammt ursprünglich aus Fertigungsunternehmen und war ein Maß für die durchschnittliche Zeit, die für die Reparatur einer ausgefallenen physischen Komponente oder eines Geräts erforderlich war. Diese Geräte hatten einen einfacheren, vorhersehbaren Betrieb mit Verschleiß, der sich für einigermaßen standardmäßige und konsistente Schätzungen der MTTR eignete. Im Laufe der Zeit hat sich die Verwendung von MTTR auf Softwaresysteme ausgeweitet, und Softwareunternehmen begannen, es als Indikator für Systemzuverlässigkeit und Teamagilität oder -effektivität zu verwenden.

Leider, sagt Nash, bedeutet seine Variabilität, dass MTTR entweder zu falschem Vertrauen führen oder unnötige Bedenken hervorrufen könnte.

„Es ist keine geeignete Metrik für komplexe Softwaresysteme, zum Teil wegen der schiefen Verteilung der Dauerdaten und weil Ausfälle in solchen Systemen nicht gleichmäßig über die Zeit auftreten“, sagt Nash. „Jeder Fehler ist von Natur aus anders, im Gegensatz zu Problemen mit physischen Fertigungsgeräten.“

Weg von der MTTR

„[MTTR] sagt uns wenig darüber aus, wie ein Vorfall wirklich für die Organisation ist, was stark variieren kann in Bezug auf die Anzahl der beteiligten Personen und Teams, das Stressniveau, was technisch und organisatorisch erforderlich ist, um ihn zu beheben, und was das Team hat daraus gelernt“, sagt Nash.

MTTR fällt der übermäßigen Vereinfachung von Vorfällen zum Opfer, weil es einen Durchschnitt berechnet – die durchschnittliche Zeit, sagt Nora Jones, CEO und Mitbegründerin von Jeli. Das einfache Messen dieses einzelnen Durchschnitts der gemeldeten Zeiten (und diese gemeldeten Zeiten haben sich auch von vornherein als nicht zuverlässig erwiesen) hindert Organisationen daran, zu sehen und zu beheben, was in der Infrastruktur vor sich geht, was zu diesem wiederkehrenden Vorfall beiträgt und wie es den Menschen geht auf Vorfälle reagieren.

„Incidents treten in allen Formen und Größen auf – Sie werden sehen, dass sie das gesamte Spektrum an Schweregrad, Auswirkungen auf Kunden und Lösungskomplexität innerhalb einer Organisation abdecken“, erklärt Jones. „Man muss wirklich die Menschen und Tools gemeinsam betrachten und einen qualitativen Ansatz für die Analyse von Vorfällen verfolgen.“

Nash sagt jedoch, dass die Abkehr von der MTTR keine Umstellung über Nacht ist – es ist nicht so einfach, nur eine Metrik gegen eine andere auszutauschen.

„Am Ende des Tages geht es darum, ehrlich zu den Faktoren zu sein, die dazu beitragen, und die Rolle, die Menschen bei der Entwicklung von Lösungen spielen“, sagt sie. „Es klingt einfach, aber es braucht Zeit, und das sind die konkreten Aktivitäten, die bessere Metriken aufbauen werden.“

Ausweitung der Verwendung von Metriken

sagt Nash Analysieren und Lernen aus Vorfällen ist der ideale Weg, um aufschlussreichere Daten und Metriken zu finden. Ein Team kann Dinge wie die Anzahl der an einem Vorfall beteiligten Personen erfassen; wie viele einzigartige Teams beteiligt waren; welche Werkzeuge benutzt wurden; wie viele Chatkanäle es gab; und wenn es gleichzeitige Vorfälle gab.

Wenn eine Organisation besser im Dirigieren wird Vorfallberichte und von ihnen zu lernen, werden Dinge wie die Anzahl der Personen, die an Post-Incident-Review-Meetings teilnehmen, das vermehrte Lesen und Teilen von Post-Incident-Berichten und die Verwendung dieser Berichte in Dingen wie Code-Reviews, Schulungen und Onboarding von Bedeutung sein.

David Severski, Senior Security Data Scientist am Cyentia Institute, sagt, dass Cyentia bei der Arbeit an Verizon DBIR das Vocabulary for Event Reporting and Incident Sharing erstellt und veröffentlicht hat, um die Arten von Metriken zu erweitern, die zur Messung eines Vorfalls verwendet werden.

„Es definiert Datenpunkte, die wir bei Sicherheitsvorfällen für wichtig halten“, sagt er. „Wir verwenden diese grundlegende Vorlage in der Cyentia-Forschung immer noch mit einigen Aktualisierungen, zum Beispiel zur Identifizierung der verwendeten ATT&CK-TTPs.“

Die Metriken zur Messung eines Vorfalls sind keine Einheitsgröße für alle Größen und Arten von Organisationen. „Teams verstehen, wo sie heute stehen, bewerten, wo ihre Prioritäten innerhalb ihrer aktuellen Einschränkungen liegen, und verstehen, dass sich ihre Fokusmetriken im Laufe der Zeit sogar weiterentwickeln können, wenn sich ihre Organisation entwickelt und skaliert“, sagt Jones.

Darüber hinaus geht es darum, den Fokus auf Erkenntnisse zu verlagern und sich dann basierend auf diesen Erkenntnissen kontinuierlich zu verbessern, z. B. auf die Bewertung von Trends zu verlagern und festzustellen, ob sich die Dinge im Laufe der Zeit in die richtige Richtung entwickeln, im Gegensatz zu Einzelmesswerten zu einem bestimmten Zeitpunkt.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.darkreading.com/edge-articles/why-mean-time-to-repair-no-longer-serves-as-a-useful-security-metric