03 - Índice de Frameworks e Padrões
video: https://youtu.be/... no frontmatter da nota.Índice de Frameworks e Padrões
Nota 03 do capítulo 27 - Governança da Biblioteca de CTI. Cataloga, em formato de índice descritivo, os frameworks e padrões citados ao longo da biblioteca, indicando o que cada um é, para que serve e em quais capítulos aparece.
É a ponte entre os capítulos temáticos e o vocabulário compartilhado, evitando que o leitor tenha de reler notas distantes para reencontrar a definição de um padrão como STIX 2.1 ou de uma metodologia como PEAK.
Complementa o glossário (02), que resolve termos isolados, e o catálogo de fontes primárias (04), que aponta onde acompanhar a evolução de cada padrão listado aqui.
1. Contexto e Posicionamento na Biblioteca
A biblioteca não ensina cada framework uma única vez: o ATT&CK aparece no capítulo 04 como modelo, no capítulo 08 como linguagem de caça, no capítulo 15 como espinha de mapeamento e no capítulo 20 como produto em evolução constante. Essa distribuição é desejável porque cada capítulo usa o padrão para um propósito diferente, mas cria um problema de navegação que esta nota resolve: um índice único que diga, por linha, o que é o padrão, para que serve e onde está tratado em profundidade. O índice não reexplica o conteúdo dos capítulos, apenas orienta a chegada até ele com precisão.
O recorte da lista segue o uso real da biblioteca e não uma lista de mercado: entraram os frameworks com nota ou salvaguarda própria, os padrões de intercâmbio operados em capítulo inteiro e os sistemas de pontuação usados em decisão concreta de priorização. Padrões com escopo restrito e citação concentrada em um único capítulo, como o ADS Framework e o DDLC do capítulo 18, ficaram no grupo complementar da seção 8, para que o índice principal permaneça na faixa de leitura de uma sessão sem perder completude.
2. Como Ler e Manter o Índice
Cada linha do índice tem quatro colunas com contratos distintos, e entender o contrato evita que o leitor espere da coluna errada o conteúdo que está na outra. A tabela abaixo define o que cada coluna promete e o que ela não promete, e vale para todas as seções do índice.
| Coluna | O que promete | O que não promete |
|---|---|---|
| Framework | Nome oficial do padrão ou da metodologia, com a grafia usada pelo mantenedor | Não traduz nem abrevia o nome de forma não oficial |
| O que é | Definição em uma frase, sem adjetivos de marketing, do escopo do padrão | Não descreve implementação, ferramenta ou licença específica |
| Para que serve | Uso concreto que a biblioteca faz do padrão em decisão, produção ou detecção | Não promete que o padrão cubra todos os casos de uso possíveis |
| Onde aparece | Capítulos e notas que tratam o padrão em profundidade, com o assunto dominante indicado | Não lista todas as citações; capítulos citadores ficam fora por design |
A manutenção segue a cadência trimestral do capítulo e tem um gatilho adicional: qualquer atualização de versão de padrão, como a troca de versão do ATT&CK ou a publicação do NIST CSF, obriga revisão da linha correspondente e, quando houver mudança estrutural, revisão do capítulo dono. A regra de ouro é que nenhuma linha deste índice pode apontar para capítulo que não exista, e a verificação cruzada com o mapa da nota 01 é passo obrigatório da revisão. Toda linha nova entra por proposta escrita, e o modelo abaixo padroniza a proposta para que a decisão em sessão de governança seja sobre conteúdo e não sobre formato.
Proposta de linha - índice de frameworks
Nome do padrão: ATT&CK v19
Grupo proposto: modelagem de adversário
O que é: versão de abril de 2026 da matriz, com divisão de Defense Evasion
Para que serve: revalidar mapeamentos e detectar técnicas afetadas pela divisão
Onde aparece: capítulo 20 (nota 01 do bloco 2) e capítulo 15 (grupo MAP)
Decisão: aprovar, revisar linha existente e atualizar capítulo dono
3. Frameworks de Modelagem de Adversário
Este grupo reúne os modelos que estruturam o conhecimento sobre o comportamento adversário e que servem de lente para análise, caça e priorização. São os padrões mais citados da biblioteca e os que exigem domínio mais cedo na trilha, porque quase todos os capítulos aplicados pressupõem o vocabulário deles. A ordem das linhas segue o peso de uso, e não a ordem alfabética.
| Framework | O que é | Para que serve | Onde aparece na biblioteca |
|---|---|---|---|
| MITRE ATT&CK | Matriz aberta de táticas, técnicas e subtécnicas observadas em adversários reais, com edições Enterprise, Mobile e ICS | Mapear cobertura, formular hipóteses de caça, estruturar relatórios e comparar grupos de ameaça | Capítulo 04 (nota 01) apresenta; capítulo 08 usa como linguagem de caça; capítulo 15 (grupo MAP) mapeia; capítulo 20 acompanha versões |
| MITRE ATLAS | Matriz análoga ao ATT&CK para ataques adversários contra sistemas de IA e machine learning | Categorizar ameaças a modelos, conjuntos de dados e pipelines de IA, com casos documentados | Capítulo 17 (nota 02 do bloco 05) e capítulo 20 (nota 03 do bloco 3) |
| Diamond Model | Modelo de análise de intrusão com quatro vértices: adversário, capacidade, infraestrutura e vítima | Descrever eventos, agrupar campanhas e correlacionar intrusões com vocabulário comum | Capítulo 04 (nota 02) e capítulo 05 (clustering e análise de campanhas, nota 01) |
| Cyber Kill Chain | Modelo de sete elos da Lockheed Martin que decompõe a intrusão de reconhecimento a ações sobre objetivos | Entender fases da intrusão, posicionar controles por fase e contrastar com a granularidade do ATT&CK | Capítulo 04 (nota 03), com comparação no capítulo 15 (nota 02 do bloco 00) |
| Pyramid of Pain | Pirâmide de David Bianco que ordena indicadores pelo custo que impõem ao adversário, de hashes a TTPs | Decidir onde investir detecção e caça e calibrar a discussão de fidelidade e de rotação de infraestrutura | Capítulo 04 (nota 05) e capítulo 03 (comparativo de indicadores, nota 05) |
| VERIS | Vocabulário aberto para registro estruturado de incidentes, com categorias de ator, ação, ativo e impacto | Padronizar a descrição de incidentes internos e contribuir com estatística setorial comparável | Capítulo 04 (nota 04) e capítulo 22 (métricas de compartilhamento) |
Duas relações entre esses modelos merecem atenção na leitura dos capítulos. O Kill Chain e o ATT&CK respondem perguntas diferentes, fases da intrusão contra comportamento técnico, e a nota 02 do bloco 00 do capítulo 15 mapeia quando usar cada um. O Diamond Model e o VERIS convivem porque um descreve o evento individual e o outro padroniza o registro do incidente completo, e a combinação dos dois é o que permite comparação estatística sem perder o detalhe analítico.
Para o analista que está começando, a recomendação de sequência dentro deste grupo é direta: ATT&CK primeiro, porque é a linguagem comum de tudo o que vem depois; Pyramid of Pain em seguida, porque ensina por que TTP valem mais que hashes; Diamond e Kill Chain por último, como lentes de análise e de comunicação. O ATLAS e o VERIS podem esperar o primeiro caso real que os convide.
4. Frameworks de Governança, Controle e Resposta
Este grupo reúne padrões que organizam o programa: controles de referência, ciclo de resposta e modelos de harmonização. São menos técnicos e mais normativos, aparecem com força no capítulo 15 e nos capítulos de metodologia emergente, e são a linguagem que o gestor fala com auditoria e com o comitê.
| Framework | O que é | Para que serve | Onde aparece na biblioteca |
|---|---|---|---|
| CIS Controls v8 | Lista priorizada de 18 controles de higiene e defesa, com salvaguardas detalhadas por controle | Comparar o que o CTH propõe com o padrão de mercado e defender investimento por controle | Capítulo 15 (nota 02 do bloco 00, relacionamento com outros frameworks) |
| NIST CSF 2.0 | Estrutura de funções de cibersegurança, atualizada com a função Govern, para organizar programa e maturidade | Posicionar o programa de CTI e hunting na linguagem de governança corporativa | Capítulo 15 (nota 02 do bloco 00) e capítulo 12 (boas práticas de programa) |
| NIST SP 800-61 | Publicação de referência sobre manuseio de incidentes, com ciclo de preparação, detecção, contenção e lições | Base para comparar processos de resposta e auditar maturidade de IR | Capítulo 15 (grupo RES) e capítulo 24 (comparação no Heptagon, nota 02 do bloco 04) |
| DAIR | Dynamic Approach to Incident Response, metodologia do SANS que trata resposta como ciclo dinâmico em vez de fase linear | Modernizar o processo de IR para ambientes com cloud, automação e incerteza | Capítulo 23 (nota 06) |
| KRAFF | Framework de DFIR que harmoniza múltiplos padrões, incluindo NIST, ISO e ITIL, em um roteiro único | Unificar referências concorrentes em um processo de forense e resposta auditável | Capítulo 23 (nota 05) |
5. Padrões de Intercâmbio e Compartilhamento
Este grupo reúne os padrões que fazem inteligência circular entre organizações e ferramentas sem perder estrutura. São padrões de implementação obrigatória para quem opera TIP, participa de ISAC ou responde por política de compartilhamento, e a biblioteca os trata com capítulos de profundidade porque a implementação malfeita degrada a troca inteira.
| Framework | O que é | Para que serve | Onde aparece na biblioteca |
|---|---|---|---|
| STIX 2.1 | Padrão aberto de serialização de inteligência em objetos, como indicador, malware e relacionamento, com vocabulário controlado | Estruturar pacotes de inteligência ricos em contexto e interoperáveis entre TIPs | Capítulo 22 (nota 05, em profundidade), capítulo 15 (PLT.3) e capítulo 20 (novo modelo de dados de detecção) |
| TAXII 2.1 | Protocolo de transporte de coleções STIX por HTTP, com serviços de discovery, coleções e canais | Automatizar distribuição e consumo de inteligência entre organizações e plataformas | Capítulo 22 (nota 06, em profundidade) e capítulo 15 (PLT.3) |
| TLP 2.0 | Esquema do FIRST de rótulos de circulação de informação, de CLEAR a RED, com a inclusão de AMBER+STRICT | Governar quem pode receber cada artefato de inteligência antes de produzi-lo | Capítulo 12 (nota 06, com tabela de uso), capítulo 15 (PLT.5) e capítulo 22 |
| OCSF | Open Cybersecurity Schema Framework, esquema aberto de classes e atributos para normalizar telemetria de segurança entre produtos | Reduzir o custo de normalização de logs antes de detecção e caça, com mapeamento entre esquemas | Capítulo 24 (plataformas de detecção) e capítulo 09 (engenharia de dados e pipelines, nota 08) |
| FIRST IEP | Inteligência Exchange Program do FIRST, política padrão de troca de inteligência entre organizações | Formalizar termos de troca bilaterais e multilaterais sem renegociar a cada acordo novo | Capítulo 22 (nota 09, política de compartilhamento) |
6. Linguagens de Detecção e Sistemas de Pontuação
Este grupo reúne as linguagens com que a biblioteca escreve detecção e as métricas com que prioriza vulnerabilidade. São os padrões de execução diária, presentes em exemplos práticos de dezenas de notas, e a combinação entre eles é o que sustenta o pipeline de detecção do capítulo 18.
| Framework | O que é | Para que serve | Onde aparece na biblioteca |
|---|---|---|---|
| Sigma | Linguagem aberta e genérica de descrição de regras de detecção sobre logs, convertível para SPL, KQL e outras linguagens | Escrever detecção uma vez e portar para qualquer SIEM, com versionamento em repositório | Capítulo 09 (nota 03), capítulo 18 (DaC e pipeline) e capítulo 17 (geração de regras por LLM, nota 04 do bloco 01) |
| YARA | Linguagem de descrição de padrões textuais e binários para identificar famílias de malware em arquivos, memória e processos | Caracterizar malware, caçar por assinatura personalizada e complementar a detecção de endpoint | Capítulo 25 (nota 05, em profundidade) e capítulo 15 (PRT.5) |
| CVSS | Common Vulnerability Scoring System, pontuação base de severidade técnica de vulnerabilidade | Padronizar a gravidade bruta antes de aplicar contexto de ameaça e exposição | Capítulo 05 (nota 05, scoring e priorização) |
| EPSS | Exploit Prediction Scoring System, probabilidade diária de exploração no mundo real por vulnerabilidade | Priorizar remediação pelo risco real de exploração e não pela severidade teórica | Capítulo 05 (nota 05) e capítulo 05 (nota 14, intelligence de vulnerabilidades) |
| KEV | Known Exploited Vulnerabilities, catálogo do CISA de vulnerabilidades com exploração confirmada | Elevar a prioridade de remediação das vulnerabilidades que já estão sendo exploradas | Capítulo 05 (nota 14) e capítulo 21 (integração com gestão de vulnerabilidades) |
7. Metodologias de Threat Hunting
Este grupo reúne as metodologias comparadas no capítulo 23, cada uma com hipótese de valor diferente: priorização por risco, taxonomia de pontos de partida, processo padrão de plataforma ou governança de hunting terceirizado. A leitura conjunta é o que permite escolher metodologia consciente por tipo de caça, em vez de adotar por moda.
| Framework | O que é | Para que serve | Onde aparece na biblioteca |
|---|---|---|---|
| TaHiTI | Taxonomia holandesa de threat hunting que classifica caças por ponto de partida: dados, hipótese, IOC ou query | Organizar o portfólio de caças e decidir o próximo passo a partir do que se tem em mãos | Capítulo 23 (nota 03) e capítulo 15 (grupo HNT, técnica TH.4) |
| OTHF | Framework para hunting prestado por terceiros, com fases de contrato, escopo, execução e qualidade | Contratar, fiscalizar e integrar hunting outsourced ao programa interno | Capítulo 23 (nota 04) |
| PEAK | Metodologia do Splunk com timeline preta, caças por hipótese e caças exploratórias, agnóstica de ferramenta | Estruturar o fluxo de caça em torno de premissas claras e de exploração disciplinada | Capítulo 23 (nota 02) |
| THRIVE | Metodologia que prioriza caças a partir de risco e inteligência de CTI, conectando ameaça relevante a caça executável | Priorizar o portfólio de caças pelo risco à organização e não pela curiosidade do hunter | Capítulo 23 (nota 01) e capítulo 10 (priorização de hipóteses por inteligência) |
A comparação entre as quatro linhas resume uma escolha de projeto: THRIVE decide o que caçar, TaHiTI decide por onde começar, PEAK decide como conduzir e OTHF decide com quem executar quando o time é terceirizado. Programas maduros combinam as quatro, e o capítulo 23 fecha com esse comparativo. O que este índice garante é que a escolha seja consciente e documentada, e não herança silenciosa da ferramenta que chegou primeiro.
8. Frameworks Complementares de Caça, Validação e Maturidade
Além das linhas anteriores, a biblioteca opera padrões de escopo mais restrito, que merecem linha própria por frequência de uso, mas não por abrangência temática. Eles aparecem concentrados em um ou dois capítulos, e a localização abaixo cobre praticamente todas as ocorrências relevantes.
| Framework | O que é | Para que serve | Onde aparece na biblioteca |
|---|---|---|---|
| HMM | Hunting Maturity Model, escala de cinco níveis, de HM0 a HM4, que mede a maturidade da caça da organização | Diagnóstico de partida e meta de evolução do programa de hunting | Capítulo 06 (nota 05) e capítulo 15 (modelo de maturidade CTH, bloco 01) |
| ADS Framework | Alerting and Detection Strategy, formato de documentação de detecção com objetivo, telemetria e critério de aposentadoria | Documentar cada detecção como decisão revisável e não como linha solta no SIEM | Capítulo 18 (nota 01 do bloco 04) |
| DDLC | Detection Development Life Cycle, ciclo de vida de desenvolvimento de detecção, de ideia a produção com testes | Padronizar a esteira que transforma hipótese de caça em regra publicada | Capítulo 18 (nota 02 do bloco 01) |
| D3FEND | Matriz do MITRE de contramedidas defensivas mapeadas contra as técnicas do ATT&CK | Justificar controles a partir da técnica adversária que cada um impede | Capítulo 15 (nota 02 do bloco 00) |
| Atomic Red Team | Biblioteca de testes mapeados em técnicas do ATT&CK, executáveis por Red Canary | Validar detecções com testes pequenos, repetíveis e versionados | Capítulo 19 (nota 02 do bloco 02) e capítulo 24 (nota 02 do bloco 03) |
| Caldera | Plataforma de emulação adversária do MITRE, com agentes, perfis de adversário e plugins | Orquestrar emulação contínua e medir cobertura de detecção | Capítulo 19 (nota 01 do bloco 02) e capítulo 24 (nota 01 do bloco 03, com extensão OT) |
9. Mapa de Aplicação por Etapa Operacional
Uma forma de consolidar o índice é ler os padrões pela etapa do ciclo operacional em que dominam, o que transforma a lista em roteiro de trabalho. A tabela abaixo cruza etapa, padrão dominante e capítulo de referência, e serve de atalho para quem precisa saber rapidamente qual padrão puxar em cada situação.
| Etapa operacional | Padrões dominantes | Capítulo de referência |
|---|---|---|
| Requisitos e coleta | PIR e EEI como produto, OSINT e feeds como insumo, TLP como freio | Capítulo 01 (notas 07 a 10), capítulo 02 completo |
| Modelagem e análise | ATT&CK, Diamond Model, Kill Chain, Pyramid of Pain | Capítulo 04 e capítulo 05 |
| Priorização de risco | CVSS, EPSS, KEV e o par CTEM e EASM para exposição | Capítulo 05 (notas 05 e 14) e capítulo 21 |
| Detecção e caça | Sigma, YARA, ADS, DDLC, TaHiTI, PEAK, THRIVE | Capítulo 08, 18 e 23 |
| Validação e emulação | Atomic Red Team, Caldera, BAS contínuo | Capítulo 19 |
| Compartilhamento | STIX 2.1, TAXII 2.1, TLP 2.0, FIRST IEP, VERIS | Capítulo 22 |
| Resposta e forense | NIST SP 800-61, DAIR, KRAFF | Capítulo 15 (grupo RES) e capítulo 23 |
| Gestão do programa | CIS Controls v8, NIST CSF 2.0, HMM, FIRST IEP | Capítulo 15 (grupos GOV e MET) e capítulo 12 |
| Análise de artefatos | YARA, sandboxes, VERIS para registro do caso | Capítulo 25 e capítulo 04 (nota 04) |
10. Exemplo de Uso do Índice em Sessão de Governança
O índice ganha vida nas sessões de governança, quando uma nota nova chega citando um padrão sem linha própria ou uma versão nova de padrão muda a coluna de localização. O fluxo recomendado é curto: o proponente preenche o modelo da seção 2, a sessão decide entre aprovar, aprovar com ajuste ou rejeitar, e a linha aprovada entra no índice no mesmo ciclo, com o capítulo dono avisado da nova citação. O exemplo abaixo mostra duas decisões típicas em um único quadro de pauta, uma inclusão e uma revisão de versão.
Pauta de índice - sessão trimestral
Item 1 - INCLUSÃO
Proposta: primeira linha para o OCSF no grupo de intercâmbio
Base: capítulo 24 passou a referenciar o esquema em duas notas
Decisão: aprovado com ajuste; localização inclui capítulo 09, nota 08
Responsável pela edição: mantenedor do capítulo 27
Item 2 - REVISÃO DE VERSÃO
Proposta: atualizar a linha do ATT&CK para a versão corrente
Base: capítulo 20 já documenta a divisão de Defense Evasion
Decisão: aprovado; capítulo 15 (grupo MAP) avisado da mudança
Impacto: nenhuma linha de outros grupos é afetada
O registro das duas decisões fica na ata da sessão, e o histórico de propostas rejeitadas é tão valioso quanto o das aprovadas, porque evita que o mesmo padrão sem capítulo dono seja reapresentado a cada trimestre. Índice governado por pauta escrita se mantém estável; índice editado por conveniência pontual volta a acumular linhas órfãs em poucos ciclos.
11. Erros Comuns e Pontos de Atenção
- Referência a capítulo que não existe: toda coluna de localização precisa ser validada contra o mapa da nota 01, porque capítulos mudam de nome e notas ganham números novos a cada implantação, e um índice de governança com destino quebrado perde a confiança que precisa ter.
- Linha sem dono claro: quando dois capítulos explicam o mesmo padrão em profundidade, o índice deve marcar o dono e reduzir o outro a citação, ou a duplicação volta a crescer e as versões divergem em silêncio.
- Versão desatualizada: padrões como ATT&CK, TLP, STIX e TAXII têm versão no nome por razão, e citar versão errada em um índice de governança compromete o contrato de interoperabilidade descrito nos capítulos 20 e 22.
- Adotar padrão por moda: uma metodologia de caça nova só entra no índice quando a biblioteca tem capítulo que a descreve, e o índice não antecipa adoção; a seção de complementares é o lugar de testes, não a principal.
12. Integração com o Restante da Biblioteca
Este índice forma com o mapa (01), o glossário (02), o catálogo de fontes (04) e a bibliografia (05) o bloco de referência do capítulo 27, e a divisão de trabalho entre eles é a seguinte: o mapa diz onde está, o glossário diz o que significa um termo, este índice diz o que é um padrão e onde é tratado, o catálogo de fontes diz onde acompanhar a evolução e a bibliografia diz o que ler primeiro. Notas de capítulos temáticos citam padrões à vontade, mas a definição canônica de cada padrão mora no capítulo dono apontado aqui.
A utilidade operacional do índice aumenta quando ele é usado como roteiro de onboarding: um analista novo que lê as colunas de descrição e uso de todas as linhas sai com a arquitetura conceitual inteira da biblioteca em uma sessão, e depois entra nos capítulos donos apenas nos pontos que seu perfil exige. O índice é, nesse sentido, o compactado do acervo, e mantê-lo com rigor é mais barato que repetir apresentações orais do mesmo conteúdo a cada novo integrante da equipe. A regra final de convivência é simples: se uma citação de padrão não encontra resposta neste índice, o defeito está no índice ou na citação, e a sessão de governança precisa dizer qual dos dois.