Cyware e Plataformas de Compartilhamento Federado

Nota 01 da subpasta 02 do capítulo 22 (Compartilhamento e Colaboração), dedicada à arquitetura de troca em que cada organização mantém seus dados e compartilha por camada federada.
Cobre o conceito de compartilhamento federado, as plataformas Cyware e concorrentes, a diferenciação do modelo MISP centralizado e um exemplo de arquitetura.
Dialoga com a nota 03 do capítulo 02 (compartilhamento e MISP), com a nota 07 deste capítulo (objetos STIX) e com as plataformas do capítulo 09.

1. Contexto e Posicionamento na Biblioteca

O capítulo 02 apresentou o MISP e o modelo de rede com sincronização entre instâncias, e a primeira subpasta deste capítulo descreveu as comunidades que usam esses canais. Esta nota trata do modelo de arquitetura que domina as plataformas comerciais de compartilhamento de última geração: o compartilhamento federado, em que cada organização mantém seus dados sob seu controle, e a troca acontece por uma camada federada que negocia o que circula, para quem e em que forma. A diferença parece sutil e não é: no modelo centralizado, a inteligência deixa de pertencer a quem a produziu no momento em que entra no hub; no modelo federado, o produtor mantém posse e decide cada fluxo, e a comunidade existe como contrato entre sistemas, e não como base de dados única.

A nota caminha em quatro passos: o conceito e seus princípios, as plataformas que o implementam com destaque para a Cyware, a comparação estrita com o MISP centralizado, e um exemplo de arquitetura que o leitor pode adaptar. As trade-offs de soberania e complexidade aparecem em toda a nota, e a escolha entre modelos é apresentada como decisão de arquitetura de programa, não como disputa de fornecedores.

2. Compartilhamento Federado: Conceito e Princípios

No compartilhamento federado, a unidade de posse é a organização. Cada participante opera seu próprio nó, com sua base de inteligência, sua política de saída e seu controle de acesso, e a federação é o conjunto de acordos técnicos, autenticação mútua, formatos compartilhados como STIX 2.1, transporte como TAXII 2.1 ou APIs proprietárias, e regras de políticas que permitem que nós independentes troquem objetos sem abrir mão da posse. O análogo mais próximo fora da segurança é a federação de identidade: a senha nunca sai da instituição de origem, e a confiança viaja por declarações assinadas.

Quatro princípios definem o modelo na prática. O primeiro é a soberania de dados: o objeto criado no nó de origem permanece lá, e o que circula é a cópia com marcações que controlam uso e repasse. O segundo é a política no ponto de origem: filtros de saída, marcação TLP 2.0 e regras de destinação são aplicadas no nó que publica, o que desloca a governança do operador central para o produtor. O terceiro é a interoperabilidade por padrão: a federação só funciona se os nós falarem o mesmo vocabulário de objetos e relacionamentos, papel que STIX 2.1 cumpre e que a nota 07 deste capítulo cataloga. O quarto é a responsabilidade distribuída: não existe base central para anonimizar, e cada nó responde pelo que publica, o que eleva o custo de curadoria e a exigência de maturidade.

O modelo também muda a topologia de confiança. Em vez de todos confiarem no operador do hub, os nós estabelecem confiança par a par ou em anéis, com verificação de identidade de organização e, em federações avançadas, assinatura de objetos para garantir proveniência. O ganho direto é que incidentes de confiança, como vazamento de uma base central, deixam de existir por construção, porque não existe base central.

Vale registrar quem adota o modelo na prática, porque a lista ilumina os requisitos reais. Comunidades setoriais maduras, em que os membros são organizações grandes com base própria de inteligência, adotam federação para não depositar produção no servidor de terceiro. Coordenações governamentais com múltiplas agências adotam federação para preservar limites jurisdicionais entre nós. E consórcios entre concorrentes diretos adotam federação porque o controle de fluxo na origem é a única forma de demonstrar ao jurídico que nada sai além do autorizado. O fio condutor é sempre o mesmo: quanto mais sensível é o material de saída, mais a posse distribuída deixa de ser luxo e passa a ser requisito.

3. Cyware: Cyber Fusion e Plataformas de ISAC

A Cyware é o fornecedor mais associado ao termo compartilhamento federado no mercado, com um portfólio que combina troca e operação. A plataforma de Cyber Fusion, em sua leitura operacional, une a triagem de inteligência, a orquestração de resposta e o compartilhamento em um único fluxo: o analista recebe material, enriquece, valida contra telemetria e, com um clique, publica para a comunidade com as marcações adequadas, sem sair da ferramenta. A linha de produtos de ISAC platforms atende entidades de compartilhamento, incluindo a operação de comunidades com federação de membros, gateways de troca automatizada e aplicativos móveis de alerta para disseminação rápida, e é usada por ISACs e ISAOs que precisam de plataforma gerenciada em vez de operação open source própria.

Três características diferenciam a abordagem da Cyware no quadro desta nota. A primeira é a integração de compartilhamento e resposta na mesma superfície, o que reduz a distância entre inteligência recebida e ação executada, problema clássico que a biblioteca trata como lacuna entre CTI e operação. A segunda é a automação de fluxos de troca, com playbooks que transformam alerta interno em objeto STIX validado e enviado, e que processam material de entrada com deduplicação e marcação antes da fila humana. A terceira é o desenho de gateway: o nó do membro decide, por política, o que sobe para cada comunidade, o que torna o modelo federado na prática e não só no discurso de vendas.

Para o programa de CTI, a leitura correta da Cyware é como pacote comercial de maturidade alta: resolve ingestão, curadoria, troca e resposta com suporte e conformidade, ao custo de licenciamento substancial e de acoplamento a um fornecedor. Organizações com equipe pequena e orçamento de ferramenta significativo tendem a extrair valor rápido; organizações com equipe técnica forte e orçamento apertado frequentemente chegam ao mesmo desenho com open source, ao custo de mais engenharia.

O mesmo exame de realidade vale para o termo Cyber Fusion, que a Cyware popularizou como categoria e que designa, na essência, a fusão física e de processo entre o time de CTI e o centro de operações: em vez de CTI que publica relatório para o SOC ler, o analista de inteligência opera no mesmo fluxo do SOC, enriquece alertas, orienta triagem e publica para a comunidade como etapa natural da resposta. A categoria é útil para a biblioteca porque descreve o estado desejado do programa maduro, com ou sem o produto de qualquer fornecedor, e o framework CTH do capítulo 15 formaliza o mesmo princípio no desenho de seus grupos de controles.

4. Outras Plataformas do Ecossistema Federado

A Cyware não está sozinha, e o leitor vai encontrar os mesmos princípios implementados com ênfases distintas nas plataformas que dominam o mercado de TIP comercial. A tabela abaixo resume as principais, com a ênfase de cada uma e o perfil de uso típico.

Duas observações evitam confusão comum nessa comparação. A primeira é que federado é arquitetura, não produto: qualquer plataforma que mantenha a base local do membro e exporte por política implementa o modelo, inclusive o MISP, que suporta sharing groups nomeados e sincronização seletiva entre instâncias. A segunda é que a escolha de plataforma não substitui a decisão de comunidade: sem clareza de quem compartilha o quê com quem, e sob qual TLP, a melhor ferramenta do mercado produz troca ruidosa e banal.

5. Diferenciação do Modelo MISP Centralizado

O MISP em sua implantação típica de comunidade funciona como hub central: os membros publicam para a instância do ISAC, a instância agrega e redistribui por sincronização, e a base completa mora no operador central. O modelo funciona há anos e sustenta comunidades inteiras, mas carrega limites que o federado endereça. A tabela abaixo compara os dois modelos nos critérios que importam para a decisão de arquitetura.

A leitura da tabela para decisão é direta em ambas as direções. O hub é superior quando a comunidade tem muitos membros com maturidade baixa, porque a curadoria central é o único mecanismo que mantém qualidade, e quando operação distribuída é inviável por capacidade. O federado é superior quando os membros são organizações grandes, com base própria de inteligência e exigências de soberania, porque ninguém quer depositar sua produção no servidor de terceiro, e quando a confiança entre membros é suficiente para troca direta. Comunidades reais maduras frequentemente combinam os dois, com hub agregador para material de base e federação direta entre nós avançados para material sensível e urgente.

6. Vantagens e Complexidade do Modelo Federado

As vantagens do federado se concentram em três eixos. Soberania e conformidade: a base de inteligência interna, que em muitos setores contém derivado de dados pessoais ou segredo comercial, nunca deixa o controle da organização, e o parecer jurídico da troca fica trivialmente simples. Qualidade e proveniência: cada objeto circula com identidade de organização de origem verificável, o que permite reputação real por fonte e rejeição seletiva, e reduz o efeito de amplificação de material sem contexto. Resiliência: sem ponto único de agregação, a falha de um nó ou a saída de um membro não apaga valor coletivo, e a federação se reconfigura por acordo.

A complexidade é o preço dessas vantagens, e aparece em quatro frentes. Operação: cada membro precisa operar, atualizar e monitorar um nó, o que em comunidades de porte médio é custo real de equipe. Governança: sem curadoria central, a política de qualidade é aplicada na origem, e a comunidade precisa de auditoria de saída, revisão de contribuições e mecanismos de exclusão para o nó que publica mal. Interoperabilidade: diferenças de versão de STIX, de interpretação de marcação e de mapeamento de taxonomias geram perda silenciosa de contexto entre nós, e o tratamento dessas diferenças é trabalho contínuo de padrões. E confiança: federado não elimina a necessidade de confiança, apenas a distribui, e construir a rede de acordos bilaterais é processo social mais lento que assinar contrato com um operador central.

A regra de decisão prática para o programa de CTI brasileiro: começar por hub quando a prioridade é entrar em comunidade com custo mínimo e maturidade em construção, e migrar para federação quando a organização se tornar produtora relevante e os requisitos de soberania se tornarem inegociáveis, o que costuma coincidir com a presença de dado sensível no material de saída e com a exigência jurídica de controle de fluxo.

7. Exemplo de Arquitetura Federada

O diagrama textual abaixo representa uma federação mínima de quatro participantes, com um ISAC como ponto de coordenação e nós de membros trocando por política. Cada linha representa fluxo autorizado e politicamente controlado na origem, com o rótulo TAXII indicando o transporte entre nós.

                  +---------------------------+
                  |  Coordenação do ISAC       |
                  |  (acordos, catálogo de     |
                  |   comunidades, auditoria)  |
                  +-------------+-------------+
                                |
       +------------------------+------------------------+
       |                        |                        |
+--------------+     +----------------+      +----------------+
| Nó Banco A   |     | Nó Banco B     |      | Nó Fintech C   |
| Base local   |TAXII| Base local     | TAXII| Base local     |
| Filtro saida |     | Filtro saida   |      | Filtro saida   |
| TLP de saida |     | TLP de saida   |      | TLP de saida   |
+------+-------+     +-------+--------+      +-------+--------+
       |                     |                       |
       +---------------------+-----------------------+
                                |
                  +-------------v-------------+
                  |  Nó Retail D (varejo)     |
                  |  consome feed setorial    |
                  |  e publica kit de phishing|
                  +---------------------------+

No fluxo de exemplo, o Banco A detecta kit de phishing mirando o setor, valida contra telemetria própria e publica três objetos STIX, um Indicator por domínio e um Malware para o kit, marcados TLP:AMBER e destinados à comunidade financeira da federação. O filtro de saída do nó do Banco A aplica a política: o material vai para os nós dos membros financeiros autorizados e para o gateway do ISAC, e não para o nó do varejo, que só recebe a versão TLP:GREEN publicada pelo ISAC dias depois, já agregada. O Banco B consome por TAXII com credencial de organização, valida contra sua telemetria, encontra acesso aos domínios nos logs de proxy de dois dias antes e responde no canal da comunidade, o que fecha o ciclo que justifica a federação.

A política de saída que governa esse fluxo cabe em configuração declarativa, e o esqueleto abaixo ilustra o formato conceitual de um filtro de saída de nó federado, aplicado objeto a objeto antes de qualquer envio.

politica_de_saida:
  - nome: "feed financeiro TLP:AMBER"
    quando:
      tlp: "TLP:AMBER"
      setores: ["financeiro"]
    destino: ["no-banco-b", "no-fintech-c", "gateway-isac"]
    exigencias: ["validado_contra_telemetria", "revisado"]
  - nome: "consolidado TLP:GREEN"
    quando:
      tlp: "TLP:GREEN"
      origem: "agregacao_isac"
    destino: ["toda_a_federacao"]
    exigencias: ["anonimizado", "sem_dado_pessoal"]
  - nome: "bloqueio padrao"
    quando: "tudo_mais"
    destino: []

A implementação técnica desse desenho em open source é possível com MISP e sharing groups nomeados, sincronização seletiva entre instâncias e filtros de tag, ou com OpenCTI distribuído e fluxos por API, e a nota 07 deste capítulo fornece o vocabulário de objetos que circula nesses fluxos. A decisão de ferramenta vem depois da decisão de topologia e de política, e nunca antes.

8. Erros Comuns e Pontos de Atenção

• Comprar plataforma federada sem decidir política de saída; efeito: o nó publica tudo ou nada, e o investimento não muda a troca; correção: escrever a política de saída por TLP e comunidade antes da implantação.
• Confundir federação com falta de curadoria; efeito: material sem validação circula com identidade da organização e destrói reputação; correção: fila de saída com revisão e auditoria periódica de publicações.
• Subestimar o custo de operar nó próprio; efeito: nó desatualizado vira risco de segurança e gargalo da comunidade; correção: orçar operação contínua e decidir hub quando a equipe não sustenta o nó.
• Trocar de modelo centralizado para federado por moda; efeito: migração cara sem ganho prático para membros de maturidade baixa; correção: decidir por porte, soberania e volume de produção própria, conforme a seção 6.
• Ignorar interoperabilidade de marcações entre nós; efeito: contexto perdido em trânsito, TLP mal interpretado e repasse indevido; correção: contrato de marcações da federação e testes de interoperabilidade por release.
• Tratar o ISAC coordenador como operador de base central; efeito: concentração de valor recria o modelo de hub sem os controles; correção: papel de coordenação limitado a acordos, catálogo e auditoria, com base distribuída.

9. Integração com o Restante da Biblioteca

A nota fornece a camada de arquitetura que sustenta a troca descrita no capítulo 02 e nas subpastas anteriores: os ISACs da subpasta 01 são os consumidores e produtores típicos dos nós federados, e a subpasta 04 mede o resultado dos fluxos aqui arquitetados. O vocabulário de objetos que circula na federação é o catálogo da nota 07 deste capítulo, e o controle PLT.3 do framework CTH, sobre formatos STIX e TAXII, é a implementação normativa desses padrões no programa interno.

A escolha entre hub e federação dialoga com a gestão de fontes do capítulo 02 e com as plataformas do capítulo 09, porque a mesma organização operará TIP interno e nó de comunidade, e a separação de responsabilidades entre essas duas bases é decisão de desenho recorrente. Para o leitor que precisa justificar arquitetura em comitê, a tabela comparativa da seção 5 e a regra de decisão da seção 6 são os artefatos de apresentação, e o diagrama da seção 7 é o ponto de partida do desenho técnico da própria organização.