03 - MET.3 - KPIs de Resposta a Incidentes
video: https://youtu.be/... no frontmatter da nota.MET.3 - KPIs de Resposta a Incidentes
Nota do grupo MET (Métricas, KPIs e Medição) da seção 15 do Framework CTH.
Deriva do Capítulo 19 do PDF de referência, controle MET.3, com os subcontroles MET.3.1 a MET.3.5.
Define os indicadores de tempo e qualidade da resposta a incidentes, os mais diretamente ligados ao impacto no negócio, e a medição honesta do dwell time quando a origem do comprometimento é desconhecida.
1. Contexto e Posicionamento no Framework CTH
Os KPIs de resposta a incidentes são as métricas mais fáceis de explicar para a diretoria e as mais difíceis de medir com honestidade. Fáceis de explicar porque traduzem diretamente dano: quanto tempo o invasor ficou dentro e quanto tempo levou para contê-lo. Difíceis de medir porque o relógio mais importante, o do comprometimento inicial, começa a correr sem testemunha, e a única forma de reconstruí-lo é evidência forense e estimativa declarada. O MET.3 trata esses dois problemas com o mesmo rigor: padroniza os pontos de medição para que os números sejam comparáveis e institui regras de estimativa para que a incerteza não contamine a série histórica.
No Framework CTH, o MET.3 é a face de medição do controle IR.5, que estabelece a redução de dwell time como objetivo estratégico do programa. Ele também fecha a esteira completa do Capítulo 20: tudo o que os grupos DAT, DET, HNT, AUT e RES fazem aparece, mais cedo ou mais tarde, como variação de MTTD, MTTR ou tempo de contenção. Por isso a leitura destas métricas nunca é isolada; cada desvio deve ser decomposto em causa de telemetria, causa de detecção, causa de decisão ou causa de capacidade de resposta.
Há também um motivo de governança para medir bem: estes são os indicadores que a diretoria, o comitê de risco e, em muitos setores, o regulador pedem primeiro. Um número de dwell time defendido com método transparente, com janelas de confiança declaradas e segmentação consistente, sustenta decisões de investimento e respostas a auditoria; o mesmo número defendido com data de abertura de ticket travestida de comprometimento desmorona na primeira pergunta técnica e arrasta consigo a credibilidade de todo o painel de segurança.
2. Os Tempos que Importam e Onde o Relógio Começa
A precisão destas métricas depende inteiramente de onde o relógio começa, e a imprecisão clássica é usar a data de abertura do ticket como ponto de partida. O incidente não começa quando alguém o nota; começa quando o adversário obtém o acesso inicial, e a distância entre esses dois pontos é exatamente aquilo que o programa tenta reduzir. A tabela a seguir fixa as definições e os pontos de medição usados em todas as notas do grupo MET, alinhados com as datas registradas obrigatoriamente na plataforma de gestão de incidentes pelo subcontrole IR.5.1.
| Métrica | Definição | Ponto inicial | Ponto final | Observações de medição |
|---|---|---|---|---|
| MTTD (Mean Time to Detect) | Tempo médio entre o comprometimento e a detecção | Data e hora do comprometimento estimado | Primeira detecção que gerou o caso | Calcular mediana e P90, não apenas média |
| Tempo de contenção | Tempo entre a detecção e a contenção efetiva do adversário | Primeira detecção | Ação que interrompeu o acesso ou persistência | Contenção é ação verificada, não decisão tomada |
| MTTR (Mean Time to Respond) | Tempo médio entre detecção e resolução completa do incidente | Primeira detecção | Encerramento do caso com erradicação e recuperação | Inclui contenção, erradicação e recuperação |
| Dwell time | Tempo total de permanência do adversário não detectado | Comprometimento estimado | Contenção efetiva | Soma do tempo pré-detecção com o tempo de contenção |
Três regras de laboratório protegem a qualidade desses números. Primeira, segmentar sempre por severidade, calculando as métricas para incidentes de severidade Alta e Crítica separadamente, porque misturar phishing reportado por usuário com comprometimento de servidor crítico produz uma média que não descreve nenhum dos dois. Segunda, preferir mediana e percentil 90 à média aritmética, pois um único incidente de contenção longa por decisão jurídica distorce a média do trimestre inteiro. Terceira, congelar as datas no encerramento do caso, com revisão permitida apenas em post-mortem documentado, para que a série histórica não seja retratada silenciosamente mês a mês.
A captura desses pontos deve acontecer no fluxo do próprio caso, e não por levantamento posterior. Cada transição relevante, abertura, detecção confirmada, contenção aplicada, erradicação verificada e encerramento, grava seu timestamp automaticamente na plataforma de casos, seja por integração com o SIEM, seja por campo de estado no fluxo do playbook. Levantamento retrospectivo de datas a partir da memória do analista é a origem mais comum de séries históricas bonitas e falsas, e a regra prática é simples: data que não foi registrada no momento não é data, é reconstrução, e precisa ser rotulada como tal na base de cálculo.
3. KPIs Recomendados de Resposta a Incidentes
Além dos quatro tempos da seção anterior, a qualidade da resposta precisa de indicadores de consequência, que medem se o incidente foi realmente encerrado e se a organização aprendeu com ele. A tabela abaixo consolida os KPIs essenciais com pontos de medição e metas exemplificadas.
| KPI | Definição e fórmula | Ponto de medição | Meta exemplificada |
|---|---|---|---|
| MTTD | Mediana e P90 entre comprometimento estimado e primeira detecção, para severidade Alta e Crítica | Plataforma de casos, campos de data estimada e data de detecção | Mediana menor que 14 dias no nível 3, menor que 24 horas no nível 5 |
| MTTR | Mediana e P90 entre detecção e resolução, segmentado por categoria de incidente | Ciclo de vida do caso na plataforma DFIR | Menor que 72 horas no nível 3, menor que 4 horas para incidentes com playbook no nível 5 |
| Tempo de contenção | Mediana entre detecção e contenção efetiva | Registro da ação de contenção verificada | Menor que 4 horas no nível 4, minutos para casos automatizados no nível 5 |
| Taxa de reinfecção em 30 dias | (Casos reabertos ou novo incidente no mesmo ativo ou vetor em 30 dias / incidentes fechados) x 100 | Junção de casos por ativo e por vetor de entrada | Menor que 10%; reinfecção indica erradicação incompleta |
| Post-mortem em 2 semanas | (Incidentes Alta e Crítica com post-mortem publicado em 14 dias / incidentes Alta e Crítica) x 100 | Data de publicação do documento no repositório | 100%, com exceção justificada por investigação jurídica |
| Cobertura de lições implementadas | (Ações do post-mortem efetivamente implantadas / ações propostas) x 100 em 90 dias | Itens de plano de ação vinculados ao post-mortem | Maior que 80%; lições não implantadas são dívida de risco |
A taxa de reinfecção merece destaque porque expõe o erro mais caro da resposta, que é fechar o caso sem erradicar a persistência. Um ativo reinfectado em 30 dias pelo mesmo vetor indica que o bloqueio removeu o sintoma e não a causa, e cada reinfecção deve disparar revisão do caso original, da detecção que falhou em prevenir o retorno e do vetor de entrada tratado pelo grupo PRT. Já a cobertura de lições implementadas protege o post-mortem de virar cerimônia: documento produzido e arquivado sem plano de ação rastreado é custo administrativo que não muda a defesa.
4. Medindo com Honestidade Quando a Origem é Desconhecida
Na maioria dos incidentes relevantes, a data exata de comprometimento é desconhecida, e fingir o contrário destrói a credibilidade da métrica. A prática recomendada combina duas camadas: evidência forense e estimativa declarada com grau de confiança. A evidência forense estabelece um limite superior e, quando possível, um limite inferior para a data de comprometimento: a criação mais antiga de persistência, o primeiro registro do IOC em logs retidos, a data do certificado ou da conta criada pelo invasor, a última alteração legítima conhecida do artefato substituído. Nenhum desses marcadores é a data exata, mas todos delimitam com honestidade o intervalo em que o acesso inicial ocorreu.
{
"caso": "IR-2025-011",
"severidade": "alta",
"deteccao": "2025-04-08T02:47:00Z",
"comprometimento_estimado": {
"data": "2025-03-20T00:00:00Z",
"confianca": "media",
"janela_inferior": "2025-03-12",
"janela_superior": "2025-03-26",
"evidencias": [
"primeira execucao do binario em 2025-03-20 (Sysmon 1, retencao de 90 dias)",
"evento 4720 de conta de servico criada em 2025-03-22",
"logs de proxy anteriores a 2025-03-12 indisponiveis"
],
"metodo": "reconstrucao forense com revisao de pares"
},
"mttd_dias": 19,
"observacao": "MTTD declarado com confianca media; janela de 14 dias"
}
O ponto crítico de governança é a regra de consistência: nunca usar a data de detecção como data de comprometimento, porque isso reduz artificialmente o MTTD e esconde exatamente o problema que o programa precisa atacar. Quando a evidência não permite estimativa, o caso entra na métrica com o campo declarado como não determinado, e o programa mede separadamente o percentual de casos com origem desconhecida. Esse percentil de incerteza é, ele mesmo, um indicador valioso: um volume crescente de casos sem origem determinável aponta para lacunas de retenção de logs e de telemetria, exatamente o tipo de problema que o grupo DAT precisa resolver.
5. Benchmarks de Mercado e o Cuidado ao Comparar
Relatórios anuais da indústria divulgam médias de dwell time que giram em torno de três semanas para casos detectados externamente, com valores muito menores para detecção interna, e esses números são úteis como régua geral de sanity check. O cuidado começa ao ler o detalhe: a média esconde uma distribuição de cauda longa, em que parte relevante dos casos fica meses ou anos sem detecção, e o percentil da própria organização pode estar muito pior ou muito melhor que a média setorial. Comparar a mediana interna com a média externa é comparar estatísticas diferentes e gerar conclusões erradas.
A segunda armadilha é o viés de detecção externa. Organizações que descobrem parte relevante dos incidentes por aviso de terceiro, como força-tarefa, parceiro ou notificação de vítima, costumam ter dwell time muito maior, porque o adversário chegou lá primeiro. Por isso a proporção de detecções internas versus externas deve acompanhar sempre o dwell time no painel do MET.5, e a meta estratégica de longo prazo é deslocar essa proporção para dentro, usando detecção automatizada e hunting proativo. O benchmark mais honesto é a própria linha de base: a tendência de seis a doze meses da organização, segmentada por severidade e por origem da detecção, diz mais sobre o programa do que qualquer comparação setorial, e os subcontroles MET.3.2 e MET.5.4 pedem exatamente essa leitura longitudinal com referências externas como contexto.
6. Relação com IR.5 e as Metas da Esteira
O IR.5 define as metas progressivas de tempo por nível de maturidade, e o MET.3 fornece o aparato de medição que verifica essas metas. A tabela abaixo reproduz a progressão de referência do framework, que o programa deve adaptar ao seu setor e à sua linha de base.
| Nível de maturidade | MTTD alvo | MTTR alvo | Dwell time alvo | Métodos primários |
|---|---|---|---|---|
| 2 (Inicial) | Menos de 30 dias | Menos de 7 dias | Menos de 37 dias | Detecção básica via SIEM, resposta manual |
| 3 (Definido) | Menos de 14 dias | Menos de 72 horas | Menos de 17 dias | Regras Sigma, hunting mensal, resposta semi-automatizada |
| 4 (Gerenciado) | Menos de 7 dias | Menos de 24 horas | Menos de 8 dias | Detecção orientada a ATT&CK, hunting semanal, SOAR |
| 5 (Otimizado) | Menos de 24 horas | Menos de 4 horas | Menos de 28 horas | Detecção quase em tempo real, resposta automatizada, simulação mensal |
A leitura estratégica dessa tabela é que os três tempos caem por vetores diferentes. O MTTD cai com telemetria e detecção, trabalho dos grupos DAT, DET e HNT; o tempo de contenção cai com automação e playbooks, trabalho dos grupos AUT e RES; e o dwell time cai com os dois juntos, mais a disciplina de não fechar caso sem erradicação verificada. Reduzir MTTD com playbooks lentos produz números bonitos de detecção e incidentes que crescem igualmente; a decomposição por métrica é o que impede essa ilusão de progresso.
7. Exemplo de Fechamento Mensal e Decomposição de Desvio
Para demonstrar a leitura em prática, considere o fechamento de um mês com três incidentes de severidade Alta e um de severidade Crítica. Nenhum caso teve comprometimento determinado com precisão de hora; dois foram reconstruídos por evidência forense com confiança alta, um com confiança média e um permaneceu sem origem determinável. A tabela abaixo resume o mês como ele apareceria no painel operacional do MET.5.
| Caso | Severidade | Comprometimento estimado | Detecção | Contenção | Resolução | MTTD | Contenção | Origem da detecção |
|---|---|---|---|---|---|---|---|---|
| IR-2025-009 | Alta | 2025-03-20, confiança alta | 2025-04-08 | 2025-04-08 | 2025-04-11 | 19 dias | 3 horas | Forense interna |
| IR-2025-010 | Alta | 2025-04-02, confiança média | 2025-04-09 | 2025-04-09 | 2025-04-12 | 7 dias | 6 horas | Forense interna |
| IR-2025-011 | Crítica | 2025-04-07, confiança alta | 2025-04-10 | 2025-04-10 | 2025-04-10 | 3 dias | 40 minutos | Forense interna |
| IR-2025-012 | Alta | Não determinado | 2025-04-21 | 2025-04-22 | 2025-04-28 | Não medido | 26 horas | Aviso externo |
A leitura correta do mês não é a média de MTTD, que ficaria distorcida pelo caso sem data, e sim três conclusões separadas. A mediana de MTTD dos casos medidos mostra tendência contra o trimestre anterior; a proporção de detecção externa subiu e merece atenção estratégica, porque o caso IR-2025-012 foi o que ficou mais tempo dentro; e a contenção de 26 horas desse mesmo caso foge do padrão e deve ser decomposta. A decomposição mostra que vinte das vinte e seis horas foram espera de aprovação para isolar um servidor de produção, achado que transforma a métrica em decisão concreta: revisar a matriz de aprovação de contenção emergencial do grupo RES. Esse é o ciclo completo de valor do MET.3, do timestamp ao gesto de governança.
O fechamento agregado, com percentis por severidade e por origem, sai direto da base de casos, como no exemplo abaixo, que pode ser adaptado à plataforma de gestão de incidentes em uso.
-- Fechamento trimestral de tempos com percentis, por severidade e origem
SELECT
severidade,
strftime('%Y-%m', deteccao) AS mes,
COUNT(*) AS casos,
SUM(CASE WHEN comprometimento_estimado IS NULL
THEN 1 ELSE 0 END) AS sem_origem,
APPROX_PERCENTILE(julianday(deteccao)
- julianday(comprometimento_estimado), 50) AS mttd_p50_dias,
APPROX_PERCENTILE(julianday(deteccao)
- julianday(comprometimento_estimado), 90) AS mttd_p90_dias,
ROUND(AVG((julianday(contencao) - julianday(deteccao)) * 24), 1)
AS contencao_media_horas
FROM incidentes
WHERE severidade IN ('alta', 'critica')
GROUP BY severidade, mes
ORDER BY mes;
8. Salvaguardas por Nível de Maturidade
| Subcontrole | Nível | Salvaguarda |
|---|---|---|
| MET.3.1 | Básico | Coleta automática de MTTD, MTTR e dwell time a partir da plataforma DFIR para incidentes de severidade Alta e Crítica, com médias mensais e trimestrais e segmentação por categoria |
| MET.3.2 | Básico | Metas formais de redução de MTTD e MTTR com revisão trimestral, evolução documentada e comparação com benchmarks do setor quando disponíveis |
| MET.3.3 | Intermediário | Medição da taxa de contenção automática, com percentual de incidentes com pelo menos uma ação de contenção executada via SOAR, e meta progressiva de 20% no nível 3 a 80% no nível 5 |
| MET.3.4 | Intermediário | Análise de MTTD e MTTR por categoria de incidente para direcionar melhorias de playbook, automação e treinamento às categorias mais lentas |
| MET.3.5 | Avançado | Análise preditiva com dados históricos para projetar tendências de volume e severidade, permitindo planejamento proativo de recursos antes dos picos |
A taxa de contenção automática da salvaguarda MET.3.3 deve ser lida em conjunto com a taxa de reversão de ações automáticas do MET.4, porque contenção rápida equivocada custa disponibilidade. A análise preditiva da MET.3.5, por sua vez, só é aplicável com pelo menos dois anos de histórico limpo, pois projeção sobre série curta ou sobre dados com datas inconsistentes produz previsões confiáveis sobre um passado que não existiu.
9. Erros Comuns e Pontos de Atenção
- Medir apenas tickets fechados: casos encerrados sem resolução completa, transferidos para outra área ou abandonados por falta de evidência saem da amostra e a média melhora magicamente; a amostra deve incluir todos os casos da severidade, fechados ou não, com estado explícito.
- Transformar tempo médio de atendimento em meta de produtividade: quando o analista é cobrado por velocidade média de caso, a investigação profunda é punida, casos complexos são fechados prematuramente e a métrica otimiza o oposto do que a organização precisa.
- Usar a média aritmética como único resumo: um incidente de 90 dias em uma série de vinte casos de 2 dias eleva a média sem representar a experiência típica; mediana, P90 e valor máximo contam a história completa.
- Misturar severidades na mesma métrica: a média global dilui os casos críticos e esconde a categoria que realmente importa; segmentação por severidade e por categoria é obrigatória desde o primeiro painel.
- Congelar a regra de que detecção externa conta igual a interna: sem separar a origem da detecção, a organização não vê que está dependendo de terceiros para descobrir intrusões, e o investimento em detecção interna fica sem justificativa quantitativa.
- Tratar post-mortem como documento e não como plano: publicar o relatório em duas semanas sem rastrear as ações até a implementação converte a lição aprendida em arquivo morto, e a cobertura de lições implementadas é a métrica que impede esse desvio.
- Delegar a coleta das datas ao fim do mês: sem captura dos timestamps no fluxo do caso, as datas saem da memória do analista, e a memória sempre favorece a resposta rápida que de fato não aconteceu.
- Apresentar MTTD sem declarar a proporção de casos sem origem determinável: quando um quarto da amostra não tem data de comprometimento, o número exibido descreve apenas três quartos da realidade, e essa omissão é descoberta justamente quando a métrica importa mais.
10. Integração com Outros Controles do Framework CTH
O MET.3 consome as datas registradas pela plataforma DFIR exigida pelo IR.5, usa os campos de evidência e reconstrução temporal praticados na resposta do grupo RES e recebe da taxa de contenção automática do AUT.5 a parcela de casos contidos sem intervenção manual. Sua leitura por categoria de incidente alimenta a priorização de playbooks do grupo RES e a seleção de técnicas para o SIM.1 e o SIM.2, porque categoria com tempo de detecção sistemicamente alto indica técnica sem cobertura de detecção. No plano executivo, o MET.5 apresenta o dwell time como o indicador resultado do programa, com a proporção de detecção interna versus externa ao lado, e o GOV usa a progressão desses tempos como evidência de subida de nível de maturidade.
Na cadeia proativa, cada achado do hunting medido pelo MET.2 é também um evento de dwell time deste controle, e a junção das duas séries produz o indicador de detecção proativa: percentual de intrusões descobertas por iniciativa defensiva antes de qualquer alerta reativo. Esse é o número que resume, em uma linha, o valor combinado de telemetria, detecção, inteligência e hunting que a esteira completa do framework foi desenhada para entregar.