NHS England y WannaCry: el fallo de parcheo que se convirtió en una prueba de continuidad asistencial

Resumen

• Confirmado:WannaCry afectó a los servicios del NHS en Inglaterra desde el 12 de mayo hasta el 19 de mayo de 2017. La National Audit Office informó de que al menos 80 de 236 trusts fueron infectados o sufrieron interrupciones, 34 trusts resultaron infectados y bloqueados de sus dispositivos, 46 trusts no fueron infectados pero notificaron interrupciones, y otras 603 organizaciones de atención primaria y otros organismos del NHS resultaron infectadas, incluidas 595 consultas de medicina general.
• Confirmado:NHS England identificó 6.912 citas canceladas durante el período de respuesta al incidente y estimó más de 19.000 cancelaciones en total. Cinco servicios de urgencias desviaron pacientes. NHS Digital informó a la NAO que no se habían visto comprometidos ni robado datos de pacientes, y el Department, NHS England y la National Crime Agency declararon a la NAO que ninguna organización del NHS pagó el rescate.
• Límite:El registro público respalda un fallo en el parcheo y en la garantía de seguridad, pero no respalda la afirmación simplista de que Windows XP por sí solo causó la interrupción del NHS. La revisión de lecciones aprendidas de NHS England señaló que el ataque explotó una vulnerabilidad de Microsoft Windows, que la mayoría de los dispositivos infectados del NHS ejecutaban Windows 7 con soporte pero sin parchear, y que los dispositivos XP sin soporte constituían una minoría de los infectados.
• Evaluación:El fallo imputable no fue meramente una deuda técnica. Fue la combinación de visibilidad de activos, despliegue de parches, gestión de dispositivos sin soporte, autonomía de los trusts locales, organismos nacionales sin un mecanismo de cumplimiento previo al incidente, respuesta local no probada y procesos de continuidad asistencial que se vieron forzados a recurrir al papel y a la coordinación manual.

Un parche puede publicarse sin que exista gobernanza

La versión más resumida de la historia del NHS y WannaCry es que existía un parche de Microsoft antes del ataque y demasiadas organizaciones del NHS no lo habían aplicado. Esa frase es cierta, pero oculta el problema de rendición de cuentas. Un parche es un artefacto técnico. El parcheo es un sistema de gobernanza. Requiere registros de activos, priorización de riesgos, ventanas de cambio, pruebas en sistemas clínicos, coordinación con proveedores, consentimiento operativo local, prueba de implementación y una visión nacional de las excepciones.

En mayo de 2017 el NHS disponía de directrices, advertencias y soporte técnico, pero no tenía suficiente garantía de que las directrices se hubieran convertido en protección.

Microsoft publicó elSecurity Bulletin MS17-010el 14 de marzo de 2017. El boletín calificó el problema como crítico y señaló que las vulnerabilidades más graves podían permitir la ejecución remota de código si un atacante enviaba mensajes manipulados a un servidor de Server Message Block 1.0 de Microsoft. Microsoft explicó posteriormente en suguía para clientes sobre WannaCryptque la actualización de marzo solucionaba la vulnerabilidad explotada, que las organizaciones con actualizaciones automáticas habilitadas estaban protegidas contra esa vulnerabilidad y que Microsoft tomó la medida inusual de poner las actualizaciones a disposición general para plataformas más antiguas como Windows XP, Windows 8 y Windows Server 2003. Su blog de seguridad describió WannaCrypt como un gusano que utilizaba vulnerabilidades ya corregidas y afectaba a equipos que no habían aplicado el parche. (blog de seguridad de Microsoft)

La alerta archivada de NHS Digital,CC-1411, planteó el mismo riesgo en lenguaje del sector sanitario. Identificó que el ransomware utilizaba las vulnerabilidades SMB parcheadas en MS17-010, advirtió de que era probable que futuras variantes de malware utilizaran esas vulnerabilidades para la autopropagación y señaló que debía priorizarse el parcheo de las versiones afectadas. También enumeró pasos de corrección como bloquear los puertos relacionados con SMB, confirmar el bloqueo de puertos, actualizar las plataformas vulnerables, utilizar escáneres de vulnerabilidades, mantener la conectividad con el dominio del interruptor de apagado, poner en cuarentena los dispositivos infectados, reconstruir las máquinas infectadas a un estándar parcheado y no pagar el rescate.

Esos detalles importan porque demuestran que la respuesta técnica no era oscura el 12 de mayo. La pregunta más difícil es si los controles nacionales y locales habían hecho que esa respuesta fuera operativamente inevitable. La investigación de laNational Audit Officeinformó de que NHS Digital había emitido alertas críticas en marzo y abril de 2017 advirtiendo a las organizaciones que parchearan sus sistemas para prevenir WannaCry. También informó de que, antes del ataque, el Department of Health no disponía de un mecanismo formal para evaluar si las organizaciones del NHS habían cumplido sus consejos y directrices. NHS Digital había evaluado in situ a 88 de los 236 trusts, y ninguno había superado su evaluación de ciberseguridad, pero NHS Digital no podía exigir a un organismo local que tomara medidas correctoras.

Ese es el eje de la rendición de cuentas. El centro podía advertir. Las organizaciones locales controlaban muchas decisiones de implementación. Pero los pacientes experimentaban el sistema combinado, no la frontera entre una alerta central y una ventana de parcheo local.

Lo que establece el registro

WannaCry empezó a afectar al NHS el viernes 12 de mayo de 2017. La NAO informó de que el ataque global de ransomware afectó a más de 200.000 equipos en al menos 100 países, y que el NHS no fue el objetivo específico. A las 4 de la tarde de ese día, NHS England declaró un incidente grave y puso en marcha medidas de emergencia para mantener la atención sanitaria y el cuidado de los pacientes. Un investigador de seguridad activó un interruptor de apagado esa misma noche, impidiendo que WannaCry siguiera bloqueando dispositivos de la misma manera. El ataque afectó a los servicios del NHS durante la semana del 12 al 19 de mayo.

La magnitud en Inglaterra fue significativa pero no totalmente mensurable. Según la NAO, al menos 80 de los 236 trusts de toda Inglaterra se vieron afectados porque resultaron infectados o apagaron sus sistemas por precaución. De ellos, 34 fueron infectados y bloqueados de sus dispositivos, incluidos 25 trusts de agudos. Otros 46 notificaron interrupciones sin ser categorizados como infectados; algunos apagaron el correo electrónico y otros sistemas por precaución y tuvieron que usar lápiz y papel para actividades que normalmente se realizaban por vía electrónica.

NHS England y NHS Digital también identificaron 21 trusts cuyos sistemas intentaron contactar con el dominio de WannaCry pero no fueron bloqueados, y otras 603 organizaciones de atención primaria y otros organismos resultaron infectados, incluidas 595 consultas de medicina general.

El registro público es igualmente claro sobre lo que se desconoce. El Department y NHS England no conocían el alcance total de la interrupción. No sabían cuántas organizaciones del NHS no podían acceder a los registros porque compartían sistemas o datos con un trust infectado. No sabían cuántas citas de medicina general se cancelaron, ni cuántas ambulancias y pacientes fueron desviados de los cinco servicios de urgencias que no pudieron atender a algunos pacientes. NHS England recopiló cierta información sobre cancelaciones entre el 12 y el 18 de mayo, pero la NAO afirmó que los datos no cubrían todos los tipos de citas.

Por tanto, las 6.912 cancelaciones identificadas notificadas y las más de 19.000 cancelaciones totales estimadas no constituyen un registro completo del impacto en los pacientes.

Larevisión de lecciones aprendidas de NHS England, dirigida por el Chief Information Officer for Health and Social Care, mantuvo el mismo marco al tiempo que añadió textura operativa. Señaló que el NHS no fue atacado directamente, que no hubo informes de daños a pacientes ni de compromiso o robo de datos de pacientes, y que el 1% de la actividad del NHS se vio directamente afectada. También indicó que 80 de los 236 hospitales se vieron afectados, 595 de 7.454 consultas de medicina general y otras ocho organizaciones del NHS y entidades relacionadas resultaron infectadas, y que la interrupción puso de manifiesto la dependencia del servicio de salud de la tecnología de la información.

Esta última conclusión es la más importante. Un incidente de ransomware que no robó datos de pacientes aún así perjudicó la continuidad asistencial. En un hospital digital, la disponibilidad no es una capa de conveniencia. Forma parte del flujo clínico, la comunicación, el acceso diagnóstico, el flujo de citas y la escalada segura.

Los sistemas sin soporte fueron parte de la historia, no toda la historia

A menudo se cuenta WannaCry como una advertencia sobre Windows XP. El software sin soporte era importante. Era un riesgo conocido, y el Department y el Cabinet Office habían escrito a los trusts en 2014 indicando que necesitaban planes sólidos para migrar desde software antiguo como Windows XP antes de abril de 2015. La revisión de laNational Data Guardian, publicada en julio de 2016, propuso nuevos estándares de seguridad de datos y un método para comprobar su cumplimiento. La revisiónSafe Data, Safe Carede la Care Quality Commission, también publicada en julio de 2016, recomendó la sustitución urgente del hardware y software que ya no pudieran recibir soporte, una auditoría y validación más sólidas, y que la dirección asumiera la responsabilidad de la seguridad de los datos.

Pero el eslogan del sistema sin soporte es demasiado limitado. La revisión de lecciones de NHS England señaló que ninguna de las 80 organizaciones afectadas del NHS había aplicado el parche de actualización de Microsoft recomendado en el boletín CareCERT de NHS Digital del 25 de abril de 2017. También señaló que WannaCry fue un ataque que utilizó una vulnerabilidad específica de Microsoft Windows, no un ataque contra el software sin soporte. La mayoría de los dispositivos infectados del NHS ejecutaban Windows 7 con soporte pero sin parchear.

Los dispositivos XP sin soporte constituían una minoría de los infectados, y el número de dispositivos XP había disminuido del 18% al 1,8% en enero de 2018.

Esta distinción es importante para la responsabilidad. Si el fallo hubiera sido solo de «sistemas operativos antiguos», la respuesta sería financiación para la sustitución y presión a los proveedores. Eran problemas reales, especialmente cuando los equipos médicos o dispositivos de diagnóstico dependían de software antiguo. Pero si las máquinas con Windows 7 con soporte permanecían sin parchear después de una alerta crítica, entonces la respuesta también incluye la gobernanza de parches, la gestión de excepciones y la prueba de cierre. Un dispositivo con soporte puede ser inseguro cuando no está parcheado.

Un dispositivo sin soporte puede aislarse o gestionarse en un modelo de controles compensatorios. El sistema necesitaba saber qué condición se aplicaba a cada punto crítico antes de que un gusano hiciera visible el inventario.

La revisión de lecciones también señaló que los controles de cortafuegos y de red podrían haber reducido el riesgo de infección. Afirmó que, incluso en los casos en que no se había parcheado, la adopción de medidas para mejorar la seguridad de los cortafuegos de red frente a la red N3 habría protegido a las organizaciones contra la infección. Esta es otra razón para no considerar el parcheo como un único interruptor. El parcheo era necesario, pero también lo eran la segmentación de la red, la configuración del perímetro, los controles de exposición SMB y el conocimiento de qué sistemas aún necesitaban soporte para protocolos heredados.

Laguía del NCSC sobre WannaCry, ahora marcada como retirada por estar desactualizada, recogió la lógica defensiva de emergencia de aquel momento. Aconsejó a las organizaciones implementar MS17-010, deshabilitar SMBv1 si el parcheo no era posible, bloquear los puertos relevantes cuando fuera necesario, aislar la tecnología heredada vulnerable, actualizar el antivirus y evitar bloquear los dominios del interruptor de apagado. En otras palabras, la respuesta inmediata requería un conjunto de controles por capas. Las organizaciones que carecían de listas claras de activos, propiedad de los cortafuegos, opciones de DNS locales, contactos de proveedores y procedimientos de reconstrucción probados no podían ejecutar fácilmente esa respuesta por capas bajo la presión de la emergencia.

La autonomía local dificultó la garantía central

El NHS no es un único entorno de TI monolítico. Los trusts locales, las consultas de medicina general, los grupos de comisionamiento clínico, los proveedores, las unidades de apoyo al comisionamiento y otras organizaciones operan dentro de marcos nacionales pero asumen muchas responsabilidades locales. La NAO señaló que las organizaciones sanitarias locales eran responsables de mantener la seguridad de la información y de los planes de incidentes y emergencias, incluidos los ciberataques. Los organismos nacionales las supervisaban y apoyaban, pero no siempre tenían autoridad para obligar a tomar medidas técnicas específicas.

Esta estructura no es inherentemente incorrecta. Las organizaciones clínicas locales conocen sus propias vías asistenciales, equipos, proveedores y riesgos de cambio. Un parche puede romper una antigua interfaz de diagnóstico, una integración de administración de pacientes o un proceso de dispositivo médico. Una instrucción central que ignore estas realidades puede producir cambios inseguros o resistencia local.

Sin embargo, la autonomía local se vuelve peligrosa cuando el centro no puede ver qué centros están expuestos, cuáles han aceptado el riesgo, cuáles disponen de controles compensatorios y cuáles no pueden actuar porque un proveedor, presupuesto o dependencia clínica bloquea la corrección.

El argumento de la NAO sobre la falta de un mecanismo formal de cumplimiento no es, por tanto, una trivialidad burocrática. Explica por qué una advertencia no se tradujo en una reducción del riesgo en todo el sistema. Una alerta nacional puede decir «parchee ahora». Pero no puede por sí misma demostrar que cada punto final relevante tiene el parche, que los dispositivos sin soporte están aislados, que SMB está bloqueado donde debería estarlo, que los sistemas que requieren excepciones están identificados o que los directivos han aceptado un riesgo residual para la seguridad del paciente.

El informe delPublic Accounts Committeeconvirtió esta misma debilidad en política. Señaló que hubo advertencias en 2016 y nuevas advertencias en marzo y abril de 2017, pero el parcheo solo se había llevado a cabo en aproximadamente dos tercios de los trusts en el momento de WannaCry, y ninguno de los 88 trusts había superado las evaluaciones de NHS Digital. También informó de que el Department y el NHS reconocían que las cosas debían cambiar y que la revisión de lecciones de 2018 contenía 22 recomendaciones, pero que los planes de implementación y los costes aún no se habían acordado cuando el Comité informó.

Esta evidencia respalda una conclusión sobria: la responsabilidad estaba distribuida, pero el paciente no recibió una atención distribuida. Si un trust local carecía del parche, si una consulta de medicina general no podía acceder a los sistemas o si una ambulancia tenía que desviarse, el daño llegaba a las personas a través de un único servicio público. La gobernanza distribuida necesita bucles de evidencia más sólidos precisamente porque el servicio público parece unificado en el punto de necesidad.

Un incidente de continuidad asistencial, no solo un incidente de TI

El daño visible de WannaCry fue la interrupción. Algunas organizaciones fueron infectadas y bloqueadas. Otras apagaron sistemas para reducir el riesgo. Algunas utilizaron papel. Otras no pudieron recibir resultados de pruebas o acceder a registros compartidos. A algunos pacientes se les cancelaron citas u operaciones. Cinco zonas desviaron pacientes de urgencias. La NAO fue cuidadosa al afirmar que no todas las categorías se contabilizaron por completo, y la revisión de NHS England no informó de daños conocidos a pacientes. Esos límites deben respetarse.

La ausencia de daños notificados no es prueba de que no existiera ningún riesgo clínico, pero el registro público no respalda la invención de una cifra de fallecidos o un robo oculto de datos de pacientes.

El prisma de rendición de cuentas más útil es la capacidad de continuidad. Los servicios sanitarios pueden sobrevivir a una breve interrupción digital solo si los modos degradados están preparados. El recurso al papel no es un plan por sí mismo. Requiere listas de pacientes imprimibles o recientes, alternativas de acceso al historial de medicación, vías seguras de traspaso, soluciones alternativas para solicitar diagnósticos, seguimiento de derivaciones, programación de quirófanos, comunicación de resultados de laboratorio, reprogramación manual de citas y conciliación tras la vuelta a la normalidad de los sistemas.

Cada alternativa tiene un perfil de rendimiento y errores. Una consulta que puede gestionar 20 excepciones manuales puede no ser capaz de gestionar cientos. Un hospital que puede aplazar con seguridad el trabajo electivo durante un día puede tener dificultades si la visibilidad diagnóstica se ve afectada en toda una región.

La revisión de lecciones de NHS England reconoció la diferencia entre un ciberincidente y un incidente grave convencional. Afirmó que NHS England utilizó su marco de Preparación, Resiliencia y Respuesta ante Emergencias, que ofrecía una estructura sólida, pero el incidente también enseñó lecciones sobre cómo los ciberincidentes difieren de otros incidentes graves. Un ciberincidente puede hacer que las propias herramientas de comunicación no sean fiables. Puede afectar a múltiples centros simultáneamente. Al principio puede no estar claro si un centro está infectado, desconectado o actuando de forma defensiva.

Puede requerir acciones de contención técnica que reduzcan la capacidad asistencial. También puede propagarse a través de redes compartidas, de modo que ayudar a una organización puede depender de cómo se comporte otra.

Por eso la rendición de cuentas no debe limitarse al dispositivo que no recibió un parche. El sistema asistencial necesitaba una forma probada de responder a preguntas básicas de continuidad en condiciones de ciberincidente. ¿Qué servicios deben seguir funcionando incluso si el correo electrónico no está disponible? ¿Qué registros son esenciales para la atención de urgencias? ¿Qué sistemas pueden apagarse localmente sin coordinación regional? ¿Qué organismo nacional lidera las comunicaciones? ¿Qué proveedores deben unirse al puente de incidentes? ¿Qué directivos locales pueden aceptar una reducción del rendimiento clínico y con qué evidencia?

La NAO informó de que el Department había desarrollado un plan que incluía funciones y responsabilidades nacionales y locales, pero no lo había probado a nivel local. También constató que el NHS no había realizado simulacros para un ciberataque nacional, por lo que no estaba claro de inmediato quién debía liderar la respuesta y hubo problemas de comunicación. No se trata de una laguna de procedimiento menor.

En la continuidad cibernética, los simulacros son la forma en que las organizaciones descubren si las listas de contactos funcionan, si existen formularios en papel, si las listas de pacientes sin conexión son suficientemente recientes, si los proveedores responden y si los clínicos entienden qué sistemas son seguros para reconectar.

La interdependencia convirtió la protección local en interrupción regional

Una de las características más difíciles del incidente es que algunas organizaciones se vieron perjudicadas por las medidas defensivas de otras. Un trust podía evitar la infección directa y aún así perder el acceso a un proceso de traspaso de ambulancias, una transferencia de imágenes diagnósticas, una vía de pedido de quimioterapia, un flujo de resultados sanguíneos o una carga de trabajo de atención primaria porque otro proveedor, suministrador o socio de red cerró el acceso para protegerse. Se trata de una contención local racional, pero crea consecuencias regionales en el servicio.

El posteriorestudio de caso sobre WannaCry del conjunto de herramientas de gestión de continuidad del negociode NHS England lo hace práctico. Describe que el County Durham and Darlington NHS Foundation Trust no sufrió un ataque directo, mientras que el servicio de ambulancias protegió su red cerrando el acceso, desactivando las pantallas del proceso de traspaso e inutilizando un portal de reserva de transporte de pacientes. Los centros terciarios cerraron el acceso, de modo que las tomografías computarizadas y las resonancias magnéticas no podían transferirse electrónicamente y los pedidos de quimioterapia no podían transferirse por la vía habitual. El proveedor de TI de atención primaria protegió su red, tras lo cual falló la transferencia automatizada de resultados sanguíneos y algunos médicos de cabecera no pudieron acceder a sus cargas de trabajo.

Las soluciones alternativas de ese estudio de caso son útiles porque son concretas en lugar de dramáticas. Las alertas previas de ambulancias continuaron por teléfono fijo y otras comunicaciones por radio. Las reservas de transporte de pacientes pasaron al teléfono. Las imágenes se transfirieron en DVD y se enviaron en taxi. Los pedidos de quimioterapia volvieron al papel y al fax. Las transferencias de resultados sanguíneos pasaron al papel y ralentizaron el proceso. Algunos médicos de cabecera accedieron a sus cargas de trabajo a través de centros de tratamiento de urgencia.

El estudio de caso indicó que los planes de continuidad del negocio se actualizaron posteriormente y concluyó que las organizaciones del NHS deben comprender sus interdependencias y coordinar los planes para los servicios compartidos a fin de minimizar el impacto en la economía de la salud.

Este es precisamente el tipo de evidencia que las cifras generales de incidentes pasan por alto. Un ciberincidente puede reducir la capacidad asistencial sin que todas las organizaciones afectadas estén infectadas. Puede convertir una decisión segura de una parte en una interrupción para otra. Puede requerir métodos analógicos que son seguros para un volumen bajo pero frágiles a escala. Un DVD enviado en taxi puede salvar una vía diagnóstica para un pequeño número de exploraciones urgentes; no es un sustituto del intercambio electrónico ordinario de imágenes en una región con mucha actividad.

Una ruta de reserva telefónica puede mantener el transporte de pacientes en movimiento; no puede preservar automáticamente la priorización, la auditoría o el rendimiento si el volumen de llamadas se dispara. Los pedidos de quimioterapia en papel pueden evitar que el tratamiento se detenga; crean cargas de transcripción, confirmación y conciliación que el proceso digital normalmente absorbe.

Estos ejemplos también explican por qué la continuidad de proveedores y socios es importante para las organizaciones más pequeñas. Una consulta de medicina general, un centro de cuidados paliativos, un proveedor comunitario, una clínica local o un servicio contratado pueden no ser propietarios del sistema central del que dependen. Pueden depender de una unidad de apoyo al comisionamiento, un sistema clínico alojado, una interfaz de patología, un socio de diagnóstico o una ruta de red controlada por otra persona. Cuando esa dependencia se desconecta, la organización más pequeña debe seguir respondiendo a los pacientes.

Debe saber si puede acceder a los registros a través de un sitio alternativo, si los resultados en papel son clínicamente aceptables, si las actualizaciones de derivaciones se están poniendo en cola y quién es responsable de informar a los pacientes de que la vía digital ha fallado.

A efectos de rendición de cuentas, la interdependencia cambia la prueba de control. No basta con que cada organización afirme que tiene un plan de continuidad del negocio. Los planes deben encajar entre sí. Si el cierre defensivo de un centro terciario bloquea la transferencia de imágenes, el plan del trust que deriva debe conocer ya la ruta alternativa. Si un proveedor de TI de atención primaria cierra el acceso, las consultas locales necesitan opciones designadas para el acceso urgente a los registros.

Si las pantallas de traspaso de ambulancias no están disponibles, los servicios de urgencias y los de ambulancias necesitan un plan de contingencia compartido que se haya ensayado. El estudio de caso del NHS es de alcance modesto, pero muestra la verdad a nivel de sistema: la continuidad cibernética es un trabajo conjunto, y una dependencia conjunta no probada puede fallar incluso cuando cada participante intenta ser prudente.

El coste fue mayor que un rescate que no se pagó

Ninguna organización del NHS pagó el rescate, según el Department, NHS England y la National Crime Agency en el informe de la NAO. Ese hecho debería evitar una interpretación errónea común: la pérdida no fue la demanda de rescate. Fue el trabajo cancelado, las horas extraordinarias, el soporte informático, la restauración, la atención diferida, el esfuerzo de los proveedores y la corrección posterior. La NAO afirmó que el Department no conocía el coste de la interrupción de los servicios en el momento de su investigación.

Identificó categorías de costes como citas canceladas, soporte informático local adicional, consultores de TI, restauración de datos y sistemas, y horas extraordinarias del personal durante la respuesta del fin de semana.

La actualización posterior del Department of Health and Social Care,Securing cyber resilience in health and care: October 2018 progress update, enlazó con elPDF de actualización de septiembre de 2018. Esa actualización se cita ampliamente por la estimación de que WannaCry costó al NHS 92 millones de libras, incluida la respuesta directa y la recuperación de TI, así como la producción perdida. Esa estimación debe utilizarse con cuidado. Se trata de una estimación de costes del sector público, no de una contabilidad completa de la ansiedad de los pacientes, el tiempo de las familias, el movimiento de ambulancias, la carga de los proveedores locales o cada hora del personal.

El trabajo académico también muestra por qué el impacto es difícil de valorar. Unanálisis retrospectivo de impacto de npj Digital Medicinede 2019 utilizó las Estadísticas de Episodios Hospitalarios para examinar cancelaciones, ingresos, asistencias a urgencias, mortalidad y costes fiscales. No encontró diferencias significativas en la actividad total en todos los trusts durante la semana de WannaCry en comparación con la línea de base, pero los hospitales directamente infectados tuvieron menos ingresos urgentes y electivos, y el estudio estimó 5,9 millones de libras en actividad hospitalaria perdida en los trusts infectados. También señaló que no hubo aumento de la mortalidad, aunque advirtió que la mortalidad es una medida burda del daño al paciente.

La diferencia entre una estimación de 5,9 millones de libras de actividad hospitalaria infectada y una estimación más amplia de 92 millones del sector público no es necesariamente una contradicción. Miden cosas diferentes. Una examina la actividad en los hospitales infectados durante un período definido utilizando datos hospitalarios. La otra incluye la respuesta, la recuperación y la corrección de TI más amplias. A efectos de rendición de cuentas, lo importante no es elegir la cifra más alta y llamarla «el coste».

Es preguntar qué costes eran evitables con un parcheo anterior, cuáles se incurrieron por la contención necesaria, cuáles fueron inversiones que deberían haberse hecho antes y cuáles recayeron en pacientes y personal sin aparecer nunca en un presupuesto de TI.

Los proveedores pequeños y medianos se encuentran dentro de esa misma cuestión. El problema es la continuidad en las organizaciones más pequeñas que se conectan a un servicio nacional: consultas de medicina general, centros de cuidados paliativos, proveedores comunitarios, contratistas, proveedores de dispositivos, socios locales de soporte informático e interfaces de atención social. La NAO contabilizó organizaciones de atención primaria y otras entre las entidades infectadas y señaló que otros proveedores podrían verse afectados a través de sistemas compartidos o información retrasada.

Por lo tanto, un ciberincidente en una gran institución pública se convierte en un choque de continuidad para las organizaciones más pequeñas que tienen menos redundancia y menos visibilidad política.

La atribución no responde a la pregunta operativa

El Reino Unido atribuyó posteriormente WannaCry a Corea del Norte. La declaración del Foreign Office sobre elactor norcoreano detrás de WannaCryafirmó que el Reino Unido consideraba que los actores norcoreanos conocidos como Lazarus Group estaban detrás de la campaña. Esa atribución es importante para la disuasión, las sanciones, la diplomacia y la seguridad nacional. No exime del control operativo nacional. El mismo registro público dice que el NHS no fue el objetivo específico, que el gusano se propagó a través de una vulnerabilidad conocida de Windows y que las organizaciones locales podrían haber tomado medidas relativamente sencillas para protegerse.

La responsabilidad penal y la responsabilidad de servicio público son capas separadas. El atacante controlaba el código malicioso y la decisión de desplegarlo. Microsoft controlaba la divulgación de la vulnerabilidad y la publicación del parche para sus productos, y luego la decisión extraordinaria de poner parches a disposición para plataformas sin soporte durante la emergencia. NHS Digital controlaba las alertas, la orientación, el soporte telefónico y el asesoramiento específico del sector. NHS England controlaba la coordinación de incidentes graves y la escalada de la continuidad asistencial.

El Department of Health controlaba la supervisión de políticas y las prioridades de financiación. Los trusts y consultas locales controlaban muchas decisiones sobre dispositivos, redes, proveedores y gestión de cambios. Los proveedores controlaban algunos dispositivos heredados, las condiciones de soporte y las restricciones de compatibilidad.

Ninguna capa por sí sola cuenta toda la historia. Tratar el incidente solo como un evento de Estado hostil lo aleja demasiado de la gestión local. Tratarlo solo como un incumplimiento local ignora el hecho de que los organismos nacionales habían visto señales de advertencia y no tenían suficiente poder de aplicación o garantía. Tratarlo solo como un problema de Microsoft ignora que el parche crítico existía antes del incidente y que no aplicar parches es una elección operativa. Tratarlo solo como un problema de proveedores ignora que los sistemas Windows con soporte también estaban sin parchear.

La rendición de cuentas es el mapa de estos controles, no una búsqueda de un actor que pueda cargar con todos ellos.

El control más importante era la evidencia. ¿Quién conocía el estado de los parches? ¿Quién sabía cuál era el estado de exposición SMB? ¿Quién sabía qué sistemas no tenían soporte? ¿Quién sabía qué dispositivos médicos no podían parchearse sin la intervención del proveedor? ¿Quién sabía si un trust local había probado su plan de emergencia cibernética? ¿Quién sabía con qué rapidez las consultas de medicina general podían pasar a un funcionamiento manual seguro? El registro público muestra que muchas de esas respuestas no estaban disponibles, estaban incompletas o no eran procesables a nivel central antes del ataque.

El programa posterior al incidente confirma el diagnóstico

El registro de medidas correctoras tras WannaCry es útil porque muestra lo que los líderes nacionales pensaban que había fallado. La revisión de lecciones de NHS England recomendó un liderazgo más fuerte y una mayor rendición de cuentas de los consejos de administración, funciones más claras, estándares de ciberseguridad, resiliencia local, mejor parcheo, sustitución de software sin soporte, mejora de los procesos de respuesta y una coordinación nacional más sólida. La actualización de progreso de 2018 del Department describió el trabajo en materia de respuesta a incidentes graves, operaciones de ciberseguridad, estándares de seguridad de datos, expectativas de los proveedores e inversión. ElData Security and Protection Toolkit, que sustituyó al anterior Information Governance Toolkit a partir de abril de 2018, se convirtió en un mecanismo de autoevaluación en línea para que las organizaciones con acceso a datos de pacientes y sistemas del NHS midieran y publicaran su rendimiento en relación con los diez estándares de seguridad de datos de la National Data Guardian.

Ese conjunto de herramientas no es una prueba de que el problema haya desaparecido. La autoevaluación tiene limitaciones, y los ciberincidentes posteriores en los sistemas de salud muestran que el ransomware y las interrupciones de proveedores seguían siendo riesgos graves. Pero es una evidencia de que el sistema posterior a WannaCry avanzó hacia una garantía explícita en lugar de limitarse a la orientación informal. También sacó la ciberseguridad del carril puramente técnico y la llevó a la rendición de cuentas a nivel de consejo de administración, la notificación de incidentes y la continuidad.

La estrategia gubernamental posterior,A cyber resilient health and adult social care system in England, extiende ese marco hasta 2030. Describe la ciberseguridad como una condición para proteger los datos de pacientes, usuarios de servicios y personal, y para recuperarse rápidamente cuando se producen ataques. La existencia de la estrategia refuerza la lección central de 2017: en la atención sanitaria, la ciberseguridad no es una disciplina de back-office separada. Sustenta la confianza pública y la continuidad del servicio.

El papel público más amplio del National Cyber Security Centre también creció durante este período. Suanuncio de la revisión anual de 2017describió el primer año del nuevo centro y su misión de hacer del Reino Unido un lugar más seguro en línea. La respuesta a WannaCry hizo que esa misión fuera concreta para hospitales y clínicas. Demostró que la capacidad cibernética nacional debía conectarse con las operaciones específicas del sector, y no limitarse a publicar advertencias para los equipos técnicos.

Cinco pruebas de rendición de cuentas

El valor perdurable del caso del NHS es que ofrece a los consejos de administración y a los líderes del sector público pruebas prácticas. Estas pruebas no consisten en culpar a un administrador por un parche. Se trata de si un servicio público puede demostrar que un riesgo cibernético conocido se ha convertido en acción operativa.

1. Visibilidad de activos:Una organización no puede parchear lo que no puede identificar. Necesita un inventario de servidores, puntos finales, dispositivos médicos, sistemas sin soporte, versiones de sistemas operativos, servicios expuestos, proveedores y dependencias clínicas. El inventario debe incluir sistemas que es incómodo poseer, como estaciones de trabajo de diagnóstico antiguas, servidores de archivos compartidos y máquinas controladas en parte por proveedores.

2. Garantía de parcheo:Emitir una advertencia no es suficiente. Una alerta crítica debe crear acciones con seguimiento, plazos, escalada ejecutiva, excepciones identificadas, controles compensatorios y evidencia de que el parche se ha instalado o la exposición se ha controlado de otro modo. Cuando la autonomía local bloquea los mandatos centrales, el centro necesita al menos una visibilidad fiable y una vía para escalar el riesgo para la seguridad del paciente.

3. Contención de sistemas heredados:Los sistemas sin soporte o difíciles de parchear requieren segmentación, restricciones de acceso, planes de proveedores, financiación para la sustitución y contingencia clínica. Dejar un sistema sin soporte es a veces una necesidad clínica temporal, pero no debería ser un hecho no gestionado que se descubre durante un brote de gusano.

4. Continuidad específica para ciberincidentes:La planificación de emergencias debe asumir que los sistemas normales de comunicación y registro pueden no estar disponibles. El recurso manual necesita una planificación de la capacidad, no solo formularios en papel. Debe especificar qué servicios clínicos se degradan primero, cómo se desvía a los pacientes, cómo se mueven los resultados de las pruebas, cómo se reprograman las citas y cómo se concilia el trabajo sin conexión de forma segura.

5. Rendición de cuentas multinivel:El centro, los organismos locales, los proveedores y las agencias de seguridad nacional tienen controles diferentes. Un marco maduro no colapsa esos controles en una única historia de culpa. Define quién debe actuar, quién debe verificar, quién debe financiar, quién debe comunicar y quién debe aceptar el riesgo residual.

Estas pruebas son incómodas porque hacen que la resiliencia cibernética sea mensurable. También protegen al personal de expectativas imposibles. Durante WannaCry, el personal del NHS trabajó horas extraordinarias e improvisó para mantener los servicios en funcionamiento. La revisión de lecciones reconoció públicamente esos esfuerzos. La respuesta local heroica no debe utilizarse como prueba de que la preparación era adecuada. A menudo es una prueba de que el sistema formal dejó demasiado trabajo a personas bajo presión.

El límite de la responsabilidad legal

Las fuentes públicas respaldan una fuerte crítica operativa. No respaldan conclusiones legales no fundamentadas contra un trust, ejecutivo, proveedor u organismo nacional concretos. Los registros del PAC, la NAO, NHS England, el DHSC, la CQC, el NCSC, Microsoft y los académicos establecen advertencias, fallos de garantía, sistemas sin parchear, interrupción del servicio y reformas posteriores al incidente. No demuestran negligencia en todas las organizaciones locales, no cuantifican todas las pérdidas ni muestran exactamente qué dispositivos fueron responsables de cada cita cancelada.

Ese límite es importante porque la lección de rendición de cuentas es más amplia que el litigio. Si los líderes reducen el caso a una batalla legal sobre si una entidad incumplió un deber, pierden de vista el diseño de control. La cuestión de servicio público es si el NHS podía saber, antes de un ciberevento nacional, que cada organización había cerrado o gestionado conscientemente una vulnerabilidad crítica conocida. La respuesta en 2017 fue no.

La cuestión de continuidad asistencial es si todas las organizaciones afectadas habían ensayado una interrupción cibernética lo suficientemente bien como para mantener los servicios esenciales en funcionamiento a una capacidad degradada conocida. El registro público dice que esos acuerdos no se habían probado suficientemente.

Por lo tanto, WannaCry sigue siendo un caso de rendición de cuentas pública porque conectó un retraso en el mantenimiento técnico con la resiliencia de cara al paciente. El riesgo tenía nombres: MS17-010, SMBv1, sistemas operativos sin soporte, planes de incidentes no probados, organismos locales sin garantía de cumplimiento central, redes compartidas y sistemas clínicos que no podían apagarse sin más. Pero el daño tenía otros nombres: citas canceladas, pacientes desviados, registros no disponibles, información retrasada, horas extraordinarias del personal y una estimación de 92 millones de libras en corrección e interrupción.

La forma más responsable de recordar el incidente no es como una moraleja sobre el software antiguo. Es una advertencia de que las instituciones públicas pueden saber lo suficiente como para estar preocupadas y aun así no saber lo suficiente como para estar preparadas. Un parche puede existir. Se puede enviar una alerta. Un consejo de administración puede recibir formación en ciberseguridad. Se puede redactar un plan.

Si la organización no puede demostrar que los sistemas vulnerables están parcheados, aislados, sustituidos o se les ha dado una solución alternativa segura, entonces el riesgo lo siguen soportando los pacientes, el personal y los proveedores más pequeños que solo descubren la dependencia cuando el servicio se detiene.