Como Utilizar Este Framework

Nota de visão geral do Framework CTH, derivada da seção 1.5 do Capítulo 1, do modelo de maturidade do Capítulo 4 e dos exercícios do Capítulo 23 do PDF de referência.
Define o método de adoção recomendado, o uso por persona, o consumo das salvaguardas por nível e os erros comuns de implementação.
Serve de manual de uso para a seção 15, conectando a leitura dos controles à execução prática do programa.

1. Contexto e Posicionamento no Framework CTH

Um framework só entrega valor quando vira rotina operacional, e é exatamente essa conversão que esta nota orienta. O Framework CTH deve ser utilizado como guia estrutural para implementação e maturação de capacidades de CTI e Threat Hunting, e não como documento de leitura única. A abordagem recomendada parte de uma avaliação honesta do estado atual, passa pela identificação das lacunas nas salvaguardas básicas e termina em um plano de implementação progressiva com donos e prazos.

Esta nota antecede a esteira completa na ordem de leitura do diretório de visão geral. Ela assume que o leitor já conhece o propósito do framework e a estrutura dos 8 grupos, e agora precisa responder à pergunta prática: por onde começo, com quem e em que ordem. As respostas variam com a persona e com o nível de maturidade, e a nota trata ambas as dimensões de forma separada.

2. Método de Adoção em Três Movimentos

O método recomendado de adoção tem três movimentos sequenciais: avaliar a maturidade atual, identificar lacunas nas salvaguardas básicas e planejar a evolução progressiva. A ordem importa porque cada movimento consome o produto do anterior. Avaliar sem mapear lacunas gera diagnósticos sem roteiro, e roteirizar sem avaliar gera planos genéricos copiados de outros contextos, que não sobrevivem ao primeiro conflito de agenda.

Na execução real, os três movimentos levam de duas a quatro semanas em uma equipe dedicada, e podem se estender por um trimestre quando dependem de entrevistas com múltiplas áreas. O erro mais caro neste estágio é pular a linha de base: sem o ponto de partida medido, todo relatório posterior de progresso vira opinião, e o programa perde credibilidade justamente na hora de pedir o próximo orçamento.

3. Avaliação de Maturidade Inicial

A avaliação inicial usa o modelo de maturidade de 5 níveis do framework, que classifica a organização como Inexistente, Inicial, Definido, Gerenciado ou Otimizado. O modelo é aplicado por grupo de controles, e não de uma vez para toda a organização, porque é comum uma mesma empresa estar Gerenciada em detecção e Inexistente em caça. A tabela a seguir resume as características de cada nível com foco operacional.

O método prático de pontuação combina duas entradas: a característica do nível observada na operação e a proporção de salvaguardas implementadas por grupo. Uma regra de bolso útil é considerar o grupo no nível cujas características correspondem à realidade majoritária das suas salvaguardas, e documentar as exceções. Essa documentação de exceções é valiosa, pois cada exceção é, na prática, um item de backlog já justificado.

O registro por grupo deve seguir um formato fixo, para que a série histórica seja comparável ao longo do tempo:

Modelo de registro de avaliação por grupo:
- Grupo: COL (Coleta de Dados e Telemetria).
- Nível atribuído: 2 (Inicial), com justificativa em uma frase por dimensão.
- Salvaguardas: 3 de 12 implementadas, todas do conjunto Básico.
- Evidências citadas: inventário de sensores, política de retenção em rascunho.
- Principais lacunas: cobertura de endpoints remotos, logs de aplicações web.
- Dono do grupo: coordenação de SOC, com revisão prevista para o próximo semestre.

Com esse registro replicado para os oito grupos, a organização obtém um retrato honesto e auditável do programa. O valor não está na nota em si, e sim na justificativa e nas lacunas, que já chegam priorizadas para o planejamento da próxima seção.

Recomenda-se registrar a avaliação em uma planilha simples com uma linha por grupo, colunas para nível atribuído, evidências citadas e principais lacunas. A revisão semestral dessa planilha cria a série histórica que sustenta o reporte executivo. Sem essa série, discussões de maturidade degeneram em impressões pessoais conflitantes, e o programa perde a capacidade de provar evolução.

4. Planejamento da Evolução Progressiva

Com a linha de base em mãos, o planejamento segue a lógica das salvaguardas: primeiro consolidar o Básico, depois expandir o Intermediário e só então atacar o Avançado. Essa disciplina evita o padrão clássico de ilha de sofisticação, no qual uma equipe brilhante mantém caça avançada enquanto inventário e telemetria básicos continuam frágeis. O cronograma ilustrativo a seguir mostra uma distribuição realista para organizações que começam entre os níveis 1 e 2.

Três regras tornam esse plano executável. Primeiro, cada onda deve ter no máximo o número de itens que a equipe consegue revisar em uma reunião de acompanhamento mensal. Segundo, cada item precisa de um critério de conclusão verificável, como log específico ingerido com retenção definida ou hipótese documentada em template. Terceiro, cada onda termina com atualização da planilha de maturidade, convertendo trabalho em evidência de progresso.

Além das regras, o planejamento precisa respeitar a capacidade real da equipe e as dependências entre grupos descritas na estrutura do framework. Agendar salvaguardas de ANA antes de COL ter telemetria mínima é declarar atraso no dia em que o roadmap é aprovado. Um plano realista com dois itens a menos por onda entrega mais que um plano ambicioso com constantes renegociações, porque a credibilidade do programa se constrói nas ondas concluídas e não nas prometidas.

5. Uso do Framework por Persona

Cada persona consome o framework por um ângulo diferente, e respeitar esses ângulos evita que o documento seja lido de capa a capa por gente que precisa apenas de uma parte. A tabela mapeia o uso recomendado por papel, com as seções de partida e os produtos típicos de cada um.

Uma dinâmica de funcionamento que funciona bem é o ritual mensal conjunto entre personas. Nele, o CTI apresenta o que mudou no panorama de ameaças, o hunter propõe quais hipóteses ganham prioridade, o SOC relata cobertura e telemetria, o CSIRT traz lições dos últimos incidentes e o gestor valida o progresso contra o roadmap. Esse ritual de uma a duas horas é o mecanismo que impede o programa de se fragmentar em iniciativas paralelas.

Cada persona também tem um anti-padrão característico que o framework ajuda a conter, e nomeá-los facilita a autorregulação da equipe:

• SOC que consome inteligência passivamente, recebendo pacotes de IOC sem contexto, e encerra a participação no ciclo ao repassar alertas.
• CSIRT que investiga sem consultar o perfil do adversário, repetindo análises que a inteligência já documentou.
• Analista de CTI que produz relatórios sem PIR definida, respondendo perguntas que ninguém fez.
• Hunter que caça sem registrar hipótese nem resultado, transformando trabalho valioso em conhecimento não replicável.
• Gestor que exige métricas sem fornecer patrocínio, cobrando evolução sem remover obstáculos de agenda e orçamento.
• Arquiteto que desenha integrações sem validar com a esteira, criando pontes que nenhum fluxo operacional atravessa.

6. Consumo das Salvaguardas por Nível de Maturidade

As salvaguardas são a moeda operacional do framework, e seu consumo deve seguir o nível da organização. Para organizações no nível 1 ou 2, a regra é exclusivamente Básica em todos os grupos, mesmo que alguma equipe tenha apetite para desafios avançados. Para organizações no nível 3, a mistura saudável é Básicas consolidadas, Intermediárias em expansão e Avançadas apenas como estudo. Níveis 4 e 5 podem operar a carteira completa, com o cuidado de reciclar salvaguardas que perderam relevância.

Na prática, o consumo por nível segue este padrão de decisão:

• Níveis 1 e 2: implementar salvaguardas Básicas de GOV, INS e COL antes de qualquer outra, porque elas destravam todos os fluxos subsequentes.
• Nível 3: completar as Básicas remanescentes e eleger as Intermediárias com maior impacto em dwell time, normalmente em COL, DET e HNT.
• Nível 4: perseguir as Intermediárias restantes e as primeiras Avançadas, com métricas de cobertura ATT&CK orientando a escolha.
• Nível 5: automatizar salvaguardas que já funcionam manualmente e usar simulação para validar que a automação mantém a eficácia.

O erro oposto também existe e merece atenção: equipes maduras demais para as salvaguardas Básicas às vezes as ignoram por tédio, e a base apodrece silenciosamente. A revisão semestral de maturidade serve justamente para verificar que nenhuma base se degradou enquanto a frente avançada evoluía, tratando salvaguardas já implementadas como compromissos contínuos e não como conquistas históricas.

A tabela a seguir cruza nível de maturidade, foco de salvaguardas e o KPI de acompanhamento mais relevante em cada estágio:

7. Combinação com os Exercícios Práticos

O framework inclui exercícios práticos integrados, detalhados no Capítulo 23 do PDF, e o uso correto é alternar leitura, implementação e exercício. Cada onda do roadmap deve terminar com um exercício que ensaie as capacidades recém-implementadas, porque o exercício revela em horas o que a operação real revelaria em meses. O exercício integrado de SOC, por exemplo, percorre a cadeia de triagem, investigação, contenção e lições aprendidas, e cada fase cita os controles que sustentam a atividade.

A cadência recomendada para os exercícios é trimestral, com complexidade crescente conforme a maturidade. Programas iniciais executam cenários guiados com dados fornecidos; programas intermediários executam cenários com dados próprios e adversário parcialmente conhecido; programas maduros incorporam emulação de adversário e validação de cobertura com plataformas de simulação. O resultado de cada exercício deve retornar à planilha de maturidade como evidência, e as falhas observadas viram itens do próximo ciclo de salvaguardas, fechando o aprendizado no mesmo mecanismo do roadmap.

A estrutura de um exercício de meio dia, adequada para equipes em nível 2 ou 3, segue o formato ilustrado a seguir:

Exercício trimestral integrado (meio dia, equipe SOC, CTI e CSIRT):
Fase 1 (60 min): triagem de alerta preparado, com enriquecimento via fontes de CTI.
Fase 2 (60 min): investigação inicial com consulta às telemetrias de COL.
Fase 3 (60 min): formulação e execução de hipótese de caça em um host suspeito.
Fase 4 (30 min): contenção simulada com registro de tempos para cálculo de MTTD e MTTR.
Debriefing (30 min): lacunas de telemetria, regras ausentes e melhorias para o roadmap.

O debriefing é a fase mais valiosa do exercício, e não a execução. É nele que a equipe confronta o plano com a prática, e é dele que saem os ajustes de salvaguardas com maior retorno por esforço investido.

8. Erros Comuns de Adoção

• Pular a governança, tratando GOV como formalidade, o que deixa o programa sem patrocínio e sem dono quando surge o primeiro conflito de prioridades.
• Comprar ferramenta antes do processo, adquirindo SOAR ou TIP para processos que ainda não existem, automatizando o caos e pagando licenças pelo privilégio.
• Tratar o framework como projeto com início e fim, quando ele é um programa contínuo cuja revisão semestral é parte da própria entrega.
• Copiar o plano de outra organização sem avaliação própria, herdando prioridades que não correspondem ao perfil de risco local.
• Medir esforço em vez de resultado, reportando quantidade de reuniões e consultas em vez de cobertura, dwell time e hipóteses convertidas em detecção.
• Deixar a retroalimentação de incidentes sem dono, perdendo os insumos mais valiosos para CTI, detecção e coleta que cada resposta a incidente produz.

Cada erro desses tem um contramedida simples e de baixo custo. O patrocínio se protege com um comitê mensal de uma hora; a disciplina de processo antecede a ferramenta com um piloto manual do fluxo; a continuidade se garante com a revisão semestral no calendário oficial da área. O padrão geral é que os erros de adoção são de gestão, e não de técnica, e por isso as contramedidas são de gestão também.

9. Critérios de Sucesso e Métricas de Uso

O uso correto do framework pode ser verificado por critérios objetivos em cada ciclo. A avaliação de maturidade existe, está datada e tem série histórica; o roadmap vigente tem donos e prazos para todas as ondas; a fila de hipóteses tem priorização documentada e taxa de execução acompanhada; as lições aprendidas geram itens que aparecem no roadmap seguinte; e o dashboard executivo exibe dwell time, cobertura e maturidade em evolução. Quando esses seis sinais estão presentes, o framework deixou de ser documento e virou programa.

A métrica final de uso é a economia de discussão que o framework proporciona. Equipes que o utilizam bem param de debater por onde começar a cada ciclo, porque o método responde essa pergunta com base em evidência. O tempo ganho é reinvestido naquilo que nenhuma estrutura substitui: telemetria melhor, hipóteses mais afiadas, resposta mais rápida e uma inteligência cada vez mais próxima da operação real.