MET.4 - KPIs de Automação e Capacidades

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.4, com os subcontroles MET.4.1 a MET.4.5.
Define os indicadores que tratam a automação como capacidade contínua e gerenciada, medindo ganho real de tempo, qualidade dos playbooks e saúde do pipeline de detecção e de coleta.

1. Contexto e Posicionamento no Framework CTH

Automação é o multiplicador de força que permite a equipes pequenas operar com eficiência de equipes grandes, mas automação sem medição é uma aposta: ninguém sabe se o investimento retornou, se os workflows funcionam conforme esperado ou se tarefas supostamente automatizadas voltaram a ser manuais por falha silenciosa. O MET.4 existe para converter a automação em capacidade gerenciada, com inventário, métricas de desempenho, regras de revisão e evidência de retorno, exatamente como qualquer outro ativo de engenharia.

No Framework CTH, este controle mede o resultado dos grupos AUT, especialmente o SOAR do AUT.1, os fluxos do AUT.2 e o pipeline de detecção como código do AUT.3, além de monitorar a saúde da coleta garantida pelo grupo DAT. A medição também protege o AUT.5, porque a resposta automatizada só pode crescer quando a taxa de sucesso e a taxa de reversão dos playbooks estão sob controle. Em termos de maturidade, o MET.4 fornece à liderança a evidência quantitativa de que o programa entrega mais com o mesmo time, argumento central do reporte executivo do MET.5.

2. Automação como Capacidade, Não como Projeto

A diferença entre tratar automação como projeto e tratá-la como capacidade está no que acontece depois do go-live. No modelo de projeto, o número de playbooks implantados é o entregável final, e a medição termina junto com o contrato; dois anos depois, metade dos workflows está quebrada silenciosamente porque uma API mudou e ninguém notou. No modelo de capacidade, cada workflow tem dono, métrica de saúde, meta e ciclo de revisão, e o portfólio inteiro é gerido como produto, com descontinuação explícita de playbooks que perderam utilidade.

O ponto de partida, exigido pelo subcontrole MET.4.1, é o inventário das tarefas operacionais repetitivas executadas pelo time, classificando cada uma como manual, semi-automatizada ou totalmente automatizada. Esse inventário, feito em uma ou duas semanas de observação honesta, é a base de três coisas: a meta de automação do MET.4.2, que parte de 30% das tarefas repetitivas no nível 3 até 70% no nível 5; a fila priorizada de candidatos, que ordena por volume de execução multiplicado pelo tempo por execução; e a linha de base de tempo manual, sem a qual o ganho depois da automação é mero palpite. Priorizar tarefas de alto volume e baixa complexidade decisória evita a armadilha de automatizar decisões que exigem julgamento humano e geram reversão em cadeia.

3. KPIs Recomendados de Automação e Capacidades

A tabela a seguir consolida os indicadores essenciais, com definição, fonte de dado e meta exemplificada. Metas são ilustrativas para um SOC de porte médio e devem ser calibradas com baseline própria antes de virarem compromisso formal.

Os dois últimos indicadores costumam ser os mais reveladores. O lead time de detecção nova mede a eficiência de toda a esteira do achado ao deploy: se um hunt confirmado em abril só vira regra em setembro, o problema não está no hunting nem no AUT.3 isoladamente, e sim nas filas de revisão e aprovação entre eles. O percentual de coleta com falha, por sua vez, é o indicador de saúde mais básico de todos, porque detecção, hunting e métrica alguma funcionam sobre dados que não chegaram; é o que o subcontrole de monitoramento da ingestão transforma em alarme e não em descoberta tardia.

A matriz abaixo fixa onde cada indicador vive, qual evidência o sustenta e com que cadência é coletado. Definir isso antes de construir o painel evita a improvisação de coleta que morre no segundo mês, princípio já aplicado pelo MET.1 e repetido aqui por ser igualmente decisivo.

4. Como Calcular Cada Indicador e Onde os Dados Vivem

Cada KPI da seção 3 tem um lar natural nos sistemas de operação, e nomear esse lar evita que a coleta dependa de boa vontade. A taxa de enriquecimento automático e a taxa de sucesso vivem no histórico de execuções do SOAR, que registra gatilho, duração, ações e resultado de cada corrida; o comparativo manual versus automático exige uma medição de baseline feita antes da automação, tipicamente cronometrando dez a vinte execuções manuais da mesma tarefa; o lead time de detecção vive no Git do pipeline do AUT.3, cruzando a data do commit da regra com a data do artefato de origem, que o registro do hunt do MET.2 fornece; e a saúde de ingestão vive nos painéis do SIEM e nos testes sintéticos do DAT.5.

-- Saude mensal do portfolio de automacao a partir do historico do SOAR
SELECT
    playbook,
    COUNT(*)                                             AS execucoes,
    ROUND(100.0 * SUM(CASE WHEN status = 'concluida'
        THEN 1 ELSE 0 END) / COUNT(*), 1)                AS pct_concluidas,
    SUM(CASE WHEN status = 'concluida'
         AND efeito_verificado = 0
        THEN 1 ELSE 0 END)                               AS erros_silenciosos,
    ROUND(AVG(duracao_segundos) / 60.0, 2)               AS duracao_media_min
FROM execucoes_soar
WHERE strftime('%Y-%m', inicio) = '2025-04'
GROUP BY playbook
HAVING execucoes >= 5
ORDER BY erros_silenciosos DESC, pct_concluidas ASC;

O campo de efeito verificado na consulta acima é o coração da medição honesta de automação. Uma execução pode terminar com status verde sem ter produzido o efeito desejado: o playbook marcou o alerta como fechado, mas o bloqueio no firewall falhou; a consulta de reputação retornou vazio por timeout mascarado; o ticket foi aberto no sistema errado. Esse é o erro silencioso, invisível na taxa de sucesso padrão, e a forma de capturá-lo é combinar verificações automatizadas de efeito, como confirmar a presença da regra no firewall após a ação de bloqueio, com amostragem humana periódica sobre execuções marcadas como bem-sucedidas.

A medição de baseline merece exemplo numérico. Antes de automatizar o enriquecimento de IOC, o time cronometrou vinte execuções manuais típicas, com mediana de 17 minutos e P90 de 31 minutos. Para um volume de 60 casos por dia útil, isso representa cerca de 17 horas de trabalho humano por dia somente em enriquecimento, número que justifica a prioridade da automação antes mesmo de qualquer outra métrica. O ganho declarado para o cálculo de retorno usa a mediana conservadora, 15,6 minutos por caso, e não o P90, porque a meta é sobreviver a auditoria com premissas defensáveis, e não apresentar o melhor número possível.

5. Metas Exemplificadas por Maturidade

A coluna de falsos positivos por regra, herdada do Capítulo 19, entra nesta tabela porque a qualidade da detecção é parte da capacidade automatizada: regra ruidosa gera fadiga de alerta, desgasta a confiança no enriquecimento automático e contamina qualquer triagem automatizada montada sobre ela. O subcontrole MET.4.4 estabelece a regra de governança correspondente: regra com taxa de falso positivo superior a 10% entra em revisão obrigatória, com tuning ou desativação em até cinco dias úteis, e essa regra precisa ter dono identificado no catálogo de detecções, porque regra sem dono é a que nunca entra em revisão.

A meta de lead time de detecção merece régua separada, porque envolve cadeia de responsabilidade entre equipes: 30 dias no nível 3 e 7 dias no nível 5, medidos do artefato de origem ao deploy em produção, são metas realistas quando o pipeline do AUT.3 tem testes de regressão automatizados, pois a barreira usual não é escrever a regra, e sim provar que ela não quebra a produção sem dias de validação manual.

6. Exemplo Ponta a Ponta: Da Tarefa Manual à Capacidade Medida

Considere a tarefa de enriquecimento de IOC na abertura de caso, escolhida no inventário do MET.4.1 por alto volume e baixa complexidade decisória. O fluxo de implantação segue cinco passos: medir o baseline manual, desenhar o playbook com verificação de efeito, implantar em modo assistido com o analista confirmando o resultado, liberar a execução plena com amostragem humana e, só então, computar a métrica no catálogo com dono e meta. A tabela abaixo resume o antes e o depois com números de um ciclo de implantação típico.

A leitura pontua dois cuidados que separam este exemplo de um caso de venda de ferramenta. Primeiro, as horas liberadas não viram lazer: parte volta para hunting e revisão de detecção, e é o MET.2 que comprova esse reinvestimento com a evolução da carteira de hunts. Segundo, os 2% de execuções sem efeito verificado recebem investigação individual, porque são exatamente as falhas silenciosas descritas na seção 7, e cada uma delas ou vira correção de playbook ou vira exceção documentada de processo.

7. Riscos de Métrica: Automatizar Demais e Medir de Menos

O primeiro risco é a inflação da métrica de automação: quando a meta percentual vira alvo, o time automatiza o que não deveria, criando playbooks para tarefas raras, instáveis ou decisórias, que quebram com frequência, exigem manutenção constante e introduzem risco operacional. A automatização de uma contenção decisória mal delimitada, por exemplo, pode isolar um servidor de produção em um falso positivo, e a taxa de automação sobe enquanto a confiança no sistema desce. A defesa é parear a meta percentual com as métricas de qualidade da seção 3, especialmente a taxa de reversão, e manter a matriz de reversibilidade e impacto do AUT.5 como filtro de candidatura à automação.

O segundo risco é a taxa de sucesso otimista, já discutido: medir apenas o status de execução sem medir o efeito cria a pior forma de falsa segurança, porque o painel fica verde enquanto o processo deixa de funcionar. O terceiro risco é medir contagem de workflows como maturidade: quinze playbooks frágeis e sem dono não valem cinco sólidos e auditados. A contagem serve para o inventário e para o reporte de escopo, mas o desempenho deve ser julgado por sucesso com verificação de efeito, tempo de execução e reversão.

8. Governança das Métricas de Automação

Métricas de automação precisam de governança explícita porque cruzam fronteiras de time e se degradam silenciosamente. Cada playbook tem um dono nomeado, responsável pela saúde do fluxo e pelo atendimento à regra de revisão; o catálogo do portfólio registra, para cada workflow, o dono, a métrica primária, a meta e a data da última revisão, e workflows sem revisão há mais de dois trimestres entram automaticamente na pauta da reunião mensal de capacidades. A revisão mensal prevista pelo subcontrole MET.4.3 analisa volume, taxa de sucesso, tempo médio de execução e falhas por workflow, identifica os ineficientes e decide entre tuning, reescrita ou descontinuação.

# Entrada do catalogo de automacao: cada campo sustenta a governanca
workflow:
  id: PB-ENR-003
  nome: Enriquecimento de IOC na abertura de caso
  dono: time_soar
  metrica_primaria: taxa_de_sucesso_com_verificacao_de_efeito
  meta: 97%
  metricas_secundarias: [duracao_mediana, taxa_de_reversao]
  reversibilidade: parcial; bloqueios em firewall exigem aprovacao
  ultima_revisao: 2025-04-11
  status: producao
  proxima_revisao: 2025-07-11

No nível avançado, o subcontrole MET.4.5 pede a medição de retorno: custo de desenvolvimento e manutenção de cada workflow comparado ao tempo economizado multiplicado pelo custo da hora da equipe. O cálculo não precisa de precisão contábil; precisa de consistência de premissas, porque é ele que transforma a automação de despesa difusa em capacidade com retorno demonstrável no reporte do MET.5. Uma regra prática fecha a governança: toda nova automação entra em produção com sua medição definida, e automação sem métrica de saúde é considerada experimental, marcada como tal no catálogo e impedida de executar ações irreversíveis.

9. Salvaguardas por Nível de Maturidade

A progressão recomendada é a ordem da tabela: inventário antes de meta, meta antes de escala, escala com medição antes de retorno financeiro. Tentar pular para o cálculo de retorno sem inventário e sem taxa de sucesso com verificação de efeito produz um número de ROI defendido com premissas que a primeira auditoria derruba.

10. Erros Comuns e Pontos de Atenção

• Automatizar tudo para inflar o percentual: playbooks de tarefas raras, instáveis ou decisórias elevam a métrica e o risco ao mesmo tempo, e a correção tardia custa mais do que o ganho inicial.
• Medir taxa de sucesso apenas pelo status de execução: o erro silencioso, execuções verdes sem efeito real, só aparece com verificação de efeito automatizada e amostragem humana periódica.
• Tratar a contagem de workflows como maturidade: quantidade de playbooks sem dono, meta e saúde é inventário de dívida, não capacidade; o catálogo com dono e métrica é que distingue os dois cenários.
• Deixar o lead time de detecção sem dono de ponta a ponta: quando a regra espera fila de revisão, fila de aprovação e janela de deploy, cada elo culpa o seguinte, e a métrica só melhora com responsabilidade de ponta a ponta definida no processo.
• Ignorar a saúde de ingestão até a descoberta tardia: semanas de coleta falhada invalidam detecção, hunting e métrica simultaneamente, e o teste sintético do DAT.5 é a única defesa confiável contra esse modo de falha.
• Cortar a medição de baseline manual depois da automação: sem a referência de quanto a tarefa custava à mão, o ganho da automação vira narrativa e o cálculo de retorno do MET.4.5 perde a base de comparação.
• Permitir playbook sem dono e sem meta no catálogo: workflow sem responsável é o que falha silenciosamente por meses, e a governança da seção 8 existe justamente para impedir esse modo de falha no portfólio.

11. Integração com Outros Controles do Framework CTH

O MET.4 mede diretamente o portfólio dos controles AUT.1, AUT.2 e AUT.3, usa o inventário de tarefas como ponto de partida e devolve às revisões de playbooks do AUT.1 os fluxos com sucesso abaixo da meta. A taxa de reversão alimenta a matriz de reversibilidade e os guardrails do AUT.5, fechando o ciclo entre medir resposta automatizada e autorizar mais automação. O indicador de ingestão monitora a coleta do grupo DAT e protege a confiabilidade de todos os outros controles de medição, incluindo o MET.1 e o MET.2, cujas fontes dependem de dados que chegam.

No plano executivo, o retorno da automação calculado pelo MET.4.5 é um dos blocos de maior peso do reporte do MET.5, porque converte horas de analista em linguagem financeira. Na cadeia de qualidade, a taxa de falsos positivos por regra conecta este controle ao DET, e o lead time de detecção conecta o hunting do MET.2 ao pipeline do AUT.3, tornando este controle a ponte de medição entre a produção de conhecimento defensivo e sua operacionalização contínua.