EH-ISAC (Setor de Saúde Europeu)

Nota 03 da subpasta 01 do capítulo 22 (Compartilhamento e Colaboração), dedicada ao ISAC europeu de saúde e ao efeito do quadro regulatório europeu na troca.
Cobre a identidade e operação do EH-ISAC, o cenário GDPR e NIS2, as ameaças típicas do setor de saúde e as lições aplicáveis à saúde brasileira.
Dialoga com a nota 01 (panorama de ISACs e Health-ISAC global), com a nota 03 do capítulo 12 (privacidade e considerações legais) e com a subpasta 04 (métricas).

1. Contexto e Posicionamento na Biblioteca

A nota 01 desta subpasta apresentou o Health-ISAC global e seus produtos; esta nota examina a face europeia do mesmo problema, em que a troca de inteligência acontece sob o regime de dados pessoais mais exigente do mundo e sob uma diretiva que transforma compartilhamento em obrigação regulatória. O EH-ISAC (European Health ISAC) é a comunidade que organiza esse jogo duplo: proteger hospitais, cadeia farmacêutica e sistemas nacionais de saúde, e fazer isso em conformidade com o GDPR e com a NIS2, que trata a saúde como setor essencial. Estudar o caso europeu importa para o leitor brasileiro por duas razões: a LGPD é herdeira conceitual do GDPR, e os problemas técnicos do setor, ransomware em operação clínica e roubo de dados de pacientes, são idênticos dos dois lados do Atlântico.

A nota caminha do geral para o específico: primeiro a identidade da comunidade, depois o quadro regulatório que a molda, em seguida as ameaças do setor e a colaboração com agências europeias, e por fim a transferência para a saúde brasileira, com exemplo de alerta e erros comuns. O capítulo 12 já tratou privacidade como desafio geral da biblioteca; aqui a privacidade aparece como restrição concreta de desenho de um canal de compartilhamento real.

2. O EH-ISAC e o Ecossistema Europeu de Saúde

O EH-ISAC é a comunidade de compartilhamento de inteligência dedicada ao setor de saúde na Europa, reunindo provedores de cuidado, hospitais e redes hospitalares, agências nacionais de saúde, indústria farmacêutica, fabricantes de dispositivos médicos e infraestruturas de dados de saúde. Sua origem está na cooperação europeia de saúde digital, e sua operação combina produtos padrão de ISAC, feed de indicadores, alertas de campanha, relatórios analíticos e grupos de trabalho, com funções próprias do quadro europeu: harmonizar o reporte de incidentes entre jurisdições, mediar a conversa do setor com a Comissão Europeia e com a ENISA, e manter grupos de resposta quando um incidente afeta múltiplos países ao mesmo tempo.

A comunidade opera sob uma restrição estrutural que poucos ISACs enfrentam com a mesma intensidade: a maior parte do material de valor contém, em algum grau, dados pessoais ou informação clínica derivada, e por isso os fluxos do EH-ISAC são desenhados com anonimização, agregação e pseudonimização como etapas do pipeline, e não como opcionais. O alerta de campanha descreve infraestrutura do adversário e TTPs, nunca detalhes clínicos de vítimas; a estatística de incidentes é agregada por categoria e por tipo de organização; e o material de incidente real circula em grupos fechados com TLP:AMBER+STRICT, sob acordos bilaterais de confidencialidade.

O ecossistema europeu também difere pela heterogeneidade de membros: um hospital universitário de grande porte, uma rede primária de um país pequeno e uma farmacêutica global têm capacidades de segurança incomensuráveis, e a comunidade precisa entregar produtos utilizáveis nos três. Na prática, isso produz uma arquitetura de produtos em camadas, com o feed automatizado e os alertas resumidos acessíveis a qualquer membro, e o material técnico profundo direcionado aos membros com capacidade de operá-lo, modelo que a seção 6 recupera como lição para o Brasil.

A adesão segue o padrão setorial com verificação de legitimidade, mas o consumo efetivo depende de mapear cada produto no fluxo interno. A tabela abaixo resume a carteira típica de produtos da comunidade e o destino operacional recomendado em um programa de CTI de hospital.

3. O Cenário Regulatório: GDPR e NIS2

O GDPR estrutura tudo o que toca dado pessoal na Europa, e no setor de saúde isso significa quase todo dado processado. Três efeitos práticos moldam o compartilhamento. Primeiro, dados de saúde são categoria especial, com base legal restrita, e por isso o EH-ISAC opera com pareceres jurídicos consolidados sobre o que pode circular, em qual formato e com qual anonimização, conhecimento que é transferido aos membros como parte do valor da adesão. Segundo, a obrigação de notificação de violação em 72 horas ao regulador torna a velocidade de detecção uma questão legal, e o alerta antecipado da comunidade se converte em instrumento de conformidade, porque encurta o tempo até a notificação e melhora sua qualidade. Terceiro, o princípio de minimização força o desenho de fluxos que compartilhem o indicador sem compartilhar o paciente, o que na prática significa IOC e TTPs limpos, com contexto clínico reduzido ao mínimo necessário.

A NIS2 eleva o setor de saúde a categoria de essencial e impõe um conjunto de obrigações que mudam a economia do compartilhamento para os membros. Entidades essenciais e importantes precisam implementar medidas de gestão de risco, registrar incidentes significativos e notificar em prazos escalonados, com alerta precoce em 24 horas, notificação de incidente em 72 horas e relatório final em um mês. A diretiva também introduz um elemento central para esta nota: a cooperação obrigatória, com registro em listas nacionais, potencial de auditoria e uma cultura de que compartilhar com a comunidade e com a autoridade é parte do dever de segurança, e não gesto opcional.

A tabela abaixo resume como cada instrumento regulatório muda a prática de compartilhamento do membro.

A leitura regulatória tem uma consequência contraintuitiva que merece registro: o ambiente mais restritivo do mundo para dados pessoais produziu uma das comunidades de compartilhamento mais maduras, porque a restrição obrigou desenho explícito de fluxos, pareceres jurídicos e processos, em vez do improviso que ainda domina comunidades onde a regulação é frouxa. Restrição bem desenhada produz confiança, e confiança é o insumo da troca.

4. Tipos de Ameaça no Setor de Saúde

As ameaças que dominam o material trocado na comunidade europeia concentram-se em quatro famílias, e a tabela abaixo organiza cada uma com o exemplo recorrente e o alvo operacional.

O ransomware hospitalar merece leitura específica porque é o caso em que o compartilhamento salva tempo de resposta clínica. O padrão europeu documentado em campanhas públicas inclui acesso inicial por credencial comprada ou VPN sem MFA, movimento lateral em rede de confiança alta, exfiltração antes de criptografia e acionamento de protocolo de desvio de ambulâncias quando a operação cai. A comunidade agrega esses padrões e entrega detecções de estágio inicial, que são as únicas que interessam ao hospital, porque depois da criptografia a conversa é de continuidade de negócio, e não de segurança. Os grupos de crime que dominam essas campanhas seguem o modelo de ransomware como serviço, com afiliados que compram acesso inicial de brokers, o que explica a repetição do vetor de entrada entre vítimas: quem vende acesso descobriu que a VPN de fornecedor sem MFA do setor é estoque renovável, e o alerta da comunidade é o mecanismo que transforma essa observação agregada em correção prioritária em dezenas de hospitais ao mesmo tempo.

O roubo de dados de pacientes tem dinâmica distinta e regulada: além do dano à vítima, o vazamento ativa a máquina de notificação do GDPR, multas e litígio coletivo, e por isso os grupos de extorsão tratam a saúde como alvo de alta pressão e baixa tolerância a negociação. O material trocado aqui é exfiltração de fornecedor de terceiros, indicadores de dumping em fóruns e padrões de infraestrutura de grupo, com cuidado máximo de anonimização, porque o dado vazado é, por definição, categoria especial.

5. Colaboração com Agências: ENISA e a Rede Europeia

O EH-ISAC não é ilha, e sua eficácia vem da posição estruturada no ecossistema europeu de resposta. A ENISA, agência da União para a cibersegurança, cumpre papel de secretaria técnica da política europeia, produz o panorama de ameaças do setor, apoia o grupo de cooperação NIS e mantém canais de contato com comunidades setoriais; o EH-ISAC alimenta esses produtos com dado agregado de setor e recebe de volta o quadro estratégico que nenhum membro sozinho enxerga. Paralelamente, cada estado membro opera sua autoridade NIS e seu CSIRT nacional, e a comunidade serve de ponte para que um hospital em um país pequeno receba, com contexto europeu, o alerta que seu CSIRT nacional não teria escala para produzir.

O modelo de colaboração agency-ISAC vale registrar como lição de desenho institucional. A agência tem autoridade, visão multinacional e poder de coordenação, mas não tem telemetria operacional dos hospitais; a comunidade tem dado de chão e velocidade, mas não tem mandato. O desenho europeu conecta os dois por acordos de intercâmbio, por participação da comunidade em exercícios paneuropeus e pela harmonização de formatos de reporte, de modo que o incidente notificado ao regulador e o incidente compartilhado com pares sejam o mesmo dado em dois formatos, e não dois trabalhos duplicados.

Para o leitor que opera em outro quadro, a pergunta de desenho que o caso europeu responde é: quem agrega o dado de setor e faz a ponte com a autoridade? Onde essa função não existe, o dado de setor não chega à política pública e a política pública não chega ao chão do hospital, e a lacuna é preenchida por vendors com interesse comercial. O análogo funcional brasileiro não precisa copiar a estrutura europeia, mas precisa responder a mesma pergunta com nome, acordo e formato definidos.

6. Lições para a Saúde Brasileira

A saúde brasileira vive os mesmos problemas técnicos com um quadro regulatório diferente: a LGPD protege dado de saúde como dado sensível, o setor é regulado por agências e conselhos, o SUS organiza uma rede pública imensa com sistemas próprios, e incidentes públicos recentes em hospitais e laboratórios mostraram ransomware com desvio de pacientes e vazamento de prontuários, o mesmo padrão europeu. A primeira lição é que existe espaço para uma comunidade setorial de saúde brasileira organizada nos moldes do EH-ISAC, com anonimização estrutural desde o desenho, porque a LGPD, como o GDPR, torna o improviso jurídico inviável.

A segunda lição é a arquitetura de produtos em camadas. O setor brasileiro tem um espectro de maturidade brutal, de hospitais de ponta a redes públicas com dificuldade de inventário, e uma comunidade que só publica material técnico profundo vai atender uma fração mínima do setor; o modelo europeu de feed acessível, alertas resumidos traduzidos e material profundo em grupos fechados é a resposta funcional. A terceira lição é o papel de ponte: no Brasil, a função de agregação e interface com governo é disputada por CERT.br na coordenação nacional, por canais do SUS, por entidades setoriais e por iniciativas regionais, e o caso europeu sugere que o valor está em formalizar a ponte, com acordos e formatos harmonizados, e não em multiplicar canais paralelos.

Duas adaptações são inevitáveis e devem ser assumidas no desenho brasileiro. A língua: material em inglês não escala no setor de saúde, e a tradução analítica é custo permanente da comunidade, não projeto pontual. E a dimensão público-privada: diferente da Europa, onde muitos provedores são públicos com governança nacional, o Brasil mistura grandes redes privadas e rede pública federada, e a confiança entre esses grupos precisa ser construída com pauta própria, porque os incentivos e restrições são diferentes.

A tabela abaixo compara, campo a campo, o desenho europeu de referência com a adaptação recomendada para uma comunidade brasileira de saúde.

7. Exemplo de Alerta Típico

O alerta abaixo reproduz a anatomia típica de um boletim europeu de ransomware direcionado ao setor, com os campos que permitem ao hospital agir sem expor vítimas nem violar regras de anonimização.

TÍTULO: Campanha de ransomware mirando hospitais via VPN de fornecedor
        de imagem, com exfiltração antes da criptografia
TLP:AMBER   ID: EH-ISAC-2026-0305-02   REGIÃO: múltiplos estados-membros
RESUMO: Três provedores de saúde reportaram padrão idêntico em 30 dias:
        acesso por conta de VPN de fornecedor sem MFA, movimento lateral
        via protocolo de gerência remota, exfiltração de bases clínicas
        e execução de payload de ransomware fora do horário clínico.
TTPs: VPN sem MFA; ferramentas de acesso remoto nativas; dupla extorsão
IOC: infraestrutura de C2 (2 IPs), hashes de loader, domínio de painel
      de vazamento usado pelo grupo
AÇÕES PARA MEMBROS: revisar contas de VPN de fornecedores e aplicar
      MFA em 7 dias; caçar sessões de VPN dos IOC em 90 dias; validar
      detecção de cópia em massa fora de janela de backup
NOTA DE CONFORMIDADE: material sem dados pessoais; vítimas não
      identificáveis; reporte ao regulador segue prazos da NIS2

O campo de nota de conformidade é a assinatura do caso europeu: ele diz ao receptor que o material pode ser usado em processo formal de notificação sem criar risco de vazamento de dado pessoal pela própria defesa. O restante dos campos segue a lógica de qualquer ISAC, com a diferença de que as ações recomendadas têm prazos concretos, alinhados ao ritmo de pressão do adversário no setor.

A conversão do alerta em material operacional pode ser automatizada como qualquer outra fonte, com uma verificação adicional de conformidade antes da publicação interna, como no trecho abaixo.

def ingerir_alerta_eh_isac(alerta):
    # Barreira de conformidade: alerta deve declarar ausência de dado pessoal
    if not alerta.get("nota_conformidade", "").startswith("material sem dados pessoais"):
        escalar_para_dpo(alerta)  # revisão jurídica antes de qualquer uso
        return None
    evento = montar_evento_misp(alerta)
    evento.add_tag("tlp:amber")
    evento.add_tag("setor:saude")
    for ttp in alerta["ttps"]:
        evento.add_galaxy("mitre-attack", ttp)
    for ioc in alerta["ioc"]:
        evento.add_attribute(tipo_do(ioc), ioc, to_ids=True)
    fila_de_revisao(enviar(evento), prazo_horas=4)

8. Erros Comuns e Pontos de Atenção

• Copiar material do alerta para listas internas sem manter a marcação TLP; efeito: material AMBER circula fora do círculo previsto e a organização quebra regra de comunidade; correção: mapear TLP para permissões de sistema e treinar times clínicos que consomem o alerta.
• Tratar conformidade como inimiga do compartilhamento; efeito: fluxos improvisados geram risco legal e paralisia; correção: desenhar anonimização e parecer jurídico como parte do pipeline, como o caso europeu demonstra ser possível.
• Consumir apenas o feed de IOC; efeito: o hospital recebe milhares de indicadores e continua sem detectar o estágio inicial do ransomware; correção: priorizar TTPs e detecções de comportamento no estágio de acesso inicial.
• Ignorar fornecedores de software clínico na comunidade; efeito: o comprometimento de um SaaS clínico atinge dezenas de hospitais ao mesmo tempo; correção: incluir cadeia de suprimentos como pauta fixa e exigir canal de advisory dos vendors.
• Subestimar a tradução e a adaptação local; efeito: alerta europeu não é lido pela equipe assistencial; correção: manter camada editorial de tradução analítica com vocabulário do setor de saúde.
• Deixar a comunidade fora do processo de resposta a incidente; efeito: notificação regulatória e troca com pares viram trabalhos duplicados na crise; correção: integrar o canal do ISAC ao playbook de notificação com prazos definidos.

9. Integração com o Restante da Biblioteca

A nota fecha a subpasta de ISACs com o caso regulatório mais denso do capítulo e conecta três fios da biblioteca. O primeiro é a privacidade tratada no capítulo 12, que aqui aparece como restrição de desenho de canal e não como tema abstrato. O segundo é a resposta a incidentes do capítulo 15, porque o alerta da comunidade alimenta o processo de notificação e a contenção clínica, e o playbook de incidente hospitalar deve prever o canal de troca. O terceiro é a mensuração da subpasta 04, que fornece as métricas para demonstrar que a comunidade entrega antecipação real ao setor.

Para o leitor que trabalha na saúde brasileira, a sequência recomendada é usar esta nota como referência de desenho, a nota 01 como mapa de fornecedores de comunidade e o capítulo 05 para transformar o material recebido em produtos internos, de alerta clínico a briefing executivo. O objetivo final é o mesmo do caso europeu: que a observação de um hospital em crise encurte a resposta de todos os outros, antes que a ambulância precise ser desviada.