Fases do CTEM (Scoping, Discovery, Prioritization, Validation, Mobilization)

Nota central do capítulo 21, dedicado ao CTEM. Detalha as cinco fases do
programa definido pelo Gartner, Scoping, Discovery, Prioritization, Validation
e Mobilization, com entregas e critérios de saída por fase, e mostra como o
ciclo opera na prática de uma organização real. Dialoga com a nota de
Conceitos e Diferenças do EASM Tradicional, com o capítulo 19 de Purple
Teaming e BAS para a fase de validação e com o grupo AUT do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

A nota anterior fixou a fronteira entre capacidade e programa; esta desmonta o programa em fases operáveis. A leitura correta das cinco fases do CTEM não é sequencial rígida, é um ciclo com esteira dominante: escopo delimita onde olhar, descoberta alimenta continuamente, priorização ordena, validação pune incerteza e mobilização transforma decisão em correção executada. Cada fase tem entregas nomeadas e critérios de saída, porque fase sem critério de saída é reunião sem pauta.

A nota se apoia em infraestrutura construída nos capítulos anteriores: PIRs do capítulo 5 para o recorte de ameaça, BAS e purple teaming do capítulo 19 para validação, ATT&CK do capítulo 20 como lente estrutural de técnicas, e o grupo AUT do Framework CTH para orquestração da mobilização. O objetivo é que o leitor saia da nota capaz de desenhar o cronograma de um programa CTEM em sua organização, não apenas de explicar o quadro do Gartner em uma reunião.

2. Scoping: Delimitar por Sistemas Críticos

Scoping é a fase que decide o que o programa se compromete a gerir, e a decisão certa é recortar por sistemas críticos do negócio, não por cobertura técnica total. O recorte parte do inventário de processos de negócio, identifica os sistemas que os sustentam e nomeia donos: o processo de pagamentos puxa o gateway, o repositório de clientes, o IdP e o ambiente cloud que os hospeda. Cada escopo ganha documento com fronteira, ativos de referência, adversários plausíveis derivados dos PIRs e critérios de exposição relevante para aquele contexto.

O erro estrutural de scoping é ambição inversa: começar por tudo e por nada. Organizações que abrem o escopo para toda a superfície no primeiro ciclo descobrem que a fila priorizada é gigante e ninguém executa nada, e o programa morre de indigestão. A prática saudável inicia com dois ou três escopos críticos, fecha o ciclo completo uma vez e só então expande. O critério de saída é simples: cada escopo tem dono de negócio, dono técnico, lista de sistemas e conjunto de adversários de referência, e nenhum dos quatro pode estar implícito.

3. Discovery: Descoberta Contínua e Registry de Exposições

Discovery no CTEM é mais que varredura EASM: é a coleta contínua de toda condição que, combinada ao escopo, caracteriza exposição. As fontes se dividem em externas, internas e de contexto. Externas incluem varredura não autenticada, monitoração de DNS e certificados, Certificate Transparency, feeds de OSINT e serviços de descoberta contratados. Internas incluem agentes de inventário, análise de IaC em repositórios, permissões cloud e de identidade, e ferramentas de gestão de vulnerabilidades existentes. Contexto vem da CTI: adversários ativos, técnicas que exploram, CVEs com exploração confirmada.

A entrega central é o registry de exposições, o dado estruturado que alimenta tudo o que vem depois. Cada registro carrega o ativo, a condição, a fonte que observou, a primeira e a última observação, o vínculo com o escopo e os identificadores técnicos, CVE, técnica ATT&CK quando aplicável e referência de configuração. A tabela a seguir resume as fontes por classe e o que cada uma entrega ao registry.

O trecho abaixo mostra o formato mínimo de um registro do registry. O formato é propositalmente simples para ser implementado em qualquer ferramenta, de banco relacional a arquivo JSON versionado, e os campos são os que as fases seguintes consomem.

{
  "id_exposicao": "EXP-2026-0417",
  "escopo": "pagamentos-varejo",
  "ativo": "lb-pagamentos-02.corp.example",
  "condicao": "TLS 1.0 habilitado com cipher fraco em VIP externa",
  "fonte": "easm_scan",
  "primeira_observacao": "2026-08-04",
  "ultima_observacao": "2026-09-01",
  "referencias_tecnicas": {
    "cve": null,
    "tecnica_attack": "T1600",
    "config": "haproxy.cfg#frontend-pay"
  },
  "estado": "descoberta"
}

O critério de saída da fase em cada ciclo é a atualização completa do registry: nenhuma fonte programada pode estar atrasada, e todo registro novo precisa estar vinculado a um escopo, porque exposição sem escopo é dado órfão que ninguém vai priorizar nem corrigir.

4. Prioritization: Ranking por Risco de Exposição

Prioritization ordena o registry por risco de exposição combinado, e a fase é o núcleo intelectual do programa. O cálculo combina quatro fatores que a biblioteca trata separadamente: severidade técnica da condição, probabilidade de exploração, com EPSS e presença no KEV como sinais objetivos, criticidade do ativo no escopo e relevância para adversários prioritários, derivada da CTI e do ATT&CK. A nota de Integração com Gestão de Vulnerabilidades detalha o cálculo com exemplo numérico; aqui o que importa é o desenho da fase.

A entrega da fase é a fila de exposições priorizada com faixa de SLA por prioridade, e a disciplina da fila é o que separa programa de relatório. Exposições no topo da fila têm dono de correção nomeado no mesmo dia da aprovação, e exposições que não entraram na fila recebem tratamento explícito de aceitação de risco com revisão datada, nunca silêncio. O critério de saída é a fila aprovada pelo comitê com capacidade de execução real do time de correção, porque fila maior que a capacidade destrói a credibilidade dos SLAs e ensina o negócio a ignorar prazos.

5. Validation: Ataque Controlado Antes de Gastar

Validation é a fase que separa o CTEM de qualquer programa de vulnerabilidades anterior: nenhuma exposição sobe para correção cara, e nenhuma é descartada como falso positivo, sem validação controlada. A validação opera em três níveis de custo crescente. O primeiro é validação de alcançabilidade, verificando com prova técnica se a condição é realmente explorável de onde um adversário estaria. O segundo é validação com BAS, executando emulação de técnica ATT&CK específica, com Atomic Red Team ou plataforma comercial, para confirmar se a condição se materializa e se os controles reagem. O terceiro é exercício purple team dirigido, do capítulo 19, para exposições complexas ou críticas demais para automação.

O resultado da validação é sempre um dos quatro estados documentados: confirmada, quando a exploração funciona e a detecção falhou; confirmada com detecção, quando o ataque funciona mas o controle alerta, o que muda o peso do risco; refutada, com evidência técnica que fecha o registro; e inconclusiva, que reentra na fila com custo de validação maior. O critério de saída é que todo item da fila priorizada do ciclo tenha estado de validação registrado com evidência anexada, e a métrica de qualidade da fase é a taxa de refutação: taxa alta indica que a priorização está inflada, e taxa zero indica que a validação é encenação.

6. Mobilization: Orquestrar a Correção que Já Está Atrasada

Mobilization é a fase que o Gartner acrescentou ao desenho original para resolver o gargalo real: em quase toda organização, o problema não é saber, é executar. A fase transforma a fila validada em trabalho entregue, e o meio é orquestração, não e-mail. Exposições confirmadas viram tickets com campo de prioridade CTEM, prazo derivado da faixa de SLA, evidência anexada e dono técnico nomeado. Ações que não são patch, como fechar bucket, revogar token longevo, corrigir policy IAM ou ativar MFA, viram playbooks de automação no SOAR ou em ferramenta de workflow, com o grupo AUT do Framework CTH como referência de desenho.

O trecho abaixo é um playbook mínimo de mobilização para a exposição do registry da seção 3, no formato de workflow declarativo usado pelo capítulo de automação da biblioteca. O ponto essencial é que o playbook recebe o registro, aplica a correção, revalida e fecha o circuito sem dependência de memória de equipe.

nome: mobilizacao-tls-legado
disparo: exposicao com condicao "TLS 1.0 habilitado" e estado confirmada
passos:
  - abrir_ticket:
      sistema: itsm
      prioridade: do_campo_ctem
      sla_dias: 7
      evidencia: anexo do relatorio de validacao
  - aplicar_correcao:
      alvo: lb-pagamentos-02
      acao: desabilitar TLS 1.0 e cipher fraco no frontend pay
      janela: com aprovacao do dono tecnico do escopo
  - revalidar:
      ferramenta: bas
      tecnica_attack: T1600
      criterio: negociação TLS 1.0 deve falhar
  - atualizar_registry:
      ao_sucesso: estado correcao-confirmada, ultima_observacao hoje
      ao_falhar: reabrir_ticket com anexo da revalidação

A fase também executa os casos que a correção não resolve: quando o patch não existe ou o sistema não pode parar, mobilization dispara mitigação compensatória, segmentação, regra de detecção dedicada no SIEM com vínculo ATT&CK e monitoração reforçada, e registra a decisão como risco aceito com prazo. O critério de saída do ciclo é a contabilidade honesta da fila: cada exposição aprovada está corrigida, mitigada ou formalmente aceita, com as três respostas nomeadas e datadas.

7. Tabela Resumo das Fases, Entregas e Critérios de Saída

A tabela abaixo é o cartão de referência do programa, adequado para virar página de processo interno. Ela presume ciclo mensal de decisão com descoberta contínua entre decisões, ajustável à maturidade da organização.

Duas notas de operação completam o quadro. A fase de discovery nunca para entre decisões, porque superfície muda diariamente, e o comitê decide sobre a fotografia mais recente possível. E a sequência pode iterar dentro do ciclo: validação que refuta devolve aprendizado à priorização, e correção que falha na revalidação devolve o item à fila, o que caracteriza o programa como circuito e não como esteira rígida de cinco estações.

8. Métricas do Programa por Fase

Cada fase tem métrica que revela sua saúde, e o painel do comitê deve mostrar as cinco juntas. Scoping mede cobertura dos sistemas críticos por escopos ativos e idade da última revisão de escopo. Discovery mede tempo médio de primeira observação de ativo novo e proporção de registros órfãos, que deve tender a zero. Prioritization mede tempo de decisão da fila e distribuição de aceites de risco, porque crescimento de aceites é alerta antecipado de esgotamento do time de correção. Validation mede taxa de refutação e custo médio de validação por classe de exposição. Mobilization mede tempo de exposição confirmada até correção, o MTTR contextualizado do programa, e proporção de correções que sobrevivem à revalidação do ciclo seguinte.

A leitura conjunta das métricas é o que impede otimização local deformante: discovery veloz com mobilization lenta cria backlog bonito e risco constante, e mobilization com taxa de reabertura alta indica que a validação está fraca. O programa é saudável quando a exposição relevante, nos recortes de escopo crítico, cai ciclo após ciclo com taxa de refutação estável e baixa.

9. Erros Comuns e Pontos de Atenção

O erro mais frequente por fase tem nome próprio. Em scoping, é escolher escopo por facilitação política, pegando sistemas cujo dono é cooperativo em vez de sistemas que importam. Em discovery, é acumular ferramentas que não se fundem no registry, gerando cinco listas que ninguém consegue reconciliar. Em prioritization, é delegar a ordenação ao score do scanner, devolvendo o programa à severidade técnica pura que ele existiu para superar. Em validation, é validar apenas o barato e rotular o restante como confirmado por inferência. Em mobilization, é medir abertura de ticket como sucesso, quando ticket aberto não corrigiu risco nenhum.

Um erro transversal merece destaque: rodar as fases com ritmos iguais. Descoberta é contínua, priorização é quinzenal ou mensal, validação tem fila própria e mobilização acompanha o cadenciamento dos times de entrega. Forçar um único ritmo produz gargalos artificiais em fase alguma e ociosidade em outras, e a correção é reconhecer explicitamente as frequências diferentes no desenho do processo. Outro erro transversal é deixar o registry virar arquivo morto: registro com mais de dois ciclos sem observação nova deve ser revalidado ou descartado com registro da decisão, porque registry inflado é priorização diluída.

10. Integração com o Restante da Biblioteca

As fases do CTEM absorvem instrumentos construídos em toda a biblioteca: os PIRs do capítulo 5 dirigem o recorte de adversários do scoping, o ATT&CK do capítulo 20 estrutura a lente de técnicas da priorização e da validação, e o BAS e o purple teaming do capítulo 19 executam a fase de validação com custo previsto. No Framework CTH, o programa se ancora nos grupos INS, para inventário e superfície, AUT, para orquestração da mobilização, e MET, para o painel de métricas por fase.

A nota seguinte fecha o capítulo mostrando a integração com a gestão de vulnerabilidades existente, que é o cenário real de adoção: quase nenhuma organização implanta CTEM do zero, todas migram um processo de VM vivo para dentro do ciclo. A tabela de fases desta nota é o contrato que essa migração precisa cumprir, e o ranking combinado da nota seguinte é o primeiro artefato concreto que os times de VM verão mudar.