Um arquivo com credenciais corporativas de três usuários apareceu num repositório público de vazamentos. As senhas tinham sido extraídas do navegador de máquinas comprometidas por um infostealer. O arquivo estava datado de novembro de 2025 e foi detectado em janeiro de 2026.

Dois meses. Nesse intervalo, as credenciais estavam válidas e disponíveis para qualquer pessoa que baixasse o arquivo. A correlação com a base de inteligência mostrou ainda que não era evento isolado: havia um caso semelhante registrado em dezembro, no mesmo cliente.

Não faltou ferramenta nessa história. O que faltou foi processo: alguém encarregado de monitorar exposição de credencial, um caminho definido para resetar senha de usuário afetado sem depender de aprovação em cascata, e uma investigação de estação de trabalho para achar o infostealer que continuava rodando.

O padrão se repete

Três casos anônimos do nosso ambiente de monitoramento mostram o mesmo desenho, com técnicas diferentes.

No caso do infostealer, o processo ausente era o de credencial exposta. Detecção sem dono não gera reset de senha.

Em outro, uma aplicação web exposta à internet foi comprometida por exploração de vulnerabilidade, com implantação de webshell e execução remota de comandos. Em seguida veio a criação de uma conta local fora do padrão do ambiente — tentativa de persistência, técnica catalogada como T1505.003 e T1136.001 no MITRE ATT&CK. O processo ausente aqui era o de correção: a vulnerabilidade explorada era conhecida.

No terceiro, um host registrou a criação e a exclusão de três contas locais em sequência, com intervalo menor que 200 milissegundos entre operações, todas desativadas e sem exigência de senha, executadas pelo contexto SYSTEM. É reconhecimento de privilégio automatizado, T1098. O processo ausente era o de resposta em endpoint: sem alguém autorizado a isolar aquele host imediatamente, a detecção vira relatório.

Nos três, a detecção funcionou. O que decidiu o desfecho foi o que existia depois dela.

Por que a lacuna aparece justamente em ambiente maduro

Existe uma ordem natural de amadurecimento que produz esse resultado. Primeiro a empresa compra proteção — firewall, endpoint, e-mail. Depois compra visibilidade — centralização de log, SIEM, inteligência. As duas etapas têm entregável claro, prazo de projeto e nota fiscal.

A terceira etapa não tem. Escrever runbook, definir alçada, treinar plantão e ensaiar cenário não vira projeto com data de encerramento, não aparece em auditoria como item comprado e não tem fornecedor único. Então fica para depois, e o ambiente chega ao estágio de ter dado suficiente para detectar tudo e organização insuficiente para responder a qualquer coisa.

O sintoma clássico é a fila de alertas em aberto: centenas de itens tecnicamente corretos, nenhum com dono, todos aguardando. Quando a fila cresce além do que o time consegue ler, o efeito é pior que não ter ferramenta, porque a organização acredita que está coberta.

O que um processo de resposta precisa ter

Quatro elementos, e nenhum deles é software.

Classificação com consequência. Severidade que não muda o que acontece a seguir é rótulo decorativo. Cada nível precisa ter prazo de atendimento e canal definidos.

Alçada por tipo de evento. Quem pode isolar host, bloquear conta, derrubar sessão, acionar fabricante — e o que fazer quando o responsável não atende.

Runbook por cenário provável, não por catálogo. Cinco cenários bem escritos valem mais que trinta genéricos: credencial exposta, ransomware em estação, comprometimento de conta em nuvem, indisponibilidade de serviço crítico, acesso indevido a dado sensível.

Ensaio periódico. Um exercício de mesa por trimestre revela em uma hora o que o organograma esconde por meses.

Onde o processo costuma quebrar primeiro

Em diagnóstico, três pontos aparecem com frequência maior que os outros.

O primeiro é a passagem de turno. O evento é detectado no fim do expediente, registrado com uma linha de anotação e retomado no dia seguinte por outra pessoa, que precisa reconstruir o raciocínio. Metade do tempo de resposta se gasta nessa reconstrução. Um registro estruturado — o que foi visto, o que foi verificado, o que ficou pendente — resolve mais que qualquer ferramenta nova.

O segundo é a fronteira entre segurança e infraestrutura. A detecção pertence a um time, a ação pertence a outro, e o incidente para no meio. Quando o combinado não existe, cada lado espera confirmação do outro.

O terceiro é a comunicação com o negócio. Isolar host, bloquear conta ou derrubar sessão tem custo operacional visível, e quem opera evita executar sem cobertura. Definir antes quem é avisado e quem autoriza remove a hesitação no momento em que ela custa caro.

Nenhum dos três se resolve com licença. Todos se resolvem com uma página escrita e um ensaio.

Ferramenta não escreve o processo por você

Existe uma promessa recorrente de plataforma que “orquestra a resposta”. Ela é real e depende de uma condição: alguém precisa ter escrito antes o que a orquestração vai executar.

Automação de resposta é a última etapa, não a primeira. Ela transforma decisão já tomada em ação imediata — bloquear indicador de alta confiança, derrubar sessão de conta comprometida, isolar host com processo malicioso. Quando entra antes de a decisão existir, a plataforma pergunta ao operador o que fazer, e o operador não sabe, porque a organização nunca respondeu.

Visibilidade também é construída, não contratada

Há um caso do nosso portfólio que mostra bem o trabalho envolvido. Um cliente do varejo operava um sistema de pagamentos desenvolvido internamente, com vários módulos e formatos de log heterogêneos. Não havia produto de mercado que entendesse aquele log.

A saída foi desenvolver parser e regras de detecção exclusivas: normalizar formatos diferentes, cobrir todos os módulos e entregar visibilidade geográfica de acesso, rastreamento de usuário e sessão, detecção de força bruta e caça a comportamento anômalo na cadeia de ações. O ambiente saiu de visibilidade zero, em um sistema crítico de alto risco regulatório, para monitoramento completo.

Nenhuma parte disso vem em licença. Vem de alguém sentado com o log, entendendo o negócio e escrevendo regra.

O que medir depois

Três indicadores mostram se a operação existe de fato. Percentual de alertas com ação registrada — não fechados, mas com decisão documentada. Tempo médio entre alerta e primeira ação, medido no relógio e não na percepção. E número de cenários com runbook ensaiado nos últimos doze meses.

Os três são desconfortáveis na primeira medição. É esse o objetivo.

O que muda para quem opera

A consequência mais imediata é sobre orçamento. Quando o próximo pedido de investimento em segurança chegar, a pergunta útil não é qual ferramenta falta, mas qual dos três pedaços da cadeia está mais fraco: detectar, decidir ou executar. Comprar sensor para resolver problema de alçada é gastar bem em coisa errada.

A segunda é sobre expectativa em relação a fornecedor. Monitoramento externo entrega turno, contexto de fora e correlação entre camadas. Alçada, prioridade de correção e conhecimento das exceções do ambiente continuam do lado de dentro, e é a combinação que funciona.

O próximo passo

Escolha o cenário mais provável no seu ambiente e responda em voz alta, com o time na sala: quem detecta, quem decide, quem executa e em quanto tempo. Se alguma das quatro respostas for um nome que não está de plantão hoje, o processo ainda não existe.

É esse desenho — do alerta ao processo — que vamos abrir no webinar com o time da CrowdStrike em 26 de agosto. Inscrições em https://lp.infomach.com.br/pt/webinar_crowdstrike_agosto2026.