Relacionamento com Outros Frameworks (CIS, NIST, ATT&CK)

Nota de visão geral do Framework CTH, derivada da seção 1.3 do Capítulo 1 do PDF de referência.
Estabelece a filosofia de complementar e não substituir os padrões consolidados de mercado.
Mapeia o CTH contra CIS Controls v8, NIST CSF 2.0, MITRE ATT&CK, OTHF, TaHiTI e ISO 27001, com orientação prática de uso combinado.

1. Contexto e Posicionamento no Framework CTH

Nenhum framework de segurança surge em um vácuo, e o CTH não é exceção. Ele foi desenhado para operar sobre padrões já adotados pela maioria das organizações, aproveitando o que eles entregam bem e preenchendo as lacunas que eles deixam. Compreender essa arquitetura de relacionamento evita dois erros opostos: descartar padrões consagrados em nome de uma novidade, ou continuar apenas com os padrões existentes e nunca construir capacidade proativa.

Esta nota serve de guia para equipes que já possuem algum nível de adoção de CIS Controls, NIST CSF ou MITRE ATT&CK. O objetivo é responder a três perguntas operacionais: o que o CTH herda de cada framework, o que ele adiciona e como usar tudo junto sem duplicar esforço. A recomendação de leitura é aplicar esta nota junto com a estrutura dos 8 grupos de controles, pois as referências cruzadas usam os prefixos INS, GOV, COL, ANA, HNT, DET, RES e AUT.

2. Filosofia: Complementar, Não Substituir

O princípio declarado do framework é claro: o CTH não busca substituir frameworks existentes, mas complementá-los e integrá-los em um contexto específico de inteligência de ameaças e caça proativa. Essa decisão tem consequências práticas de adoção. A organização não precisa rever contratos, políticas ou avaliações já feitas em outros padrões; precisa, sim, mapear onde o CTH adiciona profundidade que os demais não entregam.

Três argumentos sustentam essa filosofia de complementaridade:

• Bases amplas como o CIS Controls v8 e o NIST CSF 2.0 cobrem higiene, governança e gestão de risco, que são pré-requisitos lógicos de qualquer programa de CTI e caça; recriar isso seria desperdício.
• Frameworks focados como OTHF e TaHiTI entregam profundidade metodológica na caça, mas por definição não cobrem governança, coleta de telemetria, resposta a incidentes e automação, que o CTH integra ao pipeline.
• O MITRE ATT&CK é uma taxonomia descritiva, e não um programa de controles; o CTH o usa como linguagem comum para hipóteses, cobertura e lacunas, sem tentar competir com ele.

Na prática, essa filosofia se traduz em uma regra de ouro para o time de segurança: manter cada framework na função que desempenha melhor. O CIS responde "quais salvaguardas de higiene preciso ter", o NIST CSF responde "como organizo o programa de risco em funções", o ATT&CK responde "como o adversário opera e onde tenho lacunas", e o CTH responde "como transformo isso em um programa integrado e contínuo de inteligência e caça".

3. Tabela Comparativa com os Frameworks de Referência

A tabela a seguir consolida o relacionamento entre o CTH e os principais padrões citados no PDF de referência, acrescentando o uso recomendado de cada um quando combinados.

Essa leitura em tabela precisa se converter em prática de gestão de portfólio. Uma forma eficaz é manter uma matriz única de controles da organização, na qual cada linha de controle cita os padrões que o atendem: por exemplo, um controle interno de inventário pode citar CIS 1, NIST CSF ID.AM e CTH INS.1 simultaneamente. Assim, a mesma evidência atende auditorias e avaliações diferentes sem retrabalho.

4. Mapeamento CTH para as Funções do NIST CSF 2.0

O NIST CSF 2.0 organiza o programa de segurança em seis funções: Govern (GV), Identify (ID), Protect (PR), Detect (DE), Respond (RS) e Recover (RC). O CTH contribui de forma desigual entre elas, com concentração natural nas funções de detecção e resposta, mas com contribuições relevantes nas demais. O mapeamento abaixo orienta o gestor a localizar os controles do CTH na estrutura de reporte que a organização já usa.

Dois cuidados tornam esse mapeamento útil na prática. Primeiro, ele deve ser mantido como tabela viva do programa, revisada quando novos controles forem implementados, porque a função Identify do CTH costuma crescer com a evolução do EASM. Segundo, o mapeamento facilita conversas com áreas de risco e compliance, que normalmente já reportam pelo CSF, e evita que o programa de CTI e caça apareça nas apresentações executivas como um esforço paralelo e incompreensível.

Uma forma operacional de converter o mapeamento em reporte é estruturar o dashboard executivo pelas funções do CSF, com os indicadores do CTH distribuídos dentro delas:

Estrutura de reporte executivo por função do NIST CSF 2.0:
- GV: patrocínio ativo, orçamento aprovado e meta de maturidade do programa CTH.
- ID: cobertura do inventário, exposições externas abertas e IOEs em tratamento.
- DE: cobertura de detecção por tática, hipóteses de caça testadas e MTTD.
- RS: MTTR, incidentes contidos e lições aprendidas convertidas em regras.
- RC: restaurações completas e lacunas de detecção fechadas após cada incidente.

Com esse modelo, o gestor responde às perguntas clássicas de comitê (onde estamos, para onde vamos e o que precisamos) usando uma estrutura que a área de risco já reconhece, enquanto a execução técnica continua ancorada nos controles do CTH.

5. O Papel do MITRE ATT&CK dentro do CTH

O ATT&CK merece uma seção própria porque exerce função transversal no framework, e não a função de mais um padrão na lista. Ele é a linguagem comum em pelo menos três momentos distintos do ciclo: na formulação de hipóteses de caça, na produção de inteligência tática e na medição de cobertura de detecção. Sem esse idioma comum, hipóteses de hunters, relatórios de CTI e regras de detecção do SOC ficam em vocabulários diferentes e não se encaixam.

As contribuições operacionais mais visíveis do ATT&CK no CTH são quatro:

• Tradução de TTPs de relatórios de inteligência em técnicas e subtécnicas identificáveis, o que permite buscar por comportamento e não por indicador atômico.
• Estruturação de hipóteses de caça por tática, como persistência, elevação de privilégio e movimento lateral, facilitando a priorização por relevância de risco.
• Heatmaps de cobertura por tática, produzidos pelo grupo MAP, que mostram visualmente onde a organização tem detecção forte e onde está cega.
• Análise de lacunas que direciona a criação de novas regras Sigma, YARA e de IDS/IPS, bem como o agendamento de caças nos pontos de maior risco.

Um exemplo concreto de encaixe: a inteligência publica que um grupo específico usa execução via WMI e persistência em serviço. O hunter formula a hipótese com os códigos de técnica correspondentes, o SOC recebe a regra de detecção derivada do finding, e o gestor acompanha no heatmap que a tática de execução ganhou cobertura. O mesmo fenômeno percorre três públicos com uma única taxonomia, e é essa economia de tradução que o CTH sistematiza.

O template a seguir ilustra o formato recomendado de hipótese ancorada no ATT&CK, adotado nos controles de formulação do grupo HNT:

Template de hipótese de caça ancorada no ATT&CK:
- Origem: relatório tático interno sobre o grupo X, com TTPs confirmadas.
- Comportamento: execução remota via WMI (T1047) seguida de criação de serviço (T1543.003).
- Fontes de dados: Sysmon Event ID 1, Windows Security Event ID 7045, telemetria de endpoint.
- Consulta inicial: processo com pai wmiprvse seguido de sc.exe create em janela de 10 minutos.
- Resultado esperado: lista de hosts suspeitos, IOCs extraídos e decisão de criar regra Sigma.

Note que a hipótese nasce de uma técnica, e não de um indicador atômico. Isso é deliberado: indicadores trocam rápido, enquanto técnicas carregam custo de mudança para o adversário, na lógica da Pirâmide de Dor. A hipótese bem escrita sobrevive à troca de infraestrutura do atacante e continua gerando detecção útil meses depois.

6. Exemplo Concreto: Do CIS 1 e 2 ao Grupo INS

O exemplo citado no PDF de referência merece detalhamento, porque representa o caminho mais comum de adoção. Considere uma organização que já implementa os controles CIS 1 (Inventário e Controle de Ativos Empresariais) e CIS 2 (Inventário e Controle de Ativos de Software). Ela já tem inventário razoável de endpoints e software, provavelmente alimentado por ferramentas de gerenciamento de configuração. O grupo INS do CTH evolui esse patrimônio em três direções que o CIS não exige com a mesma profundidade.

O resultado prático desse salto é mensurável. A organização passa de saber "o que existe" para saber "o que está exposto, para quem isso importa e como se comporta em normalidade". É essa camada extra que transforma inventário, um controle clássico de higiene, em insumo para priorização de correção, formulação de hipóteses e verificação de exposição após campanhas públicas de exploração.

O mesmo raciocínio se aplica a outros pares. A organização madura em CIS 8 (gerenciamento de logs) evolui para COL com qualidade e retenção orientadas a caça. A organização com boa proteção de endpoint no CIS 10 evolui para HNT usando a telemetria existente em hipóteses ativas. Em todos os casos, o CTH adiciona a dimensão proativa e orientada por ameaça sobre uma base que já funciona.

7. Como Usar Frameworks em Conjunto sem Duplicar Esforço

A combinação de frameworks só agrega valor se cada um tiver responsabilidade única e clara. A experiência de adoção indica cinco práticas que evitam sobreposição e fadiga de evidência:

• Definir a fonte única de verdade por domínio: por exemplo, o inventário vive no processo INS e é referenciado por CIS e CSF, e não o contrário, com três inventários divergentes.
• Mapear, e não reescrever: construir uma matriz cruzada que aponte quais salvaguardas do CTH atendem requisitos do CIS, do CSF e da ISO, citando IDs de ambos os lados.
• Unificar a evidência: uma única captura de tela, consulta ou relatório serve para todas as avaliações que exigem a mesma prova, desde que o mapeamento esteja documentado.
• Alinhar o calendário: realizar uma única avaliação interna anual que gere resultados para todos os frameworks mapeados, em vez de campanhas separadas por padrão.
• Separar linguagem de gestão e linguagem técnica: reportar à liderança pelas funções do CSF e executar no dia a dia pelos controles do CTH, evitando discussões taxonômicas em reuniões operacionais.

A regra prática que resume a seção é simples: cada processo da organização deve ter um dono, um controle primário e um mapeamento para os padrões que ele atende. Quando essa regra é respeitada, adotar o CTH não adiciona carga de auditoria, e sim reaproveita evidências existentes para uma finalidade nova, que é a operação proativa contra adversários.

O registro de mapeamento a seguir exemplifica o formato mínimo recomendado para cada controle integrado ao programa:

Registro de mapeamento de um controle (formato sugerido):
- Controle primário: INS.3, Mapeamento de Superfície de Ataque Externa.
- Frameworks atendidos: CIS Controls v8 12.2, NIST CSF ID.AM-01, ISO 27001 A.5.9.
- Evidência única: export mensal do inventário EASM com registro de diferenças entre varreduras.
- Dono: arquitetura de segurança, com revisão trimestral do mapeamento.

Com registros nesse formato espalhados pelo programa, a organização constrói um inventário de conformidade cruzada que serve a qualquer avaliação. O esforço marginal de citar mais um padrão em cada controle é mínimo, e o retorno em economia de evidência é proporcional ao número de auditorias que a área enfrenta por ano.

8. Erros Comuns na Combinação de Frameworks

A combinação de padrões também tem suas armadilhas, e identificá-las com antecedência economiza meses de retrabalho. Os erros a seguir aparecem com recorrência em programas que tentam integrar CTH, CIS, CSF e ATT&CK sem governança do próprio mapeamento:
- Tentar implementar todos os frameworks ao mesmo tempo, o que dispersa capacidade e produz adoção superficial de todos; o correto é evoluir por ondas de controles.
- Tratar o mapeamento entre frameworks como projeto único e definitivo, quando ele é um artefato vivo que precisa acompanhar a evolução dos padrões e dos controles internos.
- Usar o ATT&CK apenas como figura decorativa em apresentações, sem conectar as técnicas às hipóteses de caça e às regras de detecção reais do SIEM.
- Ignorar a base de higiene e partir direto para caça avançada, hipótese que costuma fracassar pela ausência de inventário, telemetria e baselines confiáveis.
- Escolher o framework pela familiaridade da equipe e não pela função, por exemplo tentando usar o CSF como catálogo técnico de salvaguardas, papel que ele não desempenha.

9. Integração com as Demais Notas da Seção 15

Esta nota se conecta diretamente com a estrutura dos 8 grupos de controles, que detalha para onde cada evolução descrita aqui aponta, e com a esteira completa, que mostra os padrões operando juntos em tempo real. O arquivo sobre o método de adoção oferece o roteiro de avaliação e planejamento no qual o mapeamento entre frameworks deve ser produzido e mantido. Ao navegar pelos controles individuais da seção 15, o leitor encontrará referências cruzadas aos IDs do CIS, às funções do CSF e às técnicas do ATT&CK, sempre com o mesmo princípio: o CTH amplia, contextualiza e integra, sem pedir para descartar o que já funciona.