Conceitos e Diferenças do EASM Tradicional

Nota de abertura do capítulo 21, dedicado ao EASM avançado e ao CTEM.
Contrasta o External Attack Surface Management, que mapeia e monitora a
superfície externa, com o Continuous Threat Exposure Management, programa
contínuo e gerido de exposição definido pelo Gartner. Define por que inventário
não basta e prepara as notas de Fases do CTEM e de Integração com Gestão de
Vulnerabilidades. Dialoga com a nota de IOE do capítulo 3 e com o controle
INS.3 do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

A biblioteca dedicou os capítulos anteriores à inteligência e à caça: entender o adversário e procurá-lo dentro do ambiente. O capítulo 21 inverte a perspectiva e trata do outro lado da equação, a exposição que o adversário encontrará. O EASM, External Attack Surface Management, é a capacidade de descobrir e monitorar continuamente os ativos expostos à internet com os olhos do adversário. O CTEM, Continuous Threat Exposure Management, é o passo seguinte de maturidade: um programa de gestão que transforma essa descoberta, e todas as demais fontes de exposição, em um ciclo gerido de escopo, priorização, validação e correção orquestrada.

Esta nota é conceitual por escolha. Antes de detalhar fases e integrações nas notas seguintes, ela fixa a fronteira entre ferramenta e programa, porque a confusão entre EASM e CTEM leva organizações a comprar descoberta e acreditar que compraram gestão. O diálogo direto é com a nota de IOE, Indicadores de Exposição, que fornece o vocabulário de sinais externos, e com o controle INS.3 do Framework CTH, que mapeia a superfície externa como insumo do programa integrado.

2. EASM Tradicional: O Que a Capacidade Entrega

O EASM nasceu de um problema concreto: ninguém sabe tudo que a organização expôs à internet. Aquisições, ambientes cloud descartáveis, shadow IT, certificados esquecidos, APIs de teste promovidas sem revisão e subdomínios criados por marketing formam uma superfície que cresce fora do CMDB. A capacidade EASM típica combina descoberta externa não autenticada, varredura de DNS e certificados, correlação com Certificate Transparency, alocação de ASN e fingerprinting de serviços, e entrega uma lista de ativos com vulnerabilidades, configurações incorretas e exposições como buckets abertos e painéis administrativos públicos.

Essa entrega é valiosa e insuficiente. O EASM responde o que está exposto, e o dado tende a vir empilhado por severidade técnica: o painel mostra milhares de achados ordenados por CVSS, com o executivo e o auditor olhando a mesma lista sem saber o que atacar primeiro. O modo tradicional de operar a capacidade, ciclos anuais de varredura seguidos de relatórios volumosos, transforma o dado em biblioteca estática, e a superfície muda mais rápido que a publicação. O resultado organizacional conhecido é a lista que ninguém abre: o relatório de duzentas páginas que circula por e-mail, impressiona na primeira leitura e vira arquivo morto até o ciclo seguinte, quando o mesmo exercício produz outro relatório com outros números e as mesmas decisões ausentes.

3. CTEM: Exposição como Programa Contínuo Gerido

O CTEM, formalizado pelo Gartner em 2022 e consolidado em guias subsequentes, reenquadra o problema: exposição não é um relatório, é um risco gerido em ciclo. O programa opera nas cinco fases de Scoping, Discovery, Prioritization, Validation e Mobilization, detalhadas na nota seguinte, e se distingue de qualquer capacidade isolada por quatro propriedades. É contínuo, operando em cadência semanal ou diária, não anual. É gerido, com dono, métricas e comitê que decide escopo. É dirigido por ameaça, usando CTI para pesar exposições pela relevância dos adversários reais. É orientado a ação, terminando sempre em decisão e correção orquestrada, não em mais um relatório.

A mudança de unidade de análise é o coração conceitual do CTEM. O EASM tradicional fala de achados, um host com uma CVE. O CTEM fala de exposições, a junção de um ativo crítico para o negócio, uma condição explorável e um adversário com interesse demonstrado nessa condição. A mesma CVE de severidade alta vale prioridades completamente diferentes em um sistema de recebimento de pedidos exposto e em um servidor de arquivos interno, e só o enquadramento de programa captura essa diferença sistematicamente.

4. CTEM, EASM e Gestão de Vulnerabilidades: Três Camadas Distintas

A confusão mais custosa no mercado é entre CTEM e gestão de vulnerabilidades, porque os dois falam de correção e os dois produzem filas. A gestão de vulnerabilidades opera sobre ativos conhecidos, majoritariamente internos, com o par varredura e correção guiado por severidade técnica e SLA por criticidade, e cumpre bem esse papel. O EASM amplia o inventário para fora do perímetro, e o CTEM organiza os dois como fontes dentro de um sistema de decisão maior, com peso de ameaça, validação e orquestração de correção entre times.

A divisão de trabalho prática é a seguinte: a gestão de vulnerabilidades continua existindo e executando, o EASM alimenta o programa com o que está fora, e o CTEM decide a ordem e o investimento. Uma CVE crítica em appliance de borda atravessa as três camadas em sequência didática: a gestão de vulnerabilidades detecta o host vulnerável, o EASM confirma que o appliance está exposto à internet, e o CTEM combina o achado com a exploração ativa reportada pela CTI e com a relevância do serviço para o negócio, elevando o item ao topo da fila com prazo negociado. Sem a camada de programa, o mesmo achado morre em uma fila de patch com prazo de trinta dias, exatamente a janela que grupos afiliados de ransomware usam para explorar appliances de borda recém-divulgados.

5. Por Que Inventário Não Basta

O argumento contra o inventário como fim não é teórico, é aritmético de operação. Uma superfície externa de porte médio gera milhares de achados em qualquer varredura séria, e o time de segurança que os recebe tem capacidade finita de correção por sprint. Ordenar por severidade técnica sozinha produz uma fila em que vulnerabilidades altas de sistemas irrelevantes competem com a mesma severidade em sistemas que movem receita, e o time escolhe por intuição, que é o nome gentil para sorte. O inventário sem gestão é, portanto, uma fábrica de backlog.

O segundo argumento vem do adversário. Grupos como LockBit e Scattered Spider não varrem a internet em ordem de CVSS; eles escolhem setores, checam exposições conhecidas que facilitam acesso inicial e abuso de identidade, e movem-se para onde a defesa é preguiçosa. Gerenciar exposição sem peso de ameaça é jogar xadrez sem olhar o tabuleiro do oponente. O terceiro argumento é temporal: entre a varredura e a correção, o ativo pode ter sido vendido, migrado ou corrigido, e achado sem validação vira ruído que ensina o negócio a ignorar o time de segurança. O CTEM endereça as três falhas com as fases de priorização, validação e mobilização, e é por isso que o EASM sobrevive dentro dele como fonte de dado, não como produto final.

O backlog gerado pelo inventário tem ainda um efeito perverso de governança. Com a fila crescente, a organização passa a medir progresso por itens fechados, e o time aprende a fechar itens fáceis, não a reduzir risco: exposição relevante com dono relutante afunda no fundo da fila enquanto achados triviais são drenados, e a métrica de produtividade comemora o movimento errado. O ciclo gerido do CTEM corrige esse viés porque a fila não é o produto, a redução de exposição relevante medida por ciclo é o produto.

6. Ciclos de Escopo e Priorização: O Motor do Programa

O ciclo do CTEM respira em duas frequências. A frequência de descoberta é contínua: varreduras, monitores de certificado, feeds de OSINT e corredores internos de registro de ativos alimentam o banco de exposição todos os dias. A frequência de decisão é periódica: com a cadência acordada, o comitê de exposição revisa o escopo, decide se os sistemas críticos do trimestre continuam sendo os mesmos, revalida o recorte de adversários relevantes com a CTI e aprova a fila de priorização que a fase seguinte vai atacar.

Essa separação de frequências resolve o dilema clássico entre exaustividade e velocidade. Ninguém precisa priorizar tudo simultaneamente; precisa garantir que o que foi escolhido para o ciclo atual seja o que mais reduz risco, e que a escolha seja reavaliada antes que o mundo mude e ela fique errada. Na prática, o recorte de adversários é o componente mais dinâmico: a ascensão de um grupo que explora VPNs de borda reordena a fila em dias, e a nota de Integração com Gestão de Vulnerabilidades mostra o cálculo concreto desse reordenamento.

7. Vetores de Exposição que o Programa Deve Cobrir

Um programa CTEM sério não é apenas varredura de internet, e o desenho do escopo deve reconhecer explicitamente os vetores que compõem exposição moderna. A tabela abaixo organiza os vetores com exemplos concretos de exposição típica em cada um. EASM clássico cobre a primeira linha; CTEM cobre todas, com pesos definidos pelo escopo.

A consequência prática da tabela é de orçamento: ferramenta EASM resolve um vetor, programa CTEM decide quanto investimento cada vetor merece. Organizações que descobrem a diferença tarde gastam o ciclo inteiro varrendo o perímetro enquanto a exposição real está numa policy de IAM que nunca foi lida.

8. Relação com CTI e Threat Hunting

O CTEM é o consumidor mais estruturado de inteligência em toda a biblioteca, e essa é a razão de ele aparecer depois dos capítulos de CTI. Os PIRs, Prioridades de Requisitos de Inteligência, definem quais adversários importam para a organização, e são esses adversários que dão peso às exposições do escopo; a inteligência tática e operacional fornece o sinal de exploração ativa que reordena a fila; e os catálogos públicos de vulnerabilidades exploradas oferecem o dado agregado que barateia essa avaliação. Sem esse aporte, o programa degrada para priorização técnica com vocabulário de ameaça, que é apenas gestão de vulnerabilidades com outro nome.

A relação com o threat hunting é de mão dupla, e vale fixar as duas direções. O CTEM entrega ao hunting uma carteira de hipóteses de altíssima qualidade, porque uma exposição validada e relevante é candidata natural a caça: se o consentimento OAuth suspeito existe, a pergunta imediata é se já foi usado, e a caça responde com evidência. Na direção oposta, a caça devolve ao programa a prova de abuso real, que é o insumo mais forte de priorização que existe, muito acima de qualquer pontuação de severidade, e essa troca transforma dois esforços que costumam operar isolados em um ciclo único de exposição e verificação.

9. Governança e Papéis do Comitê de Exposição

O comitê de exposição é o órgão que transforma dado em decisão, e desenhar seus papéis é o passo administrativo que mais determina a sobrevivência do programa. O desenho mínimo tem cinco assentos, cada um com responsabilidade explícita no ciclo, e a regra de funcionamento é simples: nenhuma exposição entra na fila sem dono de negócio, e nenhuma sai sem decisão registrada.

A agenda padrão do comitê cabe em sessão única de sessenta minutos: revisão das métricas do ciclo anterior, entrada de novas exposições relevantes, reordenação motivada por sinal de ameaça, decisão sobre itens bloqueados e ratificação dos riscos aceitos com prazo. O registro da decisão é o produto mais importante da reunião, porque a fila aprovada sem ata vira fila contestável na primeira crise de prioridade, e a ata é o que distingue risco aceito de risco esquecido.

A fila aprovada, por sua vez, tem formato padronizado, e o exemplo abaixo mostra o nível mínimo de contexto que cada entrada precisa carregar para ser acionável por quem não participou do comitê.

FILA DE EXPOSICAO DO CICLO (EXEMPLO)
E-001 | VPN de borda com CVE em catalogo de exploracao conhecida
      | adversario: afiliado de ransomware | P1 | prazo: 5 dias
E-002 | Bucket de nuvem publico com backup de teste exposto
      | adversario: coleta oportunista de dados | P2 | prazo: 15 dias
E-003 | Consentimento OAuth de aplicativo nao revisado no IdP
      | adversario: abuso de identidade | P1 | prazo: 10 dias
E-004 | Painel administrativo de teste acessivel da internet
      | adversario: mapeamento pre-ataque | P3 | prazo: 30 dias

10. Casos Públicos que Ilustram a Diferença

A história recente de incidentes serve como prova de conceito do enquadramento. O caso Scattered Spider é o mais didático: o grupo raramente quebra criptografia, explora helpdesk, abuso de reset de MFA e confiança organizacional, que são exposições de processo e identidade invisíveis a qualquer scanner de CVSS. O caso LockBit e seus afiliados mostra o padrão de exploração de appliances de borda com CVE conhecidas, em que o vencedor é quem patcheia em dias, não quem inventaria melhor. E o caso FIN11, com campanhas longas de exploração de superfície externa de setor financeiro, demonstra que a exposição é monitorada continuamente pelo adversário enquanto a casa só olha no ciclo anual.

A lição comum desses casos é que a pergunta certa nunca foi o que temos de vulnerável, e sim quais das nossas exposições o adversário que nos interessa explora hoje. Essa pergunta é operacional, muda toda semana e exige o aparato de CTI e validação que o CTEM traz embutido, razão pela qual o programa é descrito nesta biblioteca como extensão natural do ciclo de inteligência, e não como mais uma compra de ferramenta.

A comparação entre os casos também ensina sobre tempo de exposição. O grupo que explora appliance de borda opera na janela entre a publicação da exploração e o patch aplicado, e vencer essa corrida exige o ciclo contínuo de priorização e mobilização que o programa fornece. Já o caso de abuso de identidade mostra que a exposição pode ser antiga e conhecida internamente, apenas nunca tratada como risco gerido com dono e prazo. Em ambos os cenários, a variável decisiva não foi o volume de informação disponível, e sim a existência de um sistema que transformasse informação em decisão dentro da janela do adversário.

11. Como Começar em 90 Dias

A transição de EASM para CTEM não exige reorganização da empresa; exige um ciclo fechado de prova. O plano de 90 dias abaixo é o roteiro mínimo que a biblioteca recomenda para tirar o programa do papel com risco controlado, e cada passo pressupõe dono único e entrega datada.

• Dias 1 a 15, escolher dois sistemas críticos reais, nomear donos de negócio e técnico e registrar o escopo com adversários de referência derivados dos PIRs, resistindo à tentação de escolher sistema fácil em vez de sistema que importa.
• Dias 16 a 40, ligar as fontes de discovery do par de escopos: saída da plataforma EASM existente, inventário interno, permissões cloud relevantes e achados de VM, tudo convergindo para um registry único com vínculo de escopo.
• Dias 41 a 60, rodar a primeira priorização com os quatro fatores da nota de integração, validar as cinco exposições do topo com ataque controlado e publicar a fila aprovada com SLA, aceitando que a primeira rodada será feia e honesta.
• Dias 61 a 80, mobilizar: abrir tickets com prioridade CTEM, executar as correções rápidas e registrar as lentas como risco aceito com prazo, medindo tempo de exposição confirmada até correção.
• Dias 81 a 90, sentar o comitê com os números do ciclo, decidir a expansão de escopo e cravar a cadência definitiva, transformando o piloto em programa com calendário.

O critério de sucesso do piloto não é zerar achados, e sim demonstrar o circuito completo uma vez: exposição descoberta, priorizada por contexto, validada com evidência, corrigida com prazo e reavaliada. Esse circuito fechado é o que convence o comitê a expandir, e é também o que treina os times nos papéis que vão repetir indefinidamente.

12. Erros Comuns e Pontos de Atenção

O erro fundacional é acreditar que comprar uma plataforma EASM implanta CTEM, o que equivale a comprar EDR e acreditar que se comprou resposta a incidente. A ferramenta é o braço de descoberta; o programa é o sistema de decisão que a usa. O segundo erro é definir escopo por cobertura técnica, escolhendo priorizar tudo, o que é priorizar nada, e não por sistemas críticos do negócio com donos nomeados. Um terceiro é tratar a priorização como projeto de dados perfeito, esperando inventário completo para começar, quando o desenho correto aceita incompletude e usa validação para punir incerteza rapidamente.

Há também o erro inverso de importar o EASM para dentro e esquecer a superfície interna: o CTEM cobre exposição em qualquer perímetro, incluindo cadeia de suprimentos e terceiros, e restringi-lo ao que encara a internet reproduz a cegueira original sob outro rótulo. Um deslize sutil é confundir exposição com vulnerabilidade: ativo legítimo e correto que revela informação sensível, como um status page interna indexada, é exposição, e o programa que só enxerga CVE deixa esse material passar. Por fim, cuidado com métricas de vaidade, número de ativos descobertos cresce sempre; a métrica que importa é exposição relevante eliminada por ciclo, com a fila priorizada encurtando nos recortes que importam.

13. Integração com o Restante da Biblioteca

Esta nota abre o capítulo 21 e se apoia em três fundações anteriores: a nota de IOE do capítulo 3, que tipifica os sinais de exposição que a descoberta produz, o controle INS.3 do Framework CTH, que mapeia a superfície externa, e o capítulo 5, que fornece o aparato analítico de priorização por ameaça. As notas seguintes do capítulo operacionalizam o programa: a segunda detalha as cinco fases com entregas e critérios de saída, e a terceira mostra a fusão com a gestão de vulnerabilidades existente, o cenário real de quase toda organização que adota CTEM.

No horizonte da biblioteca, o CTEM é o consumidor natural de tudo que os capítulos 19 e 20 produziram: BAS e purple teaming validam exposições, e o ATT&CK estrutura a lente de adversários aplicada à fila de priorização. A leitura deste capítulo com o Framework CTH aberto transforma o programa em controles nomeados, donos e métricas, que é a forma que a biblioteca inteira usa para impedir que conceito bom morra em apresentação. O leitor que terminar o capítulo com uma frase na cabeça deve levar esta: o inventário responde o que existe, o programa responde o que faremos a respeito, e nenhuma compra de ferramenta produz a segunda resposta por si só.