CTI.1 - Requisitos de Inteligência (PIRs)

Nota do grupo COL (Ciclo de Inteligência: Planejamento e Coleta) da seção 15 - Framework CTH - Controles.
Deriva do Capítulo 9 do PDF de referência e do modelo de ciclo de CTI da seção 2.8.
Define os PIRs como filtro inicial e critério final de valor do programa integrado de CTI e Threat Hunting.

1. Contexto e Posicionamento no Framework CTH

O controle CTI.1 abre o grupo COL, dedicado ao planejamento e à coleta do ciclo de inteligência descrito na seção 2.8 do Framework CTH. Esse ciclo é um processo iterativo de seis etapas, e a primeira delas, o planejamento e a direção, determina o que a inteligência precisa responder. Sem essa definição, as fases de coleta, processamento, análise e disseminação operam sem critério de relevância, e o programa passa a produzir volume em vez de valor. O CTI.1 é, portanto, o mecanismo que conecta o risco do negócio ao esforço técnico de SOC, CSIRT e Threat Hunting.

O Framework CTH recomenda manter entre 5 e 15 PIRs ativos, priorizados pela relevância para o risco da organização. O intervalo é proposital: com menos de cinco requisitos, o programa cobre apenas uma fração das decisões que dependem de inteligência; com mais de quinze, a equipe perde capacidade de responder a todos dentro do prazo e a profundidade da análise sofre. Cada PIR deve ter proprietário designado, frequência de revisão definida e critério de satisfação explícito, três atributos que convertem uma pergunta vaga em um compromisso verificável de produção.

2. Definição e Papel dos PIRs no Ciclo de Inteligência

Priority Intelligence Requirements (PIRs) são as perguntas críticas que o programa de CTI deve ser capaz de responder para apoiar decisões defensivas e de negócio. Eles não são listas de IOCs, feeds nem relatórios, são perguntas. A coleta existe para reunir dados capazes de respondê-las, a análise organiza essas respostas e a disseminação as entrega a quem decide. Por isso se diz que o ciclo de inteligência começa e termina nos PIRs: eles orientam o planejamento e, na etapa de retroalimentação (CTI.9), indicam se as respostas foram úteis e o que deve ser reformulado.

Um conjunto de PIRs bem formulado produz três efeitos práticos. Primeiro, reduz desperdício, porque a equipe deixa de colecionar relatórios sem relação com o risco real. Segundo, cria rastreabilidade, já que cada produto de inteligência pode ser vinculado ao requisito que o motivou. Terceiro, viabiliza medição honesta, porque o percentual de PIRs efetivamente respondidos passa a ser a métrica de valor do programa, no lugar da contagem de relatórios publicados.

3. Derivação de PIRs a Partir do Risco de Negócio

PIRs derivam das decisões que a organização precisa tomar e dos riscos que ameaçam seus objetivos, não do catálogo editorial dos fornecedores. A oficina de derivação reúne CISO, liderança de resposta a incidentes, gestor de vulnerabilidades e donos de processo de negócio, e segue quatro passos. O resultado é um conjunto de perguntas ancoradas em decisões reais, com prazo e consequência, e que nenhum analista inventaria sozinho diante de um feed.

1. Inventariar as decisões de segurança e de negócio que dependem de informação externa sobre ameaças, como priorizar a remediação de uma CVE, renovar a arquitetura de acesso remoto ou contratar seguro cibernético.
2. Mapear os ativos e processos que sustentam essas decisões, incluindo dados regulados, sistemas transacionais e serviços expostos, para dar peso ao impacto potencial.
3. Converter cada risco priorizado em pergunta específica, verificando se a resposta alteraria uma decisão concreta; se não altera, não é PIR.
4. Priorizar as perguntas por relevância de risco, validar com os stakeholders e atribuir a cada uma proprietário, cadência e critério de satisfação.

A tabela a seguir ilustra a conversão de decisões em requisitos de inteligência.

4. Exemplos de PIRs por Setor

Formulações corretas delimitam adversário ou comportamento, ambiente e janela temporal, e apontam a decisão ou o controle que a resposta vai alimentar. As formulações genéricas, em contraste, não têm consumidor definido e não podem ser respondidas de forma verificável.

Em todos os exemplos aceitos há três elementos comuns: um adversário ou comportamento delimitado, um escopo de ambiente e de tempo, e um destino da resposta, seja uma detecção, um controle ou uma decisão. Sem esses elementos, a pergunta vira tema de pesquisa acadêmica, não requisito de inteligência. O teste final é perguntar o que muda na segunda-feira seguinte à entrega da resposta; se nada muda, o requisito precisa ser reformulado.

5. Cascata PIR, SIR, EEI e Requisitos de Coleta

O Framework CTH trata a decomposição como obrigatória: cada PIR deve ser desdobrado em requisitos específicos de informação (SIRs, Specific Information Requirements) que detalham os tipos de dado necessários, e cada SIR em requisitos de coleta (CRs, Collection Requirements) que identificam fontes e métodos. A doutrina clássica de inteligência adiciona um nível intermediário, os EEI (Essential Elements of Information), que são os fatos elementares cuja observação compõe a informação específica. A cascata completa segue o formato abaixo.

• PIR: pergunta prioritária de negócio, respondida por produtos de inteligência.
• SIR: subpergunta operacional que materializa o PIR em algo analisável dentro da cadência definida.
• EEI: fato elementar a ser observado, como um grupo ativo, um vetor empregado ou uma vulnerabilidade explorada.
• CR: fonte e método de coleta que produzirão evidência para cada EEI.

O registro preenchido abaixo mostra a cascata para um PIR de um hospital, em formato consumível pela plataforma de CTI (PLT.x).

pir:
  id: PIR-02
  pergunta: "Quais campanhas de ransomware estão ativas contra hospitais e laboratórios no Brasil e quais vetores de acesso inicial predominam?"
  proprietario: "Líder do CSIRT"
  cadencia: "Trimestral, com revisão ad hoc em campanha confirmada no setor"
  criterio_satisfacao: "Relatório tático com grupos ativos, vetores de acesso inicial, TTPs mapeadas em ATT&CK e detecções recomendadas, cobrindo janela de 90 dias"
  sir:
    - id: SIR-02.1
      pergunta: "Quais grupos de ransomware atacaram o setor de saúde brasileiro na janela avaliada?"
      eei:
        - id: EEI-02.1.1
          fato: "Nome dos grupos ativos e vítimas confirmadas no setor"
          cr:
            - fonte: "Relatórios táticos de fornecedores (TLP:AMBER)"
            - fonte: "Alertas de ISAC de saúde e notas do CERT nacional"
        - id: EEI-02.1.2
          fato: "Variações de malware e hashes associados"
          cr:
            - fonte: "Repositórios de malware e sandbox própria (CTI.4)"
    - id: SIR-02.2
      pergunta: "Quais vetores de acesso inicial predominam nas campanhas identificadas?"
      eei:
        - id: EEI-02.2.1
          fato: "Técnicas ATT&CK de acesso inicial por grupo"
          cr:
            - fonte: "Relatórios de pesquisa OSINT (CTI.3)"
            - fonte: "Logs internos de gateway de e-mail e WAF (DAT.1, DAT.3)"
  saidas_esperadas:
    - "Relatório tático trimestral para CSIRT e SOC"
    - "Regras Sigma e consultas de hunting para acesso inicial (TH.x, SIM.x)"

A cascata garante que nenhuma pergunta fique sem fonte e que nenhuma fonte seja coletada sem pergunta. Quando um EEI não tem CR viável, o registro explicita uma lacuna de coleta, que se transforma em demanda para o CTI.3, para o CTI.4 ou para a contratação de fontes comerciais (PLT.4).

6. Critérios de um Bom PIR

A qualidade de um PIR pode ser auditada com cinco critérios objetivos. A tabela serve como checklist de revisão trimestral e como artefato de onboarding para novos analistas.

Um teste adicional é o do consumidor: nomeie quem lê a resposta e o que essa pessoa fará com ela. Se não houver consumidor identificado, o requisito deve ser reformulado ou descontinuado, por mais interessante que pareça. Requisitos sem consumidor consomem coleta e análise, mas nunca viram decisão.

7. Revisão Periódica, Revisão Ad Hoc e Descontinuação

O CTI.1.3 exige revisão trimestral documentada, avaliando três questões para cada PIR: ele continua relevante, foi respondido de forma satisfatória no período e precisa ser reformulado. A resposta negativa não é fracasso, é insumo. Um PIR respondido de forma estável por dois ciclos pode migrar para monitoramento contínuo e liberar capacidade da equipe para riscos emergentes.

A revisão ad hoc (CTI.1.4) dispara fora do calendário em eventos como vulnerabilidade zero-day amplamente explorada, campanha direcionada ao setor, mudança relevante de infraestrutura, como aquisição ou migração para nuvem, e incidente interno que revele lacuna de inteligência. Nesses gatilhos, a pergunta é sempre a mesma: os PIRs atuais ainda direcionam a coleta para o risco que importa agora. Cada revisão deve gerar ata com decisões, mantendo o histórico de por que um requisito entrou, mudou ou saiu.

A descontinuação é parte normal do ciclo de vida. Um PIR cuja resposta já está embutida em detecções estáveis, cujo consumidor saiu do processo de decisão ou cujo risco desapareceu deve ser arquivado com justificativa e data. Manter requisitos mortos ativos infla o catálogo, consome coleta e esconde o fato de que o programa deixou de responder às perguntas vivas.

8. Anti-Padrões na Formulação de PIRs

• PIR genérico do tipo "quais são as ameaças": não delimita adversário, ambiente nem decisão, e qualquer resposta serve e não serve ao mesmo tempo.
• PIR espelho do mercado: copia a agenda editorial de relatórios de fornecedores em vez do risco da organização, gerando coleta por colecionar.
• PIR sem consumidor: ninguém nomeado para usar a resposta, o que garante produtos lidos por ninguém.
• PIR enciclopédico: pergunta que exigiria meses de análise para uma resposta única; deve ser fatiado em SIRs com janelas curtas.
• PIR estático: catálogo idêntico há dois anos, sinal de que o processo de revisão existe apenas no papel.
• PIR sem decomposição: pergunta sem SIR, EEI e CR associados, impossível de operacionalizar em coleta.

Cada anti-padrão tem correção direta: aplicar os critérios da seção 6, refazer a derivação com os stakeholders e forçar a cascata da seção 5 antes de aceitar o requisito no catálogo. O catálogo enxuto e vivo é mais valioso do que um catálogo extenso e decorativo.

9. Implementação Prática e Salvaguardas por Nível

O Framework CTH organiza o controle em cinco salvaguardas progressivas, que funcionam como roteiro de adoção por nível de maturidade.

Dois detalhes de implementação evitam atrito. Primeiro, versionar o catálogo de PIRs em repositório com histórico de alterações, o que simplifica auditoria e evidencia evolução. Segundo, publicar uma versão resumida para SOC e CSIRT, porque analistas que conhecem os PIRs escalam melhor os achados e pedem inteligência com contexto adequado.

10. Métricas, Rastreabilidade e Ligação com o Feedback

O CTI.1.5 propõe medir o percentual de PIRs efetivamente respondidos e identificar requisitos negligenciados. Métricas úteis incluem a proporção de produtos de inteligência vinculados a algum PIR, o tempo médio entre formulação e primeira resposta satisfatória e a quantidade de PIRs sem nenhuma coleta associada no ciclo. A rastreabilidade pode viver na plataforma de CTI (PLT.2), vinculando relatórios, notas e eventos aos identificadores de PIR e SIR.

O fechamento do ciclo acontece no feedback (CTI.9): os consumidores avaliam utilidade e lacunas, e essa avaliação realimenta a revisão trimestral. Um PIR cujas respostas nunca geram decisão sinaliza erro de derivação; um risco novo sem PIR correspondente sinaliza cegueira de planejamento. O par CTI.1 e CTI.9 transforma o catálogo de requisitos em um sistema vivo de aprendizagem, e não em um documento anual de estante.

11. Integração com Outros Controles do Framework CTH

Adotar o CTI.1 sem ligar o catálogo aos consumidores e às métricas produz um artefato de prateleira. A prática que funciona é simples e disciplinada: poucos requisitos vivos, cascata completa, revisão com ata e rastreabilidade na plataforma, de modo que cada hora de coleta e análise possa ser justificada pelo risco que ela efetivamente reduz.