OpenCTI, MISP, IntelOwl, YETI (Open Source)

Nota da subpasta 01 - Threat Intelligence Platforms (TIPs), no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Estrutura o stack open source de inteligência: OpenCTI como grafo de conhecimento, MISP para compartilhamento, IntelOwl para análise automatizada de observáveis e YETI para trabalho centrado em observáveis.
Dialoga com as notas comerciais da mesma pasta, com o controle PLT do Capítulo 15 e com a nota de plataformas de gerenciamento de IOCs do Capítulo 03.

1. Contexto e Posicionamento na Biblioteca

O Capítulo 09 apresentou a categoria TIP e o Capítulo 15 definiu o processo que ela deve servir; esta nota organiza a resposta open source madura que a comunidade usa em produção. A tese central é que não existe uma ferramenta open source que faça tudo, e sim quatro ferramentas especializadas que se combinam: o MISP domina o compartilhamento e a gestão de eventos, o OpenCTI domina a modelagem relacional da inteligência, o IntelOwl automatiza a análise de observáveis individuais e o YETI organiza a caixa de ferramentas de um analista centrado em observáveis. O controle PLT.1 e PLT.2 do Capítulo 15 já situou MISP e OpenCTI como plataforma de compartilhamento e de gerenciamento; aqui o objetivo é mostrar como as quatro peças formam um ecossistema com fronteiras claras.

A justificativa econômica também importa. Organizações sem orçamento para TIP comercial operam esse stack com custo de infraestrutura e horas de engenharia, e equipes com TIP comercial o usam como camada de compartilhamento, de enriquecimento ou de laboratório. Em ambos os casos, o desenho da arquitetura, quem é a fonte da verdade, quem enriquece e quem distribui, vale mais do que a escolha isolada de cada ferramenta, e é isso que as seções seguintes fixam.

2. Papéis Distintos no Stack

A confusão mais comum é tratar as quatro como concorrentes diretas. A tabela fixa o papel real de cada uma no pipeline de inteligência, do recebimento da matéria prima até a distribuição.

Lida por colunas, a tabela explica por que programas maduros não escolhem entre elas: cada uma resolve um elo diferente da corrente. O erro de arquitetura é duplicar funções, por exemplo manter watchlists independentes no MISP e no OpenCTI sem fonte única, ou usar o IntelOwl como banco histórico, função que ele não foi desenhado para cumprir.

Outro eixo de diferenciação é o ciclo de vida do dado. MISP e OpenCTI guardam e versionam conhecimento ao longo de anos, IntelOwl trabalha com jobs que têm minutos de vida e YETI mantém observáveis correntes com histórico leve. O desenho saudável posiciona as ferramentas de memória longa como fonte da verdade e as de memória curta como serviço, e o contrato entre elas é assinado por conector documentado, não por exportação manual de planilha.

3. OpenCTI: Grafo de Conhecimento, Conectores e Streams

O OpenCTI modela inteligência como grafo de entidades e relacionamentos conforme o padrão STIX 2.1: malware, atores, intrusions sets, infraestrutura, observáveis, relatórios e relações entre todos eles. A força prática do produto está no ecossistema de conectores, componentes que importam dados de feeds, relatórios e plataformas externas, enriquecem entidades com serviços externos e exportam conteúdo para SIEM, SOAR e outras plataformas. As streams do OpenCTI, baseadas em mensageria, permitem que sistemas externos recebam em tempo real cada evento do grafo, o que transforma a plataforma em barramento de inteligência e não apenas em banco consultável.

Na operação diária, o valor do grafo aparece na pergunta analítica que listas planas não respondem: quais intrusion sets usaram este loader nos últimos dois anos e quais infraestruturas compartilharam. A configuração mínima de um conector externo ilustra o modelo de implantação, geralmente um contêiner por conector ao lado da plataforma.

# Exemplo de variáveis de um conector de enriquecimento do OpenCTI
OPENCTI_URL: https://opencti.exemplo.org
OPENCTI_TOKEN: "token-do-usuario-de-servico"
CONNECTOR_ID: "uuid-fixo-do-conector"
CONNECTOR_TYPE: EXTERNAL_IMPORT
CONNECTOR_NAME: "Feed Setorial TAXII"
CONNECTOR_CONFIDENCE_LEVEL: 60
CONNECTOR_SCOPE: indicator,observable
CONNECTOR_DURATION_PERIOD: PT6H
TAXII_URL: https://isac.exemplo.org/taxii2/
TAXII_COLLECTION: colecao-setor

A granularidade das streams merece configuração consciente, porque receber todos os eventos do grafo em um SIEM cobra indexação permanente. O padrão recomendado é filtrar por tipo de objeto e por marcador de confiança na origem, deixando o restante para consulta sob demanda pela API. A mesma disciplina vale para conectores de enriquecimento, que devem respeitar quota de serviço e evitar reprocessar entidades já enriquecidas, e um conector mal configurado é a causa mais comum de custo surpresa em implantações do OpenCTI.

A regra de arquitetura que evita sofrimento é definir o OpenCTI como repositório master do conhecimento: relatórios, entidades e contexto vivem ali, e as demais ferramentas enviam dados para dentro dele ou consomem dele, nunca o contrário.

4. MISP: Compartilhamento, Eventos e Comunidade

O MISP é a peça mais antiga e mais difundida do stack, e continua insubstituível na função de compartilhamento: eventos com atributos classificados por taxonomias e galáxias, sincronização ponto a ponto entre instâncias, controle fino por TLP 2.0, feeds sincronizáveis e a rede de comunidades e ISACs que já opera sobre ele. A unidade de trabalho é o evento, um conjunto de atributos com contexto compartilhável, e o ciclo de vida inclui proposta de atributo, correção pela comunidade e distribuição seletiva. Para a organização que recebe inteligência de um ISAC setorial ou de um CERT nacional, o MISP é o ponto de entrada natural.

A integração clássica com o restante do stack é bidirecional: conectores importam eventos do MISP para o grafo do OpenCTI, e exportadores devolvem observáveis curados ao MISP para compartilhamento. O ponto fraco conhecido é a modelagem relacional rasa para entidades complexas, e é exatamente por isso que o OpenCTI existe ao lado, guardando o grafo enquanto o MISP guarda os eventos compartilháveis.

Para o compartilhamento ativo, a configuração de sincronização define direção, filtros e TLP, e vale versionar como código, como qualquer outro componente do pipeline.

# Parametros de sincronizacao de um servidor MISP (exemplo abstrato)
name: isac-setor
url: https://misp.isac.exemplo.org
push: true
pull: true
pull_rules: '{"tags": {"NOT": {"tlp:red"}}}'
push_rules: '{"tags": {"OR": {"tlp:amber", "tlp:green"}}}'
certificado_pinned: true
org_send: organizacao-local

5. IntelOwl: Análise Automatizada de Observáveis

O IntelOwl resolve um problema diário e repetitivo: dado um observável, executar de uma vez a bateria completa de análises em fontes externas e internas e devolver um veredito consolidado. A arquitetura se organiza em analyzers, consultas a serviços de reputação, sandbox e classificação, e connectors, que enviam o resultado para ferramentas externas como o OpenCTI e o MISP. O analista dispara um job por API, pela interface ou por integração com a caixa de e-mail de phishing, e recebe em minutos o resultado agregado com confiança e evidência de cada analyzer.

O ganho de escala aparece na triagem de phishing e de anexos, onde dezenas de observáveis por dia seriam consultados manualmente em cinco ou seis portais. O fluxo a seguir mostra a sequência típica de um job e o encadeamento com o restante do stack.

1. Observável chega: hash de anexo suspeito ou dominio de phishing
2. Job criado no IntelOwl com analyzer set padrao
3. Analyzers executam: reputacao, sandbox, Whois, resolucao, YARA
4. Veredito consolidado por classe de analise
5. Connector empurra observavel com veredito para o OpenCTI
6. OpenCTI enriquece o grafo e dispara stream para MISP e SOAR

A limitação a gerenciar é o acoplamento com serviços externos: quotas, chaves de API e dependências de terceiros fazem parte do custo, e o time deve versionar a configuração de analyzers como código, no mesmo espírito do Capítulo 18.

A escolha do set de analyzers segue a telemetria real do time: um set mínimo de reputação, Whois, resolução e sandbox cobre a triagem de phishing, e sets de análise de código e de credenciais entram quando a operação exige. Cada analyzer com chave de API é um ponto de falha silenciosa, e o monitor de saúde do IntelOwl deve entrar no mesmo painel de observabilidade da plataforma, com alerta de degradação para o time de plataforma. A revisão semestral do set, removendo analyzers sem consumo, mantém o custo sob controle.

6. YETI: Trabalho Centrado em Observáveis

O YETI organiza o dia a dia do analista que caça por observáveis: uma caixa única onde feeds são ingested automaticamente, observáveis ficam indexados com tags, e analytics, scripts executáveis, enriquecem ou correlacionam o acervo sob demanda. O modelo é deliberadamente simples, o que explica a longevidade do projeto em equipes de CTI que querem velocidade sem a cerimônia de uma plataforma completa. O analista consulta um IP, vê de que feeds veio, quais tags carrega e roda um analytics de resolução ou de pivô em segundos.

No ecossistema, o YETI funciona melhor como estação de trabalho do analista e como camada de coleta que alimenta o OpenCTI via export, e não como repositório master. A comparação de posicionamento com os demais componentes evita a duplicação de funções que degrada qualquer stack.

O limite prático do YETI aparece quando o programa exige modelagem relacional de campanhas e atores, função que o grafo do OpenCTI executa melhor. A exportação de observáveis curados para o OpenCTI mantém o histórico analítico no lugar certo, e a rotina de limpeza de feeds no YETI evita o crescimento sem critério que degrada as consultas. Times pequenos podem operar apenas YETI e MISP no primeiro ano, e migrar para o desenho completo conforme o volume de casos cresce.

7. Arquitetura Integrada e Comparativo

O desenho abaixo combina as quatro ferramentas em um pipeline com fronteiras claras: fontes entram pelo MISP e por feeds diretos, a análise individual passa pelo IntelOwl, o conhecimento consolidado vive no OpenCTI e o YETI atende o analista em caça pontual. A distribuição sai do grafo por streams e conectores para os pontos de detecção.

Fontes externas (ISAC, feeds, relatorios)      Entrada interna (phishing, triagem)
        |                                                   |
        +-------------+                          +----------+
                      v                          v
                  [ MISP ]  <--- sync --->  [ IntelOwl ]
                      |                          |
                eventos curados            vereditos por job
                      v                          v
                  [ OpenCTI: grafo de conhecimento master ]
                      |  streams e conectores
                      +----> [ SIEM, EDR, SOAR, notebooks ]
                      |
                  [ YETI ] estacao de trabalho do analista

A ordem de implantação recomendada respeita a dependência natural entre as peças e evita o zoológico de ferramentas sem consumo.

O comparativo final consolida os critérios técnicos que diferenciam as quatro peças, para consulta durante o desenho da arquitetura.

8. Erros Comuns e Pontos de Atenção

• Instalar as quatro ferramentas no primeiro mês e operar nenhuma com qualidade; a sequência saudável costuma ser MISP primeiro para compartilhamento, OpenCTI depois como master, e IntelOwl e YETI conforme a dor aparece.
• Deixar o conector de OpenCTI para MISP em mão dupla sem filtro, criando loops de sincronização e duplicação de indicadores; defina direção, escopo e TLP por conector.
• Usar o IntelOwl como banco de conhecimento de longo prazo, quando seu papel é job e veredito; o histórico analítico pertence ao grafo.
• Não versionar configuração de conectores e analyzers, perdendo a reprodutibilidade que o Capítulo 18 exige; tudo que é configuração vira código no repositório.
• Ignorar o custo operacional de chaves de API e quotas de serviços externos usados por IntelOwl e por conectores de enriquecimento, que estouram silenciosamente no fim do mês.
• Medir o stack por volume de indicadores em vez de por uso: a métrica útil é quantos indicadores chegaram a detecção e geraram contexto em casos, e não o total armazenado.
• Pular a definição de TLP e de regras de compartilhamento, expondo conteúdo sensível por sincronização mal filtrada; a revisão dos filtros é tarefa trimestral.
• Tratar o stack como imune a atualização, quando conectores e plataformas evoluem rápido; o ambiente de teste que valida conectores faz parte da arquitetura.

9. Integração com o Restante da Biblioteca

O stack open source serve diretamente os controles PLT do Capítulo 15, com MISP e OpenCTI nomeados nos controles de compartilhamento e de gerenciamento, e a nota de plataformas de gerenciamento de IOCs do Capítulo 03 descreve as funções que esta nota implementa em produto. As fontes do Capítulo 02 entram pelas ferramentas deste stack, e a análise de campanhas do Capítulo 05 ganha corpo no grafo do OpenCTI, onde clusters e pivôs se tornam consultas em vez de planilhas. A nota de APIs e enriquecimento do Capítulo 09 cobre os padrões de integração que os conectores aqui citados seguem.

Para o hunting, o stack fornece insumos nas duas direções do Capítulo 10: hipóteses alimentadas por inteligência chegam pelo grafo, e descobertas de caça voltam como observáveis curados no OpenCTI e no YETI. A recomendação final de arquitetura é sustentar a fonte única de verdade: o grafo do OpenCTI como master do conhecimento, o MISP como canal de compartilhamento, o IntelOwl como frente de triagem e o YETI como estação de trabalho, com fronteiras documentadas e auditadas, é o desenho que aguenta anos de operação sem virar um zoológico de listas duplicadas.

A opção entre este stack e a TIP comercial da nota 01 não é exclusiva, e o desenho híbrido é comum em programas maduros: a plataforma comercial como fonte curada, o OpenCTI como master e o MISP como canal comunitário. O custo real do desenho, em qualquer combinação, é engenharia de integração, governança de dados e disciplina de consumo por detecção. Os padrões de implementação dessas integrações estão na nota de APIs e enriquecimento do Capítulo 09, e a métrica de sucesso continua sendo uso por detecção e por caso, nunca volume armazenado.