PLT.2 - Plataforma de Gerenciamento de CTI (OpenCTI)

Controle PLT.2 do grupo PLT (Plataformas de Inteligência de Ameaças) do Framework CTH, derivado do Capítulo 8 do PDF de referência. Posiciona o OpenCTI (Open Cyber Threat Intelligence Platform) como plataforma de conhecimento, responsável pelo ciclo completo de gestão da CTI com grafo de conhecimento e mapeamento nativo de ATT&CK. O controle sustenta CTI e MAP ao transformar dados dispersos de fontes em conhecimento estruturado, navegável e reutilizável por CTI, SOC e Threat Hunting.

1. Contexto e Posicionamento no Framework CTH

O OpenCTI é uma plataforma de nova geração que vai além da gestão de IOCs, oferecendo suporte ao ciclo de vida completo da inteligência de ameaças. Enquanto o MISP do controle PLT.1 é otimizado para compartilhamento rápido de indicadores técnicos, o OpenCTI é otimizado para análise profunda, construção de perfis de atores e mapeamento de campanhas. A combinação das duas plataformas cobre o espectro completo: dados técnicos de alta rotatividade no MISP, conhecimento analítico de longa duração no OpenCTI.

Sem uma plataforma de gerenciamento, a inteligência estratégica e tática fica presa em relatórios de PDF e anotações pessoais, sem relacionamentos navegáveis entre ator, malware, infraestrutura e vítima. O Framework CTH exige que o programa mantenha esse conhecimento em modelo estruturado, porque consultas do tipo quais grupos usam a técnica T1059.001 e visam o setor financeiro só são possíveis quando entidades e relacionamentos existem como dados, e não como texto corrido. O OpenCTI usa nativamente o padrão STIX 2.1 do controle PLT.3, o que garante interoperabilidade com feeds, parceiros e ferramentas de mercado.

A escolha da plataforma de gerenciamento não precisa ser o OpenCTI em toda situação, mas o controle assume requisitos que qualquer candidata deve atender. O mínimo esperado é suporte nativo a STIX 2.1, grafo de conhecimento navegável, conectores configuráveis e controle de acesso por grupo. O OpenCTI atende esses requisitos com comunidade ativa e licença open source, o que o torna o caso de referência neste Framework.

2. Modelo de Dados Baseado em STIX 2.1

Todas as informações no OpenCTI são entidades STIX 2.1 conectadas por relacionamentos explícitos. As entidades principais descrevem o adversário e seu comportamento, os observáveis registram evidência técnica e as marcações controlam a divulgação conforme o PLT.5. A tabela resume as famílias de objetos mais usadas na prática.

Os relacionamentos são o diferencial decisivo sobre planilhas e repositórios de documentos. Um indicador isolado diz apenas que um IP existe; o mesmo IP ligado por communicates-with a uma infraestrutura de C2, atribuída a um intrusion set e observada em três campanhas, vira padrão investigável. A disciplina de criação de relacionamentos determina o valor real da plataforma ao longo dos meses.

3. Conectores: Tipos e Funções

Os conectores são módulos que integram o OpenCTI com fontes externas, ferramentas internas e fluxos de automação. Cada tipo tem função específica no pipeline, e a implantação mínima do nível Básico exige conector do MISP, enriquecimento com VirusTotal e ingestão de indicadores do abuse.ch. A tabela descreve os tipos essenciais.

A ordem de implantação dos conectores importa mais do que a quantidade. External import do MISP entra primeiro, enriquecimento em segundo e stream por último, porque o stream publica cada mudança da plataforma em tempo real e só faz sentido depois que a modelagem está estável. Cada conector deve ser monitorado por estado de execução e tamanho de fila, já que falhas silenciosas de ingestão são a principal causa de grafo desatualizado percebido tarde pela equipe.

4. Visualização em Grafo, Investigações e Dashboards

A visualização em grafo é a interface central para investigações. O analista parte de um indicador extraído de um alerta, expande os relacionamentos e visualiza em poucos cliques qual intrusion set usa aquela infraestrutura, quais técnicas ATT&CK aparecem na campanha e quais observáveis se repetem entre relatórios. Esse percurso substitui a busca manual em dezenas de PDFs e reduz o tempo de triagem de um alerta de inteligência.

A exploração do grafo é guiada por perguntas analíticas, e não por navegação aleatória. Antes de abrir a investigação, o analista formula a pergunta, como quem entrega esse malware, qual setor é visado e qual infraestrutura se repete, e usa filtros e expandir seletivamente para evitar telas ilegíveis com centenas de nós. O resultado é salvo dentro do caso correspondente, preservando a trilha de raciocínio para revisão posterior.

Os dashboards operacionais complementam o grafo com visões agregadas e temporais. Painéis típicos mostram evolução de campanhas por mês, distribuição de TTPs por ator, novos observáveis por fonte e prioridade de investigação. O trecho abaixo ilustra uma consulta GraphQL usada para montar um painel de perfil de ator, listando técnicas ATT&CK associadas a um grupo.

query PerfilDeAtor($nome: String!) {
  threatActors(first: 10, search: $nome) {
    edges {
      node {
        name
        description
        attackPatterns(first: 30) {
          edges { node { name x_mitre_id } }
        }
        targets(first: 10) {
          edges { node { ... on Country { name } } }
        }
      }
    }
  }
}

A investigação estruturada em casos organiza esse trabalho em etapas repetíveis. O fluxo típico usado pelo CTI em apoio ao SOC é o seguinte:

1. Criar um caso de investigação vinculado ao alerta ou ao PIR que motivou o trabalho.
2. Adicionar os observáveis iniciais e expandir os relacionamentos no grafo para identificar o grupo responsável.
3. Registrar notas analíticas e hipóteses dentro do caso, com referência às entidades consultadas.
4. Gerar produtos de saída, como lista de indicadores para o SIEM e resumo tático para o CSIRT.
5. Encerrar o caso com status e lições aprendidas, mantendo o conhecimento reutilizável na base.

5. OpenCTI e MISP: Divisão de Papéis no Pipeline

A integração entre as plataformas segue um fluxo com direções bem definidas. O MISP ingere feeds brutos, deduplica valores e publica eventos; um conector external import do OpenCTI consome esses eventos e cria indicadores, observáveis e relações com a fonte original. Enriquecimentos executados no OpenCTI geram contexto que pode ser exportado de volta ao MISP por conector stream ou exportação STIX, fechando o ciclo de ida e volta.

A divisão de papéis evita dois erros simétricos. Usar apenas o MISP mantém a operação presa a indicadores sem conhecimento acumulado, e usar apenas o OpenCTI para troca tática de IOCs sobrecarrega a plataforma de análise com tarefas de sincronização em massa. A regra prática é simples: valores técnicos que expiram rápido ficam no MISP; contexto e conhecimento que duram meses ficam no OpenCTI.

6. Casos de Uso Principais

Quatro casos de uso concentram o valor do OpenCTI no programa. Cada um exige modelagem própria e é atendido por consultas e visualizações específicas do grafo.

• Perfil de ator de ameaça: construir a ficha de um intrusion set com TTPs mapeadas em ATT&CK, malware e ferramentas usadas, infraestrutura histórica e setores visados, servindo de base para hunts do controle INS e para relatórios táticos.
• Rastreio de campanha: registrar campanha como entidade, ligar indicadores, e-mails de phishing e infraestrutura por communicates-with e related-to, e acompanhar a evolução temporal conforme novos relatórios confirmam ou expandem o escopo.
• Mapeamento de infraestrutura: representar domínios, IPs e certificados como infraestrutura conectada, revelando redes compartilhadas entre grupos aparentemente distintos e apoiando o EASM na descoberta de superfície do adversário.
• Inteligência de vulnerabilidades: ligar vulnerabilidades exploradas ativamente a atores e campanhas conhecidos, priorizando correções com base em quem realmente explora a falha, e apoiar o PRT na decisão de janelas de patch.

O caso de perfil de ator merece exemplo concreto de consulta. Perguntas como quais técnicas o grupo usa e quais vulnerabilidades ele explora em firewall de borda são respondidas no grafo com dois cliques a partir da entidade do ator. Essas respostas alimentam diretamente a priorização de detecções e os exercícios de simulação do grupo SIM.

7. Governança de Dados e Deduplicação

A qualidade do grafo depende de governança desde o primeiro dia de operação. Feeds que importam milhares de observáveis sem contexto criam entidades órfãs, sem fonte, sem marcação TLP e sem relação com qualquer ator. A política de ingestão deve exigir, para cada entidade criada, fonte identificada, marcação de divulgação e, quando possível, ao menos um relacionamento contextual.

A deduplicação exige regras conscientes, porque o OpenCTI propõe correspondência por valor de observável, mas não decide sozinho entre entidades semelhantes com nomes diferentes. Dois relatórios que citam o mesmo intrusion set com variantes de nome podem criar entidades duplicadas, fragmentando o conhecimento. Práticas recomendadas incluem usar aliases padrão das fontes de referência, revisar mensalmente candidatos a duplicata e registrar a fusão com nota explicativa de quem aprovou.

O controle de acesso deve espelhar a estrutura de divulgação da organização. Grupos separados para CTI, SOC e equipes de resposta, combinados com marcações TLP convertidas em regras de visibilidade, impedem que conteúdo recebido de parceiros circule internamente além do permitido. Auditorias trimestrais de permissão, comparando membros de grupos com a matriz de papéis, mantêm o acesso alinhado à rotatividade de pessoas e de projetos.

Além da entrada, a saída de dados também precisa de política. Indicadores expirados devem ser desativados na exportação, relatórios antigos permanecem como contexto histórico e infraestrutura inativa ganha rótulo correspondente. Uma revisão semestral do panorama, comparando entidades ativas com os PIRs vigentes, remove conhecimento fora de escopo e mantém o grafo enxuto e confiável.

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

O Framework CTH organiza as salvaguardas do controle em três níveis cumulativos, com evidências verificáveis. O plano de implantação deve preencher a coluna de entregável com data e responsável. A tabela resume os objetivos.

Os playbooks são o mecanismo de automação que sustenta os níveis Intermediário e Avançado. O exemplo abaixo descreve, em formato ilustrativo, um playbook que enriquece indicadores novos e os exporta para o MISP, respeitando a divisão de papéis da seção 5. Registre cada versão do playbook com dono e objetivo, porque regras sem documentação se tornam inauditáveis em poucos meses.

# Playbook ilustrativo: enriquecimento e exportação de indicador novo
triggers:
  - on_create: Indicator
filters:
  - key: labels
    operator: contains
    values: [phishing]
actions:
  - connector: virustotal-analysis
    scope: [domain-name, ipv4-addr]
  - connector: shodan-internetdb
    scope: [ipv4-addr]
  - connector: export-stix-misp
    scope: [Indicator]
    marking_required: [tlp-amber, tlp-clear]

9. Erros Comuns e Pontos de Atenção

Os erros abaixo aparecem em grande parte das implantações e degradam o grafo silenciosamente. Cada item traz o efeito observável e a correção recomendada.

• Importar feeds sem contexto, acumulando milhares de observáveis órfãos; efeito: buscas lentas e analistas que desconfiam da base; correção: exigir fonte e marcação mínimas por entidade.
• Plataforma vazia de relacionamentos, com entidades isoladas; efeito: grafo sem valor analítico; correção: modelar ao menos um relacionamento por entidade de ameaça criada.
• Duplicatas de atores com nomes divergentes entre fontes; efeito: conhecimento fragmentado e métricas distorcidas; correção: aliases padronizados e revisão periódica de fusões.
• Enriquecimento executado em todo observável sem filtro de prioridade; efeito: custo alto de API e cotas esgotadas; correção: playbooks com critérios de prioridade e cache.
• Marcações TLP ausentes na importação automática; efeito: risco de divulgação indevida; correção: mapping obrigatório de tag para marking no conector.
• Dashboards criados sem dono e sem pergunta de negócio; efeito: painéis obsoletos; correção: vincular cada painel a um PIR do ciclo de inteligência.
• Exportar para o SIEM tudo que entra na plataforma, sem priorização; efeito: detecções genéricas e alertas de baixa qualidade; correção: exportar apenas indicadores com score mínimo e fonte confiável.

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

O PLT.2 funciona como memória de longo prazo do programa e alimenta múltiplos controles simultaneamente. O CTI usa o grafo para produzir relatórios táticos e estratégicos, o INS consome perfis de ator para hipóteses de hunt, o AUT sincroniza indicadores priorizados com o SIEM e o EDR, e o IR recupera contexto de infraestrutura durante respostas a incidentes. A interoperabilidade por STIX 2.1 liga o controle ao PLT.3, e a governança de fontes que abastece o grafo é definida no PLT.4.

No plano de maturidade, o marco Básico exige instância operando com conectores mínimos e panorama modelado; o Intermediário exige automação por playbooks e integração com fontes externas adicionais; o Avançado exige descobertas analíticas reais produzidas pelo grafo, como redes de infraestrutura compartilhada entre grupos. A métrica definitiva não é o volume de entidades armazenadas, e sim a quantidade de decisões de detecção e de investigações que citam a plataforma como fonte.