◇ OpenCyber Academy
Engenharia · Capítulo 29 · Português

Capítulo 29 — Operações de segurança e blue team: medição

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 29 — Operações de segurança e blue team: medição

Mapa da aula

Aula 29 publicada. Mapa, exemplo, EX085.

flowchart TD
  N0["29.1 Por que medir"]
  N1["29.2 Escolhendo métricas"]
  N2["Laboratório — resumos dos tempos de resposta"]
  N3["29.3 Lendo o resultado"]
  N4["29.4 Métricas que distorcem"]
  N5["29.5 Contexto"]
  N6["29.6 Qualidade dos dados"]
  N7["Métricas de cobertura"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX085"]

Desenho lógico

flowchart LR
  N0["29.1 Por que medir"]
  N1["29.2 Escolhendo métricas"]
  N2["Laboratório — resumos dos tempos de resposta"]
  N3["29.3 Lendo o resultado"]
  N4["29.4 Métricas que distorcem"]
  N5["29.5 Contexto"]
  N6["29.6 Qualidade dos dados"]
  N7["Métricas de cobertura"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX085"]
[29.1 Por que medir]
    |
    v
[29.2 Escolhendo métricas]
    |
    v
[Laboratório — resumos dos tempos de resposta]
    |
    v
[29.3 Lendo o resultado]
    |
    v
[29.4 Métricas que distorcem]
    |
    v
[29.5 Contexto]
    |
    v
[29.6 Qualidade dos dados]
    |
    v
[Métricas de cobertura]
    |
    v
[Exemplo resolvido] --> [Exercício EX085]

Objetivos de aprendizagem

Você vai (1) definir métricas de SOC ligadas a objetivos; (2) calcular resumos robustos dos tempos de resposta; (3) evitar métricas que distorcem o comportamento; (4) apresentar as medições com contexto.

29.1 Por que medir

Knerler, Parker e Zimmerman (2022) tratam a medição como uma estratégia: "meça o desempenho para melhorar o desempenho". As métricas mostram se as mudanças ajudam e para onde o esforço deve ir. Sem medição, um SOC não consegue saber se uma nova regra reduziu o dano ou só acrescentou ruído, nem se uma mudança na equipe ajudou. As medidas também sustentam conversas honestas com a direção sobre o que a equipe consegue entregar. O objetivo é a melhoria, não julgar indivíduos, o que afeta como as métricas são escolhidas e compartilhadas. A Lindqvist começa com um punhado de medidas e só acrescenta outras quando há uma pergunta clara a responder.

29.2 Escolhendo métricas

Boas métricas de SOC se ligam a objetivos: tempo da detecção ao reconhecimento, fração de incidentes detectados internamente em vez de relatados por clientes, cobertura das técnicas prioritárias e taxas de alertas falsos por regra. Cada métrica deve responder a uma pergunta que alguém de fato faz. O tempo até o reconhecimento diz ao CISO com que rapidez o SOC reage; a detecção interna versus a relatada por clientes mostra se o monitoramento encontra os problemas primeiro; a cobertura de técnicas mostra a amplitude; as taxas de alertas falsos por regra mostram onde é preciso ajustar. Coletar métricas que ninguém usa desperdiça esforço e polui os relatórios.

Laboratório — resumos dos tempos de resposta

"""Median and 90th percentile of detection-to-acknowledgement minutes (synthetic)."""
import statistics
minutes = [3, 4, 4, 5, 5, 6, 6, 7, 8, 9, 11, 12, 14, 18, 41]
q = statistics.quantiles(minutes, n=10, method="inclusive")
print(f"n={len(minutes)} mean={statistics.mean(minutes):.1f} median={statistics.median(minutes)} p90={q[8]:.1f}")

Execute com python3 lab_latency.py. Saída verificada:

n=15 mean=10.2 median=7 p90=16.4

29.3 Lendo o resultado

Quinze tempos de reconhecimento dão uma média de 10,2 minutos, mas uma mediana de 7 e um percentil 90 de 16,4. Um único caso de 41 minutos puxa a média para cima. A mediana descreve o caso típico; o percentil 90, a cauda lenta que importa para o requisito de 15 minutos. Relatar só a média sugeriria que a equipe costuma levar dez minutos, quando a maioria dos reconhecimentos acontece em cerca de sete. Relatar só a mediana esconderia que um décimo dos casos leva mais de dezesseis minutos, além do requisito. Amara examina o caso de 41 minutos separadamente e descobre que ele chegou durante uma passagem de turno, o que aponta para uma correção de processo.

29.4 Métricas que distorcem

Kokulu et al. (2019) constataram que desalinhamentos de métricas são comuns nos SOCs. Recompensar o fechamento rápido pode produzir fechamento descuidado. Combine as métricas de velocidade com verificações de qualidade, como amostras revisadas de alertas fechados. Quando um número vira meta, as pessoas encontram formas de movê-lo que não refletem melhoria real. Se os analistas são julgados por alertas fechados por hora, fechamentos rápidos sem investigação se tornam racionais. Usar várias métricas juntas torna qualquer uma delas mais difícil de manipular. A amostra de alertas fechados é sorteada a cada semana, para que os analistas não consigam prever quais fechamentos serão revisados.

29.5 Contexto

Uma métrica sem contexto engana: o tempo de reconhecimento subiu no mês passado porque a equipe noturna diminuiu, e não porque os analistas ficaram mais lentos. Os relatórios incluem essas explicações. Um gráfico mostrando reconhecimentos mais lentos poderia levar os gestores a culpar os analistas ou exigir horas extras. Com a explicação de que a equipe noturna caiu de dois para um, a conversa passa para as decisões de pessoal. Amara acrescenta ao relatório mensal uma coluna curta de observações para eventos como mudanças de equipe, incidentes e novas regras. Os relatórios comparam cada mês com o mesmo mês do ano anterior quando há padrões sazonais.

29.6 Qualidade dos dados

As métricas dependem dos carimbos de tempo do sistema de casos; analistas que reconhecem tarde na ferramenta, mas agem cedo, tornam os dados errados. Treinamento e ferramentas corrigem isso. Se os analistas começam a investigar a partir de uma notificação por e-mail e só clicam em reconhecer depois, o sistema de casos registra um tempo mais lento do que o real. A métrica então engana no sentido oposto. Tornar o reconhecimento automático quando o analista abre o alerta, e treinar a equipe sobre por que os carimbos de tempo importam, alinha os dados com o que de fato aconteceu. Amara confere uma amostra de casos contra os logs de chat.

Métricas de cobertura

A cobertura das técnicas prioritárias do ATT&CK é medida como a fração que tem pelo menos uma detecção testada. Detecções não testadas não contam, porque uma regra que nunca disparou num evento de teste seguro pode não funcionar. A Lindqvist relata essa fração a cada trimestre, com a lista de lacunas anexada, para que o número não possa esconder quais técnicas faltam.

Exemplo resolvido

Amara relata: "Mediana de reconhecimento de 7 minutos, percentil 90 de 16,4 contra uma meta de 15 minutos. O caso mais lento (41 minutos) ocorreu durante uma passagem de turno; propomos sobrepor as passagens de turno em 15 minutos."

Caso sintético. Os tempos vêm do script do laboratório.

Erros e limites

Quinze valores são poucos; percentis de amostras pequenas são instáveis.

Exercícios

Síntese

Meça o que se liga aos objetivos, resuma de forma robusta, proteja-se contra a distorção e sempre relate o contexto.

Continue estudando — capítulo 29 de 50

← Capítulo 28 (rascunho) · Índice de capítulos do curso · Capítulo 30 (rascunho) →