Resumo
- Confirmado:O WannaCry afetou os serviços do NHS na Inglaterra de 12 a 19 de maio de 2017. O National Audit Office (NAO) relatou que pelo menos 80 dos 236 trusts do NHS foram infectados ou interrompidos, 34 trusts foram infectados e bloqueados de dispositivos, 46 trusts não foram infectados mas relataram interrupção, e mais 603 organizações de atenção primária e outros NHS foram infectados, incluindo 595 consultórios de GP.
- Confirmado:A 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. A NHS Digital informou ao NAO que nenhum dado de paciente foi comprometido ou roubado, e o Departamento, a NHS England e a National Crime Agency informaram ao NAO que nenhuma organização do NHS pagou o resgate.
- Limitação:Os registros públicos apoiam uma falha de aplicação de patches e garantia, mas não apoiam a alegação simples de que apenas o Windows XP causou a paralisação do NHS. A análise de lições aprendidas da 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 uma minoria dos dispositivos 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 de atendimento que foram forçados a usar papel e coordenação manual.
Um patch pode ser emitido sem ser governado
A versão mais curta da história do NHS sobre o WannaCry é que um patch da Microsoft existia antes do ataque e muitas organizações do NHS não o haviam aplicado. Essa frase é verdadeira, mas esconde o problema de responsabilidade. Um patch é um artefato técnico. Aplicar patches é um sistema de governança. Exige registros de ativos, priorização de riscos, janelas de alteração, testes em sistemas clínicos, coordenação com fornecedores, consentimento operacional local, comprovação de implantação e uma visão nacional das 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 se haviam tornado proteção.
A Microsoft publicou oSecurity Bulletin MS17-010em 14 de março de 2017. O boletim classificou o problema como crítico e disse que as vulnerabilidades mais graves poderiam permitir a 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 suaorientação para clientes WannaCryptque a atualização de março corrigia a vulnerabilidade explorada, que organizações com atualizações automáticas ativadas 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 que já haviam sido corrigidas, afetando computadores que não haviam aplicado o patch. (blog de segurança da Microsoft)
O alerta arquivado da NHS Digital,CC-1411, enquadrava o mesmo risco em linguagem do setor de saúde. Ele identificava o ransomware como usando vulnerabilidades SMB corrigidas no MS17-010, alertava que as vulnerabilidades provavelmente seriam usadas por futuras variantes de malware para autopropagação e dizia que a aplicação de patches nas versões afetadas deveria ser priorizada. Também listava etapas de remediação, como bloquear portas relacionadas ao SMB, confirmar o bloqueio de portas, atualizar plataformas vulneráveis, usar scanners de vulnerabilidade, manter a conectividade com os domínios kill-switch, isolar dispositivos infectados, reconstruir máquinas infectadas para um padrão com patch e não pagar o resgate.
Esses detalhes são importantes 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 haviam tornado a resposta operacionalmente inevitável. ONational Audit Officerelatou que a NHS Digital havia emitido alertas críticos em março e abril de 2017, orientando as organizações a aplicar 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 seus conselhos e orientações. A NHS Digital havia avaliado 88 dos 236 trusts pessoalmente, e nenhum havia passado em sua avaliação de segurança cibernética, mas a 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 opções de implementação. Mas os pacientes experimentaram o sistema combinado, não o limite entre um alerta central e uma janela local de patches.
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, a NHS England declarou um incidente grave e implementou medidas de emergência para manter a saúde e o atendimento ao paciente. 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 por estarem infectados ou por terem desligado sistemas como precaução. Desses, 34 foram infectados e bloqueados de dispositivos, incluindo 25 trusts de hospitais gerais. Outros 46 relataram interrupção 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.
A NHS England e a 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 GP.
O registro público é igualmente claro sobre o que é desconhecido. O Departamento e a 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 GP foram canceladas, ou quantas ambulâncias e pacientes foram desviados dos cinco departamentos de acidentes e emergências que não podiam atender alguns pacientes. A 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 estimados no total não são, portanto, um registro completo do impacto nos pacientes.
Aanálise de lições aprendidas da NHS England, liderada pelo Diretor de Informação para Saúde e Assistência Social, manteve o mesmo quadro enquanto adicionava textura operacional. Ela disse que o NHS não foi diretamente visado, que não houve relatos de danos a pacientes ou comprometimento ou roubo de dados de pacientes, e que 1% da atividade do NHS foi diretamente afetada. Também afirmou que 80 dos 236 trusts hospitalares foram afetados, 595 de 7.454 consultórios de GP e outras oito organizações do NHS e relacionadas foram infectadas, e a interrupção tornou mais clara a dependência do serviço de saúde da 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 atendimento. Em um hospital digital, a disponibilidade não é uma camada de conveniência. É parte da produtividade clínica, comunicação, acesso a diagnósticos, fluxo de consultas e encaminhamento seguro.
Sistemas não suportados fizeram parte da história, não a história toda
O WannaCry é frequentemente recontado como um conto de advertência do Windows XP. Software não suportado importou. Era um risco conhecido, e o Departamento e o Cabinet Office haviam escrito para os trusts em 2014 dizendo que eles precisavam de planos robustos para migrar de softwares antigos, como Windows XP, até abril de 2015. ANational 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. ASafe Data, Safe Careda 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 responsabilidade da liderança pela segurança dos dados.
Mas um slogan de sistema não suportado é muito estreito. A análise de lições aprendidas da NHS England disse que nenhuma das 80 organizações afetadas do NHS havia aplicado o patch de atualização da Microsoft recomendado pelo boletim CareCERT da NHS Digital em 25 de abril de 2017. Também disse que o WannaCry foi 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% até janeiro de 2018.
A distinção é importante para a responsabilidade. Se a falha fosse apenas "sistemas operacionais antigos", a resposta seria financiamento para substituição e pressão sobre fornecedores. Essas eram questões 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 conclusão. Um dispositivo suportado pode ser inseguro quando não está patchado.
Um dispositivo não suportado pode ser isolado ou gerenciado em um modelo de controles compensatórios. O sistema precisava saber qual condição se aplicava a cada ponto crítico antes que um worm tornasse o inventário visível.
A análise de lições aprendidas também observou que os 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 ação para melhorar a segurança dos firewalls de rede voltados para a rede N3 teria protegido as organizações contra infecção. Essa é outra razão para não tratar a aplicação de patches como um único interruptor. Aplicar patches era necessário, mas também o eram a segmentação de rede, configuração de perímetro, controles de exposição SMB e o conhecimento de quais sistemas ainda precisavam de suporte a protocolos legados.
Asorientações do NCSC sobre o WannaCry, agora marcadas como retiradas por estarem desatualizadas, capturavam a lógica defensiva de emergência na época. Aconselhavam as organizações a implantar o MS17-010, desabilitar o SMBv1 se o patch 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 kill-switch. Em outras palavras, a resposta imediata exigia um conjunto de controles em camadas. Organizações que não tinham listas claras de ativos, propriedade de firewall, opções locais de DNS, contatos de fornecedores e procedimentos testados de reconstrução 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 GP, grupos de comissionamento clínico, fornecedores, unidades de suporte de comissionamento e outras organizações operam dentro de estruturas nacionais, mas detê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 os supervisionavam e apoiavam, mas nem sempre tinham autoridade para compelir ações técnicas específicas.
Essa estrutura não é intrinsecamente errada. As 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 ignore essas realidades pode produzir mudanças inseguras ou resistência local.
No entanto, a autonomia local se torna perigosa quando o centro não pode ver quais locais estão expostos, quais aceitaram o 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 correção.
O ponto do NAO sobre a falta de um mecanismo formal de conformidade não é, portanto, um detalhe burocrático. 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". Não pode provar por si só que todos os endpoints relevantes têm o patch, que os dispositivos não suportados estão isolados, que o SMB está bloqueado onde deveria, que os sistemas que exigem exceções estão nomeados ou que os executivos aceitaram um risco residual para a segurança do paciente.
Orelatório do Public Accounts Committeetornou a mesma fraqueza política. Disse que houve alertas em 2016 e novos alertas em março e abril de 2017, mas a aplicação de patches havia ocorrido em apenas cerca de dois terços dos trusts na época do WannaCry, e nenhum dos 88 trusts havia passado pelas avaliações da NHS Digital. Também relatou que o Departamento e o NHS reconheceram que as coisas precisavam mudar e que a análise de lições aprendidas de 2018 continha 22 recomendações, mas que os planos de implementação e custos ainda não haviam sido acordados quando o Comitê se pronunciou.
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 GP não conseguia acessar os sistemas, ou se uma ambulância tinha que desviar, o dano alcançava 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 atendimento, 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 riscos. Algumas usaram papel. Algumas não conseguiam 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 teve o cuidado de dizer que nem todas as categorias foram totalmente contadas, e a análise da NHS England relatou nenhum dano conhecido 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 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 medicamentos, rotas seguras de transferência, soluções alternativas 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 capacidade e erro.
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 do diagnóstico for prejudicada em uma região.
A análise de lições aprendidas da NHS England reconheceu a diferença entre um incidente cibernético e um incidente grave convencional. Disse que a NHS England usou sua estrutura de Emergency Preparedness, Resilience and Response, que fornecia 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 por 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 cuidados 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 redução de produtividade clínica, e com base em que evidências?
O NAO relatou que o Departamento havia desenvolvido um plano incluindo funções e responsabilidades nacionais e locais, mas não o havia testado em nível local. Também constatou que o NHS não havia ensaiado para um ataque cibernético nacional, então não ficou imediatamente claro quem deveria liderar a resposta e houve problemas de comunicação. Isso não é uma lacuna processual 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 de pacientes offline 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 interrupçã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 podia evitar a infecção direta e ainda perder o acesso a um processo de transferência de ambulância, uma transferência de imagem de diagnóstico, um caminho de pedido de quimioterapia, um fluxo de resultados de sangue ou uma carga de trabalho 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.
Oestudo de caso do toolkit de gerenciamento de continuidade de negócios da NHS England sobre o WannaCrytorna isso prático. Descreve o County Durham and Darlington NHS Foundation Trust como não tendo sofrido um ataque direto, enquanto o serviço de ambulância protegeu sua rede fechando o acesso, desabilitando as telas do processo de transferência e tornando um portal de reservas de transporte de pacientes indisponível. Centros terciários fecharam o acesso, o que significava que as tomografias e ressonâncias não podiam ser transferidas eletronicamente e os pedidos de quimioterapia não podiam ser transferidos pela rota habitual. O provedor de TI de atenção primária protegeu sua rede, após o que a transferência automatizada de resultados de sangue falhou e alguns GPs não conseguiram acessar suas cargas de trabalho.
As soluções alternativas nesse estudo de caso são úteis porque são concretas, não dramáticas. Os pré-avisos de ambulância continuaram por telefone fixo e outras comunicações de rádio. As reservas de transporte de pacientes passaram para telefone. As imagens foram transferidas para DVD e enviadas por táxi. Os pedidos de quimioterapia voltaram para papel e fax. As transferências de resultados de sangue passaram para papel e diminuíram o processo. Alguns GPs acessaram cargas de trabalho por meio 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.
Esse é exatamente o tipo de evidência que as contagens amplas de incidentes perdem. Um incidente cibernético pode reduzir a capacidade de atendimento sem que todas as organizações afetadas estejam infectadas. 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 de diagnóstico para um pequeno número de exames urgentes; não é um substituto para a troca eletrônica de imagens comum em uma região movimentada.
Uma rota de reserva telefônica pode manter o transporte de pacientes funcionando; não pode preservar automaticamente a priorização, auditoria ou capacidade se o volume de chamadas aumentar. Os pedidos de quimioterapia em papel podem impedir que o tratamento pare; criam sobrecarga 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 GP, hospício, provedor comunitário, clínica local ou serviço contratado pode não possuir o sistema central do qual depende. Pode depender de uma unidade de suporte de 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 por meio de um local alternativo, se os resultados em papel são clinicamente aceitáveis, se as atualizações de encaminhamento estão sendo colocadas em fila 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 têm que se encontrar. Se o desligamento defensivo de um centro terciário bloqueia a transferência de imagens, o plano do trust de referência já deve conhecer a rota alternativa. Se um provedor de TI de atenção primária fecha o acesso, as clínicas locais precisam de opções nomeadas para acesso urgente a registros.
Se as telas de transferência 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 foi ensaiado. O estudo de caso do NHS é modesto em escopo, mas mostra a verdade em nível de sistema: a continuidade cibernética é um trabalho conjunto, e uma dependência conjunta não testada pode falhar mesmo quando cada participante tenta 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, a NHS England e a National Crime Agency no relatório do NAO. Esse fato deve evitar uma leitura comum incorreta: a perda não foi o pedido de resgate. Foram trabalho cancelado, horas extras, suporte de TI, restauração, cuidados adiados, 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 na época de sua investigação.
Identificou categorias de custo, como consultas canceladas, suporte local adicional de TI, consultores de TI, restauração de dados e sistemas e horas extras da equipe durante o fim de semana de resposta.
A atualização posterior do Departamento de Saúde e Assistência Social,Securing cyber resilience in health and care: October 2018 progress update, vinculada ao detalhadoPDF 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 perda de produção. 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 do fornecedor ou cada hora da equipe.
O trabalho acadêmico também mostra por que o impacto é difícil de precificar. Umaanálise retrospectiva de impacto do npj Digital Medicine de 2019usou as Hospital Episode Statistics para examinar cancelamentos, admissões, atendimentos de emergência, mortalidade e custos fiscais. Constatou nenhuma 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 admissões eletivas e de emergência, e o estudo estimou £5,9 milhões em perda de atividade hospitalar nos trusts infectados. Também observou nenhum aumento na mortalidade, embora alertando que a mortalidade é uma medida grosseira de dano ao paciente.
A diferença entre uma estimativa de £5,9 milhões de atividade hospitalar infectada e uma estimativa mais ampla de £92 milhões do setor público não é necessariamente uma contradição. Elas medem coisas diferentes. Uma examina 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 fins de responsabilidade, o ponto importante não é escolher o maior número e chamá-lo de "o custo".
É perguntar quais custos eram evitáveis com patches mais precoces, quais foram incorridos por contenção necessária, quais eram investimentos que deveriam ter sido feitos antes e quais recaíram sobre pacientes e equipe sem nunca aparecer em um orçamento de TI.
Provedores de pequeno e médio porte estão dentro dessa mesma questão. A questão é a continuidade em todas as organizações menores que se conectam a um serviço nacional: consultórios de GP, hospícios, 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 por meio 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.
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 oator norte-coreano por trás do WannaCrydisse que o Reino Unido julgou que atores norte-coreanos conhecidos como Lazarus Group estavam por trás da campanha. Essa atribuição é importante 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 foi o alvo específico, que o worm se espalhou por uma vulnerabilidade conhecida do Windows e que as organizações locais poderiam ter tomado medidas 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 então a decisão extraordinária de disponibilizar patches para plataformas não suportadas durante a emergência. A NHS Digital controlou alertas, orientações, suporte por telefone e conselhos específicos do setor. A NHS England controlou a coordenação do incidente grave e a escalada da continuidade do atendimento.
O Departamento de Saúde controlou a supervisão política e as prioridades de financiamento. Trusts e clínicas locais controlaram muitas decisões de dispositivos, redes, fornecedores e gerenciamento de mudanças. Fornecedores controlaram alguns dispositivos legados, termos de suporte e restrições de compatibilidade.
Nenhuma camada isolada é a história toda. Tratar o incidente apenas como um evento de estado hostil o torna muito distante da gestão local. Tratá-lo apenas como não conformidade local ignora que os órgãos nacionais haviam visto 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 os sistemas Windows suportados também estavam sem patch.
A responsabilidade é o mapa desses controles, não uma busca por um único ator que possa carregar todos eles.
O controle mais consequente foi a evidência. Quem conhecia o estado dos patches? Quem conhecia o estado do SMB exposto? Quem sabia quais sistemas não eram suportados? Quem sabia quais dispositivos médicos não podiam ser patchados 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 GP 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 análise de lições aprendidas da 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, processos de resposta melhorados e coordenação nacional mais forte. A atualização de progresso de 2018 do Departamento descreveu 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. OData 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 da 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 uma garantia explícita, em vez de apenas orientação informal. Também tirou o cibernético do caminho puramente técnico e o colocou na responsabilidade no nível do conselho, notificação de incidentes e continuidade.
A estratégia governamental posterior,A cyber resilient health and adult social care system in England, estende esse quadro até 2030. 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 ocorrem ataques. A existência da estratégia reforça a lição central de 2017: na área da saúde, a segurança cibernética não é uma disciplina separada de back-office. Ela sustenta a confiança pública e a continuidade dos serviços.
O papel público mais amplo do National Cyber Security Centre também cresceu durante esse período. Seuanúncio de revisão anual de 2017descreveu 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 tinha que se conectar a operações específicas do setor, não apenas publicar avisos para equipes técnicas.
Cinco testes de responsabilidade
O valor duradouro do caso do NHS é que ele oferece 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. São sobre se um serviço público pode provar que o risco cibernético conhecido foi convertido em ação operacional.
1. Visibilidade de ativos:Uma organização não pode corrigir o que não pode identificar. Precisa de um inventário de servidores, endpoints, dispositivos médicos, sistemas não suportados, versões de sistemas operacionais, 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 patches: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 à segurança do paciente.
3. Isolamento 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 não suportado é à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 cibernética específica:O planejamento de emergência deve assumir 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 de papel. Deve especificar quais serviços clínicos se degradam primeiro, como os pacientes são desviados, como os resultados de exames circulam, como as consultas são reagendadas e como o trabalho offline é reconciliado com segurança.
5. Responsabilidade em vários níveis:O centro, os órgãos locais, os fornecedores e as agências nacionais de segurança têm controles diferentes. Uma estrutura madura não colapsa esses controles em uma única história de culpa. 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 a equipe de expectativas impossíveis. Durante o WannaCry, a equipe do NHS trabalhou horas extras e improvisou para manter os serviços funcionando. A análise de lições aprendidas reconheceu publicamente esses esforços. A resposta heroica local não deve ser usada como evidência de que a preparação foi adequada. É frequentemente evidência de que o sistema formal deixou muito trabalho para pessoas sob pressão.
O limite de responsabilidade
As fontes públicas apoiam fortes críticas operacionais. Não apoiam conclusões legais não fundamentadas contra um trust, executivo, fornecedor ou órgão nacional específico. O 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 cada perda ou mostram exatamente quais dispositivos foram responsáveis por cada consulta cancelada.
Esse limite é importante porque a lição de responsabilidade é mais ampla do que litígio. Se os líderes reduzem o caso a uma disputa legal sobre se uma entidade violou um dever, eles perdem o desenho do controle. A questão do serviço público é se o NHS podia saber, antes de um evento cibernético nacional, que cada organização havia fechado ou gerenciado conscientemente uma vulnerabilidade crítica conhecida. A resposta de 2017 foi não.
A questão da continuidade do atendimento é se todas as organizações afetadas haviam ensaiado uma interrupção cibernética bem o suficiente para manter os serviços essenciais funcionando com uma capacidade degradada conhecida. O registro público diz que esses arranjos não foram suficientemente testados.
O WannaCry, portanto, continua sendo um caso de responsabilidade pública porque conectou um acúmulo de manutenção técnica à resiliência voltada para o 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 da equipe 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 um conto moral sobre software antigo. É um aviso de que as instituições públicas podem saber o suficiente para estar preocupadas e ainda 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 pode provar que os sistemas vulneráveis estão patchados, 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.