Por qué el tiempo medio de reparación no siempre es una métrica de seguridad útil

Por que el tiempo medio de reparacion no siempre es

Los equipos de seguridad han utilizado tradicionalmente tiempo estimado o promedio para reparar (MTTR) como una forma de medir la eficacia con la que manejan los incidentes de seguridad. Sin embargo, las variaciones en la gravedad de los incidentes, la agilidad del equipo y la complejidad del sistema pueden hacer que la métrica de seguridad sea menos útil, dice Courtney Nash, analista de investigación principal de Verica y autora principal del informe Open Incident Database (VOID).

MTTR se originó en las organizaciones de fabricación y era una medida del tiempo promedio requerido para reparar un componente o dispositivo físico defectuoso. Estos dispositivos tenían operaciones más simples y predecibles con desgaste que se prestaban a estimaciones razonablemente estándar y consistentes de MTTR. Con el tiempo, el uso de MTTR se ha expandido a los sistemas de software y las empresas de software comenzaron a usarlo como un indicador de la confiabilidad del sistema y la agilidad o eficacia del equipo.

Desafortunadamente, dice Nash, su variabilidad significa que MTTR podría generar una confianza falsa o causar una preocupación innecesaria.

«No es una métrica apropiada para sistemas de software complejos, en parte debido a la distribución sesgada de los datos de duración y porque las fallas en dichos sistemas no llegan uniformemente con el tiempo», dice Nash. «Cada falla es intrínsecamente diferente, a diferencia de los problemas con los dispositivos de fabricación física».

Alejarse del MTTR

«[MTTR] nos dice poco sobre cómo es realmente un incidente para la organización, que puede variar enormemente en términos de la cantidad de personas y equipos involucrados, el nivel de estrés, lo que se necesita técnica y organizacionalmente para solucionarlo, y lo que el equipo aprendió como resultado. un resultado», dice Nash.

MTTR es víctima de la simplificación excesiva de los incidentes porque calcula un promedio: el tiempo promedio, dice Nora Jones, directora ejecutiva y cofundadora de Jeli. La simple medición de este promedio único de tiempos informados (y se ha demostrado que esos tiempos informados no son confiables en primer lugar) impide que las organizaciones vean y aborden lo que sucede dentro de la infraestructura, lo que contribuye a ese incidente recurrente y cómo las personas están respondiendo a incidentes.

«Los incidentes vienen en todas las formas y tamaños; verá que abarcan el rango completo en gravedad, impacto para los clientes y complejidad de resolución, todo dentro de una organización», explica Jones. «Realmente tienes que mirar a las personas y las herramientas juntas y adoptar un enfoque cualitativo para el análisis de incidentes».

Sin embargo, Nash dice que alejarse del MTTR no es un cambio de la noche a la mañana, no es tan simple como cambiar una métrica por otra.

«Al final del día, se trata de ser honesto acerca de los factores contribuyentes y el papel que desempeñan las personas en la búsqueda de soluciones», dice ella. «Suena simple, pero lleva tiempo, y estas son las actividades concretas que generarán mejores métricas».

Ampliación del uso de métricas

Nash dice que analizar y aprender de los incidentes es el camino ideal para encontrar datos y métricas más perspicaces. Un equipo puede recopilar cosas como la cantidad de personas involucradas en un incidente; cuántos equipos únicos participaron; qué herramientas usaba la gente; cuántos canales de chat había; y si hubo incidentes concurrentes.

A medida que una organización mejora en la realización de revisiones de incidentes y aprende de ellas, comenzará a ver tracción en cosas como la cantidad de personas que asisten a las reuniones de revisión posteriores al incidente, el aumento de la lectura y el intercambio de informes posteriores al incidente y el uso de esos informes en cosas como revisiones de código, capacitación e incorporación.

David Severski, científico sénior de datos de seguridad en el Instituto Cyentia, dice que cuando trabajaba en Verizon DBIR, Cyentia creó y lanzó el Vocabulario para informes de eventos e intercambio de incidentes para expandir los tipos de métricas utilizadas para medir un incidente.

«Define puntos de datos que creemos que es importante recopilar sobre incidentes de seguridad», dice. «Todavía usamos esta plantilla básica en la investigación de Cyentia con algunas actualizaciones, por ejemplo, identificando los TTP de ATT&CK utilizados».

Las métricas para medir un incidente no son únicas para todos los tamaños y tipos de organizaciones. «Los equipos entienden dónde están hoy, evalúan dónde están sus prioridades dentro de sus limitaciones actuales y comprenden que sus métricas de enfoque podrían incluso evolucionar con el tiempo a medida que su organización se desarrolla y escala», dice Jones.

Además, se trata de cambiar el enfoque a los aprendizajes y luego mejorar continuamente en función de esos aprendizajes, por ejemplo, cambiar a evaluar tendencias y si las cosas van en la dirección correcta a lo largo del tiempo, a diferencia de las métricas de un solo punto en el tiempo.

Fuente del artículo

Deja un comentario