Em segurança da informação, medir é inevitável. Mas existe um problema silencioso em muitas organizações: elas estão medindo muito, e entendendo pouco.
Dashboards sofisticados, gráficos bem construídos e indicadores recorrentes passam uma sensação de controle. No entanto, quando um incidente relevante acontece, a pergunta inevitável surge:
“Como não vimos isso antes?”
Na maioria dos casos, a resposta não está na falta de dados, mas na escolha errada do que medir.
O conforto perigoso das métricas “bonitas”
Grande parte das métricas utilizadas em segurança são, na prática, métricas de conforto. São fáceis de coletar, fáceis de apresentar e raramente geram questionamento.
Entre as mais comuns: Número total de vulnerabilidades, percentual de conformidade com políticas, quantidade de incidentes reportados e número de usuários treinados
Esses indicadores têm valor operacional, mas são frequentemente usados como substitutos de segurança real.
Um caso recorrente
Uma empresa do setor financeiro apresentava ao board: 98% de compliance, redução contínua de vulnerabilidades e 100% dos colaboradores treinados
Ainda assim, sofreu um incidente relevante envolvendo acesso indevido a dados sensíveis.
A causa não estava em algo “invisível”, mas simplesmente não monitorado: permissões excessivas em um sistema crítico.
A organização estava “segura” nas métricas, mas exposta na prática.
O problema central: medir esforço em vez de risco
Muitas métricas mostram atividade, não impacto.
Exemplos comuns: “Aplicamos 1.000 patches” e “Fechamos 800 vulnerabilidades”
Isso demonstra produtividade, mas não responde à pergunta essencial: “Estamos menos expostos ao risco?”
Sem essa conexão, segurança vira uma função orientada a volume, não a redução real de risco.
Quando menos incidentes não é uma boa notícia
Em operações de segurança, uma queda no número de incidentes pode parecer positiva.
Mas nem sempre é.
Em alguns casos, essa redução vem de: Ajustes para diminuir alertas, perda de visibilidade e monitoramento incompleto
Ferramentas como Splunk ou IBM QRadar frequentemente passam por esse tipo de “otimização”, onde menos alertas são confundidos com mais segurança.
Na prática, pode ser apenas menos detecção.
Métricas moldam comportamento (e podem distorcer decisões)
Métricas não apenas medem, elas direcionam comportamento. Se você mede:
Vulnerabilidades fechadas → prioriza-se o que é mais fácil
Tempo de resposta → incentiva-se fechamento rápido
Compliance → foco vira “passar na auditoria”
O resultado é previsível: indicadores melhoram, mas o risco permanece.
O risco invisível: quem mede também executa
Existe um problema ainda mais sutil e crítico.
Em muitas organizações, a mesma equipe que: Executa controles, opera processos, tem metas de performance e também define e acompanha suas próprias métricas.
Isso cria um conflito estrutural.
No modelo de linhas de defesa: A primeira linha executa, a segunda linha deveria monitorar e a terceira linha avalia de forma independente
Quando essa separação é fraca, surge um cenário onde: quem executa também define o que é “bom desempenho”.
Na prática, isso leva a distorções como: Escolha de métricas mais fáceis de atingir, ajustes de critérios ao longo do tempo, reclassificação de problemas e subnotificação de falhas
Nem sempre por má intenção, muitas vezes por pressão por resultado. Um exemplo comum
Times de vulnerabilidade com meta de reduzir “críticos abertos” podem: Reclassificar severidades, ajustar escopo de análise e priorizar o que é mais simples
O número melhora. O risco, não necessariamente.
Sem uma segunda linha forte (GRC/riscos), a organização perde algo essencial: a capacidade de confiar nas próprias métricas.
Casos reais que reforçam o problema
Esse padrão aparece com frequência no mercado:
Empresas certificadas na ISO/IEC 27001 enfrentando incidentes relevantes Ataques de ransomware em ambientes com controles “implementados” Exposição via terceiros mesmo com alto nível de governança interna
O problema raramente é ausência de controle, é falta de visibilidade sobre o que realmente importa.
O que medir de verdade
Métricas eficazes mudam o foco de volume para risco.
Alguns exemplos mais relevantes: Tempo de detecção e contenção, exposição ativa a vulnerabilidades críticas, cobertura de ativos realmente críticos, taxa de falha de controles e risco traduzido para impacto no negócio
Essas métricas não são necessariamente mais complexas, mas são mais úteis.
Contexto é tudo
Nenhuma métrica deve ser analisada isoladamente.
Mais incidentes pode significar melhor detecção, menos vulnerabilidades pode indicar perda de visibilidade. Sem contexto, métricas contam histórias erradas, com aparência de precisão.
Conclusão
Métricas de segurança são poderosas, e perigosas.
Elas podem criar uma sensação de controle que não corresponde à realidade, distorcer decisões e até esconder riscos relevantes.
A maturidade em GRC não está em medir mais, mas em medir melhor, com foco em risco, impacto e integridade da informação.
No fim, existem duas perguntas fundamentais: “Estamos medindo as coisas certas?”
E, talvez mais importante: “Podemos confiar no que estamos medindo?”
Siga o Itshow no LinkedIn e assine a nossa News para ficar por dentro de todas as notícias do setor de TI e Cibersegurança!