Agentic SOC Summit: o novo padrão para defesa autônomaInscreva-se

O guia completo do SIEM de última geração

Saiba como modernizar seu Centro de Operações de Segurança (SOC, na sigla em inglês) com soluções de SIEM de última geração. Conheça as principais funcionalidades e benefícios do gerenciamento e correlação de eventos de segurança (SIEM) avançado.

Faça o download do guia agora

O guia completo do SIEM de última geração

Saiba como modernizar seu Centro de Operações de Segurança (SOC, na sigla em inglês) com soluções de SIEM de última geração. Conheça as principais funcionalidades e benefícios do gerenciamento e correlação de eventos de segurança (SIEM) avançado.

Faça o download do guia agora

MTTR: definição

Tempo médio para reparo (MTTR) é um indicador-chave de desempenho (KPI) que representa o tempo médio necessário para restaurar a funcionalidade de um sistema após um incidente. O MTTR é usado junto com outras métricas de incidentes para avaliar o desempenho de DevOps e ITOps, medir a eficácia de processos de segurança, avaliar a efetividade das soluções de segurança e mensurar a capacidade de manutenção de sistemas.

Os acordos de nível de serviço com provedores terceirizados geralmente estabelecem as expectativas de MTTR. No entanto, os tempos de reparo não são garantidos, uma vez que alguns incidentes são mais complexos do que outros. Nessa mesma linha, comparar o MTTR de diferentes organizações não é algo útil, pois o MTTR depende altamente de fatores exclusivos relacionados ao tamanho e ao tipo de infraestrutura e ao tamanho e à capacitação das equipes de ITOps e DevOps. Cada empresa precisa determinar quais métricas atenderão melhor aos seus propósitos e como colocá-las em ação em seu próprio ambiente.

Diferença entre métricas de falha comuns

Os modernos sistemas empresariais são complexos e podem falhar de diversas maneiras. Por esses motivos, não existe um conjunto de métricas de incidentes único que deva ser usado por todas as empresas — mas existem muitas opções, e as diferenças entre elas podem ser sutis.

Tempo médio para detecção (MTTD)

Também chamado de tempo médio para descoberta, o MTTD é o tempo médio entre o início de uma falha do sistema e sua detecção. Como KPI, o MTTD é usado para medir a eficácia das ferramentas e dos processos adotados pelas equipes de DevOps.

Para calcular o MTTP, selecione um período, como um mês, e rastreie os tempos decorridos entre o início de quedas dos sistemas e sua descoberta; em seguida, para encontrar a média, some o tempo total e divida esse valor pelo número de incidentes. O MTTD deve ser baixo. Caso a detecção ou a descoberta de falhas do sistema continue demorando (isto é, uma tendência crescente), é necessária uma revisão imediata das ferramentas e dos processos existentes de gerenciamento de resposta a incidentes (IR).

Tempo médio para identificação (MTTI)

Essa medida acompanha o número de horas úteis decorridas entre o momento em que um alerta é acionado e o momento em que a equipe de cibersegurança começa a investigar esse alerta. O MTTI mostra se os sistemas de alerta são eficazes e se as equipes de cibersegurança têm membros suficientes para atender à demanda. Um MTTI alto ou um MTTI que apresenta uma tendência na direção correta pode ser um indicador de que a equipe de cibersegurança está sofrendo de fadiga de alertas.

Tempo médio para recuperação (MTTR)

O tempo médio para recuperação é o tempo médio, medido em horas úteis, entre o início de um incidente e a recuperação completa das operações normais. Esta métrica de incidente representa a eficácia das equipes de DevOps e ITOps e identifica oportunidades de melhorar seus processos e capacidades.

Tempo médio para resolução (MTTR)

O tempo médio para resolução é o tempo médio decorrido entre o primeiro alerta e a análise pós-incidente, incluindo o tempo gasto para garantir que a falha não se repetirá. Esse tempo é medido em horas úteis.

Tempo médio entre falhas (MTBF)

O tempo médio entre falhas é uma importante métrica de desempenho que mede a confiabilidade e a disponibilidade do sistema. As equipes de ITOps usam o MTBF para compreender quais sistemas ou componentes apresentam um bom desempenho e quais precisam ser avaliados para reparo ou substituição. Conhecer o MTBF favorece a manutenção preventiva, minimiza a manutenção reativa, reduz o tempo de inatividade total e permite que as equipes priorizem efetivamente a workload. É possível usar dados históricos de MTBF para tomar decisões melhores sobre agendamento do tempo de inatividade de manutenção e alocação de recursos.

O MTBF é calculado como o número de horas decorridas entre as falhas do sistema, no andamento normal das operações ao longo de um período.

Tempo médio até a falha (MTTF)

O tempo médio até a falha é uma forma de comparar tempo de atividade x tempo de inatividade. Diferentemente do MTBF, uma métrica que se concentra na capacidade de reparo, o MTTF foca em falhas que não podem ser reparadas. O MTTF é usado para prever a vida útil de sistemas. No entanto, o MTTF não é adequado para todos os sistemas. Por exemplo, sistemas bancários centrais ou vários sistemas de controle industrial não são ideais para as métricas de MTTF porque têm uma vida útil longa. Quando eles são finalmente substituídos, a troca é feita por um tipo de sistema totalmente diferente, devido aos avanços tecnológicos. Em casos assim, o MTTF e irrelevante.

Por outro lado, o monitoramento do MTTF de sistemas com vida útil mais comum é uma boa forma de obter insights sobre quais marcas têm melhor desempenho ou quais fatores ambientais influenciam mais a durabilidade de um produto.

Benefícios do MTTR para DevOps e ITOps

O MTTR visa reduzir o tempo de inatividade não planejado e encurtar o tempo para comprometimento. No entanto, seu uso também aprimora a cultura dentro das equipes de ITOps.

Quando os incidentes são reparados antes que os usuários sejam afetados, as equipes de DevOps e ITOps são consideradas eficientes e eficazes. A recomendação é um design de sistema resiliente. Quando a equipe de DevOps sabe que seu desempenho será medido pelo MTTR, ela cria apps que podem ser reparados com mais rapidez, como aqueles formados por distintos serviços da Web, de forma que a falha de um serviço não cause a queda de todo o app. O MTTR, quando realizado adequadamente, inclui a análise pós-incidente, que deve alimentar um ciclo de feedback que resulta no aprimoramento das futuras compilações de softwares e incentiva a correção de bugs no início do processo de SDLC.

Como calcular o tempo médio para reparo

A fórmula do MTTR é simples: basta somar o tempo total de reparo não planejado gasto em um sistema dentro de um determinado período e dividir o resultado pelo número total de incidentes relevantes.

Saiba mais

Por exemplo, se um sistema falha quatro vezes em um dia útil e você gasta uma hora reparando esse sistema em cada uma dessas instâncias de falha, seu MTTR seria de 15 minutos (60 minutos / 4 = 15 minutos).

No entanto, nem todas as quedas são iguais. O tempo gasto reparando um componente falho ou um sistema voltado ao cliente que cai durante o horário de pico custa mais caro (em termos de vendas perdidas, prejuízo à produtividade ou danos à marca) do que o tempo gasto reparando uma queda não crítica no meio da noite. As organizações podem definir um "orçamento para erros" que especifica que cada minuto gasto no reparo de sistemas mais impactantes vale uma hora gasta no reparo de sistemas menos impactantes. Esse nível de granularidade ajuda a expor os verdadeiros custos do tempo de inatividade e explica melhor o que significa o MTTR para uma organização específica.

Como reduzir o MTTR

É possível reduzir o MTTR por meio de três elementos.

  1. O primeiro é uma estratégia definida para o gerenciamento do processo de resolução, que deve incluir uma análise pós-incidente para capturar as lições aprendidas.
  2. Evidentemente, a tecnologia desempenha um papel fundamental, e a melhor solução oferecerá visibilidade, monitoramento e manutenção corretiva para ajudar a erradicar problemas e desenvolver defesas contra futuros ataques.
  3. Por fim, é preciso que as habilidades necessárias para mitigar o incidente estejam disponíveis.

É possível reduzir o MTTR com o aumento do orçamento ou da quantidade de funcionários, mas nem sempre isso é viável. Em vez disso, implemente inteligência artificial (IA) e machine learning (ML) para automatizar o máximo possível do processo de reparo. Essas medidas incluem detecção rápida, minimização de falso-positivos, encaminhamento inteligente e remediação automatizada, que inclui fluxos de trabalho capazes de reduzir o MTTR.

O MTTR pode ser uma métrica útil para reduzir o tempo de inatividade e otimizar suas equipes de DevOps e ITOps, mas esse aprimoramento não deve ser o objetivo final. Afinal, o intuito do uso de métricas não é simplesmente melhorar números, mas, neste caso, a questão prática é manter os sistemas em operação e proteger a empresa e seus clientes. Use o MTTR para suas equipes a proteger os clientes e otimizar o tempo de atividade do sistema.

Aprimore o MTTR com uma solução moderna de gerenciamento de log

Eleve sua cibersegurança com a plataforma CrowdStrike Falcon®, a principal plataforma nativa de IA para SIEM e gerenciamento de log. Experimente registro de log de segurança em uma escala de petabytes, optando por nativo em nuvem ou implementação auto-hospedada. Registre seus dados com uma arquitetura avançada e livre de índices, sem gargalos e que permite investigação de ameaças com mais de 1 PB de ingestão de dados por dia. Assegure capacidades de pesquisa em tempo real para superar os adversários, atingindo latência de menos de um segundo para consultas complexas. Aproveite uma visibilidade completa, consolidando os dados para quebrar silos e possibilitar que as equipes de segurança, TI e DevOps investiguem ameaças, monitorem o desempenho e garantam a conformidade perfeitamente em 3 bilhões de eventos e em menos de um segundo.

Arfan Sharif é líder de marketing de produtos para o portfólio de observabilidade na CrowdStrike. Ele tem mais de 15 anos de experiência em gerenciamento de log, ITOps, observabilidade, segurança e soluções de CX para empresas como Splunk, Genesys e Quest Software. Arfan formou-se em Ciência da Computação na Universidade Bucks and Chilterns e sua carreira abrange as áreas de Marketing de Produtos e Engenharia de Vendas.