Evolução das Táticas e Técnicas

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Explica como o
framework evolui: táticas estáveis como esqueleto, técnicas e subtécnicas em
expansão contínua, cloud, containers, identidade e IA como vetores de
crescimento, e a dinâmica de contribuição e deprecação que mantém o banco
vivo. Dialoga com as notas de Histórico de Versões e de Migração de
Mapeamentos deste capítulo e com MAP.5, Evolução Contínua da Cobertura.

1. Contexto e Posicionamento na Biblioteca

Quem consome o ATT&CK como um mapa estático erra duas vezes: subestima o ritmo de mudança e se surpreende quando mapeamentos, heatmaps e integrações quebram a cada release. Esta nota estabelece o modelo mental correto de evolução: a camada de táticas muda raramente e com impacto forte, a camada de técnicas e subtécnicas cresce de forma contínua em duas releases por ano, e os vetores de crescimento seguem a migração real dos adversários para cloud, identidade, contêineres e, mais recentemente, sistemas de IA.

Para a biblioteca, esta nota é o enquadramento das demais do capítulo: as notas de versão v18, v19 e v19.2 documentam releases específicas, e esta explica o motor que as produz. Ela também justifica o controle MAP.5 do Framework CTH, que exige revisão periódica de cobertura, porque o denominador das métricas de cobertura, a própria técnica, muda embaixo dos pés do programa.

2. Táticas Estáveis, Técnicas em Expansão

A coluna de táticas é a parte mais estável do ATT&CK: do Reconnaissance ao Impact, os objetivos do adversário mudam devagar, porque derivam do ciclo de ataque, não da tecnologia. A exceção prova a regra: a v19 de abril de 2026 dividiu Defense Evasion em Stealth e Defense Impairment, a maior mudança tática em anos, tema da nota própria deste capítulo. Quando uma tática muda, todo recorte por tática quebra de uma vez, das layers do Navigator aos dashboards de cobertura.

As técnicas e subtécnicas, em contraste, seguem em expansão líquida contínua. O domínio Enterprise atravessou a casa das 200 técnicas e 400 subtécnicas e seguiu crescendo, com cada release trazendo técnicas novas, divisões de técnicas antigas em subtécnicas e, menos frequentemente, deprecações. O ritmo tem duas forças: a observação do adversário real, alimentada por relatórios públicos e privados, e a reorganização interna do banco, que periodicamente refina granularidade onde a detecção exige, como a cisão da antiga T1021 de movimento lateral em uma técnica-mãe com sete subtécnicas de protocolos distintos.

3. Vetores de Crescimento: Cloud, Containers, Identidade e IA

O crescimento do ATT&CK não é uniforme; ele segue o dinheiro e a infraestrutura do adversário. O vetor cloud foi o primeiro a acelerar: técnicas de IaaS, SaaS e identity providers entraram em volume a partir da segunda metade da década passada, cobrindo abuso de tokens, manipulação de policies e persistência em funções serverless, e o framework criou explicitamente plataformas como IaaS, SaaS e Office 365 para acolher esse material. Containers e Kubernetes vieram na sequência, com técnicas de execução em pods, abuso de imagens e manipulação de API server consolidadas nas releases de 2024 e na v19.2 de agosto de 2026, que detalha Kubernetes e CI-CD em nota própria.

Identidade é hoje o vetor dominante no Enterprise, refletindo adversários como Scattered Spider e grupos de ransomware que preferem logar a quebrar: manipulação de federation trust, abuso de OAuth applications, device code phishing e persistência em enrolamento de dispositivos formaram uma frente inteira de Credential Access e Persistence. O vetor mais recente é IA: técnicas de abuso e ataque a sistemas de IA, alinhadas com o MITRE ATLAS, entraram no banco na v19.2, e a nota de Técnicas Específicas de Ameaças com IA deste capítulo cobre o material. A lição operacional é que a superfície do framework cresce onde a casa menos tem telemetria madura, o que explica por que médias de cobertura caem sem que ninguém tenha desligado nada: o denominador cresceu.

A leitura correta da tabela é direção de esforço: onde o vetor expande rápido e a casa tem telemetria fraca, ali nasce o próximo gap de cobertura, e é ali que a caça e a engenharia de detecção devem ser direcionadas antes que o comitê descubra a lacuna em um teste de intrusão.

Vale também definir como se sabe que a casa acompanhou um vetor, e não apenas leu sobre ele. Os sinais abaixo são objetivos e cabem na revisão semestral do comitê de cobertura.

• As técnicas novas do vetor na última release já foram triadas contra os PIRs, com decisão de priorizar ou descartar registrada por técnica.
• A telemetria exigida pelas técnicas priorizadas aparece no inventário de dados do grupo DAT, com lacuna formalmente registrada quando não existe.
• A camada de adversários do Navigator já reflete as técnicas do vetor para os grupos relevantes, e não apenas para os grupos históricos.
• Há pelo menos uma caça ou teste BAS executado no vetor no último trimestre, com resultado registrado na camada de caças.

4. Dinâmica de Contribuição e Deprecação

O banco é alimentado por contribuições externas coordenadas pelo MITRE, por trabalho de equipes patrocinadas e por material derivado de relatórios de ameaça. O ciclo típico começa em issue pública ou proposta de técnica, passa por avaliação de evidência, precisa demonstrar comportamento observável em ambiente real e só então entra em release, com crédito registrado na página da técnica. Times de detecção e CTI podem contribuir em três frentes úteis: propostas de técnica nova amparadas em relatório, correções de contexto e fontes de detecção, e sugestões de refinamento de granularidade onde uma técnica agrupa comportamentos detetáveis de forma distinta.

O material que melhor acelera uma contribuição aceita segue um padrão constante, e prepará-lo antes de abrir a proposta reduz semanas de ida e volta com os mantenedores.

• Relatório público ou interno que descreva o comportamento observado em ambiente real, com a técnica candidata proposta e o contexto do adversário.
• Exemplo de log ou evento que demonstre a observabilidade do comportamento em pelo menos uma plataforma comum, porque proposta sem telemetria morre na avaliação.
• Distinção clara em relação às técnicas existentes mais próximas, explicando por que a granularidade nova é detetável de forma diferente.

A saída de material segue dois caminhos com semântica diferente, e confundi-los causa erros de integração. Deprecação marca a técnica como obsoleta e a substitui por outra, com o campo x_mitre_deprecated e a referência de substituição; consumidores decentes devem remapear. Revogação (revoked) indica que o conteúdo foi fundido ou reorganizado, com relacionamento de revoked-by apontando para o destino. Em ambos os casos o identificador antigo permanece no banco para preservar histórico e links, o que significa que contar técnicas sem filtrar deprecadas infla cobertura inexistente.

Fluxo do ciclo de vida de uma técnica no ATT&CK
Proposta (issue pública ou trabalho interno MITRE)
  -> avaliação de evidência e discussão comunitária
  -> aprovação e entrada em release semestral com x_mitre_version
  -> revisões incrementais (0.1, 0.2) conforme contexto melhora
  -> deprecação ou revogação quando observação se funde em outra
  -> objeto permanece no banco marcado, com substituição indicada

A tabela abaixo resume os marcadores de ciclo de vida que os consumidores devem tratar explicitamente. Ela é o contrato mínimo que qualquer integração séria com o banco precisa implementar antes de calcular qualquer métrica.

Alguns episódios de reorganização ficaram célebres pelo custo de reatribuição que geraram, e conhecê-los ajuda a estimar o esforço de mudanças futuras do mesmo tipo.

A leitura desses episódios reforça uma regra de bolso: mudanças de granularidade são mais custosas para quem mantém mapeamentos do que adições, porque reorganizam o que já estava contado, e por isso a fila de revisão da nota de Migração de Mapeamentos e Controles as trata com prioridade entre a deprecada e a nova.

5. Como Acompanhar o Changelog por Versão

Cada release publica changelog com seções de técnicas novas, técnicas alteradas, relações de revogação e deprecação, grupos adicionados e objetos defensivos, além de notas de migração quando há mudança estrutural. Para consumo automatizado, o repositório público de dados do ATT&CK publica os bundles STIX de cada versão, e o campo x_mitre_version de cada objeto permite detectar o que mudou sem depender de leitura manual. O padrão saudável em um time de CTI é uma revisão guiada no dia do lançamento, seguida de diff automatizado no fim da mesma semana, tema aprofundado na nota de Migração de Mapeamentos e Controles.

O recorte prático para CTI é acompanhar grupos e técnicas usadas pelos adversários dos PIRs na mudança, não o changelog inteiro: uma release pode adicionar dezenas de técnicas de ICS irrelevantes para um banco que não opera OT, e o time que trata toda mudança como igual afoga na leitura. O recorte prático para detecção é o inverso: técnicas novas sem analytics correspondente e técnicas alteradas que podem ter quebrado regras existentes merecem varredura completa.

A propriedade da revisão também precisa estar respondida antes do anúncio da release: uma pessoa nomeada do time de CTI é responsável pela revisão guiada, e uma pessoa da engenharia de detecção é responsável pelo diff. Times que assumem que o changelog será lido por alguém descobrem, na release seguinte, que ninguém leu nada.

O diff automatizado básico é curto com a biblioteca attackcti, e o snippet abaixo lista técnicas novas e deprecadas comparando dois bundles baixados. Ele é a semente do processo formal descrito na nota de migração, e roda em minutos com Python e os arquivos STIX das duas versões.

from stix2 import MemoryStore

velho, novo = MemoryStore(), MemoryStore()
velho.load_from_file("enterprise-attack-v17.json")
novo.load_from_file("enterprise-attack-v19.json")

ids_velho = {o["external_references"][0]["external_id"]
             for o in velho.source["objects"] if o["type"] == "attack-pattern"}
ids_novo  = {o["external_references"][0]["external_id"]
             for o in novo.source["objects"] if o["type"] == "attack-pattern"}

print("Novas:", sorted(ids_novo - ids_velho))
print("Deprecadas ou removidas:", sorted(ids_velho - ids_novo))

6. Exemplo de Tabela de Evolução por Domínio

A tabela abaixo consolida a leitura de evolução por domínio do framework, com foco no que o time de CTI e detecção precisa reavaliar a cada ciclo. Ela é o insumo típico da revisão semestral do comitê técnica descrita em MAP.5, e deve ser reconstruída a cada release a partir do changelog, não copiada.

Essa tabela por domínio deve nascer do changelog de cada release e morrer no fim do ciclo seguinte, quando é substituída. Guardar as versões anteriores da tabela em repositório dá ao programa um registro histórico de como a superfície do framework se moveu, dado que se revela valioso quando o comitê pede justificativa de investimento em telemetria de um domínio específico.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é tratar a versão do framework como evento cosmético e descobrir na prática que um identificador delegado de pai para filho, como quando uma técnica vira subtécnica, deixou dashboards apontando para nada. O segundo erro é contar técnicas deprecadas nas métricas de cobertura, inflando números sem nenhum conteúdo operacional. Um terceiro é ignorar a data de revisão dos objetos: técnica sem revisão há cinco anos em domínio que evolui rápido pode estar desatualizada em contexto, e usá-la em relatório de CTI sem checagem arrisca desinformar o comitê.

Há também o erro de leitura inversa, presumir que técnica nova implica lacuna de detecção da casa. Técnicas novas entram com evidência de adversário, mas a prevalência no seu setor pode ser baixa, e a nota de Threat Prevalence e Priorização do capítulo 18 é o antídoto: priorize pela combinação de novidade, prevalência e relevância para adversários dos PIRs, não pela ordem alfabética do changelog. Por fim, cuidado com o efeito colecionador de grupos: adicionar cada grupo novo citado na imprensa à camada de adversários dilui os PIRs, e a regra da biblioteca é que grupo entra na camada quando há relevância para o setor e evidência de TTPs aplicáveis, não quando há manchete.

8. Integração com o Restante da Biblioteca

Esta nota fundamenta a cadência de revisão exigida pelo controle MAP.5 do Framework CTH e prepara o terreno para as três notas seguintes deste capítulo: a de Mudanças no Modelo de Dados e Detecções, que detalha o que muda para consumidores STIX e TAXII, a de Migração de Mapeamentos e Controles, que operacionaliza a reatribuição, e a de Histórico de Versões e Impactos Operacionais, que cronometra a adoção. No eixo de CTI, ela dialoga com a nota de Mapeamento de Atores de Ameaças do grupo MAP, porque camadas de adversários também envelhecem com o banco, e com a Pirâmide de Dor, que lembra por que o foco em TTPs sobrevive melhor a essas mudanças do que qualquer lista de IOCs.