Indicadores Compartilhados e Infraestrutura Multi-Tenant

Sexta nota do subcapítulo de IOCs no capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Trata do compartilhamento de indicadores em comunidades, do TLP aplicado a IOCs e da arquitetura multi-tenant no MISP.
Define a fronteira externa da esteira: sindicalização de feeds, conflito de visões e anonimização antes da troca.

1. Contexto e Posicionamento na Biblioteca

Nenhum programa de CTI enxerga sozinho o suficiente. O adversário reutiliza infraestrutura entre vítimas, e a organização que não troca indicadores descobre tarde o que a comunidade já sabia. O compartilhamento transforma cada vítima observada em sensor da rede de defesa coletiva, e é por isso que ISACs setoriais, grupos de confiança e comunidades federadas de MISP existem e crescem. A troca, porém, tem contrato: sem regras de confidencialidade, sem separação entre inquilinos e sem tratamento de visões conflitantes, o compartilhamento vira vazamento regulatório ou ruído recíproco.

Esta nota fecha o subcapítulo de IOCs definindo a fronteira externa da esteira. As notas anteriores construíram indicadores contextualizados, pontuados e validados; esta define como eles saem da organização, em que nível de TLP, com que anonimização e como coexistem com indicadores de terceiros numa infraestrutura que atende múltiplos inquilinos. O controle PLT.5 da seção 15 estabelece a política de TLP do programa, e esta nota aplica essa política ao caso específico dos indicadores.

2. Modelos de Compartilhamento de Indicadores

A troca de indicadores tem quatro modelos estruturais, e cada um implica custos e governança diferentes. Escolher o modelo antes de implantar ferramenta evita a situação comum de comunidade sem fluxo real, na qual a plataforma existe e ninguém publica.

Na prática, operações maduras combinam modelos: consomem feeds abertos como radar bruto, participam de ISAC para inteligência do setor e mantêm um grupo de confiança para casos sensíveis de TLP:AMBER. A direção da troca também varia: ingestão pura é o modo iniciante, e a contribuição recíproca é o que mantém o grupo vivo, porque comunidade na qual todos consomem e ninguém publica colapsa em meses.

O critério de escolha do modelo parte de duas perguntas. Primeira: o que a organização tem para dar, porque contribuição é a moeda das comunidades fechadas e quem chega só para consumir não sustenta acesso. Segunda: qual o custo de uma exposição indevida no seu setor, porque esse custo define o quão fechado o círculo precisa ser. Um grupo de confiança entre concorrentes de um mesmo nicho, por exemplo, exige acordos nominais e revisão de anonimização por evento, enquanto a ingestão de feeds abertos exige apenas higiene de validação do lado receptor.

Antes de ingressar ou fundar uma comunidade, avalie a saúde dela com sinais objetivos, porque plataforma ativa e comunidade ativa são coisas diferentes.

• Frequência de publicação revisada por múltiplos membros, e não por uma única organização que monopoliza a origem.
• Presença de moderadores ou curadores com papel declarado, que resolvem conflitos de visão e rejeitam material sem contexto.
• Histórico de incidentes de exposição, com post-mortem público interno e correção de processo.
• Métrica de acionamento relatada pelos membros, indicando que o material compartilhado chega a detecção real.
• Acordo de TLP aceito formalmente na entrada, com consequência definida para violação.
• Rotatividade saudável de coordenadores, sem dependência de uma única pessoa para toda a operação da comunidade.

3. TLP Aplicado a Indicadores

O TLP (Traffic Light Protocol) 2.0, padronizado pelo FIRST, é o contrato mínimo de confidencialidade da troca, e cada nível tem consequência operacional direta sobre o que o indicador pode fazer. A tabela abaixo aplica cada nível ao caso concreto de indicadores, com exemplo e política de exportação.

Duas regras de engenharia evitam desastre. Primeiro, o TLP deve ser metadado no nível do evento e do atributo, e o pipeline de exportação deve filtrar por marcação, não por confiança humana. Segundo, TLP:RED nunca deve chegar a sistema automatizado de disseminação, porque automação não tem julgamento para recipientes nomeados; material vermelho circula por canal humano e documentado. A marcação ausente deve ser tratada como TLP:AMBER por padrão conservador, e não como TLP:CLEAR.

O trecho abaixo ilustra a criação de um evento já com TLP e distribuição restrita via PyMISP, o que torna a marcação inseparável da publicação, e não um cuidado manual opcional.

from pymisp import PyMISP, MISPEvent

misp = PyMISP("https://misp.interno", "CHAVE_API", False)

evento = MISPEvent()
evento.info = "IOC de C2 do caso SUPORTE-2025-041"
evento.add_tag("tlp:amber")
evento.add_tag("admiralty-scale:source-reliability=a")
evento.distribution = 4              # grupo de compartilhamento
evento.sharing_group_id = 3          # circulo do ISAC setorial
evento.add_attribute("ip-dst", "198.51.100.23", to_ids=True, distribution=5)
misp.add_event(evento)

O evento herdou distribuição do grupo de compartilhamento e o atributo nasce com distribuição restrita, o que demonstra o controle em duas camadas: o evento define o teto de alcance, e cada atributo pode ficar abaixo dele, nunca acima. Revisão de distribuição antes da publicação é a etapa que verifica exatamente esse encaixe.

4. Arquitetura Multi-Tenant no MISP

O MISP resolve a convivência de múltiplos inquilinos, como num MSSP que atende vários clientes ou num grupo corporativo com subsidiárias, por meio de quatro mecanismos combinados: organizações, que identificam a origem de cada evento; servidores de sincronização, que conectam instâncias; níveis de distribuição, que definem o alcance de cada evento e atributo; e grupos de compartilhamento, que formam círculos nomeados de destinatários. A combinação permite, por exemplo, publicar um IOC simultaneamente para o inquilino afetado, para o grupo interno de resposta e para a comunidade federada, com três alcances distintos no mesmo evento.

A regra de arquitetura recomendada para MSSP é instância por conta quando o contrato exige separação forte, e instância única com grupos de compartilhamento quando a separação exigida é de visibilidade e não de soberania de dados. A primeira opção isola falhas e negociações, ao custo de operar mais plataformas; a segunda maximiza correlação, ao custo de disciplina rigorosa na definição de distribuição no momento da criação do evento, porque correção posterior de distribuição mal definida é trabalho manual e risco regulatório.

Os servidores de sincronização completam o desenho com filtros por ambos os lados. Regras de pull definem o que a instância local aceita, por tag, por TLP e por organização remota, e regras de push definem o que a instância local se dispõe a enviar. Um padrão conservador e comum é puxar apenas TLP:CLEAR e TLP:GREEN de comunidades amplas, puxar TLP:AMBER apenas de parceiros nominais de confiança e bloquear todo push automático, aceitando apenas o que passa por revisão humana. A sindicação federada sem filtro é a receita clássica de base contaminada por material de baixa qualidade que depois custa semanas de limpeza.

No cenário de MSSP com instância única, a disciplina por inquilino se materializa em três configurações permanentes. Cada cliente recebe um grupo de compartilhamento próprio, com os seus eventos e os eventos da comunidade que o contrato autoriza. Cada conta de usuário é vinculada à organização do cliente, com acesso negado por padrão aos grupos de outros inquilinos. E cada exportação agendada para detecção é executada com a identidade do inquilino, nunca com uma conta de serviço global, para que o filtro de visibilidade vale também no caminho até o SIEM. Com essas três regras, a correlação central continua funcionando, e a visualização cruzada fica impossível por construção.

5. Sindicación de Feeds e Deduplicação Entre Fontes

Uma instância bem governada consome dezenas de feeds, e o desafio técnico é sindicar sem duplicar. O mecanismo do MISP em modo cache baixa apenas os hashes do conteúdo remoto e verifica correspondência com atributos locais, reduzindo volume; a sobreposição de feeds, por sua vez, revela corroboração, pois o mesmo valor em feeds de origens distintas vale mais que o valor único. O pipeline de sindicação recomendado ordena três etapas: canonizar e deduplicar na ingestão, registrar todas as fontes que afirmam cada valor, e calcular a confiança agregada com as regras da nota de pontuação, evitando o erro de contar republicações como confirmações.

A sindicação também revela cobertura e lacunas. Um relatório mensal simples por feed, com volume ingerido, volume deduplicado, taxa de corroboração e acionamentos no ambiente, mostra quais fontes acrescentam e quais apenas repetem. O padrão típico em operações reais é uma curva de cauda longa: poucos feeds originais carregam a maior parte dos valores novos, e a maioria dos feeds assinados republisha conteúdo com atraso. Essa métrica alimenta a renegociação de contratos e o corte de fontes redundantes com base em número, e não em impressão.

A leitura da tabela mostra o que a média esconderia: o Feed B é quase integralmente republicação de terceiros, com 120 itens novos em 4500 ingeridos, e é candidato natural a corte; o Feed C é pequeno, mas original e acionado, e merece permanência. Decisões de portfólio de feeds saem de quatro linhas assim, e não de percepção de qualidade.

A cadência de revisão do portfólio deve acompanhar a rotação do próprio mercado de inteligência. Feeds mudam de dono, de escopo e de qualidade sem aviso, e um contrato anual sem revisão trimestral de números permite que a fonte degradue silenciosamente. A revisão recomendada compara a tabela do mês com as três anteriores, e uma queda sustentada de itens novos ou de acionamentos abre conversa com o fornecedor antes da renovação, com o histórico em mãos.

6. Conflito de Visões Entre Organizações

O compartilhamento inevitavelmente produz contradição: uma organização classifica um domínio como C2, outra o classifica como benigno, e as duas têm razão dentro de seus contextos. As causas mais comuns são o valor observado em épocas diferentes, com infraestrutura que mudou de mão; o ponto de observação distinto, no qual uma vê rede e outra vê endpoint; e a semântica diferente, na qual infraestrutura de hospedagem abusada é maliciosa para quem viu o abuso e neutra para quem só vê o host. Tratar contradição como erro de fonte é o caminho curto para perder acesso a visões valiosas.

A política de adjudicação recomendada tem quatro passos. Primeiro, comparar os carimbos de tempo, porque visões de épocas diferentes não conflitam, apenas documentam mudança. Segundo, comparar a confiabilidade das fontes envolvidas, com a escala Admiralty da nota de pontuação. Terceiro, decidir pela ação conservadora quando o conflito persistir: detectar em modo silencioso, nunca bloquear, até que evidência nova decida. Quarto, registrar a decisão e a justificativa no indicador, transformando o conflito em memória institucional. O caso clássico do domínio estacionado que foi C2 há três meses e hoje é página de venda do registrador é o exemplo padrão de visão desatualizada, e a regra de ouro é o carimbo de tempo mandar mais que a reputação acumulada.

Um exemplo concreto ancora a política. Fonte A, de confiabilidade B, publica o domínio como C2 em 2 de maio; fonte C, de confiabilidade C, publica o mesmo domínio como benigno em 9 de maio, com screenshot de página institucional. Os carimbos mostram que as visões são de épocas diferentes, e a decisão correta não é escolher uma das duas, e sim registrar que o domínio foi C2 até aproximadamente o início de maio e passou a estacionado depois. A detecção interna permanece em modo silencioso pela possibilidade de reuso, e o histórico completo fica no indicador para a próxima campanha que reutilizar o mesmo host.

Quando a contradição persiste e importa para a comunidade, comunicar o desacordo é contribuição, e não atrito. A proposta de atributo do MISP, por exemplo, permite que a organização discordante anexe a própria observação ao evento original, com justificativa, sem editar o material alheio. A curadoria do grupo decide com o histórico em mãos, e o mecanismo transforma visões conflitantes em corroboração qualificada para terceiros que chegam depois.

7. Anonimização e Proteção de Dados na Troca

Compartilhar indicadores de incidentes próprios expõe dados que não pertencem ao adversário: nomes de hosts internos, endereços de vítimas, contas de usuários e detalhes de negócio. A anonimização antes da publicação é, portanto, obrigação de conformidade, com respaldo direto na LGPD quando o dado compartilhado é pessoal. A técnica mínima envolve três operações: remover identificadores diretos de vítima, como hostname e e-mail interno; pseudonimizar identificadores que precisam permanecer comparáveis, como hash de hostname com sal próprio da organização; e agregar quando o valor do indicador está na proporção e não na identidade, por exemplo número de máquinas afetadas em vez da lista delas.

O MISP oferece suporte nativo a esse fluxo, com atribuição de organização pseudonimizada em eventos sincronizados e campos de proposta que permitem a outro membro sugerir enriquecimento sem ver mais do que o necessário. A disciplina final é revisar cada evento com um segundo par de olhos antes do primeiro sincronismo externo, porque anonimização malfeita não tem desfazer. Uma pergunta simples guia a revisão: se este evento vazar integralmente, há algum dado que identifique nossos usuários, clientes ou arquitetura? A resposta afirmativa trava a publicação até a remoção.

O contraste abaixo mostra um atributo antes e depois da anonimização mínima, preservando o valor técnico para a comunidade e removendo o que aponta para a vítima.

antes:  host-vendas-sp03.empresa-interna.example negociou com 198.51.100.23
        usuario j.moreira executou o anexo fatura-041.exe

depois: endpoint corporativo da organizacao A negociou com 198.51.100.23
        usuario interno pseudonimizado executou o anexo com sha256 7c1e4a9d...e7c1

Repare que o valor técnico do IOC, o IP e o hash do anexo, permanece intacto, porque é exatamente isso que a comunidade precisa para detectar. O que sai é o dado de vítima, que não agrega detecção e agrega risco legal. A pseudonimização estável do hash de usuário, com sal mantido internamente, permite que a própria organização correlacione o evento compartilhado com sua base interna depois, sem expor a identidade no canal externo.

8. Erros Comuns e Pontos de Atenção

A troca de indicadores falha por padrões conhecidos, e cada um abaixo tem correção de governança mais que de tecnologia.

• Publicar material sensível com TLP ausente, deixando a decisão de alcance para o receptor; correção: padrão conservador de TLP:AMBER quando a marcação não existe.
• Contar como corroboração a repetição do mesmo upstream em vários feeds, inflando confiança; correção: rastrear origem raiz e ponderar apenas fontes independentes.
• Definir distribuição errada na criação do evento e tentar corrigir depois do sincronismo, quando o dado já circulou; correção: revisão de distribuição como etapa obrigatória antes da publicação.
• Consumir sem contribuir, esvaziando a comunidade e perdendo acesso a inteligência de qualidade; correção: meta mínima de contribuições revisadas por trimestre.
• Anonimizar apenas nomes óbvios, deixando padrões de negócio que identificam a organização; correção: revisão por segundo par de olhos com a pergunta do vazamento integral.
• Tratar conflito entre fontes como defeito e descartar uma das visões; correção: política de adjudicação com carimbo de tempo, confiabilidade e registro da decisão.
• Exportar eventos de incidente sem revisão de anonimização, por pressão de prazo; correção: gate de revisão por segundo par de olhos com prazo acordado na comunidade.
• Assinar feeds sem medir acionamento e corroboração, mantendo portfólio por inércia; correção: relatório mensal por feed com corte baseado em números.

9. Integração com o Restante da Biblioteca

O TLP desta nota materializa a política do controle PLT.5 na camada de indicadores, a arquitetura multi-tenant executa o PLT.1 em cenários de MSSP e de grupo corporativo, e a sindicação com métricas alimenta a governança de fontes do PLT.4. A pontuação agregada das fontes externas é exatamente a máquina da nota de pontuação aplicada a terceiros, e a validação tripartite da nota anterior é o gate que impede que lixo comunitário entre na exportação interna. No plano de leitura, esta nota fecha a subpasta de IOCs e prepara o contraste com a nota de IOA: o que a comunidade compartilha em volume são indicadores de comprometimento, enquanto a detecção que sobrevive à rotação de infraestrutura, tema da próxima nota, exige ler o ataque em progresso e não apenas o rastro que ele deixa.