0
0
As equipes de segurança tradicionalmente usam o tempo médio de reparo (MTTR) como uma forma de medir a eficácia com que lidam com os incidentes de segurança. No entanto, variações na gravidade do incidente, agilidade da equipe e complexidade do sistema podem tornar essa métrica de segurança menos útil, diz Courtney Nash, principal analista de pesquisa da Verica e principal autora do relatório Open Incident Database (VOID).
O MTTR originou-se em organizações de manufatura e era uma medida do tempo médio necessário para reparar um componente ou dispositivo físico com falha. Esses dispositivos tinham operações mais simples e previsíveis com desgaste que se prestavam a estimativas razoavelmente padronizadas e consistentes de MTTR. Com o tempo, o uso do MTTR se expandiu para sistemas de software, e as empresas de software começaram a usá-lo como um indicador de confiabilidade do sistema e agilidade ou eficácia da equipe.
Infelizmente, diz Nash, sua variabilidade significa que o MTTR pode levar a uma falsa confiança ou causar preocupação desnecessária.
“Não é uma métrica apropriada para sistemas de software complexos, em parte devido à distribuição distorcida dos dados de duração e porque as falhas em tais sistemas não chegam uniformemente ao longo do tempo”, diz Nash. “Cada falha é inerentemente diferente, ao contrário dos problemas com dispositivos físicos de fabricação.”
Afastando-se do MTTR
“[MTTR] nos diz pouco sobre como é realmente um incidente para a organização, que pode variar muito em termos de número de pessoas e equipes envolvidas, o nível de estresse, o que é necessário técnica e organizacionalmente para corrigi-lo e o que a equipe aprendeu como resultado”, diz Nash.
O MTTR é vítima da simplificação excessiva dos incidentes porque está calculando uma média – o tempo médio, diz Nora Jones, CEO e cofundadora da Jeli. A simples medição dessa média única de tempos relatados (e esses tempos relatados também não são confiáveis em primeiro lugar) inibe as organizações de ver e abordar o que está acontecendo dentro da infraestrutura, o que está contribuindo para esse incidente recorrente e como as pessoas estão responder a incidentes.
“Os incidentes vêm em todas as formas e tamanhos – você os verá abrangendo toda a gama de gravidade, impacto para os clientes e complexidade de resolução, tudo dentro de uma organização”, explica Jones. “Você realmente precisa observar as pessoas e as ferramentas juntas e adotar uma abordagem qualitativa para a análise de incidentes.”
No entanto, Nash diz que abandonar o MTTR não é uma mudança da noite para o dia – não é tão simples quanto apenas trocar uma métrica por outra.
“No final das contas, é ser honesto sobre os fatores que contribuem e o papel que as pessoas desempenham na busca de soluções”, diz ela. “Parece simples, mas leva tempo, e essas são as atividades concretas que irão construir melhores métricas.”
Ampliando o Uso de Métricas
Nash diz que analisar e aprender com os incidentes é o caminho ideal para encontrar dados e métricas mais perspicazes. Uma equipe pode coletar coisas como o número de pessoas envolvidas em um incidente; quantas equipes únicas foram envolvidas; quais ferramentas as pessoas usaram; quantos canais de chat havia; e se houve incidentes simultâneos.
À medida que uma organização melhora na condução de revisões de incidentes e aprende com eles, ela começa a ver tração em coisas como o número de pessoas que participam de reuniões de revisão pós-incidente, maior leitura e compartilhamento de relatórios pós-incidente e uso desses relatórios em coisas como revisões de código, treinamento e integração.
David Severski, cientista sênior de dados de segurança do Cyentia Institute, diz que, ao trabalhar no Verizon DBIR, a Cyentia criou e lançou o Vocabulário para Relatórios de Eventos e Compartilhamento de Incidentes para expandir os tipos de métricas usadas para medir um incidente.
“Ele define pontos de dados que consideramos importantes para coletar sobre incidentes de segurança”, diz ele. “Ainda usamos esse modelo básico na pesquisa da Cyentia com algumas atualizações, por exemplo, identificando os TTPs ATT&CK utilizados.”
As métricas para medir um incidente não são de tamanho único para todos os tamanhos e tipos de organização. “As equipes entendem onde estão hoje, avaliam onde estão suas prioridades dentro de suas restrições atuais e entendem que suas métricas de foco podem até evoluir com o tempo à medida que sua organização se desenvolve e escala”, diz Jones.
Além disso, trata-se de mudar o foco para aprendizados e, em seguida, melhorar continuamente com base nesses aprendizados, por exemplo, mudar para avaliar tendências e se as coisas estão indo na direção certa ao longo do tempo, em oposição a métricas de ponto único no tempo.
FONTE: DARK READING