Todo SOC que eu conheço tem as caixas marcadas. SIEM ingerindo alguns terabytes por dia, EDR em cada endpoint, XDR prometendo unificar tudo, SOAR com dezenas de playbooks. No papel, cobertura completa.
Aí acontece o incidente real. E a pergunta que trava a sala não é “qual ferramenta detectou?”. É outra, muito mais simples e muito mais difícil:
O que aconteceu aqui, na ordem em que aconteceu, e por quê?
Essa pergunta é o gargalo do SOC moderno. Não é falta de dado. É excesso de dado sem costura.
O paradoxo que os números escancaram
O M-Trends 2026 da Mandiant é baseado em mais de 500 mil horas de resposta a incidente em 2025. Dois números do relatório, lado a lado, contam a história inteira.
Primeiro: o tempo entre o acesso inicial e o repasse para o grupo que executa o ransomware caiu de mais de 8 horas em 2022 para 22 segundos em 2025. O corretor de acesso já entrega o ambiente com o túnel e o malware do parceiro pré-instalados. Quando o operador de ransomware encosta na sua rede, ele já está armado.
Segundo: o dwell time global mediano subiu, de 11 para 14 dias. Em casos de espionagem e de falso funcionário de TI norte-coreano, 122 dias.
Leia os dois juntos. O atacante ficou mais rápido em ordens de magnitude, e nós ficamos mais lentos para enxergar. Isso aconteceu na mesma década em que o orçamento de ferramentas de detecção explodiu.
Se o problema fosse cobertura de telemetria, esse número teria caído. Ele não caiu.
O que a ferramenta entrega, e o que ela não entrega
Uma ferramenta de detecção entrega eventos. Um evento é uma afirmação isolada e sem memória:
- “powershell.exe executou com string codificada em base64”
- “usuário j.silva autenticou de um ASN não usual”
- “conexão de saída para host recém registrado”
- “conta de serviço adicionada ao grupo de administradores”
Cada um desses, sozinho, é ruído defensável. Analista fecha como falso positivo e segue o dia. Eu já fechei. Você já fechou.
Os quatro juntos, na ordem certa, com quinze minutos de intervalo, na mesma máquina, são um comprometimento em andamento.
A diferença entre as duas leituras não está em nenhuma das ferramentas. Está no tecido conectivo entre elas. E esse tecido, na esmagadora maioria dos SOCs, é um analista cansado com onze abas abertas tentando lembrar o que viu na aba três.
Por que a correlação do SIEM não resolve isso sozinha
Aqui vem a objeção óbvia: “mas correlação é literalmente a função do SIEM”.
É, e ela funciona dentro de um limite bem específico. Regra de correlação é uma hipótese que alguém escreveu no passado sobre um ataque que já entendia. Ela pega o que foi previsto.
Três coisas quebram esse modelo na vida real:
A regra não conhece o seu negócio. “Acesso a banco de dados fora do horário comercial” é crítico na Secretaria de Saúde e é rotina no time de faturamento que fecha folha de madrugada. A regra não sabe disso. Só o contexto organizacional sabe, e ele quase nunca está no SIEM. Está na cabeça de alguém, ou numa planilha desatualizada.
A janela de tempo é arbitrária. Correlação normalmente opera em janelas de minutos ou horas. O atacante que faz hand-off em 22 segundos passa por baixo. O que fica 122 dias em dispositivo de borda passa por cima. Quem calibra a janela para o meio perde os dois extremos.
Identidade fragmenta. O mesmo humano é j.silva no AD, joao.silva@empresa no Microsoft 365, jsilva no Linux, um UUID no cloud e um IP no firewall. Sem resolução de identidade, o SIEM vê cinco atores desconexos onde existe uma pessoa só, ou uma credencial roubada só.
Ferramenta nenhuma resolve isso por você. Isso é trabalho de engenharia de detecção e de modelagem do ambiente.
O custo humano: fadiga de alerta
O SOC médio processa perto de 3 mil alertas por dia. Levantamentos de mercado em 2025 apontam que cerca de 40% nunca chegam a ser investigados. Não por preguiça. Por aritmética.
Some a isso o tempo real de investigação. Relatos de dentro de SOCs europeus falam em torno de 56 minutos até um alerta sequer ser olhado, e mais de 70 minutos para uma investigação decente, dependendo do ambiente.
Faça a conta com um time de plantão de três pessoas.
O resultado não é só alerta perdido. É algo pior e mais silencioso: o analista aprende, por condicionamento, que aquela categoria de alerta é sempre falso positivo. Quando o verdadeiro chega, ele fecha por reflexo. A detecção funcionou perfeitamente. O SOC não viu.
O que efetivamente muda o jogo
Nada disso é argumento contra ferramenta. É argumento contra comprar ferramenta esperando que ela produza entendimento. Ferramenta produz sinal. Entendimento é construído.
O que a gente vê dar resultado concreto:
Inventário que serve para decidir, não para auditoria
Não é a lista de ativos que você imprime para o auditor. É saber, no momento do alerta, o que aquele host faz, quem depende dele, qual dado ele guarda e se ele pode ser isolado às 3h sem parar o pronto-socorro. Sem isso, toda decisão de contenção vira negociação política no meio da crise.
Linha do tempo como artefato de primeira classe
A saída de uma investigação não deveria ser um ticket com status “resolvido”. Deveria ser uma narrativa: entrou por aqui, moveu-se assim, tocou nestes ativos, saiu por ali, e o que ainda não sabemos é isto. Essa narrativa é o que permite responder à diretoria e, mais importante, o que impede que o mesmo caminho seja usado de novo em três meses.
Enriquecimento antes da fila, não durante
Se o analista precisa abrir cinco consoles para descobrir de quem é o IP, o custo de contexto foi jogado no ponto mais caro e mais lento do processo: o humano sob pressão. Identidade resolvida, criticidade do ativo, dono do sistema e histórico recente devem chegar junto com o alerta.
Threat hunting como correção de rota
Hunting não é luxo de SOC maduro. É o mecanismo que descobre o que as suas regras não cobrem e transforma isso em detecção nova. Um SOC que só reage a alerta está permanentemente limitado pela imaginação de quem escreveu as regras no ano passado.
Memória institucional
O incidente de dezembro precisa estar acessível para quem está de plantão em julho. Sem isso, o time reinvestiga o mesmo falso positivo pela quarta vez e a rotatividade de analistas apaga o aprendizado junto com o crachá.
A parte que ninguém coloca no datasheet
Existe um detalhe no M-Trends 2026 que merece atenção: em 52% dos casos a própria organização detectou a atividade maliciosa primeiro, contra 43% em 2024. Isso melhorou de verdade.
Mas detectar primeiro e entender primeiro são coisas diferentes. O relatório mostra que o dwell time subiu no mesmo período. Ou seja: estamos vendo mais cedo e demorando mais para juntar as peças.
Esse intervalo, entre o primeiro sinal e a compreensão do ataque inteiro, é onde o dano acontece. É onde o atacante escala privilégio, apaga backup e negocia com você a partir de uma posição que ele já consolidou.
Não existe SKU para comprar esse intervalo de volta. Ele encurta com processo, com gente que conhece o ambiente e com a disciplina chata de manter contexto atualizado.
Como a Cloud4Sec trabalha isso
Nosso SOC gerenciado é construído em torno dessa premissa. Não vendemos console novo para a sua parede de monitores. Operamos correlação com contexto do seu ambiente: identidade resolvida, criticidade de ativo mapeada com o seu time, linha do tempo entregue como parte do fechamento de cada incidente relevante.
Na prática, isso significa que quando chamamos você às 3h da manhã, a ligação começa com o que aconteceu e o que precisa ser decidido, não com “recebemos um alerta e estamos apurando”.
Se o seu time hoje gasta mais tempo montando o quebra-cabeça do que respondendo ao ataque, vamos conversar. Uma avaliação da sua operação atual leva menos tempo do que uma investigação mal instrumentada.
Fontes: Mandiant M-Trends 2026 (Google Cloud Threat Intelligence, mar/2026, baseado em 500 mil horas de resposta a incidentes em 2025); levantamentos de mercado sobre fadiga de alerta em SOC, 2025.
