Requisitos de Informação Essencial (EEIs)

Nota 09 do capítulo 01 - Fundamentos de Cyber Threat Intelligence (CTI). Ensina a decompor cada PIR em EEIs (Essential Elements of Information), as informações específicas que a coleta precisa capturar para responder ao requisito.
É a nota que transforma pergunta em plano de coleta, herdando da doutrina militar de inteligência a disciplina de decomposição hierárquica.
Dialoga com a nota 07 (PIRs de origem), com a nota 02 (fontes de coleta) e com os controles CTI.1 e CTI.4 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Um PIR formulado com excelência ainda não é um programa de coleta: é uma pergunta esperando um plano. Entre a pergunta da nota 07 e a coleta do capítulo 02 existe uma camada de decomposição que define, com precisão operacional, quais informações específicas precisam ser capturadas, de quais fontes, com que cadência e em que formato, para que a resposta ao requisito se torne possível. O EEI (Essential Element of Information), ou elemento essencial de informação, é o instrumento dessa camada, e é ele que impede o cenário mais comum de fracasso: equipe com dezenas de feeds assinados e nenhuma capacidade de responder às perguntas que importam.

Esta nota cobre a origem doutrinária do conceito, a taxonomia aplicável a CTI, a estrutura de registro que conecta EEI, PIR e fonte, exemplos concretos por tipo de ameaça, a análise de lacunas entre o que precisa ser coletado e o que é possível coletar, e a governança do catálogo. No capítulo 15, o CTI.1 institui os PIRs e exige sua decomposição em elementos coletáveis, e o CTI.4 organiza a coleta técnica que executa o plano resultante. A nota 10 cuida do momento em que os EEIs consomem mais capacidade do que a equipe consegue sustentar, e a nota 11 mede se o material capturado chega a apoiar decisões.

2. O Que É um EEI e De Onde Ele Vem

O conceito vem da doutrina militar de inteligência, na qual o comandante declara PIRs e o estado-maior os decompõe em EEIs: itens específicos de informação que, quando coletados, permitem responder ao requisito e decidir. Na doutrina original, os EEIs integram os CCIR (Commander's Critical Information Requirements) e orientam o plano de coleta dos órgãos de inteligência, evitando que sensores e analistas trabalhem sem saber o que realmente importa para a decisão. A tradução para CTI é direta: o PIR é a pergunta do CISO ou do SOC, e o EEI é o dado específico que o analista precisa capturar do ambiente de ameaças para respondê-la.

A hierarquia completa tem três camadas que a biblioteca mantém separadas. O PIR pergunta de forma estrutural e duradoura, com a estrutura definida na nota 07. O SIR (Specific Intelligence Requirement) decompõe o PIR em subperguntas situacionais quando um incidente ou campanha em curso exige resposta imediata. O EEI desce ao nível do dado: uma informação específica, identificável e coletável, como a lista de domínios recém-registrados que imitam a marca ou o conjunto de técnicas de acesso inicial usadas por um grupo contra o setor. PIR vence em meses, SIR vence em dias, EEI vive enquanto o PIR pai existir e permanecer prioritário.

A camada de EEIs é também a que torna a coleta auditável e automatizável. Quando cada item tem fonte, cadência e formato de produto declarados, o pipeline do capítulo 02 executa, monitora e reporta sem depender da memória de um analista. Sem essa camada, a coleta vira hábito acumulado, e a pergunta "por que monitoramos isso" não tem resposta documentada.

Bons EEIs compartilham características verificáveis, úteis como critério de revisão do catálogo:

• Específicos: descrevem a informação em si, e não outra pergunta; "domínios com a marca registrados nos últimos 30 dias" é EEI, "como está o phishing contra nós" é pergunta.
• Coletáveis: existe pelo menos uma fonte realista, acessível e legal, capaz de produzir o item na cadência declarada.
• Rastreáveis: cada EEI aponta para o PIR pai que o originou e para as fontes que o alimentam, nos dois sentidos.
• Acionáveis: a informação capturada muda alguma detecção, busca, decisão ou resposta quando chega, e não apenas enriquece um repositório.
• Mensuráveis: é possível auditar se a coleta aconteceu na cadência declarada e com a qualidade prometida.

3. Taxonomia de EEIs e Estrutura de Registro

Sem taxonomia, o catálogo vira lista infinita de itens soltos, e a análise de lacunas fica impossível de fazer. A taxonomia de referência desta biblioteca divide os EEIs em quatro classes, que cobrem o espectro do dado bruto ao contexto de campanha e se mapeiam naturalmente nos capítulos de indicadores e de modelos analíticos. As classes não são excludentes, e um mesmo requisito normalmente gera itens em mais de uma delas:

A estrutura de registro abaixo é o formato de referência do catálogo. Cada campo sustenta uma operação específica: o PIR pai sustenta a rastreabilidade da nota 07, a taxonomia sustenta a análise de lacunas da seção 5 e o dono nominal sustenta a governança da seção 6.

catalogo_eei:
  pir_origem: PIR-2025-003
  itens:
    - id: EEI-2025-041
      descricao: grupos de ransomware ativos contra o setor logístico com vítimas públicas nos últimos 12 meses
      taxonomia: campanha
      fonte_primaria: sites de vazamento e ISAC setorial
      fonte_secundaria: imprensa especializada e CERTs nacionais
      cadencia: semanal
      formato_produto: lista curada com grupo, vítima, data e evidência citada
      dono: analista tático 1
      validade: 2025-09-30
    - id: EEI-2025-042
      descricao: vetores de acesso inicial observados nas campanhas contra o setor, com técnica ATT&CK e evidência
      taxonomia: ttp
      fonte_primaria: relatórios comerciais e repositórios públicos de relatórios
      fonte_secundaria: hunting retrospectivo na telemetria interna
      cadencia: mensal
      formato_produto: matriz ATT&CK com frequência observada e casos citados
      dono: analista tático 2
      validade: 2025-09-30

Dois cuidados de preenchimento evitam erros clássicos logo na criação do item. A descrição deve conter o que contar e a janela temporal, porque "grupos ativos" sem janela não é coletável. As fontes previstas devem nomear o canal real de acesso, porque "internet" não é fonte, e sim "sites de vazamento monitorados pelo TIP" ou "feed comercial com cobertura de infraestrutura".

3.1 Regras de Derivação de um PIR em EEIs

A decomposição não precisa ser um exercício criativo a cada vez, e um conjunto pequeno de regras torna o resultado repetível entre analistas. O rascunho de resposta hipotética é a técnica central: quem tenta responder o PIR com o que já tem descobre na hora onde faltam dados. As regras abaixo completam o método e evitam tanto a escassez quanto o excesso:

• Responda o PIR com um rascunho hipotético: os buracos desse rascunho são os EEIs candidatos, porque revelam exatamente o que falta saber.
• Uma informação por item: quando a descrição usa "e" para unir informações diferentes, são dois EEIs, porque a coleta da dupla raramente acontece na mesma cadência.
• Prefira o observável ao inferido: "técnicas de acesso inicial observadas" é coletável; "nível de risco do grupo" é produto de análise, e não item de coleta.
• Limite entre três e sete itens por requisito: menos que três indica PIR mal formulado, e mais que sete indica um requisito abrigando dois.
• Nomeie a janela temporal em toda descrição: última campanha, últimos 30 dias, último trimestre; sem janela, a coleta nunca sabe quando parar.

4. Exemplos Concretos por Tipo de Ameaça

A decomposição em EEIs muda de perfil conforme o tipo de ameaça, porque cada família de adversário expõe rastros diferentes no ambiente. A tabela abaixo traz conjuntos típicos de EEIs para três ameaças de referência, com a classe da taxonomia e a fonte que normalmente sustenta a coleta. Os itens são referências de partida, e a calibração final depende do setor, da superfície e da telemetria da organização que os adota:

Três observações tornam a tabela operacional. Primeiro, o mesmo PIR gera EEIs de classes diferentes, e a mistura é saudável, porque resposta de qualidade combina dado bruto e contexto. Segundo, ameaças de ciclo rápido, como phishing, exigem cadência diária ou semanal, enquanto perfis de APT aceitam cadência mensal sem perda de valor, e essa diferença precisa estar registrada no campo de cadência do catálogo. Terceiro, quando um incidente real acontece, os EEIs de campanha dão origem a SIRs situacionais da nota 07, e o catálogo já preparado é o que permite escalar sem improviso.

5. Relação com Fontes de Coleta e Análise de Lacunas

O catálogo de EEIs é o que transforma a gestão de fontes de colecionismo em engenharia de cobertura. Cada EEI declara as fontes que o alimentam, e cada fonte do capítulo 02, de OSINT a feeds comerciais e telemetria interna, passa a ter papel explícito no plano. A conversa sobre renovar ou cancelar uma fonte usa essa aderência como critério objetivo, e não como preferência de contrato:

A análise de lacunas compara o que o catálogo pede com o que as fontes entregam, e todo EEI sem fonte viável é uma lacuna que precisa ser declarada. A equipe resolve cada lacuna por uma de três saídas: adquirir ou ativar uma fonte nova, reformular o EEI para o coletável mais próximo, ou aceitar formalmente o risco, com registro e validade. Lacunas silenciosas, itens que ninguém coleta e ninguém declarou impossíveis, são o pior estado possível, porque produzem a falsa sensação de que o PIR está coberto. O registro abaixo documenta uma lacuna resolvida por reformulação:

registro_lacuna:
  eei: EEI-2025-044
  descricao: credenciais de colaboradores expostas em stealer logs recentes
  motivo_lacuna: nenhuma fonte acessível e legal cobre os fóruns onde os logs circulam
  saida_escolhida: reformulacao para o coletavel mais proximo
  eei_reformulado: e-mails de colaboradores presentes em bases publicas agregadas de vazamentos
  risco_aceito: cobertura parcial do requisito, registrada com o CISO
  revisao: 2025-08-01

A consulta abaixo, no estilo do Microsoft Sentinel e reutilizando a convenção de watchlists da nota 07, expõe os itens órfãos do catálogo, que são o primeiro sinal de lacuna silenciosa:

// EEIs sem fonte ou sem cadencia declaradas: lacunas do plano de coleta
_GetWatchlist('EEIs')
| where isempty(FontePrimaria) or isempty(Cadencia)
| project EEIId, Descricao, PIRId, Taxonomia, FontePrimaria
| order by PIRId asc

O mesmo mecanismo serve para a direção inversa, e vale aplicá-lo todo mês. EEIs coletados há mais de duas cadências sem produção registrada indicam coleta inútil, que consome capacidade sem responder a nada, e merecem o mesmo corte que a nota 10 aplica a requisitos sem consumo. A regra é simétrica: sem fonte, o item não coleta; sem produção, o item não justifica a coleta.

6. Gestão do Catálogo de EEIs

O catálogo é um produto vivo do programa, e não um documento de fundação. Ele vive no TIP quando a organização opera MISP ou OpenCTI, com EEIs modelados como tags ou objetos vinculados aos PIRs, ou em repositório versionado de YAML quando a maturidade ainda não sustenta plataforma. A regra essencial é uma só: uma fonte de verdade, com dono e revisão declarados. A governança recomendada combina as práticas abaixo:

• ID estável e imutável: o identificador nunca é reaproveitado, porque históricos de coleta e métricas referenciam o item ao longo dos anos.
• Dono nominal por EEI: cada item tem um analista responsável pela coleta na cadência, e a distribuição do catálogo é decidida em reunião, não presumida.
• Revisão junto ao PIR pai: quando a nota 07 revisa o portfólio trimestralmente, os EEIs de cada requisito são revalidados na mesma sessão, com aposentadoria em cascata quando o requisito sai.
• Versionamento e histórico: itens aposentados ficam arquivados com o material que produziram, servindo de memória institucional e de base para caças retrospectivas futuras.
• Indicador de saúde por item: última coleta, última produção e fontes ativas, exibidos no painel do programa no padrão do grupo MET do capítulo 15.

A modelagem na plataforma importa menos do que a capacidade de responder às perguntas de saúde do item: quando foi coletado pela última vez, o que produziu e por qual fonte. Em MISP, os EEIs costumam aparecer como tags de coleta vinculadas a eventos, enquanto o OpenCTI permite objetos personalizados ligados aos casos de requisito. Modelagens que não respondem a essas três perguntas criam catálogos bonitos e inúteis.

O teste de maturidade do catálogo é simples e rápido: escolha três PIRs prioritários e pergunte a três analistas, separadamente, quais EEIs os sustentam. Respostas coincidentes indicam catálogo vivo, que orienta a rotina real da equipe. Respostas divergentes ou vagas indicam que a decomposição existe apenas no papel, e que o programa está coletando por hábito, não por requisito.

7. Erros Comuns e Pontos de Atenção

Os erros abaixo aparecem com regularidade em catálogos reais e têm correção direta:

• Confundir EEI com pergunta: item redigido como subpergunta desce a decomposição infinita; correção: exigir que a descrição nomeie a informação a capturar, com janela temporal explícita.
• EEI sem fonte: item coletável no papel e impossível na prática; correção: fonte primária obrigatória no registro, com lacuna formal quando ela não existir.
• Decomposição exaustiva: transformar cada PIR em vinte EEIs, replicando em miniatura o portfólio inflado que a nota 10 combate; correção: de três a sete itens por requisito, focados nos que de fato sustentam a resposta.
• Cadência idêntica para tudo: coletar perfis de APT diariamente e phishing mensalmente, desperdiçando capacidade e atrasando resposta ao mesmo tempo; correção: cadência por natureza do item, revisada com o dono.
• Catálogo paralelo: EEIs vivos em planilha, e-mail e cabeça de analista, sem fonte de verdade; correção: registro único no TIP ou em repositório versionado, com migração completa e data declarada.
• Confundir coleta com produção: item capturado todo mês e nunca convertido em produto consumível; correção: campo de formato de produto obrigatório e indicador de saúde por item.
• Ignorar a telemetria interna: tratar todo EEI como material externo, quando resposta a incidentes e caças passadas estão entre as melhores fontes de TTPs; correção: mapear telemetria interna como fonte nos itens de classe TTP.
• EEI órfão: item que sobrevive sem PIR pai ativo depois que o requisito saiu do portfólio; correção: aposentadoria em cascata na revisão trimestral da nota 07.
• Fonte ambígua: descrição de fonte como "monitorar redes sociais", sem canal nem método; correção: nomear canal, conta e método no campo de fonte, com teste de coleta na criação.

Um ponto final de atenção é a fronteira entre EEI e IOC. O domínio de phishing específico que a campanha usou ontem é indicador, e entra no ciclo do capítulo 03 com validade curta e tratamento operacional. O padrão de registro de domínios que a marca deve monitorar continuamente é EEI, e vive no catálogo enquanto o PIR existir. A confusão entre as duas camadas produz feeds gigantes sem contexto ou catálogos vagos sem dado, e a separação disciplinada é o que permite aos dois ciclos funcionar juntos.

8. Integração com o Restante da Biblioteca

Os EEIs são a dobradiça entre direção e coleta. A nota 07 cria as perguntas, esta nota as decompõe em itens coletáveis e o capítulo 02 executa a coleta por fonte, com o CTI.3 e o CTI.4 do capítulo 15 como salvaguardas do processo. Na sequência do capítulo, a nota 10 prioriza o esforço quando os EEIs excedem a capacidade da equipe, e a nota 11 mede se a informação capturada chega a apoiar decisões reais. No capítulo 03, os indicadores capturados pelo catálogo ganham contexto, confiança e validade, e no capítulo 04 os TTPs observados se organizam em modelos como ATT&CK e Diamond Model.

Para aplicar esta nota hoje, escolha o PIR mais importante do portfólio, decomponha-o em três a cinco EEIs com o formato da seção 3, nomeie fonte e dono para cada item e registre o catálogo no lugar onde hoje concentra o trabalho real da equipe. Um único requisito bem decomposto já muda a natureza da coleta da semana seguinte, e o padrão se replica ao restante do portfólio na primeira revisão trimestral. Quando o catálogo estiver de pé, a pergunta "por que coletamos isso" passa a ter resposta com ID, fonte e dono, e essa é a diferença entre uma equipe de inteligência e um agregador de feeds.