Métricas de SOC 2026: MTTD, MTTR e KPIs Que Importam

As métricas de SOC que realmente importam separam um time que detecta ameaças de um que apenas reúne alertas. Em 2025, 73% das organizações apontaram falsos positivos como o maior desafio de detecção, segundo o SANS Institute. Volume de alerta deixou de ser métrica — precisão virou a única que realmente importa.

Pontos-chave antes de continuar

MTTD abaixo de 4 horas e MTTR entre 2 e 4 horas são os benchmarks de equipes maduras.
Taxa de falso positivo por severidade: crítico abaixo de 25%, alto abaixo de 50%.
Cobertura de cerca de 65% no MITRE ATT&CK já gera sinal confiável de detecção.
A capacidade do time deve exceder a carga de trabalho esperada em pelo menos 15%.
Tempo médio de um operador de ransomware para atingir objetivos fica em torno de 24 horas.

Volume de alerta é métrica enganosa

Por anos, painéis de SOC celebraram “alertas gerados” como sinônimo de cobertura. O problema é que cada alerta custa tempo de investigação — e a maioria não representa ameaça real. A pesquisa 2025 SANS Detection & Response Survey mostra que mais de 60% dos times encontram falsos positivos com frequência, e o grupo que os classifica como “muito frequentes” saltou de 13% para 20% em um ano.

Em paralelo, dados consolidados por especialistas indicam que taxas de falso positivo em SOCs corporativos frequentemente ultrapassam 50%, com alguns relatos chegando a 80%. Quando o analista passa mais tempo descartando falsos positivos do que caçando ameaças, duas consequências surgem: ameaças reais se escondem no barulho e o time queima.

O raciocínio é simples: mais alertas não significam mais detecção. Significam mais backlog de investigação, mais oportunidades para movimento lateral passar despercebido e mais rotatividade de analistas. Um SOC maduro mede sinal, não decibéis.

MTTD: da atividade ao alerta

Mean Time to Detect mede o tempo médio entre o início da atividade maliciosa e o momento em que o SOC é alertado. O erro mais comum é calcular a partir do timestamp do alerta — isso mede a latência da ferramenta, não a eficácia da detecção. O cálculo correto, segundo o Prophet Security, é subtrair o “Activity Started At” do “Alerted At” do evento mais antigo do incidente.

Organizações de alto desempenho mantêm MTTD entre 30 minutos e 4 horas. Latência costuma se acumular nos estágios iniciais do ataque — por exemplo, autenticações VPN com credenciais válidas comprometidas, que são difíceis de identificar antes de uma ação mais direta em um endpoint gerenciado. Por isso, revisão pós-incidente de detecção é inegociável: é dela que sai o “Activity Started At” real.

Para reduzir MTTD, invista em cobertura de detecção alinhada a comportamentos comuns (não em cobertura total) e em enriquecimento de alertas com contexto de identidade e endpoint. Sem contexto, o analista perde minutos preciosos abrindo consoles paralelos.

MTTR: do evento ao containment

Mean Time to Respond cobre todo o pipeline operacional: ingestão de telemetria, reconhecimento do alerta, triagem, investigação e containment inicial. O benchmark aceito fica entre 2 e 4 horas considerando todas as severidades, mas o correto é segmentar por criticidade, conforme a tabela abaixo.

Severidade	MTTR alvo	Latência de alerta alvo	Taxa de falso positivo aceitável
Crítico	1 hora	20 minutos	abaixo de 25%
Alto	2 horas	1 hora	abaixo de 50%
Médio	4 horas	2 horas	abaixo de 75%
Baixo	8 horas	6 horas	abaixo de 90%

Fonte dos benchmarks: Prophet Security. Note que a latência de alerta (tempo entre atividade e reconhecimento pelo analista) é tão crítica quanto o MTTR — um alerta crítico esperando 40 minutos na fila já comprometeu boa parte do orçamento de resposta.

Uma observação prática de quem opera: prefira mediana em vez de média para MTTR e MTTI. Medianas resistem melhor a outliers — um único incidente de 72 horas distorce a média mensal e mascara o desempenho real do dia a dia.

Cobertura de detecção no ATT&CK

Detecção eficaz não exige 100% de cobertura do MITRE ATT&CK. O framework lista 194 técnicas ou comportamentos associados a agentes de ameaça antes de exfiltração e impacto. Com uma hipótese conservadora de detectar pelo menos 3 comportamentos por ciclo de vida do atacante, cerca de 127 detecções — ou ~65% de cobertura — já oferecem sinal confiável, segundo análise do Prophet Security.

Isso significa que o esforço de engenharia de detecção deve priorizar comportamentos mais prováveis (segundo inteligência de ameaças real, relatórios de incidentes e tendências observadas), e não perseguir a cauda longa do framework. O custo operacional de manter detecções para técnicas raras consome ciclos do time sem retorno proporcional.

Quando o time está sobrecarregado, os candidatos ideais para supressão são exatamente as detecções com alta taxa de falso positivo que já estão cobertas por outra regra. A cobertura efetiva não cai, mas a capacidade do time sobe.

Capacidade do time versus carga

Um SOC não pode operar no limite o tempo todo. A fórmula prática de capacidade assume um analista com 8 horas de jornada, das quais cerca de 70% (5,6 horas) ficam disponíveis para triagem após reuniões, pausas e tarefas administrativas. Para um time de 5 analistas dedicando 40% do tempo a triagem, a capacidade mensal fica em torno de 224 horas.

A carga esperada é MTTR multiplicado pelo volume de alertas. Se o time leva em média 1,1 hora por alerta e recebe 200 alertas por mês, a carga ideal com buffer de 15% fica próxima de 250 horas. Quando a carga esperada ultrapassa a capacidade, três coisas acontecem, quase sempre juntas: MTTR cresce, falsos negativos aumentam e analistas pedem demissão.

O dado que completa o quadro: segundo o relatório State of the Threat da Secureworks, citado pelo Prophet Security, o tempo mediano para um operador de ransomware atingir seus objetivos é de pouco menos de 24 horas. Se o MTTR do seu SOC ultrapassa esse valor em incidentes críticos, o atacante vence por inanição da sua resposta.

Falso negativo: a métrica escondida

Taxa de falso negativo, ou taxa de erro de investigação, mede com que frequência um analista (ou automação) descarta uma atividade verdadeiramente maliciosa como falso positivo. É notoriamente difícil de medir — afinal, se você pudesse calcular seus erros, não os teria. A prática recomendada é amostragem periódica de alertas fechados como benignos, reanalisados por um analista sênior ou processo de controle de qualidade.

O alvo de operações maduras fica em 1% ou menos de erro. Quando a taxa sobe, os sinais costumam apontar para três causas: documentação de runbooks deficiente, falta de treinamento e fadiga de alerta. Ignorar essa métrica é operar no escuro — o falso negativo é exatamente o tipo de falha que vira manchete semanas depois.

Painel de métricas para o negócio

A pergunta final de qualquer gestor de SOC deveria ser: estas métricas suportam o objetivo do negócio? Muitas equipes ainda reportam volume de alertas processados e se sentem produtivas — mas se o MTTD subiu e a taxa de falso negativo não é medida, o painel está vendendo uma ilusão.

Um conjunto mínimo útil, mensurável em 30 dias, inclui: MTTD e MTTR segmentados por severidade, taxa de falso positivo por severidade, latência de alerta, cobertura de detecção no MITRE ATT&CK, taxa de falso negativo por amostragem e capacidade versus carga esperada. Revisar esses números todo mês, e não a cada trimestre, é o que separa melhoria contínua de reação a incidente.

O SOC que mede certo detecta mais rápido, contém antes e retém analistas. O que mede errado coleta dashboards — e perde ameaças no caminho.