Resumen

  • Confirmado:WannaCry afectó a los servicios del NHS en Inglaterra del 12 de mayo al 19 de mayo de 2017. La National Audit Office informó que al menos 80 de 236 trusts resultaron infectados o interrumpidos, 34 trusts fueron infectados y bloqueados de sus dispositivos, 46 trusts no fueron infectados pero informaron de interrupciones, y otras 603 organizaciones de atención primaria y otras entidades del NHS resultaron infectadas, incluidas 595 consultas de médicos de cabecera.
  • Confirmado:NHS England identificó 6,912 citas canceladas durante la ventana de respuesta al incidente y estimó más de 19,000 cancelaciones en total. Cinco servicios de urgencias desviaron pacientes. NHS Digital declaró a la NAO que no se vieron comprometidos ni se robaron datos de pacientes, y el Department of Health, NHS England y la National Crime Agency declararon a la NAO que ninguna organización del NHS pagó el rescate.
  • Alcance:El registro público respalda un fallo de parcheo y aseguramiento, 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 del NHS infectados ejecutaban Windows 7 compatible pero sin parchear, y que los dispositivos con XP sin soporte representaban una minoría de los dispositivos infectados.
  • Evaluación:El fallo responsable no fue solo la deuda técnica. Fue la combinación de visibilidad de activos, despliegue de parches, gestión de dispositivos sin soporte, autonomía local de los trusts, organismos nacionales sin un mecanismo de cumplimiento previo al incidente, respuesta cibernética local no probada y procesos de continuidad asistencial que se vieron forzados a recurrir al papel y la coordinación manual.

Un parche puede emitirse sin estar gobernado

La versión corta de la historia WannaCry del NHS 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. La aplicación de parches es un sistema de gobierno. Requiere registros de activos, priorización del riesgo, 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 contaba con directrices, advertencias y soporte técnico, pero no tenía la seguridad suficiente de que esas directrices se hubieran convertido en protección.

Microsoft publicóel boletín de seguridad 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 podrían permitir la ejecución remota de código si un atacante enviaba mensajes manipulados a un servidor de Microsoft Server Message Block 1.0. Microsoft explicó más tarde en suguía para clientes sobre WannaCryptque la actualización de marzo abordaba la vulnerabilidad explotada, que las organizaciones con actualizaciones automáticas activadas 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 que afectaba a equipos que no habían aplicado el parche. (Blog de seguridad de Microsoft)

La alerta archivada de NHS Digital,CC-1411, enmarcó el mismo riesgo en el lenguaje del sector sanitario. Identificó el ransomware como aquel que utilizaba las vulnerabilidades SMB parcheadas en MS17-010, advirtió que era probable que futuras variantes de malware utilizaran esas vulnerabilidades para la autopropagación y recomendó priorizar la aplicación de parches en las versiones afectadas. También enumeró pasos de remediació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 los dominios de interruptor de seguridad, poner en cuarentena los dispositivos infectados, reconstruir los equipos infectados con un estándar parcheado y no pagar el rescate.

Esos detalles importan porque demuestran que la respuesta técnica no era algo oscuro para el 12 de mayo. La cuestión más difícil es si los controles nacionales y locales habían hecho que la respuesta fuera operativamente inevitable. Lainvestigación de la National Audit Officeinformó de que NHS Digital había emitido alertas críticas en marzo y abril de 2017 advirtiendo a las organizaciones que aplicaran parches a 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 con sus consejos y directrices. NHS Digital había evaluado in situ 88 de los 236 trusts y ninguno había superado su evaluación de ciberseguridad, pero NHS Digital no podía obligar a un organismo local a tomar medidas correctivas.

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 experimentaron el sistema combinado, no la frontera entre una alerta central y una ventana de parcheo local.

Lo que establece el registro

WannaCry comenzó 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 mayor y puso en marcha disposiciones de emergencia para mantener la atención sanitaria y el cuidado de los pacientes. Un investigador de seguridad activó un interruptor de seguridad esa misma noche, impidiendo que WannaCry bloqueara más dispositivos de la misma manera. El ataque afectó a los servicios del NHS durante la semana del 12 al 19 de mayo.

La escala en Inglaterra fue significativa pero no completamente mensurable. Según la NAO, al menos 80 de los 236 trusts de Inglaterra se vieron afectados porque estaban infectados o apagaron sistemas como medida de precaución. De ellos, 34 se infectaron y quedaron bloqueados de sus dispositivos, incluidos 25 trusts de agudos. Otros 46 informaron de interrupciones sin ser catalogados como infectados; algunos apagaron el correo electrónico y otros sistemas como precaución y tuvieron que utilizar papel y bolígrafo para actividades que normalmente se realizaban electrónicamente. 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 otras entidades resultaron infectadas, incluidas 595 consultas de médicos de cabecera.

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 médicos de cabecera 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 del 12 al 18 de mayo, pero la NAO afirmó que los datos no cubrían todos los tipos de citas. Por lo tanto, las 6,912 cancelaciones identificadas 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 Director de Información de Salud y Asistencia Social, mantuvo el mismo marco añadiendo textura operativa. Señaló que el NHS no fue un objetivo directo, 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 afirmó que 80 de 236 trusts hospitalarios se vieron afectados, 595 de 7,454 consultas de médicos de cabecera y otras ocho organizaciones del NHS y relacionadas resultaron infectadas, y la interrupción hizo más evidente la dependencia del servicio de salud de las tecnologías de la información.

Esa ú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 rendimiento clínico, la comunicación, el acceso a diagnósticos, el flujo de citas y la escalada segura.

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

A menudo se cuenta WannaCry como una advertencia sobre Windows XP. El software sin soporte importaba. Era un riesgo conocido, y el Department y el Cabinet Office habían escrito a los trusts en 2014 diciéndoles que necesitaban planes sólidos para migrar desde software antiguo como Windows XP antes de abril de 2015. Larevisión de la National Data Guardian, publicada en julio de 2016, propuso nuevos estándares de seguridad de datos y un método para verificar su cumplimiento. La revisiónSafe Data, Safe Care de 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 estrictas y la asunción de la propiedad de la seguridad de los datos por parte de los directivos.

Pero el eslogan del sistema sin soporte es demasiado limitado. La revisión de lecciones aprendidas de NHS England señaló que ninguna de las 80 organizaciones del NHS afectadas había aplicado el parche de Microsoft recomendado por el boletín CareCERT de NHS Digital el 25 de abril de 2017. También afirmó que WannaCry fue un ataque que utilizaba una vulnerabilidad específica de Microsoft Windows, no un ataque contra el software sin soporte. La mayoría de los dispositivos del NHS infectados ejecutaban Windows 7, compatible pero sin parchear. Los dispositivos con XP sin soporte representaban una minoría de los dispositivos infectados, y el número de dispositivos con XP había disminuido del 18% al 1,8% en enero de 2018.

La distinción es importante para la responsabilidad. Si el fallo fuera solo "sistemas operativos antiguos", la respuesta sería financiación para su sustitución y presión a los proveedores. Esos eran problemas reales, especialmente cuando el equipo médico o los dispositivos de diagnóstico dependían de software más antiguo. Pero si las máquinas con Windows 7 compatible permanecían sin parchear tras una alerta crítica, entonces la respuesta incluye también el gobierno del parcheo, la gestión de excepciones y la prueba de cierre. Un dispositivo compatible puede ser inseguro cuando no está parcheado. Un dispositivo sin soporte puede aislarse o gestionarse en un modelo de control compensatorio. 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 aprendidas también señaló que los controles de firewall y red podrían haber reducido el riesgo de infección. Dijo que incluso donde no se había aplicado el parche, la mejora de la seguridad de los firewalls de red que dan a la red N3 habría protegido a las organizaciones contra la infección. Esa es otra razón para no tratar el parcheo como un interruptor único. El parcheo era necesario, pero también lo era 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 WannaCry del NCSC, ahora marcada como retirada por estar desactualizada, recogía la lógica defensiva de emergencia de la época. Aconsejaba a las organizaciones desplegar MS17-010, deshabilitar SMBv1 si no era posible aplicar el parche, bloquear los puertos relevantes cuando fuera necesario, aislar la tecnología heredada vulnerable, actualizar el antivirus y evitar bloquear los dominios del interruptor de seguridad. En otras palabras, la respuesta inmediata requería un conjunto de controles en capas. Las organizaciones que carecían de listas de activos claras, propiedad del firewall, opciones de DNS locales, contactos con proveedores y procedimientos de reconstrucción probados, no podían ejecutar fácilmente esa respuesta en capas bajo la presión de una emergencia.

La autonomía local dificultaba la garantía central

El NHS no es un único parque informático monolítico. Los trusts locales, las consultas de médicos de cabecera, los grupos de contratación clínica, los proveedores, las unidades de apoyo a la contratación y otras organizaciones operan dentro de marcos nacionales pero tienen muchas responsabilidades locales. La NAO afirmó 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 los 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é sitios están expuestos, cuáles han aceptado el riesgo, cuáles tienen controles compensatorios y cuáles no pueden actuar porque un proveedor, presupuesto o dependencia clínica bloquea la solución.

El comentario 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 convirtió en una reducción del riesgo en todo el sistema. Una alerta nacional puede decir "parchee ahora". No puede por sí sola demostrar que todos los puntos relevantes tienen 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.

Elinforme del Public Accounts Committeehizo política de esa misma debilidad. Dijo que había habido advertencias en 2016 y más advertencias en marzo y abril de 2017, pero el parcheo solo se había llevado a cabo en alrededor de 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 aprendidas 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ó.

Esa 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 médico de cabecera 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 circuitos de evidencia más sólidos precisamente porque el servicio público parece unificado en el momento de la necesidad.

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

El daño visible de WannaCry fue la interrupción. Algunas organizaciones se infectaron y quedaron bloqueadas. Otras apagaron sistemas para reducir el riesgo. Algunas utilizaron papel. Otras no pudieron recibir resultados de pruebas ni acceder a registros compartidos. A algunos pacientes se les cancelaron citas u operaciones. Cinco zonas desviaron pacientes de urgencias. La NAO se cuidó de decir que no todas las categorías se contabilizaron por completo, y la revisión de NHS England informó de que no se conocían daños a pacientes. Esos límites deben respetarse. La ausencia de daños notificados no es una prueba de que no existiera ningún riesgo clínico, pero el registro público no respalda la invención de un número de víctimas mortales ni un robo oculto de datos de pacientes.

La lente de rendición de cuentas más útil es la capacidad de continuidad. Los servicios de salud 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, rutas seguras de transferencia, soluciones para la solicitud de 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 recuperación de los sistemas. Cada alternativa tiene un perfil de rendimiento y error. Una consulta que puede gestionar 20 excepciones manuales puede no 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 aprendidas de NHS England reconoció la diferencia entre un incidente cibernético y un incidente mayor convencional. Dijo que NHS England utilizó su marco de Preparación, Resiliencia y Respuesta ante Emergencias, que proporcionó una estructura sólida, pero que el incidente también enseñó lecciones sobre en qué se diferencia lo cibernético de otros incidentes mayores. Lo cibernético puede hacer que las propias herramientas de comunicación no sean fiables. Puede afectar a múltiples sitios simultáneamente. Al principio puede no estar claro si un sitio está infectado, desconectado o actuando a la defensiva. Puede requerir acciones técnicas de contención que reduzcan la capacidad del servicio. También puede propagarse a través de redes compartidas, por lo que ayudar a una organización puede depender de cómo se comporte otra.

Por eso la rendición de cuentas no debe terminar en el dispositivo al que le faltaba un parche. El sistema asistencial necesitaba una forma probada de responder a preguntas básicas de continuidad en condiciones cibernéticas. ¿Qué servicios deben mantenerse en funcionamiento aunque el correo electrónico esté fuera de línea? ¿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 descubrió que el NHS no había realizado simulacros para un ciberataque nacional, por lo que no estaba inmediatamente claro quién debía liderar la respuesta y hubo problemas de comunicación. No se trata de una laguna de proceso menor. En la continuidad cibernética, los simulacros son la forma en que las organizaciones descubren si las listas de contactos funcionan, si los formularios en papel existen, si las listas de pacientes fuera de línea son suficientemente recientes, si los proveedores responden y si los clínicos entienden qué sistemas son seguros para volver a conectar.

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 organizaciones. Un trust podía evitar la infección directa y aún así perder el acceso a un proceso de transferencia de ambulancias, a la transferencia de imágenes diagnósticas, a una vía de prescripción de quimioterapia, al flujo de resultados de sangre o a la carga de trabajo de atención primaria porque otro proveedor, suministrador o socio de red cerró el acceso para protegerse a sí mismo. Se trata de una contención local racional, pero crea consecuencias regionales para el servicio.

El posteriorestudio de caso sobre WannaCry del kit de herramientas de gestión de continuidad del negocio de NHS Englandlo 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, deshabilitando las pantallas del proceso de transferencia e inutilizando un portal de reserva de transporte de pacientes. Los centros terciarios cerraron el acceso, lo que significó que las tomografías computarizadas y las resonancias magnéticas no se pudieran transferir electrónicamente y las órdenes de quimioterapia no se pudieran transferir a través de la ruta habitual. El proveedor de TI de atención primaria protegió su red, tras lo cual falló la transferencia automática de resultados de sangre 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 se realizaron por teléfono. Las imágenes se transfirieron a DVD y se enviaron en taxi. Las órdenes de quimioterapia volvieron al papel y al fax. Las transferencias de resultados de sangre pasaron al papel y ralentizaron el proceso. Algunos médicos de cabecera accedieron a las cargas de trabajo a través de centros de tratamiento urgente. El estudio de caso decía que los planes de continuidad del negocio se actualizaron posteriormente y concluía que las organizaciones del NHS necesitan entender sus interdependencias y coordinar los planes de los servicios compartidos para minimizar el impacto en la economía de la salud.

Este es exactamente el tipo de evidencia que los recuentos generales de incidentes pasan por alto. Un incidente cibernético 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 sustituye al intercambio electrónico ordinario de imágenes en una región concurrida. 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 aumenta. Las órdenes 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 del proveedor y del socio es importante para las organizaciones más pequeñas. Una consulta de médico de cabecera, un hospicio, 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 a la contratación, de un sistema clínico alojado, de una interfaz de patología, de un socio de diagnóstico o de una ruta de red controlada por otra persona. Cuando esa dependencia se desconecta, la organización más pequeña debe seguir atendiendo 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 diga 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 derivante ya debe conocer 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 transferencia de ambulancias no están disponibles, los servicios de urgencias y los servicios de ambulancias necesitan una alternativa compartida que se haya ensayado. El estudio de caso del NHS tiene un 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 más amplio 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 extra, el soporte informático, la restauración, la atención diferida, el esfuerzo de los proveedores y la remediación posterior. La NAO dijo 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 informáticos, restauración de datos y sistemas, y horas extra del personal durante la respuesta del fin de semana.

La posterior actualización del Department of Health and Social Care,Securing cyber resilience in health and care: actualización de progreso de octubre de 2018, enlazaba con elPDF detallado de actualización de septiembre de 2018. Esta actualización se cita ampliamente por la estimación de que WannaCry le costó al NHS 92 millones de libras, incluyendo la respuesta directa y la recuperación informática, así como la producción perdida. Esa estimación debe utilizarse con cuidado. Es una estimación de costes del sector público, no una contabilidad completa de la ansiedad de los pacientes, el tiempo de las familias, el movimiento de ambulancias, la carga para los proveedores locales o cada hora del personal.

El trabajo académico también muestra por qué el impacto es difícil de cuantificar. Unanálisis de impacto retrospectivo de npj Digital Medicine de 2019utilizó las Estadísticas de Episodios Hospitalarios (Hospital Episode Statistics) para examinar cancelaciones, ingresos, asistencias a urgencias, mortalidad y costes fiscales. Descubrió que no había 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 pérdida de actividad hospitalaria en los trusts infectados. También señaló que no hubo aumento de la mortalidad, advirtiendo al mismo tiempo 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 perdida en los infectados y una estimación más amplia de 92 millones de libras del sector público no es necesariamente una contradicción. Miden cosas diferentes. Una analiza la actividad en los hospitales infectados durante un período definido utilizando datos hospitalarios. La otra incluye una respuesta, recuperación y remediación informática más amplias. A efectos de rendición de cuentas, el punto importante no es elegir la cifra más grande y llamarla "el coste". Es preguntarse qué costes eran evitables mediante un parcheo más temprano, cuáles se incurrieron por la contención necesaria, cuáles fueron inversiones que deberían haberse hecho antes y cuáles recayeron sobre pacientes y personal sin aparecer nunca en un presupuesto de TI.

Los proveedores pequeños y medianos se encuentran dentro de esa misma pregunta. La cuestión es la continuidad en todas las organizaciones más pequeñas que se conectan a un servicio nacional: consultas de médicos de cabecera, hospicios, proveedores comunitarios, contratistas, proveedores de dispositivos, socios locales de soporte informático e interfaces de asistencia social. La NAO contabilizó las 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 incidente cibernético en una gran institución pública se convierte en un shock 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ó más tarde WannaCry a Corea del Norte. La declaración del Foreign Office sobre elactor norcoreano detrás de WannaCrydijo 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 interno. 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 del 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 de plataformas sin soporte durante la emergencia. NHS Digital controlaba las alertas, las directrices, el soporte telefónico y el asesoramiento específico del sector. NHS England controlaba la coordinación de incidentes mayores 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 limitaciones de compatibilidad.

Ninguna capa 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 que los organismos nacionales habían visto señales de advertencia y no tenían suficiente poder de ejecución o aseguramiento. 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 decisión operativa. Tratarlo solo como un problema de los 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 la 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 conocía 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 médicos de cabecera 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 después de WannaCry es útil porque muestra lo que los líderes nacionales pensaban que había fallado. La revisión de lecciones aprendidas de NHS England recomendó un liderazgo más fuerte y una rendición de cuentas a nivel de consejo, 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 mayores, 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 los datos y sistemas de pacientes 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 incidentes cibernéticos posteriores en los sistemas de salud demuestran que el ransomware y las interrupciones de los proveedores siguen siendo riesgos graves. Pero es una prueba de que el sistema posterior a WannaCry se movió hacia un aseguramiento explícito en lugar de solo directrices informales. También sacó lo cibernético del carril puramente técnico y lo llevó a la rendición de cuentas a nivel de consejo, la notificación de incidentes y la continuidad.

La estrategia gubernamental posterior,Un sistema de salud y asistencia social para adultos ciberresiliente en Inglaterra, extiende ese marco hasta 2030. Describe la ciberseguridad como una condición para proteger los datos de los pacientes, los usuarios de los servicios y el personal, y para recuperarse rápidamente cuando se producen ataques. La existencia de la estrategia refuerza la lección fundamental de 2017: en la asistencia 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 2017describía 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 concreta esa misión para hospitales y clínicas. Demostró que la capacidad cibernética nacional tenía que conectarse a las operaciones específicas del sector, 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 los 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 sistema operativo, servicios expuestos, proveedores y dependencias clínicas. El inventario debe incluir sistemas cuya propiedad resulta incómoda, 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 generar acciones con seguimiento, plazos, escalada ejecutiva, excepciones nominativas, 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 los sistemas heredados:Los sistemas sin soporte o difíciles de parchear requieren segmentación, restricciones de acceso, planes de proveedores, financiación para su 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 el ámbito cibernético:La planificación de emergencias debe asumir que los sistemas normales de comunicación y registro pueden no estar disponibles. El recurso manual al papel 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 fuera de línea 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 reduce esos controles a 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 extras e improvisó para mantener los servicios en funcionamiento. La revisión de lecciones aprendidas reconoció públicamente esos esfuerzos. La heroica respuesta local 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 concreto. Los registros del PAC, la NAO, NHS England, DHSC, CQC, NCSC, Microsoft y los académicos establecen advertencias, falta de aseguramiento, sistemas sin parchear, interrupción del servicio y reformas posteriores al incidente. No prueban negligencia en cada organización local, ni 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 disputa legal sobre si una entidad incumplió un deber, pierden de vista el diseño del control. La cuestión de servicio público es si el NHS podía saber, antes de un evento cibernético 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 preparativos no se probaron 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 se podían apagar sin más. Pero el daño tenía otros nombres: citas canceladas, pacientes desviados, registros no disponibles, información retrasada, horas extras del personal y una estimación de 92 millones de libras en remediación e interrupción.

La forma más responsable de recordar el incidente no es como una fábula moral sobre el software antiguo. Es una advertencia de que las instituciones públicas pueden saber lo suficiente para estar preocupadas y aun así no saber lo suficiente para estar preparadas. Un parche puede existir. Una alerta puede enviarse. Un consejo puede recibir formación en ciberseguridad. Un plan puede redactarse. Si la organización no puede demostrar que los sistemas vulnerables están parcheados, aislados, sustituidos o compensados de forma segura, entonces el riesgo sigue recayendo sobre pacientes, personal y proveedores más pequeños que solo descubren la dependencia cuando el servicio se detiene.