Reincidência é o segundo incidente na mesma empresa depois que o primeiro foi contido. Ela quase nunca repete o vetor original. O que repete é a condição que abriu o primeiro. Um ativo publicado que não estava em lista nenhuma, e que por isso ficou fora da correção e fora do monitoramento.
Boa parte das empresas que procuram a CSURFACE chega com o incidente já encerrado. O backup voltou, o jurídico fez o que tinha de fazer, o relatório de resposta foi arquivado. Sobrou uma pergunta que ninguém do time consegue responder com uma lista na mão. Por onde mais dá para entrar?
É essa pergunta que este texto trata. A que vem antes dela, o que a visão externa entrega enquanto o incidente ainda está aberto, está no artigo vizinho.
A segunda vez entra por outro lugar
Quem responde a incidente por profissão reconhece o padrão. O time fecha o vetor usado, gira as credenciais, aplica o patch, escreve o post-mortem. Meses depois o adversário volta, e volta por um endereço que não aparecia em diagrama nenhum da resposta anterior.
O motivo é desconfortável. A resposta trabalha sobre o escopo do incidente, e o escopo do incidente é aquilo que foi encontrado. Nenhuma etapa dela pergunta quantos ativos publicados existem fora daquele recorte.
O DBIR 2026 da Verizon mostra por que a segunda vez costuma encontrar porta aberta. A falha exposta ultrapassou a credencial roubada como caminho de entrada mais comum, e enquanto isso o prazo mediano de correção se alongou de 32 para 43 dias. O catálogo da CISA de vulnerabilidades comprovadamente exploradas registrava 26% de correção, o que dá a medida de quanto tempo um ativo segue disponível depois de a falha já ser pública.
Junte as três coisas e o que sobra é uma janela que se alarga sozinha: a entrada mais provável ficou mais fácil, o remédio ficou mais lento, e a maior parte do que já se sabe perigoso segue no ar. Corrigir mais rápido deixou de dar conta nessa velocidade.
Três dias parados, e a conta que veio depois
Uma operação de e-commerce ficou três dias sem vender. R$ 900 mil em vendas perdidas nesse intervalo. As despesas operacionais do período, que correm na casa das dezenas de milhões, fecharam 11% acima do projetado, somando resposta emergencial e horas extras.
Os números vieram da própria empresa e não estão aqui para provar nada sobre plataforma. Interessa mais o que veio depois, quando a operação se recompôs e voltou com uma pergunta que ninguém tinha feito antes do incidente, sobre o que mais estava publicado no nome dela.
Esse é o momento em que a conversa muda de assunto dentro do cliente. Sai do incidente e entra no inventário.
O inventário oficial não é a superfície
Em dois casos documentados, uma instituição financeira de médio porte operava com 160 ativos externos no inventário oficial e a descoberta entregou 271. Uma startup de SaaS B2B monitorava 85, e a descoberta entregou 570.
O coordenador de cibersegurança de uma das maiores empresas do Brasil resumiu o efeito assim, e a frase está publicada no site: descobrir que monitorávamos apenas 15% da nossa real superfície de ataque.
Nenhum desses números fala de falha nova. Falam de denominador. Toda métrica de cobertura que um SOC reporta, o percentual de ativos monitorados e o percentual dentro da janela de patch, sai de uma lista que alguém escreveu à mão em algum momento e nunca mais auditou. Um subdomínio de campanha, um ambiente de homologação que subiu junto com uma integração, um domínio herdado de aquisição. Medir esse denominador em vez de presumi-lo exige olhar de fora, e de forma contínua, porque a lista interna só registra o que alguém lembrou de registrar.
Uma ressalva que quase nenhum fornecedor faz. Descobrir 400 ativos novos, sozinho, dobra a fila do time e não reduz risco nenhum. Descoberta sem ordenação é dívida.
Ordenar por gravidade teórica não reduz exposição
A fila da maioria das empresas está ordenada por CVSS. É a ordenação disponível, e ela responde a uma pergunta que quase ninguém está fazendo, que é o quanto a falha seria grave se explorada.
A pergunta operacional é outra. Dentre as milhares de falhas abertas, quais estão sendo exploradas contra alguém agora, e quais delas estão em ativo meu alcançável pela internet.
A base pública do ThreatSensor mostra o tamanho da diferença. Apurado em 21 de setembro de 2026, o núcleo que reúne catálogo KEV, exploit público e EPSS alto ao mesmo tempo é 26,9% da base monitorada. E a mediana entre a publicação de uma CVE e o primeiro exploit público é de menos de um dia: em 55,8% dos casos o código já existia na data da publicação.
Ponha isso ao lado dos 43 dias medianos de correção que o DBIR 2026 mede. O exploit não chega no meio do prazo de correção, ele já está lá quando o prazo começa a contar. É por essa aritmética que ordenar pela exploração observada muda mais o resultado do que qualquer aumento de equipe na fila de patch. A fila entrega as coisas erradas primeiro, e é aí que o tempo se perde.
O ciclo que fecha isso já tem nome
O que descrevi até aqui é um ciclo de cinco fases: escopo, descoberta, priorização, validação e mobilização. O nome dele é CTEM, continuous threat exposure management, e existe como framework público desde 2022. Uma variação mais recente do vocabulário, preemptive exposure management, fixa o que o CTEM deixou em aberto, que é o momento em que o trabalho acontece. Antes de existir alerta.
Duas observações honestas sobre o framework. A primeira é que analista de mercado não certifica produto, então nenhum fornecedor tem selo de CTEM. A segunda é que o ciclo não define cadência, o que permite rodar as cinco fases uma vez por trimestre e chamar aquilo de CTEM sem mentir uma vírgula.
Para uma empresa que já foi comprometida, a cadência é justamente a variável que interessa. A janela entre o ativo ficar exposto e alguém do time saber que ele existe é o intervalo em que a reincidência acontece.
A infraestrutura de IA que ninguém registrou
Nos últimos dois anos entrou uma classe nova de ativo esquecido, e ela merece um parágrafo próprio porque quase nenhum inventário a acompanha.
Times de produto e de dados subiram painéis de orquestração, endpoints de inferência e ambientes de teste com modelos. Boa parte disso foi publicada por engenharia sem passar por segurança, ficou em pé depois do experimento e nunca entrou em CMDB alguma. O verbete de shadow AI descreve o resultado: boa parte do shadow AI vira ativo exposto na internet antes de virar incidente de dado. E o de segurança de IA agêntica explica por quê. Todo agente em produção acrescenta um endpoint, uma chave e uma integração, e ativo novo entra na superfície externa como qualquer outro.
O limite precisa estar escrito, porque é ele que decide se a frase acima é vendável ou verdadeira. Visão externa não protege agente de IA. O que ela alcança é a infraestrutura de IA que a empresa publicou e esqueceu, o painel, o endpoint e a chave, e a verificação de que aquilo responde. Inventário de identidade de agente, análise de escopo de token OAuth e teste de prompt injection exigem acesso interno e são outra categoria de produto.
O que já funciona sem nada de novo é a fila. Quando sai CVE crítico em um componente de stack de IA, a priorização reordena pelo que está sob exploração observada, sem perguntar que tipo de software é o afetado.
Quem opera SOC para terceiros vê o mesmo roteiro se repetir
Um provedor que atende dezenas de clientes assiste ao ciclo inteiro várias vezes por ano, sempre com o mesmo desenho. O cliente contrata monitoramento sobre a lista que entregou, o incidente entra por fora dela, e o pós-incidente vira uma discussão sobre escopo de contrato.
É por isso que a superfície externa costuma ser o primeiro módulo que um SOC terceirizado embute no próprio serviço. Ela ataca o problema anterior ao monitoramento, que é saber sobre o que monitorar. Operar assim exige três coisas que raramente vêm juntas: visão por organização com separação entre clientes, controle de acesso por escopo, e trilha de auditoria que sobreviva a um cliente perguntando quem olhou o quê. Sem isso, o provedor acaba rodando um scan por cliente a partir de um console só, e o modelo não fecha.
O ganho comercial para o provedor está no relatório do trimestre seguinte, quando ele consegue mostrar ao cliente uma linha que nenhum concorrente mostra: quantos ativos entraram e saíram da superfície do cliente desde a última reunião, e quantos deles ninguém tinha registrado.
Onde a CSURFACE entra nisso
Nada do que está acima depende de comprar coisa alguma. Medir o denominador, ordenar pela exploração observada e fechar o ciclo são trabalho, e dá para fazer com ferramenta própria, com script ou com outro fornecedor.
A CSURFACE resolve três dessas partes de fora, sem agente instalado: a descoberta contínua do que está publicado sob o nome do grupo, com histórico de primeira e última observação; a priorização por exploração observada em vez de nota teórica, alimentada pelo threat intelligence; e o ciclo completo de CTEM em cima disso.
Para quem opera SOC para terceiros, a conversa é a de parceiros, porque ali o que se compra é modelo comercial e não funcionalidade.
Perguntas frequentes
A reincidência acontece sempre pelo mesmo caminho?
Raramente. O vetor usado no primeiro incidente costuma ser o mais bem tratado depois dele, porque é o que a resposta documentou. O que sobrevive é a condição de fundo, ou seja, ativos publicados fora do inventário. O segundo incidente entra por um deles.
Um SOC bem montado não resolve isso sozinho?
Um SOC resolve a detecção do que está sob monitoramento. A pergunta de onde vem a lista de ativos monitorados nunca fez parte do escopo dele, e é anterior à detecção. Os dois trabalhos são complementares, e o de superfície externa vem primeiro na ordem.
Quanto tempo leva para ter a superfície externa mapeada?
Os primeiros ativos aparecem em poucas horas a partir de um domínio semente, e a cobertura se consolida nos primeiros dias. O que leva mais tempo é a atribuição de propriedade, ou seja, provar que um ativo achado pertence mesmo à empresa e não a um homônimo.
A CSURFACE protege agentes de IA?
Não. Ela encontra a infraestrutura de IA publicada na internet e verifica se está exposta. Proteção de agente em tempo de execução, inventário de identidade não humana e teste de injeção de prompt exigem acesso interno ao ambiente e não são feitos por uma plataforma externa.
O que fazer enquanto o incidente ainda está aberto?
Essa é a outra metade do assunto e está tratada em o que a visão externa entrega ao time de resposta, que descreve as listas que dá para levantar de fora em poucas horas com o incidente em curso.