Métricas SOC: Os Indicadores que Realmente Melhoram a Deteção e Resposta

Qual o Objetivo da Medição

Antes de escolher um KPI, defina uma decisão. Se a métrica subir ou descer, o que fará? Um tempo de Triagem alto pode justificar uma mudança na Fila, automação ou treino. Uma taxa de Falsos Positivos alta justifica o Ajuste. A falta de logs de um ativo crítico requer tratamento no Pipeline de Dados.

Separe Volume, Eficiência, Qualidade, Cobertura e Resultado. O volume descreve quanto trabalho entrou; a eficiência — quanto tempo e recursos foram necessários; a qualidade — se as decisões foram corretas; a cobertura — o que pode ser detetado; o resultado — se o dano foi contido e se ele se repete.

Para cada métrica, defina o Proprietário, a fonte de dados, a fórmula, a frequência, as segmentações e os limites de uso. Sem um Dicionário de Dados, dois gerentes podem calcular o "MTTR" de forma diferente.

Métricas de Tempo

Mean Time to Triage mede o tempo desde a criação do Incidente até o contacto analítico significativo ou a primeira alteração, dependendo da definição. O Time to Assign mede o tempo até o Proprietário. O Time to Contain mede o tempo até uma ação que impede a propagação. O Time to Close mede até o fecho administrativo. Estes são pontos diferentes e não devem ser confundidos.

MTTD — Mean Time to Detect — é mais difícil de medir porque o tempo de início do ataque nem sempre é conhecido. Pode-se usar o First Activity Time versus Created Time, mas deve-se notar que esta é uma aproximação. MTTR é um termo ambíguo: Respond, Remediate, Recover ou Resolve. Escreva a palavra completa em cada relatório.

Segmentar por Severity, tipo de Caso de Uso, fonte de Deteção, horas de trabalho, Proprietário e ativo. Uma média geral esconde incidentes de Alta severidade lentos dentro de um grande volume de incidentes de Baixa severidade rápidos.

Porquê os Percentis são Importantes

A média é influenciada por eventos extremos. Se nove Incidentes foram fechados em uma hora e um após cem horas, a média será de 10.9 horas — um dado que não descreve a maioria dos casos nem a cauda. A Mediana (P50) descreve o caso médio; o P90 mostra o tempo abaixo do qual 90% dos casos foram fechados.

A Microsoft apresenta exemplos de KQL para calcular os percentis de Time to Triage e Time to Closure a partir de SecurityIncident. Para a equipa, é recomendado acompanhar pelo menos o P50 e o P90, e investigar o P90: trata-se de uma aprovação de TI, falta de Proprietário, Data Gap ou processo manual.

Não compare percentis entre períodos se a definição de CreatedTime, FirstModifiedTime ou ClosedTime mudou. Documente as alterações no sistema e no Workflow.

Métricas de Qualidade de Deteção

A taxa de Falsos Positivos por si só não é suficiente, pois um Positivo Benigno pode ser uma Deteção correta de atividade autorizada. É preferível classificar: Positivo Verdadeiro, Positivo Benigno, Falso Positivo, Indeterminado e Duplicado. Analise por Regra e não apenas ao nível do SOC.

Meça também a Capacidade de Ação: em que percentagem dos Alertas existem Contexto e Entidades que permitem a investigação? Quantos Tickets foram fechados sem evidências? Quantos Incidentes foram reabertos? Quantas escaladas foram devolvidas para complemento? Estas métricas refletem a qualidade operacional.

Para a Engenharia de Deteção, adicione Precisão e Cobertura quando possível, mas tenha cuidado ao calcular o Recall sem uma Verdade de Referência (Ground Truth). Purple Team, Simulação e Testes Atómicos podem fornecer uma verificação controlada de Casos de Uso.

Métricas de Cobertura e Visibilidade

O SOC não pode detetar o que não é recolhido. Meça a percentagem de ativos críticos que enviam logs, Freshness, volume anómalo, falhas de Parsing, campos em falta, Retenção e Sincronização de Relógios. A Disponibilidade da Fonte de Dados deve ser um KPI operacional, não apenas um problema de infraestrutura.

Construa um Mapa de Cobertura contra Casos de Uso e MITRE ATT&CK: quais técnicas são relevantes para a organização, quais Fontes de Dados são necessárias, quais Regras existem e quando foram testadas. O número de técnicas "cobertas" não é uma prova de qualidade, mas ajuda a identificar lacunas.

Meça também a Dívida de Deteção: Regras sem Proprietário, sem Teste, sem documentação, sem Revisão ou com uma Fonte de Dados alterada. Essa dívida aumenta o risco, mesmo que o dashboard mostre Alertas.

Métricas de Carga de Trabalho e Processo

Acompanhe o Backlog, Aging, Alertas por Analista, Incidentes sem Proprietário, tempo de espera para equipas externas, taxa de Reatribuição e horas de On-call. Uma carga de trabalho alta não é necessariamente um problema de pessoal; pode ser uma Regra ruidosa ou um Workflow desnecessário.

Não classifique os analistas pelo número de Tickets fechados. Tal métrica incentiva a escolha de casos fáceis e o fecho rápido. É preferível usar métricas de grupo e combinar Revisão de qualidade, complexidade, documentação, contribuição para o Ajuste e capacidade de identificar o Escopo.

Meça a Padronização: percentagem de Incidentes em que as Tarefas necessárias foram concluídas, o Playbook foi ativado, a Classificação incluiu uma justificação e a Timeline foi escrita. O objetivo não é criar um formulário, mas garantir um mínimo profissional.

Métricas de Impacto e Melhoria

O resultado importante é a redução do impacto e da recorrência. Meça o Time to Contain em eventos verificados, o número de ativos afetados antes e depois da Deteção, eventos recorrentes da mesma Causa Raiz, Recomendações implementadas e o tempo para fechar lacunas de Logging ou Controlo.

A Revisão Pós-Incidente deve criar Ações mensuráveis: nova Regra, alteração de Política, formação, etiquetagem de Ativos ou melhoria de Backup. Acompanhe a percentagem de Ações concluídas e verifique se o evento se repetiu.

É preciso apresentar à gestão métricas ligadas ao risco: tempo sem visibilidade em ativos críticos, eventos de Privilégio, impacto no serviço e tempo de recuperação — não apenas volume de Alertas.

Scorecard Mensal para uma Equipa SOC Pequena

Como Prevenir o "Gaming"

Para cada KPI, defina uma Anti-Métrica. Se o tempo de fecho for medido, verifique a Taxa de Reabertura e a qualidade da Classificação. Se menos Alertas forem medidos, verifique a Cobertura e os testes de Deteção. Se menos Falsos Positivos forem medidos, verifique se não foram criadas Deteções Perdidas.

Apresente tendências e não uma "pontuação única". Uma grande alteração exige uma verificação da Qualidade dos Dados: a fonte parou de enviar? O Workflow mudou? As atualizações de Incidentes criam duplicados na tabela? A Microsoft adverte que cada Atualização de um Incidente cria um novo registo em SecurityIncident, portanto as Queries devem selecionar o último registo.

Realize uma Revisão mensal onde os analistas explicam o que as métricas não mostram. Uma medição saudável gera perguntas, não apenas uma cor verde.

Checklist Prático

• ✓Para cada KPI, existe uma decisão que ele deve melhorar.
• ✓A fórmula e a fonte de dados estão documentadas.
• ✓Estou a usar P50/P90 e não apenas a média.
• ✓MTTR é definido pela palavra completa.
• ✓As métricas são segmentadas por Severidade e Caso de Uso.
• ✓Métricas de qualidade e cobertura equilibram métricas de velocidade.
• ✓Existe uma Anti-Métrica para prevenir o "Gaming".
• ✓A Qualidade dos Dados é verificada antes das conclusões.
• ✓A equipa realiza Revisões e gera Ações.

Erros Comuns

• Medir apenas o número de Alertas e Tickets.
• Comparar períodos com definições diferentes.
• Classificar analistas pela quantidade de fechos.
• Apresentar Média sem Percentis.
• Ignorar eventos sem Proprietário e Backlog.
• Reduzir ruído desativando a Deteção sem verificar a Cobertura.
• Apresentar um KPI verde quando a fonte de log parou de enviar.

Resumo e CTA

Escolha um mês e construa um pequeno Scorecard com P50/P90 Triagem, Classificação por Regra, disponibilidade de logs, Backlog e Time to Contain. Ao lado de cada métrica, escreva qual decisão ela deve gerar. No curso Cybersecurity & AI da HPI, pratica-se investigação e SIEM, uma base que permite entender o significado por trás das métricas e não apenas apresentar um Dashboard.

Perguntas frequentes