Resumo

  • Confirmado:O WannaCry afetou os serviços do NHS na Inglaterra de 12 a 19 de maio de 2017. O National Audit Office relatou que pelo menos 80 dos 236 trusts foram infectados ou sofreram interrupções, 34 trusts foram infectados e bloqueados de dispositivos, 46 trusts não foram infectados mas relataram interrupções, e mais 603 organizações de atenção primária e outras do NHS foram infectadas, incluindo 595 consultórios de clínica geral.
  • Confirmado:O NHS England identificou 6.912 consultas canceladas durante a janela de resposta ao incidente e estimou mais de 19.000 cancelamentos no total. Cinco departamentos de acidentes e emergências desviaram pacientes. O NHS Digital informou ao NAO que nenhum dado de paciente foi comprometido ou roubado, e o Departamento, o NHS England e a National Crime Agency informaram ao NAO que nenhuma organização do NHS pagou o resgate.
  • Limite:O registro público apoia uma falha de patching e garantia, mas não apoia uma alegação simples de que o Windows XP sozinho causou a interrupção do NHS. A revisão de lições aprendidas do NHS England disse que o ataque explorou uma vulnerabilidade do Microsoft Windows, que a maioria dos dispositivos infectados do NHS rodava Windows 7 suportado mas sem patch, e que os dispositivos XP não suportados eram minoria entre os infectados.
  • Avaliação:A falha responsável não foi apenas dívida técnica. Foi a combinação de visibilidade de ativos, implantação de patches, gerenciamento de dispositivos não suportados, autonomia local dos trusts, órgãos nacionais sem um mecanismo de conformidade pré-incidente, resposta cibernética local não testada e processos de continuidade do cuidado que foram forçados a papel e coordenação manual.

Um patch pode ser emitido sem ser governado

A versão mais curta da história do WannaCry no NHS é que um patch da Microsoft existia antes do ataque e muitas organizações do NHS não o aplicaram. Essa frase é verdadeira, mas esconde o problema de responsabilidade. Um patch é um artefato técnico. Patching é um sistema de governança. Requer registros de ativos, priorização de riscos, janelas de mudança, testes em sistemas clínicos, coordenação com fornecedores, consentimento operacional local, comprovação de implantação e uma visão nacional de exceções.

Em maio de 2017, o NHS tinha orientações, alertas e suporte técnico, mas não tinha garantia suficiente de que as orientações haviam se tornado proteção.

A Microsoft publicou o Security Bulletin MS17-010 em 14 de março de 2017. O boletim classificou o problema como crítico e disse que as vulnerabilidades mais graves poderiam permitir execução remota de código se um invasor enviasse mensagens especialmente criadas para um servidor Microsoft Server Message Block 1.0.

A Microsoft explicou posteriormente em sua orientação ao cliente sobre o WannaCrypt que a atualização de março corrigia a vulnerabilidade explorada, que organizações com atualizações automáticas habilitadas estavam protegidas contra essa vulnerabilidade e que a Microsoft tomou a medida incomum de disponibilizar atualizações para plataformas mais antigas, como Windows XP, Windows 8 e Windows Server 2003. Seu blog de segurança descreveu o WannaCrypt como um worm que usava vulnerabilidades já corrigidas, afetando computadores que não haviam aplicado o patch. (blog de segurança da Microsoft)

O alerta arquivado do NHS Digital, CC-1411, enquadrou o mesmo risco em linguagem do setor de saúde. Ele identificou o ransomware como usando vulnerabilidades SMB corrigidas no MS17-010, alertou que as vulnerabilidades provavelmente seriam usadas por futuras variantes de malware para autopropagação e disse que a aplicação de patches nas versões afetadas deveria ser priorizada.

Também listou etapas de remediação, como bloquear portas relacionadas ao SMB, confirmar o bloqueio de portas, atualizar plataformas vulneráveis, usar scanners de vulnerabilidade, manter conectividade com o domínio do kill-switch, colocar dispositivos infectados em quarentena, reconstruir máquinas infectadas para um padrão com patch e não pagar o resgate.

Esses detalhes importam porque mostram que a resposta técnica não era obscura até 12 de maio. A questão mais difícil é se os controles nacionais e locais tornaram a resposta operacionalmente inevitável. A investigação do National Audit Office relatou que o NHS Digital havia emitido alertas críticos em março e abril de 2017 alertando as organizações para aplicarem patches em seus sistemas para prevenir o WannaCry. Também relatou que, antes do ataque, o Departamento de Saúde não tinha um mecanismo formal para avaliar se as organizações do NHS haviam cumprido suas orientações e conselhos.

O NHS Digital havia avaliado 88 dos 236 trusts in loco, e nenhum havia passado em sua avaliação de segurança cibernética, mas o NHS Digital não podia exigir que um órgão local tomasse medidas corretivas.

Essa é a dobradiça da responsabilidade. O centro podia alertar. As organizações locais controlavam muitas escolhas de implementação. Mas os pacientes experimentaram o sistema combinado, não o limite entre um alerta central e uma janela de patch local.

O que o registro estabelece

O WannaCry começou a afetar o NHS na sexta-feira, 12 de maio de 2017. O NAO relatou que o ataque global de ransomware afetou mais de 200.000 computadores em pelo menos 100 países, e que o NHS não era o alvo específico. Às 16h desse dia, o NHS England declarou um incidente grave e implementou medidas de emergência para manter a saúde e o atendimento aos pacientes. Um pesquisador de segurança ativou um kill-switch naquela noite, impedindo que o WannaCry bloqueasse mais dispositivos da mesma forma. O ataque afetou os serviços do NHS durante a semana de 12 a 19 de maio.

A escala na Inglaterra foi significativa, mas não totalmente mensurável. De acordo com o NAO, pelo menos 80 dos 236 trusts em toda a Inglaterra foram afetados porque foram infectados ou desligaram sistemas como precaução. Destes, 34 foram infectados e bloqueados de dispositivos, incluindo 25 trusts de cuidados agudos. Outros 46 relataram interrupções sem serem categorizados como infectados; alguns desligaram e-mail e outros sistemas como precaução e tiveram que usar papel e caneta para atividades normalmente realizadas eletronicamente.

O NHS England e o NHS Digital também identificaram 21 trusts cujos sistemas tentaram contatar o domínio do WannaCry, mas não foram bloqueados, e mais 603 organizações de atenção primária e outras foram infectadas, incluindo 595 consultórios de clínica geral.

O registro público é igualmente claro sobre o que é desconhecido. O Departamento e o NHS England não sabiam a extensão total da interrupção. Eles não sabiam quantas organizações do NHS não conseguiam acessar registros porque compartilhavam sistemas ou dados com um trust infectado. Eles não sabiam quantas consultas de clínica geral foram canceladas, ou quantas ambulâncias e pacientes foram desviados dos cinco departamentos de acidentes e emergências que não puderam tratar alguns pacientes. O NHS England coletou algumas informações de cancelamento de 12 a 18 de maio, mas o NAO disse que os dados não cobriam todos os tipos de consulta.

Os 6.912 cancelamentos identificados e os mais de 19.000 cancelamentos totais estimados não são, portanto, um registro completo do impacto ao paciente.

A revisão de lições aprendidas do NHS England, liderada pelo Diretor de Informação para Saúde e Assistência Social, manteve o mesmo quadro enquanto adicionava textura operacional. Disse que o NHS não foi diretamente visado, que não houve relatos de danos a pacientes ou de dados de pacientes comprometidos ou roubados, e que 1% da atividade do NHS foi diretamente afetada. Também afirmou que 80 dos 236 trusts hospitalares foram afetados, 595 dos 7.454 consultórios de clínica geral e oito outras organizações do NHS e relacionadas foram infectadas, e a interrupção tornou mais clara a dependência do serviço de saúde em tecnologia da informação.

Essa última conclusão é a mais importante. Um incidente de ransomware que não roubou dados de pacientes ainda danificou a continuidade do cuidado. Em um hospital digital, a disponibilidade não é uma camada de conveniência. É parte do fluxo clínico, comunicação, acesso a diagnósticos, fluxo de consultas e encaminhamento seguro.

Sistemas não suportados fizeram parte da história, não toda a história

O WannaCry é frequentemente recontado como uma história de advertência sobre o Windows XP. Software não suportado importava. Era um risco conhecido, e o Departamento e o Cabinet Office haviam escrito aos trusts em 2014 dizendo que eles precisavam de planos robustos para migrar de software antigo, como Windows XP, até abril de 2015. A revisão do National Data Guardian, publicada em julho de 2016, propôs novos padrões de segurança de dados e um método para testar a conformidade.

A revisão Safe Data, Safe Care do Care Quality Commission, também publicada em julho de 2016, recomendou a substituição urgente de hardware e software que não pudessem mais ser suportados, auditoria e validação mais fortes e liderança na segurança de dados.

Mas um slogan de sistema não suportado é muito restrito. A revisão de lições do NHS England disse que nenhuma das 80 organizações do NHS afetadas havia aplicado o patch de atualização da Microsoft recomendado pelo boletim CareCERT do NHS Digital em 25 de abril de 2017. Também disse que o WannaCry era um ataque usando uma vulnerabilidade específica do Microsoft Windows, não um ataque a software não suportado. A maioria dos dispositivos infectados do NHS rodava Windows 7 suportado, mas sem patch.

Dispositivos XP não suportados estavam em minoria entre os dispositivos infectados, e o número de dispositivos XP havia diminuído de 18% para 1,8% em janeiro de 2018.

A distinção importa para a responsabilidade. Se a falha fosse apenas "sistemas operacionais antigos", a resposta seria financiamento para substituição e pressão sobre fornecedores. Esses eram problemas reais, especialmente onde equipamentos médicos ou dispositivos de diagnóstico dependiam de software mais antigo. Mas se máquinas com Windows 7 suportado permaneciam sem patch após um alerta crítico, a resposta também inclui governança de patches, gerenciamento de exceções e comprovação de encerramento. Um dispositivo suportado pode ser inseguro quando não tem patch.

Um dispositivo não suportado pode ser isolado ou gerenciado em um modelo de controle compensatório. O sistema precisava saber qual condição se aplicava a cada endpoint crítico antes que um worm tornasse o inventário visível.

A revisão de lições também observou que controles de firewall e rede poderiam ter reduzido o risco de infecção. Disse que mesmo onde a aplicação de patches não havia ocorrido, ações para melhorar a segurança dos firewalls de rede voltados para a rede N3 teriam protegido as organizações contra infecção. Essa é outra razão para não tratar o patching como uma chave única. O patching era necessário, mas também a segmentação de rede, configuração de perímetro, controles de exposição SMB e conhecimento de quais sistemas ainda precisavam de suporte a protocolos legados.

O guia do NCSC sobre WannaCry, agora marcado como desatualizado, capturou a lógica defensiva de emergência da época. Aconselhava as organizações a implantar o MS17-010, desabilitar o SMBv1 se o patching não fosse possível, bloquear portas relevantes onde necessário, isolar tecnologia legada vulnerável, atualizar antivírus e evitar bloquear os domínios de kill-switch. Em outras palavras, a resposta imediata exigia um conjunto de controles em camadas.

Organizações que não tinham listas de ativos claras, propriedade de firewall, opções locais de DNS, contatos de fornecedores e procedimentos de reconstrução testados não podiam executar facilmente essa resposta em camadas sob pressão de emergência.

A autonomia local tornou a garantia central mais difícil

O NHS não é um único parque de TI monolítico. Trusts locais, consultórios de clínica geral, grupos de comissionamento clínico, fornecedores, unidades de suporte ao comissionamento e outras organizações operam dentro de estruturas nacionais, mas mantêm muitas responsabilidades locais. O NAO disse que as organizações locais de saúde eram responsáveis por manter a segurança da informação e pelos arranjos de incidentes e emergências, incluindo ataques cibernéticos. Os órgãos nacionais supervisionavam e apoiavam, mas nem sempre tinham autoridade para compelir ações técnicas específicas.

Essa estrutura não é inerentemente errada. Organizações clínicas locais entendem seus próprios caminhos de cuidado, equipamentos, fornecedores e riscos de mudança. Um patch pode quebrar uma interface de diagnóstico antiga, uma integração de administração de pacientes ou um processo de dispositivo médico. Uma instrução central que ignora essas realidades pode produzir mudanças inseguras ou resistência local.

No entanto, a autonomia local se torna perigosa quando o centro não consegue ver quais locais estão expostos, quais aceitaram risco, quais têm controles compensatórios e quais são incapazes de agir porque um fornecedor, orçamento ou dependência clínica bloqueia a remediação.

O ponto do NAO sobre o mecanismo de conformidade formal ausente não é, portanto, um detalhe burocrático. Ele explica por que um alerta não se tornou redução de risco em todo o sistema. Um alerta nacional pode dizer "aplique o patch agora". Ele não pode, por si só, provar que todos os endpoints relevantes têm o patch, que dispositivos não suportados estão isolados, que o SMB está bloqueado onde deveria, que os sistemas que exigem exceções são nomeados ou que os executivos aceitaram um risco residual de segurança do paciente.

O relatório do Public Accounts Committee tornou a mesma fraqueza política. Ele disse que houve alertas em 2016 e novos alertas em março e abril de 2017, mas apenas cerca de dois terços dos trusts haviam aplicado patches no momento do WannaCry, e nenhum dos 88 trusts havia passado nas avaliações do NHS Digital. Também relatou que o Departamento e o NHS reconheceram que as coisas precisavam mudar e que a revisão de lições de 2018 continha 22 recomendações, mas que os planos de implementação e custos ainda não haviam sido acordados quando o Comitê relatou.

Essa evidência apoia uma conclusão sóbria: a responsabilidade estava distribuída, mas o paciente não recebeu cuidado distribuído. Se um trust local não tinha o patch, se um consultório de clínica geral não conseguia acessar sistemas, ou se uma ambulância tinha que desviar, o dano atingia as pessoas através de um único serviço público. A governança distribuída precisa de loops de evidência mais fortes precisamente porque o serviço público parece unificado no ponto de necessidade.

Um incidente de continuidade do cuidado, não apenas um incidente de TI

O dano visível do WannaCry foi a interrupção. Algumas organizações foram infectadas e bloqueadas. Outras desligaram sistemas para reduzir o risco. Algumas usaram papel. Outras não conseguiram receber resultados de exames ou acessar registros compartilhados. Alguns pacientes tiveram consultas ou cirurgias canceladas. Cinco áreas desviaram pacientes de acidentes e emergências. O NAO foi cuidadoso ao dizer que nem todas as categorias foram totalmente contadas, e a revisão do NHS England não relatou danos conhecidos a pacientes. Esses limites devem ser respeitados.

A ausência de danos relatados não é prova de que todo risco clínico estava ausente, mas o registro público não apoia a invenção de um número de mortes ou um roubo oculto de dados de pacientes.

A lente de responsabilidade mais útil é a capacidade de continuidade. Os serviços de saúde podem sobreviver a uma interrupção digital curta apenas se os modos degradados estiverem prontos. O fallback em papel não é um plano por si só. Requer listas de pacientes imprimíveis ou recentes, alternativas de acesso ao histórico de medicação, rotas seguras de transferência, soluções para pedidos de diagnóstico, rastreamento de encaminhamentos, programação de cirurgias, comunicação de resultados laboratoriais, reagendamento manual de consultas e reconciliação após o retorno dos sistemas. Cada fallback tem um perfil de throughput e erros.

Uma clínica que pode lidar com 20 exceções manuais pode não lidar com centenas. Um hospital que pode adiar com segurança o trabalho eletivo por um dia pode ter dificuldades se a visibilidade diagnóstica estiver prejudicada em toda uma região.

A revisão de lições do NHS England reconheceu a diferença entre um incidente cibernético e um incidente grave convencional. Disse que o NHS England usou sua estrutura de Preparação, Resiliência e Resposta a Emergências, que forneceu uma estrutura robusta, mas o incidente também ensinou lições sobre como o cibernético difere de outros incidentes graves. O cibernético pode tornar as próprias ferramentas de comunicação não confiáveis. Pode afetar vários locais simultaneamente. Pode não estar claro no início se um local está infectado, desconectado ou agindo defensivamente.

Pode exigir ações de contenção técnica que reduzem a capacidade do serviço. Também pode se espalhar através de redes compartilhadas, então ajudar uma organização pode depender de como outra organização se comporta.

É por isso que a responsabilidade não deve terminar no dispositivo que perdeu um patch. O sistema de cuidado precisava de uma maneira testada de responder a perguntas básicas de continuidade sob condições cibernéticas. Quais serviços devem continuar funcionando mesmo que o e-mail esteja offline? Quais registros são essenciais para o atendimento de emergência? Quais sistemas podem ser desligados localmente sem coordenação regional? Qual órgão nacional lidera as comunicações? Quais fornecedores devem participar da ponte de incidentes? Quais executivos locais podem aceitar uma redução no fluxo clínico e com base em que evidências?

O NAO relatou que o Departamento desenvolveu um plano incluindo papéis e responsabilidades nacionais e locais, mas não o testou em nível local. Também descobriu que o NHS não havia ensaiado um ataque cibernético nacional, então não ficou imediatamente claro quem deveria liderar a resposta e houve problemas de comunicação. Essa não é uma lacuna de processo menor.

Na continuidade cibernética, os ensaios são como as organizações descobrem se as listas de contatos funcionam, se os formulários em papel existem, se as listas offline de pacientes são recentes o suficiente, se os fornecedores atendem e se os clínicos entendem quais sistemas são seguros para reconectar.

A interdependência transformou a proteção local em disrupção regional

Uma das características mais difíceis do incidente é que algumas organizações foram prejudicadas pelos movimentos defensivos de outras organizações. Um trust poderia evitar infecção direta e ainda assim perder o acesso a um processo de entrega de ambulância, uma transferência de imagem diagnóstica, um caminho de pedido de quimioterapia, um fluxo de resultados de exames de sangue ou uma carga de casos de atenção primária porque outro provedor, fornecedor ou parceiro de rede fechou o acesso para se proteger. Isso é contenção local racional, mas cria consequências regionais para o serviço.

O estudo de caso do toolkit de gestão de continuidade de negócios do NHS England sobre o WannaCry torna isso prático. Ele descreve o County Durham and Darlington NHS Foundation Trust como não sofrendo um ataque direto, enquanto o serviço de ambulância protegeu sua rede fechando o acesso, desabilitando telas de processo de entrega e tornando um portal de reserva de transporte de pacientes indisponível. Centros terciários fecharam o acesso, o que significava que exames de TC e RM não podiam ser transferidos eletronicamente e pedidos de quimioterapia não podiam ser transferidos pela rota usual.

O fornecedor de TI de atenção primária protegeu sua rede, após o que a transferência automatizada de resultados de exames de sangue falhou e alguns médicos de clínica geral não conseguiram acessar suas cargas de casos.

As soluções improvisadas nesse estudo de caso são úteis porque são concretas, não dramáticas. Os pré-alertas de ambulância continuaram por telefone fixo e outras comunicações de rádio. As reservas de transporte de pacientes migraram para telefone. As imagens foram transferidas para DVD e enviadas por táxi. Os pedidos de quimioterapia voltaram a papel e fax. As transferências de resultados de exames de sangue migraram para papel e diminuíram o processo. Alguns médicos de clínica geral acessaram cargas de casos através de centros de tratamento urgente.

O estudo de caso disse que os planos de continuidade de negócios foram atualizados posteriormente e concluiu que as organizações do NHS precisam entender suas interdependências e alinhar planos para serviços compartilhados para minimizar o impacto na economia da saúde.

Isso é exatamente o tipo de evidência que as contagens amplas de incidentes perdem. Um incidente cibernético pode reduzir a capacidade de cuidado sem que toda organização afetada seja infectada. Pode transformar uma decisão segura de uma parte em uma interrupção para outra. Pode exigir métodos analógicos que são seguros para baixo volume, mas frágeis em escala. Um DVD enviado por táxi pode salvar um caminho diagnóstico para um pequeno número de exames urgentes; não é um substituto para a troca comum de imagens eletrônicas em uma região movimentada. Uma rota de reserva por telefone pode manter o transporte de pacientes funcionando;

não pode preservar automaticamente a priorização, auditoria ou throughput se o volume de chamadas aumentar. Pedidos de quimioterapia em papel podem evitar que o tratamento pare; eles criam cargas de transcrição, confirmação e reconciliação que o processo digital normalmente absorve.

Esses exemplos também explicam por que a continuidade de fornecedores e parceiros é importante para organizações menores. Um consultório de clínica geral, hospital paliativo, provedor comunitário, clínica local ou serviço contratado pode não ser o proprietário do sistema central do qual depende. Pode depender de uma unidade de suporte ao comissionamento, um sistema clínico hospedado, uma interface de patologia, um parceiro de diagnóstico ou uma rota de rede controlada por outra pessoa. Quando essa dependência é desconectada, a organização menor ainda deve responder aos pacientes.

Deve saber se pode acessar registros através de um local alternativo, se resultados em papel são clinicamente aceitáveis, se as atualizações de encaminhamento estão sendo enfileiradas e quem é responsável por informar os pacientes de que o caminho digital falhou.

Para fins de responsabilidade, a interdependência altera o teste de controle. Não basta que cada organização diga que tem um plano de continuidade de negócios. Os planos precisam se encontrar. Se o fechamento defensivo de um centro terciário bloquear a transferência de imagens, o plano do trust encaminhador já deve conhecer a rota alternativa. Se um fornecedor de TI de atenção primária fechar o acesso, as clínicas locais precisam de opções nomeadas para acesso urgente a registros.

Se as telas de entrega de ambulância não estiverem disponíveis, os departamentos de emergência e os serviços de ambulância precisam de um fallback compartilhado que tenha sido ensaiado. O estudo de caso do NHS é modesto em escopo, mas mostra a verdade em nível de sistema: a continuidade cibernética é trabalho conjunto, e uma dependência conjunta não testada pode falhar mesmo quando cada participante está tentando ser prudente.

O custo foi maior do que um resgate que não foi pago

Nenhuma organização do NHS pagou o resgate, de acordo com o Departamento, NHS England e National Crime Agency no relatório do NAO. Esse fato deve evitar uma leitura equivocada comum: a perda não foi a demanda de resgate. Foram trabalho cancelado, horas extras, suporte de TI, restauração, cuidado adiado, esforço de fornecedores e remediação posterior. O NAO disse que o Departamento não sabia o custo da interrupção dos serviços no momento de sua investigação.

Ele identificou categorias de custo, como consultas canceladas, suporte de TI local adicional, consultores de TI, restauração de dados e sistemas e horas extras de funcionários durante a resposta de fim de semana.

A atualização posterior do Departamento de Saúde e Assistência Social, Assegurando a resiliência cibernética na saúde e assistência: atualização de progresso de outubro de 2018, vinculada ao PDF de atualização de setembro de 2018. Essa atualização é amplamente citada pela estimativa de que o WannaCry custou ao NHS £92 milhões, incluindo resposta direta e recuperação de TI, bem como produção perdida. Essa estimativa deve ser usada com cuidado. É uma estimativa de custo do setor público, não uma contabilidade completa da ansiedade dos pacientes, tempo da família, movimento de ambulâncias, ônus local de fornecedores ou cada hora de funcionário.

Trabalhos acadêmicos também mostram por que o impacto é difícil de precificar. Uma análise retrospectiva de impacto do npj Digital Medicine de 2019 usou Estatísticas de Episódios Hospitalares para examinar cancelamentos, internações, atendimentos de emergência, mortalidade e custos fiscais. Não encontrou diferença significativa na atividade total em todos os trusts durante a semana do WannaCry em comparação com a linha de base, mas hospitais diretamente infectados tiveram menos internações de emergência e eletivas, e o estudo estimou £5,9 milhões em atividade hospitalar perdida em trusts infectados.

Também observou nenhum aumento na mortalidade, embora tenha alertado que a mortalidade é uma medida grosseira de dano ao paciente.

A diferença entre uma estimativa de atividade hospitalar infectada de £5,9 milhões e uma estimativa mais ampla de £92 milhões do setor público não é necessariamente uma contradição. Elas medem coisas diferentes. Uma analisa a atividade em hospitais infectados durante um período definido usando dados hospitalares. A outra inclui resposta mais ampla, recuperação e remediação de TI. Para a responsabilidade, o ponto importante não é escolher o maior número e chamá-lo de "o custo".

É perguntar quais custos eram evitáveis com aplicação de patches mais precoce, quais foram incorridos por contenção necessária, quais eram investimentos que deveriam ter acontecido antes e quais recaíram sobre pacientes e funcionários sem jamais aparecer em um orçamento de TI.

Pequenos e médios provedores estão dentro dessa mesma questão. O problema é a continuidade entre as organizações menores que se conectam a um serviço nacional: consultórios de clínica geral, hospitais paliativos, provedores comunitários, contratados, fornecedores de dispositivos, parceiros locais de suporte de TI e interfaces de assistência social. O NAO contou a atenção primária e outras organizações entre as entidades infectadas e observou que outros provedores poderiam ser afetados através de sistemas compartilhados ou informações atrasadas.

Um incidente cibernético em uma grande instituição pública torna-se, portanto, um choque de continuidade para organizações menores que têm menos redundância e menos visibilidade política.

A atribuição não responde à questão operacional

O Reino Unido posteriormente atribuiu o WannaCry à Coreia do Norte. A declaração do Foreign Office sobre o ator norte-coreano por trás do WannaCry disse que o Reino Unido considerou que atores norte-coreanos conhecidos como Lazarus Group estavam por trás da campanha. Essa atribuição importa para dissuasão, sanções, diplomacia e segurança nacional. Não absolve o controle operacional doméstico. O mesmo registro público diz que o NHS não era o alvo específico, que o worm se espalhou através de uma vulnerabilidade conhecida do Windows e que organizações locais poderiam ter tomado ações relativamente simples para se proteger.

Responsabilidade criminal e responsabilidade do serviço público são camadas separadas. O atacante controlou o código malicioso e a decisão de implantá-lo. A Microsoft controlou a divulgação da vulnerabilidade e o lançamento do patch para seus produtos, e depois a decisão extraordinária de disponibilizar patches para plataformas não suportadas durante a emergência. O NHS Digital controlou alertas, orientações, suporte telefônico e conselhos específicos para o setor. O NHS England controlou a coordenação de incidentes graves e a escalada de continuidade do cuidado.

O Departamento de Saúde controlou a supervisão de políticas e prioridades de financiamento. Trusts e clínicas locais controlaram muitas decisões de dispositivos, rede, fornecedores e gerenciamento de mudanças. Fornecedores controlaram alguns dispositivos legados, termos de suporte e restrições de compatibilidade.

Nenhuma camada isolada é toda a história. Tratar o incidente apenas como um evento de estado hostil o torna muito distante do gerenciamento local. Tratá-lo apenas como não conformidade local ignora o fato de que os órgãos nacionais viram sinais de alerta e não tinham poder de fiscalização ou garantia suficiente. Tratá-lo apenas como um problema da Microsoft ignora que o patch crítico existia antes do incidente e que não aplicar patches é uma escolha operacional. Tratá-lo apenas como um problema de fornecedor ignora que sistemas Windows suportados também estavam sem patch.

A responsabilidade é o mapa desses controles, não uma busca por um ator que possa carregar todos eles.

O controle mais consequente era a evidência. Quem sabia o estado dos patches? Quem sabia o estado de exposição do SMB? Quem sabia quais sistemas não eram suportados? Quem sabia quais dispositivos médicos não podiam receber patch sem intervenção do fornecedor? Quem sabia se um trust local havia testado seu plano de emergência cibernética? Quem sabia com que rapidez os consultórios de clínica geral poderiam mudar para operação manual segura? O registro público mostra que respostas suficientes para essas perguntas estavam indisponíveis, incompletas ou não acionáveis centralmente antes do ataque.

O programa pós-incidente confirma o diagnóstico

O registro de remediação após o WannaCry é útil porque mostra o que os líderes nacionais achavam que havia falhado. A revisão de lições do NHS England recomendou liderança mais forte e responsabilidade do conselho, papéis mais claros, padrões de segurança cibernética, resiliência local, melhor aplicação de patches, substituição de software não suportado, melhoria dos processos de resposta e coordenação nacional mais forte. A atualização de progresso do Departamento de 2018 descreveu o trabalho em resposta a incidentes graves, operações de segurança cibernética, padrões de segurança de dados, expectativas de fornecedores e investimento.

O Data Security and Protection Toolkit, que substituiu o Information Governance Toolkit anterior a partir de abril de 2018, tornou-se um mecanismo de autoavaliação online para organizações com acesso a dados e sistemas de pacientes do NHS medirem e publicarem seu desempenho em relação aos dez padrões de segurança de dados do National Data Guardian.

Esse toolkit não é prova de que o problema desapareceu. A autoavaliação tem limites, e incidentes cibernéticos posteriores em sistemas de saúde mostram que ransomware e interrupções de fornecedores continuam sendo riscos sérios. Mas é evidência de que o sistema pós-WannaCry se moveu em direção a garantia explícita, em vez de apenas orientação informal. Também deslocou o cibernético do domínio puramente técnico para a responsabilidade do conselho, relato de incidentes e continuidade.

A estratégia governamental posterior, Um sistema de saúde e assistência social adulta resiliente na Inglaterra: estratégia de segurança cibernética para 2030, estende esse quadro até 2030. Ela descreve a segurança cibernética como uma condição para proteger dados de pacientes, usuários de serviços e funcionários e para se recuperar rapidamente quando ocorrerem ataques. A existência da estratégia reforça a lição central de 2017: na saúde, a segurança cibernética não é uma disciplina de back-office separada. Ela sustenta a confiança pública e a continuidade do serviço.

O papel público mais amplo do National Cyber Security Centre também cresceu durante esse período. Seu anúncio de revisão anual de 2017 descreveu o primeiro ano do novo centro e sua missão de tornar o Reino Unido mais seguro online. A resposta ao WannaCry tornou essa missão concreta para hospitais e clínicas. Mostrou que a capacidade cibernética nacional precisava se conectar a operações específicas do setor, não apenas publicar alertas para equipes técnicas.

Cinco testes de responsabilidade

O valor duradouro do caso do NHS é que ele fornece testes práticos para conselhos e líderes do setor público. Esses testes não são sobre culpar um administrador por um patch. Eles são sobre se um serviço público pode provar que um risco cibernético conhecido foi convertido em ação operacional.

1. Visibilidade de ativos:Uma organização não pode aplicar patch no que não pode identificar. Ela precisa de um inventário de servidores, endpoints, dispositivos médicos, sistemas não suportados, versões de sistema operacional, serviços expostos, fornecedores e dependências clínicas. O inventário deve incluir sistemas que são inconvenientes de possuir, como estações de trabalho de diagnóstico antigas, servidores de arquivos compartilhados e máquinas controladas parcialmente por fornecedores.

2. Garantia de patch:Emitir um alerta não é suficiente. Um alerta crítico deve criar ações rastreadas, prazos, escalação executiva, exceções nomeadas, controles compensatórios e evidências de que o patch foi instalado ou a exposição foi controlada de outra forma. Onde a autonomia local bloqueia mandatos centrais, o centro precisa pelo menos de visibilidade confiável e uma rota para escalar o risco de segurança do paciente.

3. Contenção de legados:Sistemas não suportados ou difíceis de corrigir exigem segmentação, restrições de acesso, planos de fornecedores, financiamento para substituição e contingência clínica. Deixar um sistema sem suporte é às vezes uma necessidade clínica temporária, mas não deve ser um fato não gerenciado descoberto durante um surto de worm.

4. Continuidade específica para cibernético:O planejamento de emergência deve presumir que os sistemas normais de comunicação e registro podem estar indisponíveis. O fallback manual precisa de planejamento de capacidade, não apenas formulários em papel. Deve especificar quais serviços clínicos degradam primeiro, como os pacientes são desviados, como os resultados de exames se movem, como as consultas são reagendadas e como o trabalho offline é reconciliado com segurança.

5. Responsabilidade multinível:O centro, os órgãos locais, os fornecedores e as agências de segurança nacional têm controles diferentes. Uma estrutura madura não colapsa esses controles em uma única história de culpa. Ela define quem deve agir, quem deve verificar, quem deve financiar, quem deve se comunicar e quem deve aceitar o risco residual.

Esses testes são desconfortáveis porque tornam a resiliência cibernética mensurável. Eles também protegem os funcionários de expectativas impossíveis. Durante o WannaCry, os funcionários do NHS trabalharam horas extras e improvisaram para manter os serviços funcionando. A revisão de lições reconheceu publicamente esses esforços. A resposta heróica local não deve ser usada como evidência de que a preparação foi adequada. Muitas vezes é evidência de que o sistema formal deixou muito trabalho para pessoas sob pressão.

O limite da responsabilidade

As fontes públicas apoiam críticas operacionais fortes. Elas não apoiam conclusões legais não fundamentadas contra um trust, executivo, fornecedor ou órgão nacional nomeado. Os registros do PAC, NAO, NHS England, DHSC, CQC, NCSC, Microsoft e registros acadêmicos estabelecem alertas, garantia perdida, sistemas sem patch, interrupção de serviço e reformas pós-incidente. Eles não provam negligência em todas as organizações locais, quantificam todas as perdas ou mostram exatamente quais dispositivos foram responsáveis por cada consulta cancelada.

Esse limite importa porque a lição de responsabilidade é mais ampla que litígios. Se os líderes reduzem o caso a uma luta legal sobre se uma entidade violou um dever, eles perdem o design de controle. A questão do serviço público é se o NHS poderia saber, antes de um evento cibernético nacional, que cada organização havia fechado ou gerenciado conscientemente uma vulnerabilidade crítica conhecida. A resposta em 2017 foi não. A questão da continuidade do cuidado é se cada organização afetada havia ensaiado uma interrupção cibernética bem o suficiente para manter os serviços essenciais funcionando a uma capacidade degradada conhecida.

O registro público diz que esses arranjos não foram suficientemente testados.

O WannaCry permanece, portanto, um caso de responsabilidade pública porque conectou um acúmulo técnico de manutenção à resiliência voltada ao paciente. O risco tinha nomes: MS17-010, SMBv1, sistemas operacionais não suportados, planos de incidentes não testados, órgãos locais sem garantia de conformidade central, redes compartilhadas e sistemas clínicos que não podiam ser desligados casualmente. Mas o dano tinha nomes diferentes: consultas canceladas, pacientes desviados, registros indisponíveis, informações atrasadas, horas extras de funcionários e uma estimativa de remediação e interrupção de £92 milhões.

A maneira mais responsável de lembrar o incidente não é como uma história moral sobre software antigo. É um aviso de que instituições públicas podem saber o suficiente para estar preocupadas e ainda assim não saber o suficiente para estar prontas. Um patch pode existir. Um alerta pode ser enviado. Um conselho pode receber treinamento cibernético. Um plano pode ser escrito.

Se a organização não puder provar que os sistemas vulneráveis foram corrigidos, isolados, substituídos ou contornados com segurança, então o risco ainda está sendo carregado por pacientes, funcionários e provedores menores que só descobrem a dependência quando o serviço para.