Estrutura dos 8 Grupos de Controles

Nota de visão geral do Framework CTH, derivada da seção 1.4 do Capítulo 1 e dos capítulos de controles do PDF de referência.
Apresenta os grupos INS, GOV, COL, ANA, HNT, DET, RES e AUT, o modelo padronizado de cada controle e as dependências lógicas entre grupos.
Cumpre o papel de mapa de navegação para todos os controles detalhados nos demais diretórios da seção 15 da biblioteca.

1. Contexto e Posicionamento no Framework CTH

O Framework CTH é organizado em 8 grupos de controles, cada um identificado por um prefixo de três letras que reflete sua área de atuação. Essa estrutura cobre todo o pipeline defensivo, desde o inventário de ativos e o mapeamento da superfície de ataque até a redução efetiva do dwell time por meio de caça proativa. Cada grupo é projetado para implementação progressiva, acompanhando a maturidade da organização e permitindo evolução incremental das capacidades de CTI e Threat Hunting.

Esta nota entrega três visões complementares. A primeira é panorâmica, com objetivo e exemplos de cada grupo; a segunda é interna, mostrando o modelo padronizado que descreve cada controle e suas salvaguardas por nível; a terceira é relacional, expondo as dependências lógicas que determinam a ordem sensata de implementação. A nota também posiciona os domínios expandidos detalhados pela biblioteca, que ampliam o detalhamento do PDF em áreas como proteção, plataformas, simulação, resposta, integração, mapeamento e métricas.

2. Visão Geral dos 8 Grupos

A tabela consolidada a seguir resume os 8 grupos, seus prefixos, a quantidade de controles e o objetivo central de cada um. Os prefixos funcionam como chaves de navegação em toda a seção 15 e devem ser memorizados, pois todas as referências cruzadas da biblioteca os utilizam.

A leitura correta da tabela é por fluxo, e não por hierarquia. GOV sustenta todos os grupos; INS e COL produzem a matéria-prima; ANA converte dados em inteligência; HNT e DET consomem inteligência e telemetria para encontrar ameaças; RES elimina o que foi encontrado; AUT acelera todas as transições. Essa sequência é o fio condutor da esteira completa, detalhada em nota própria.

Em números, o núcleo do framework reúne 45 controles, com cada grupo contendo entre 4 e 8 controles individuais. Essa granularidade é intencional: grupos pequenos demais seriam rótulos sem substância, e grupos grandes demais dificultariam a atribuição de dono e o acompanhamento de maturidade por área. Ao somar os domínios expandidos detalhados pela biblioteca, o corpo completo de controles e salvaguardas cobre todas as capacidades operadas por um SOC maduro.

3. Detalhamento por Grupo

INS: Inventário e Superfície de Ataque

O grupo INS responde à pergunta "o que existe, o que está exposto e como se comporta em normalidade". Ele une o inventário clássico de ativos corporativos e de software com a visão externa do EASM, que descobre domínios, subdomínios, portas, serviços e certificados expostos. Além disso, define baselines de normalidade por segmento, insumo direto para detecção de anomalias e para formulação de hipóteses de caça. Sem esse grupo, todo o restante do programa opera sobre um mapa incompleto do próprio território.

GOV: Governança e Maturidade

O grupo GOV transforma iniciativa em programa. Ele estabelece patrocínio executivo, posicionamento organizacional das equipes, papéis e responsabilidades, matriz de competências e a missão e estratégia da capacidade de CTI e caça. Inclui também o modelo de maturidade de 5 níveis, que serve de régua para avaliação e planejamento. Na prática operacional, o GOV é o que garante orçamento, prioridade e sustentação política quando o programa atravessa trocas de gestão ou incidentes de grande impacto.

COL: Coleta de Dados e Telemetria

O grupo COL constrói a base factual de todo o framework: logs de endpoint, telemetria de rede, logs de aplicações web, ingestão centralizada em SIEM e gestão de qualidade e retenção dos dados. A qualidade da coleta define o teto das capacidades de detecção, caça e investigação, pois nenhum analista caça o que não foi capturado. As salvaguardas típicas deste grupo envolvem cobertura de sensores, padronização de campos, sincronização de relógio e retenção compatível com o tempo médio de descoberta dos incidentes.

ANA: Análise e Produção de CTI

O grupo ANA opera o ciclo de inteligência propriamente dito, convertendo dados coletados em produtos acionáveis. Ele cobre a análise de TTPs com mapeamento ATT&CK, a produção de relatórios nos níveis tático, operacional e estratégico, a disseminação segmentada por público e o feedback loop que valida o que foi útil. Inclui também a proteção de contrainteligência, evitando que a própria operação de inteligência exponha a organização. O resultado típico são alertas táticos, perfis de atores relevantes e pacotes de indicadores com contexto.

HNT: Threat Hunting

O grupo HNT estrutura a busca proativa por ameaças que evadiram a detecção automatizada. Ele cobre o inventário de dados disponíveis para caça, baselines, ambiente isolado de investigação, metodologia documentada, priorização de hipóteses e as técnicas de execução, como grouping, stack counting, clustering e busca baseada em IOC e IOA. As variantes avançadas incluem caça de endpoint, de rede, de memória e análise de autenticação. O princípio central do grupo é que caça sem processo e sem retroalimentação é hobby, e não capacidade.

DET: Detecção e Monitoramento

O grupo DET converte conhecimento em alertas permanentes. Ele cobre regras de detecção, análise de logs, correlação entre fontes, UEBA para detecção comportamental e a gestão de alertas como um ciclo de vida, com engenharia, teste e aposentadoria de regras. A ligação com o grupo HNT é direta: findings de caça que se mostram recorrentes tornam-se regras Sigma, YARA ou de IDS/IPS, transformando busca manual em cobertura permanente. A ligação com COL é igualmente direta, porque regra sem telemetria é promessa sem entrega.

RES: Resposta e Retroalimentação

O grupo RES fecha o ciclo operacional, integrando detecção e caça à resposta a incidentes. Ele cobre a gestão de incidentes com plataforma DFIR, triagem e classificação, contenção e erradicação, recuperação e lições aprendidas, além do controle específico de redução de dwell time. A retroalimentação é o diferencial do grupo: cada incidente devolve TTPs novas ao ciclo de inteligência, regras novas ao ciclo de detecção e lacunas de visibilidade ao plano de coleta. Sem esse fechamento, a organização paga o preço do mesmo incidente repetidas vezes.

AUT: Automação e Orquestração

O grupo AUT remove o gargalo humano das transições entre etapas. Ele cobre orquestração com SOAR, automação por plataformas de workflows, automação de detecção, uso de machine learning para caça e orquestração de resposta automatizada. As automações típicas incluem enriquecimento automático de alertas com contexto de inteligência, implantação de regras via API e contenção automática de endpoints com guardrails aprovados. O princípio do grupo é automatizar o que é repetitivo e previsível, preservando o julgamento humano para o que é ambíguo e arriscado.

4. O Modelo Padronizado de Cada Controle

Cada controle do framework segue um modelo padronizado inspirado no CIS Controls v8. O modelo garante que qualquer controle, de qualquer grupo, possa ser lido, avaliado e implementado com a mesma estrutura mental, o que reduz a curva de aprendizado e facilita a automação da própria gestão de controles. O esqueleto é composto por quatro elementos:

• Descrição do controle, definindo com precisão o que a organização precisa fazer e qual capacidade entrega.
• Justificativa crítica, na forma da pergunta "por que este controle é crítico?", ancorada em risco e em consequência operacional.
• Procedimentos e capacidades necessárias, listando processos, pessoas e ferramentas envolvidos na execução.
• Salvaguardas numeradas e específicas, cada uma marcada com o nível de maturidade requerido.

O exemplo a seguir ilustra o formato, com salvaguardas hipotéticas que seguem a marcação do framework:

Modelo de controle (esqueleto padronizado):
Controle: HNT.6, Formulacao de Hipoteses Estruturadas.
Por que e critico: sem hipotese estruturada, a busca perde foco, nao e replicavel
e nao gera aprendizado acumulavel para a equipe.
Procedimentos: registrar hipotese em template padrao, mapear tecnicas ATT&CK,
definir fontes de dados e validar viabilidade com o inventario de caixa.
Salvaguardas:
  [Basico] 6.1 - Documentar hipoteses em repositorio unico com autor e data.
  [Intermediario] 6.2 - Mapear cada hipotese a tecnicas ATT&CK e fontes de dados.
  [Avancado] 6.3 - Priorizar hipoteses por modelo de risco combinado com CTI.

A marcação de nível nas salvaguardas é o que permite o uso progressivo do framework. Uma equipe no nível Inicial de maturidade implementa as salvaguardas Básicas de todos os grupos antes de avançar para as Intermediárias, evitando o padrão comum de construir ilhas de sofisticação sobre bases omissas. A contagem de salvaguardas implementadas por nível também alimenta diretamente a avaliação de maturidade.

5. Dependências Lógicas entre Grupos

Os grupos podem ser tratados de forma relativamente independente, mas existem dependências lógicas que a experiência de adoção torna evidentes. O exemplo citado no PDF é direto: é difícil implementar coleta e análise de CTI sem antes ter governança e inventário de ativos estabelecidos. Inteligência sem inventário não sabe dizer se uma ameaça é relevante para o ambiente, e análise sem governança não sobrevive ao primeiro ciclo de reorganização interna.

A cadeia de dependências mais importante do framework pode ser lida assim:

• GOV sustenta todos os grupos, porque patrocínio, papéis e competências são pré-condição de qualquer capacidade formal e financiada.
• INS precede COL na prática, porque o inventário define onde implantar sensores e o que é normalidade por segmento.
• COL precede ANA, porque análise de inteligência sem dados internos e fontes externas estruturadas produz opinião, e não inteligência.
• ANA precede HNT na modalidade intelligence-driven, porque hipóteses de qualidade nascem de TTPs e perfis de ator documentados.
• COL e ANA sustentam DET, porque regras de detecção exigem telemetria disponível e conhecimento do comportamento adversário.
• DET e HNT alimentam RES, e RES realimenta ANA, DET e COL com lições aprendidas, fechando o ciclo.
• AUT atravessa todos os grupos, mas exige processos manuais maduros antes de automatizá-los.

Uma consequência prática dessas dependências é a ordem de ataque recomendada em programas iniciantes: GOV e INS primeiro, COL em sequência, ANA e DET em paralelo quando a telemetria amadurece, HNT logo depois, RES e AUT consolidando o ciclo. Ignorar essa ordem não impede o trabalho, mas costuma gerar retrabalho, como criar regras para logs que não existem ou automatizar processos que ainda não existem.

A matriz de dependências a seguir condensa essas relações e serve de referência rápida para o planejamento de ondas de implementação:

6. Domínios Expandidos na Biblioteca

Além dos 8 grupos do núcleo, a biblioteca expande o detalhamento em domínios adicionais que aparecem no PDF como capítulos específicos. Esses domínios complementam os grupos com profundidade operacional e mantêm o mesmo modelo padronizado de controle. A tabela a seguir mostra como tudo se encaixa.

A leitura integrada dessas duas camadas é simples. Os 8 grupos respondem "o que o programa precisa ter", e os domínios expandidos respondem "como cada peça funciona em profundidade". Ao navegar na seção 15, os arquivos de controles individuais herdam o prefixo do grupo ou domínio correspondente, e as notas de visão geral como esta fornecem o mapa que costura o conjunto.

Um exemplo mostra o encaixe na prática. O conceito de IOE, indicador de exposição, nasce no domínio de indicadores, é operacionalizado pelo grupo INS via EASM e se materializa em alertas priorizados pela automação do AUT. Percorrer esse caminho em três documentos distintos da biblioteca é proposital: cada parada aprofunda uma camada diferente do mesmo problema, e as referências cruzadas evitam a repetição de conteúdo entre arquivos.

7. Erros Comuns e Pontos de Atenção

• Ler os grupos como silos independentes e implementar, por exemplo, caça avançada sem telemetria e inventário, o que produz caça às cegas e frustração rápida.
• Tratar o modelo padronizado como burocracia e pular a justificativa crítica, perdendo o argumento de valor que sustenta o controle na hora de disputar orçamento.
• Implementar salvaguardas Avançadas de um grupo enquanto salvaguardas Básicas de outros grupos ficam descobertas, criando desequilíbrio estrutural difícil de corrigir depois.
• Confundir controles com ferramentas: a salvaguarda define um estado de capacidade, e a ferramenta é apenas um dos meios possíveis de alcançá-lo.
• Esquecer que AUT exige processo manual maduro, automatizando fluxos quebrados e amplificando o problema em escala.
• Ignorar a retroalimentação de RES, tratando o fim do incidente como fim do ciclo, quando é exatamente ali que nascem os melhores insumos para CTI, detecção e coleta.

8. Critérios de Sucesso e Métricas de Estrutura

A estrutura dos grupos se valida quando cada controle implementado tem dono, salvaguardas verificáveis e evidência associada. Um indicador útil é a porcentagem de salvaguardas Básicas implementadas por grupo, calculada na avaliação de maturidade inicial e recalculada a cada semestre. Em programas saudáveis, esse indicador sobe de forma relativamente uniforme entre os grupos, e desvios persistentes revelam gargalos, como telemetria defasada em COL ou hipóteses acumuladas sem execução em HNT.

Outra verificação prática é o teste de rastreabilidade: escolher um incidente real recente e percorrer, com a estrutura dos grupos, cada etapa de sua detecção e resposta, identificando os controles envolvidos. Se o percurso INS, COL, ANA, DET, HNT, RES e AUT puder ser narrado com controles específicos e evidências, a estrutura está viva na operação e não apenas no documento. Se etapas inteiras ficarem sem controle correspondente, o resultado aponta exatamente onde o programa precisa evoluir primeiro.