Propósito e Público-Alvo

Nota de visão geral do Framework CTH, derivada do Capítulo 1 (Introdução) do PDF de referência.
Define o problema que o framework resolve, o objetivo central de reduzir o dwell time e os seis públicos-alvo atendidos.
Cumpre o papel de porta de entrada da seção 15 da biblioteca, orientando a leitura dos 8 grupos de controles que se seguem.

1. Contexto e Posicionamento no Framework CTH

O cenário contemporâneo de ameaças cibernéticas é caracterizado por complexidade e sofisticação sem precedentes. Grupos de ransomware operam de forma industrializada, campanhas de espionagem são patrocinadas por Estados-nação e ataques de phishing direcionado alcançam organizações de todos os portes e segmentos. Frente a esse panorama, estratégias de segurança fundadas apenas em prevenção e em detecção reativa demonstram limitações crescentes para proteger os ativos de informação críticos.

O Framework CTH (Cyber Threat Intelligence e Threat Hunting) foi criado como resposta a essa insuficiência. Ele organiza um programa integrado que conecta inteligência de ameaças, caça proativa, detecção, resposta a incidentes, automação e medição em uma esteira contínua de defesa. Esta nota posiciona o framework no ecossistema de padrões de mercado, explica o problema central que ele resolve e detalha para quem ele foi escrito.

Como nota de visão geral, este arquivo antecede os demais do diretório 00 da seção 15 da biblioteca. A leitura recomendada começa aqui, prossegue pela estrutura dos 8 grupos de controles e termina na esteira completa, que mostra como todos os componentes se integram. Os arquivos posteriores da seção 15 expandem cada controle individual com salvaguardas, exemplos práticos e métricas.

2. O Problema que o Framework Resolve

A lacuna central endereçada pelo framework está situada entre dois extremos do ecossistema de frameworks de segurança. De um lado, frameworks amplos como o CIS Controls v8 oferecem diretrizes abrangentes de higiene de segurança, mas não aprofundam os processos específicos de inteligência de ameaças e de caça proativa. De outro, metodologias dedicadas como o OTHF (Outsourced Threat Hunting Framework) e o TaHiTI (Threat Hunting Integrative Taxonomy) cobrem a caça em profundidade, porém não oferecem uma visão holística que integre CTI, governança, automação, resposta e medição em um pipeline coerente.

Essa lacuna produz efeitos concretos e recorrentes nas operações defensivas:

• Programas de CTI que produzem relatórios sem tradução para detecção, hipóteses de caça ou ações de correção, o que gera inteligência teórica e pouco acionável.
• Iniciativas de Threat Hunting ad hoc, dependentes de indivíduos específicos, sem processo documentado, sem priorização estruturada de hipóteses e sem retroalimentação para o ciclo de inteligência.
• Investimento pesado em ferramentas como SIEM, EDR, NDR e TIP sem os processos e controles que convertem telemetria e inteligência em cobertura de detecção real.
• Ausência de modelo de maturidade e de métricas que permitam justificar investimento, demonstrar evolução e sustentar o programa ao longo do tempo.

O Framework CTH fecha essa lacuna organizando o programa em 8 grupos de controles: INS (inventário e superfície de ataque), GOV (governança e maturidade), COL (coleta e processamento), ANA (análise e produção de CTI), HNT (Threat Hunting), DET (detecção e monitoramento), RES (resposta e retroalimentação) e AUT (automação e orquestração). Cada grupo contém salvaguardas progressivas marcadas como Básico, Intermediário ou Avançado. A proposta é que a organização evolua de forma incremental, sem saltos irreais de capacidade, e que o mesmo framework sirva tanto para uma equipe iniciante estabelecendo inventário e baselines quanto para um SOC maduro automatizando o pipeline entre inteligência e detecção.

3. Limitações da Defesa Puramente Reativa

A segurança reativa pressupõe que o ataque será detectado pelas ferramentas existentes, e essa premissa perde validade a cada evolução do adversário. Antivírus, IDS/IPS e regras de SIEM baseadas em assinaturas dependem de conhecimento prévio do malicioso, o que cria um descompasso estrutural em relação a técnicas novas. A experiência operacional de SOC e CSIRT mostra, com frequência, que o alerta chega tarde, chega incompleto ou simplesmente não chega.

Essas limitações não invalidam as ferramentas de detecção automatizada, que continuam essenciais para cobrir o volume operacional do dia a dia. A conclusão correta é de complemento, e não de substituição: o que falta à pilha reativa é exatamente o que CTI e Threat Hunting adicionam. A inteligência antecipa e contextualiza as ameaças relevantes para o negócio, enquanto a caça ativamente procura no ambiente aquilo que escapou das regras automatizadas.

A alternativa viável a esse cenário é a detecção comportamental apoiada em telemetria de qualidade, que observa o que o adversário faz em vez de depender do que ele usa. Isso exige telemetria deliberadamente planejada, como os exemplos a seguir:

Telemetria mínima para detecção e caça comportamental em endpoints Windows:
- Sysmon Event ID 1: criação de processo com linha de comando completa e hash do executável.
- Windows Security Event ID 4688: criação de processo no log de auditoria do sistema.
- Sysmon Event ID 3: conexão de rede iniciada por processo, com destino, porta e processo pai.
- Sysmon Event ID 11: criação de arquivo, útil para identificar staging de ferramentas ofensivas.
- Sysmon Event ID 13: modificação de registro, essencial para detectar persistência.

Com essa base, o analista deixa de perguntar apenas "há uma assinatura para este malware?" e passa a perguntar "há um processo pai incoerente, um destino de rede anômalo ou uma persistência sem justificativa operacional?". Essa mudança de pergunta é o que o framework sistematiza nos grupos COL e DET.

4. O Objetivo Central: Reduzir o Dwell Time

O dwell time é o período entre o comprometimento inicial e a detecção seguida de contenção. Segundo o relatório Verizon Data Breach Investigations Report (DBIR) citado no PDF de referência, aproximadamente 68% das violações permanecem não detectadas por meses ou até anos. Durante essa janela, o adversário opera livremente no ambiente da vítima: exfiltra dados, estabelece persistência, move-se lateralmente e compromete sistemas adicionais. Reduzir o dwell time é, portanto, o objetivo central que dá coerência a todos os controles do framework.

Cada grupo de controles ataca um segmento diferente dessa janela temporal, e a soma dos esforços encurta o caminho entre o comprometimento e a contenção.

A meta declarada do framework é reduzir o dwell time de meses para horas. Isso não é alcançado por uma única ferramenta, e sim pela engrenagem entre descoberta de exposição, coleta de telemetria, produção de inteligência, hipóteses de caça, detecção permanente e resposta rápida. Por isso o framework é lido como um sistema, e não como uma lista de itens independentes.

O custo de manter o dwell time elevado vai além do risco técnico, e visibilizá-lo ajuda gestores a sustentar o patrocínio do programa.

Na prática de medição, o dwell time se decompõe em duas métricas complementares que o SOC já consegue operar: o tempo médio de detecção (MTTD, Mean Time To Detect) e o tempo médio de resposta até a contenção (MTTR, Mean Time To Respond). A soma aproximada das duas, quando o momento do comprometimento é determinável, fornece a estimativa do dwell time do incidente. Os KPIs do grupo MET detalham como acompanhar essas métricas por trimestre e por tipo de adversário.

5. Os Seis Públicos-Alvo e o Valor para Cada Um

O framework foi escrito para equipes e papéis que participam da defesa cibernética, reconhecendo que cada um consome o mesmo corpo de controles de maneiras distintas. A tabela a seguir resume o ganho principal de cada público e os pontos de partida mais relevantes.

Dois pontos merecem destaque na prática. Primeiro, os públicos não são isolados: o analista de CTI alimenta o hunter, o hunter alimenta o SOC com novas detecções, e o CSIRT devolve lições aprendidas que recomeçam o ciclo. Segundo, o framework evita que o programa dependa de heroísmo individual, porque documenta processo, responsabilidade e métrica para cada papel.

No primeiro ciclo de adoção, cada persona consome o framework de forma diferente. O gestor começa pela avaliação de maturidade para estabelecer a linha de base e escolher as salvaguardas Básicas ainda não implementadas. O arquiteto usa a esteira completa para verificar se a arquitetura atual tem os pontos de integração mínimos entre SIEM, plataforma de CTI e resposta. O SOC e o CSIRT partem para os controles de coleta e detecção que produzem ganho imediato de triagem, enquanto CTI e hunters adotam o ciclo de inteligência e a fila de hipóteses. Essa distribuição evita que o programa vire iniciativa de um único time e, consequentemente, morra com a saída de uma pessoa.

6. O que o Framework Entrega

Além do diagnóstico do problema, o framework entrega artefatos operacionais que podem ser adotados de imediato pelas equipes. São entregas concretas, verificáveis e progressivas:

• Controles padronizados com salvaguardas numeradas por nível (Básico, Intermediário, Avançado), seguindo o modelo de apresentação consagrado pelo CIS Controls v8, com descrição, justificativa crítica e procedimentos.
• Matriz de maturidade de 5 níveis (Inexistente, Inicial, Definido, Gerenciado, Otimizado) com características por dimensão de CTI, Threat Hunting e Automação.
• Mapeamento para o MITRE ATT&CK, incluindo heatmaps de cobertura por tática e análise de lacunas de detecção que orientam priorização.
• KPIs e métricas de programa, com destaque para dwell time, tempo médio de detecção e tempo médio de resposta.
• Exercícios práticos integrados para SOC, CTI e Threat Hunting, que transformam a leitura em ensaio operacional com dados e cenários reais.
• A esteira completa do Capítulo 20, que conecta todos os grupos em um fluxo único, da superfície de ataque ao dwell time reduzido.

Essas entregas se sustentam mutuamente. A matriz de maturidade dá o ponto de partida, as salvaguardas dão o roteiro de evolução, o mapeamento ATT&CK mostra cobertura, os KPIs comprovam progresso e os exercícios validam que o processo funciona sob pressão. Nenhuma dessas peças entrega valor sozinha por muito tempo, e o framework deixa isso explícito na sua estrutura.

Para localizar cada entrega no corpo do framework, vale mapear as entregas aos capítulos do PDF de referência:

Um exemplo curto mostra como as entregas se combinam em um caso real, no qual o ganho do framework aparece na velocidade entre as etapas:

Cadeia de valor das entregas em um caso de phishing direcionado:
1. A equipe de CTI registra PIR sobre campanha direcionada ao setor e coleta fontes relevantes.
2. A análise mapeia as TTPs da campanha para técnicas ATT&CK e publica alerta operacional.
3. O hunter valida a hipótese de execução via documento com macro na telemetria de endpoint.
4. O finding da caça gera uma regra Sigma que passa a alertar de forma permanente no SIEM.
5. O gestor registra o ganho de cobertura no heatmap ATT&CK e reporta o resultado ao comitê.

Sem o framework, essa cadeia costuma se fragmentar: o relatório de CTI não vira hipótese, o finding da caça não vira regra permanente e o gestor não tem métrica para reportar. Com os controles do CTH, cada elo tem controle, salvaguarda e dono atribuídos.

7. Erros Comuns de Interpretação do Propósito

A experiência de adoção mostra interpretações equivocadas que limitam o valor do framework desde o início. Identificá-las cedo evita retrabalho e frustração:

• Tratar o CTH como substituto do CIS Controls ou do NIST CSF, quando o desenho é de complemento sobre a base de higiene já existente.
• Reduzir o framework a listas de IOC, ignorando que o valor está nos TTPs, nas hipóteses e nos processos que transformam indicadores em detecção e caça.
• Ler o framework como catálogo de ferramentas, quando ele descreve processos, pessoas e métricas que devem preceder qualquer aquisição.
• Esperar valor do grupo de caça sem governança, inventário e telemetria, que são pré-requisitos lógicos para qualquer busca produtiva.
• Assumir que o público é apenas o SOC, quando gestores e arquitetos têm papéis determinantes no patrocínio e na integração das capacidades.

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

O propósito do framework se valida por evidências operacionais, e não por adesão formal ao documento. Uma equipe pode considerar que internalizou o propósito quando consegue articular, em uma frase, qual segmento do dwell time cada grupo de controles ataca. Outro critério prático é a existência de ao menos um indicador por público: KPI de cobertura para o gestor, fila de hipóteses priorizadas para o hunter, taxa de enriquecimento para o SOC e tempo de contextualização para o CSIRT.

Uma métrica de linha de base recomendada é medir o tempo entre o comprometimento (quando determinável) e a contenção nos últimos incidentes, mesmo que de forma aproximada. Esse número, ainda que imperfeito, dá âncora para os objetivos dos grupos INS, HNT e RES nos primeiros ciclos de adoção. A partir dessa linha de base, a evolução esperada é mensurável em trimestres, com reduções sucessivas do tempo total e aumento documentado da cobertura de detecção mapeada no ATT&CK.

Por fim, o propósito não é alcançado uma única vez e dado por encerrado. A recomendação prática é reavaliar a maturidade e o propósito do programa a cada ciclo semestral, verificando se os públicos continuam consumindo as entregas e se o dwell time continua em trajetória de redução. Mudanças no panorama de ameaças, no portfólio de tecnologia e na estrutura da equipe podem reposicionar prioridades, e o framework foi desenhado exatamente para absorver esse reposicionamento sem perder coerência.