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 afectados, 34 trusts fueron infectados y bloqueados de sus dispositivos, 46 trusts no fueron infectados pero reportaron interrupciones, y otros 603 organismos de atención primaria y otras organizaciones del NHS fueron infectados, incluyendo 595 consultorios de médicos de cabecera.
- Confirmado:NHS England identificó 6912 citas canceladas durante la ventana de respuesta al incidente y estimó más de 19 000 cancelaciones en total. Cinco departamentos de urgencias desviaron pacientes. NHS Digital informó a la NAO que no se comprometió ni robó datos de pacientes, y el Departamento, NHS England y la National Crime Agency informaron a la NAO que ninguna organización del NHS pagó el rescate.
- Límite:El registro público respalda un fallo de parcheo y de aseguramiento, pero no apoya una simple afirmación de que Windows XP por sí solo causó la interrupción del NHS. La revisión de lecciones aprendidas de NHS England dijo que el ataque explotó una vulnerabilidad de Microsoft Windows, que la mayoría de los dispositivos infectados del NHS ejecutaban Windows 7 compatible pero sin parchear, y que los dispositivos XP no compatibles eran una minoría de los dispositivos infectados.
- Evaluación:El fracaso responsable no fue solo una deuda técnica. Fue la combinación de visibilidad de activos, implementación de parches, gestión de dispositivos no compatibles, 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 coordinación manual y en papel.
Un parche puede emitirse sin ser gobernado
La versión más corta de la historia del WannaCry en el NHS es que existía un parche de Microsoft antes del ataque y que demasiadas organizaciones del NHS no lo habían aplicado. Esa frase es cierta, pero oculta el problema de la 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 de 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 tenía orientación, advertencias y apoyo técnico, pero no tenía suficiente seguridad de que la orientación se hubiera convertido en protección.
Microsoft publicó elboletín de seguridad MS17-010el 14 de marzo de 2017. El boletín calificó el problema como crítico y dijo que las vulnerabilidades más graves podrían permitir la ejecución remota de código si un atacante enviaba mensajes especialmente diseñados a un servidor de Microsoft Server Message Block 1.0. Microsoft explicó más tarde en suguía para clientes de WannaCryptque la actualización de marzo abordaba la vulnerabilidad explotada, que las organizaciones con actualizaciones automáticas habilitadas estaban protegidas contra esa vulnerabilidad, y que Microsoft tomó la inusual medida de poner actualizaciones ampliamente disponibles para plataformas más antiguas como Windows XP, Windows 8 y Windows Server 2003. Su blog de seguridad describió WannaCrypt como un gusano que utiliza vulnerabilidades que ya habían sido corregidas, afectando a ordenadores 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 lenguaje del sector sanitario. Identificó el ransomware como el que utiliza vulnerabilidades de SMB parcheadas en MS17-010, advirtió que era probable que las vulnerabilidades fueran utilizadas por futuras variantes de malware para autopropagarse, y dijo que se debía priorizar el parcheo de las versiones afectadas. También enumeró pasos de remediación como bloquear puertos relacionados con SMB, confirmar el bloqueo de puertos, actualizar plataformas vulnerables, usar escáneres de vulnerabilidades, mantener la conectividad con el dominio de interrupción, poner en cuarentena los dispositivos infectados, reconstruir las máquinas infectadas con un estándar parcheado y no pagar el rescate.
Esos detalles importan porque muestran que la respuesta técnica no era oscura para el 12 de mayo. La pregunta 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ó 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ó que antes del ataque, el Departamento de Salud no tenía un mecanismo formal para evaluar si las organizaciones del NHS habían cumplido con sus consejos y orientación. NHS Digital había evaluado a 88 de 236 trusts in situ, y ninguno había aprobado su evaluación de ciberseguridad, pero NHS Digital no podía exigir a una entidad local que tomara 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 el límite 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ó que el ataque global de ransomware afectó a más de 200.000 ordenadores en al menos 100 países, y que el NHS no fue el objetivo específico. A las 4 p. m. de ese día, NHS England declaró un incidente mayor e implementó arreglos de emergencia para mantener la salud y la atención al paciente. Un investigador de seguridad activó un kill switch esa noche, deteniendo que WannaCry bloqueara más dispositivos de la misma manera. El ataque afectó los servicios del NHS durante la semana del 12 de mayo al 19 de mayo.
La escala en Inglaterra fue significativa pero no completamente medible. Según la NAO, al menos 80 de 236 trusts en toda Inglaterra se vieron afectados porque estaban infectados o apagaron sistemas como precaución. De esos, 34 fueron infectados y bloqueados de sus dispositivos, incluyendo 25 trusts de agudos. Otros 46 reportaron interrupciones sin ser categorizados como infectados; algunos cerraron el correo electrónico y otros sistemas como precaución y tuvieron que usar papel y bolígrafo para actividades normalmente realizadas electrónicamente.
NHS England y NHS Digital también identificaron 21 trusts cuyos sistemas intentaron contactar el dominio de WannaCry pero no fueron bloqueados, y otros 603 organismos de atención primaria y otras organizaciones fueron infectados, incluyendo 595 consultorios de médicos de cabecera.
El registro público es igualmente claro sobre lo que se desconoce. El Departamento y NHS England no conocían la extensión completa 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 fueron canceladas, ni cuántas ambulancias y pacientes fueron desviados de los cinco departamentos de urgencias que no podían tratar a algunos pacientes. NHS England recopiló algo de información sobre cancelaciones del 12 de mayo al 18 de mayo, pero la NAO dijo que los datos no cubrían todos los tipos de citas.
Las 6912 cancelaciones identificadas y las más de 19 000 cancelaciones totales estimadas no son, por lo tanto, un registro completo del impacto en los pacientes.
Larevisión de lecciones aprendidas de NHS England, liderada por el Director de Información de Salud y Atención Social, mantuvo el mismo marco mientras agregó textura operativa. Dijo que el NHS no fue atacado directamente, que no hubo informes de daño a pacientes ni de datos de pacientes comprometidos o robados, 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 7454 consultorios de médicos de cabecera y otras ocho organizaciones del NHS y relacionadas fueron infectados, y la interrupción hizo más clara la dependencia del servicio de salud de la tecnología 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 dañó la continuidad de la atención. En un hospital digital, la disponibilidad no es una capa de conveniencia. Es parte del rendimiento clínico, la comunicación, el acceso a diagnósticos, el flujo de citas y la escalada segura.
Los sistemas no compatibles fueron parte de la historia, no toda la historia
WannaCry a menudo se cuenta como una advertencia sobre Windows XP. El software no compatible importaba. Había sido un riesgo conocido, y el Departamento y la Cabinet Office habían escrito a los trusts en 2014 diciendo que necesitaban planes sólidos para migrar desde software antiguo como Windows XP para 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 probar el cumplimiento. Larevisión Safe Data, Safe Care de la Care Quality Commission, también publicada en julio de 2016, recomendó el reemplazo urgente de hardware y software que ya no pudieran recibir soporte, una auditoría y validación más sólidas, y la propiedad de la seguridad de datos por parte del liderazgo.
Pero un eslogan de sistemas no compatibles es demasiado estrecho. La revisión de lecciones de NHS England dijo que ninguna de las 80 organizaciones del NHS afectadas había aplicado el parche de actualización de Microsoft recomendado por el boletín CareCERT de NHS Digital del 25 de abril de 2017. También dijo que WannaCry fue un ataque que utilizó una vulnerabilidad específica de Microsoft Windows, no un ataque a software no compatible. La mayoría de los dispositivos infectados del NHS ejecutaban Windows 7 compatible pero sin parchear.
Los dispositivos XP no compatibles estaban en la minoría de los dispositivos infectados, y el número de dispositivos XP había disminuido del 18% al 1.8% en enero de 2018.
La distinción importa para la responsabilidad. Si el fallo fuera solo "sistemas operativos antiguos", entonces la respuesta sería financiación para el reemplazo y presión a los proveedores. Esos eran problemas reales, especialmente cuando los equipos médicos o los dispositivos de diagnóstico dependían de software antiguo. Pero si las máquinas compatibles con Windows 7 permanecieron sin parchear después de una alerta crítica, entonces la respuesta también incluye la gobernanza del parcheo, la gestión de excepciones y la prueba de cierre. Un dispositivo compatible puede ser inseguro cuando no está parcheado.
Un dispositivo no compatible puede aislarse o gestionarse en un modelo de control compensatorio. El sistema necesitaba saber qué condición se aplicaba a cada punto final crítico antes de que un gusano hiciera visible el inventario.
La revisión de lecciones también señaló que los cortafuegos y los controles de red podrían haber reducido el riesgo de infección. Dijo que incluso donde no se había realizado el parcheo, las acciones para mejorar la seguridad de los cortafuegos de red que enfrentan la red N3 habrían 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 eran la segmentación de red, la configuración perimetral, los controles de exposición de SMB y el conocimiento de qué sistemas aún necesitaban soporte de protocolo heredado.
Laguía de WannaCry del NCSC, ahora marcada como retirada porque está desactualizada, capturó la lógica defensiva de emergencia en ese momento. Aconsejó a las organizaciones implementar MS17-010, deshabilitar SMBv1 si no era posible parchear, bloquear los puertos relevantes donde fuera necesario, aislar la tecnología heredada vulnerable, actualizar el antivirus y evitar bloquear los dominios de kill switch. 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 de cortafuegos, opciones de DNS local, contactos de proveedores y procedimientos de reconstrucción probados no podían ejecutar fácilmente esa respuesta en capas bajo presión de emergencia.
La autonomía local dificultó el aseguramiento central
El NHS no es un único parque de TI monolítico. Los trusts locales, los consultorios de médicos de cabecera, los grupos de comisionamiento clínico, los proveedores, las unidades de apoyo al comisionamiento y otras organizaciones operan dentro de marcos nacionales pero tienen muchas responsabilidades locales. La NAO dijo que las organizaciones sanitarias locales eran responsables de mantener la seguridad de la información y de los arreglos para incidentes y emergencias, incluidos los ciberataques. Los organismos nacionales las supervisaban y apoyaban, pero no siempre tenían autoridad para exigir acciones técnicas específicas.
Esta estructura no es inherentemente incorrecta. Las organizaciones clínicas locales entienden sus propias vías de atención, 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 un cambio inseguro 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 remediación.
El punto de la NAO sobre la falta de un mecanismo formal de cumplimiento no es, por lo tanto, una trivialidad burocrática. Explica por qué una advertencia no se convirtió en una reducción de riesgo en todo el sistema. Una alerta nacional puede decir "parchee ahora". No puede por sí misma probar que cada punto final relevante tenga el parche, que los dispositivos no compatibles estén aislados, que SMB esté bloqueado donde debería, que los sistemas que requieren excepciones estén nombrados o que los ejecutivos hayan aceptado un riesgo residual para la seguridad del paciente.
Elinforme del Public Accounts Committeehizo de la misma debilidad un tema político. Dijo que hubo advertencias en 2016 y otras advertencias en marzo y abril de 2017, pero el parcheo solo se había realizado en aproximadamente dos tercios de los trusts en el momento de WannaCry, y ninguno de los 88 trusts había aprobado las evaluaciones de NHS Digital. También informó que el Departamento y el NHS reconocieron 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 costos 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ó atención distribuida. Si un trust local carecía del parche, si un consultorio 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 solo 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 usaron papel. Algunas no pudieron recibir resultados de pruebas o acceder a registros compartidos. Algunos pacientes tuvieron citas u operaciones canceladas. Cinco áreas desviaron pacientes de urgencias. La NAO fue cuidadosa al decir que no todas las categorías se contaron por completo, y la revisión de NHS England informó que no se conocía daño a pacientes. Esos límites deben respetarse.
La ausencia de daño reportado no es prueba de que todo riesgo clínico estuviera ausente, pero el registro público no respalda inventar un número de muertes o un robo oculto de datos de pacientes.
El lente de rendición de cuentas más útil es la capacidad de continuidad. Los servicios de salud pueden sobrevivir a una interrupción digital breve solo si los modos degradados están listos. El respaldo en 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 órdenes de diagnóstico, seguimiento de derivaciones, programación de quirófanos, comunicación de resultados de laboratorio, reprogramación manual de citas y reconciliación después de que los sistemas vuelvan.
Cada respaldo tiene un perfil de rendimiento y error. Una clínica que puede manejar 20 excepciones manuales puede no manejar cientos. Un hospital que puede diferir de manera segura el trabajo electivo por 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 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 el incidente también enseñó lecciones sobre cómo el cibernético difiere de otros incidentes mayores. El cibernético puede hacer que las propias herramientas de comunicación no sean fiables. Puede afectar a múltiples sitios simultáneamente. Puede no estar claro al principio si un sitio está infectado, desconectado o actuando defensivamente.
Puede requerir acciones de contención técnica 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 organización.
Por eso la rendición de cuentas no debe terminar en el dispositivo que omitió un parche. El sistema de atención necesitaba una forma probada de responder a preguntas básicas de continuidad en condiciones cibernéticas. ¿Qué servicios deben seguir funcionando incluso si el correo electrónico está fuera de línea? ¿Qué registros son esenciales para la atención de emergencia? ¿Qué sistemas pueden apagarse localmente sin coordinación regional? ¿Qué organismo nacional lidera las comunicaciones? ¿Qué proveedores deben unirse al puente de incidentes? ¿Qué ejecutivos locales pueden aceptar un rendimiento clínico reducido, y con qué evidencia?
La NAO informó que el Departamento había desarrollado un plan que incluía roles y responsabilidades nacionales y locales, pero no lo había probado a nivel local. También encontró que el NHS no había ensayado un ciberataque nacional, por lo que no estaba claro de inmediato quién debía liderar la respuesta y hubo problemas de comunicación. Eso no es una brecha de proceso menor.
En la continuidad cibernética, los ensayos son cómo las organizaciones descubren si las listas de contactos funcionan, si existen formularios en papel, si las listas de pacientes fuera de línea son lo suficientemente recientes, si los proveedores responden y si los clínicos entienden qué sistemas es seguro 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 resultaron perjudicadas por los movimientos defensivos de otras organizaciones. Un trust podía evitar la infección directa y aun así perder el acceso a un proceso de entrega de ambulancias, una transferencia de imágenes diagnósticas, una ruta de pedido de quimioterapia, un flujo de resultados de análisis de sangre o una carga de trabajo de atención primaria porque otro proveedor, proveedor de servicios o socio de red cerró el acceso para protegerse. Eso es contención local racional, pero crea consecuencias regionales para el servicio.
El posteriorestudio de caso del toolkit de gestión de continuidad de negocio de NHS England sobre WannaCrylo 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 entrega y haciendo que una plataforma de reserva de transporte de pacientes no estuviera disponible. Los centros terciarios cerraron el acceso, lo que significó 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 a través de la ruta habitual. El proveedor de TI de atención primaria protegió su red, después de lo cual la transferencia automatizada de resultados de análisis de sangre falló y algunos médicos de cabecera no pudieron acceder a sus cargas de trabajo.
Las soluciones alternativas en ese estudio de caso son útiles porque son concretas en lugar de dramáticas. Las prealertas de ambulancias continuaron por línea telefónica fija y otras comunicaciones por radio. Las reservas de transporte de pacientes pasaron al teléfono. Las imágenes se transfirieron a DVD y se enviaron en taxi. Los pedidos de quimioterapia volvieron al papel y al fax. Las transferencias de resultados de análisis 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 dijo que los planes de continuidad de negocio se actualizaron después y concluyó que las organizaciones del NHS necesitan comprender sus interdependencias y ajustar los planes para servicios compartidos para minimizar el impacto en la economía de la salud.
Este es exactamente el tipo de evidencia que los recuentos amplios de incidentes pasan por alto. Un incidente cibernético puede reducir la capacidad de atención 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 gran escala. Un DVD enviado en taxi puede salvar una ruta 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 ocupada.
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. 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. Un consultorio de médico de cabecera, un hospicio, un proveedor comunitario, una clínica local o un servicio contratado puede no ser propietario del sistema central del que depende. Puede 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 aún debe responder 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 están en cola y quién es responsable de informar a los pacientes que la ruta digital ha fallado.
A efectos de rendición de cuentas, la interdependencia cambia la prueba de control. No es suficiente que cada organización diga que tiene un plan de continuidad de negocio. Los planes deben encontrarse entre sí. Si el cierre defensivo de un centro terciario bloquea la transferencia de imágenes, el plan del trust remitente ya debe conocer la ruta alternativa. Si un proveedor de TI de atención primaria cierra el acceso, las prácticas locales necesitan opciones designadas para el acceso urgente a registros.
Si las pantallas de entrega de ambulancias no están disponibles, los departamentos de urgencias y los servicios de ambulancia necesitan un respaldo compartido que se haya ensayado. El estudio de caso del NHS es modesto en alcance, 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 costo fue más amplio que un rescate que no se pagó
Ninguna organización del NHS pagó el rescate, según el Departamento, NHS England y la National Crime Agency en el informe de la NAO. Ese hecho debería evitar una lectura errónea común: la pérdida no fue la demanda de rescate. Fue el trabajo cancelado, las horas extra, el soporte de TI, la restauración, la atención diferida, el esfuerzo de los proveedores y la remediación posterior. La NAO dijo que el Departamento no conocía el costo de la interrupción de los servicios en el momento de su investigación.
Identificó categorías de costo como citas canceladas, soporte de TI local adicional, consultores de TI, restauración de datos y sistemas, y horas extra del personal durante la respuesta del fin de semana.
La actualización posterior del Departamento de Salud y Atención Social,Securing cyber resilience in health and care: October 2018 progress update, enlazada alPDF de actualización de septiembre de 2018. Esa actualización es ampliamente citada por la estimación de que WannaCry costó al NHS £92 millones, incluyendo respuesta directa y recuperación de TI, así como producción perdida. Esa estimación debe usarse con cuidado. Es una estimación de costo del sector público, no una contabilidad completa de la ansiedad de los pacientes, el tiempo familiar, el movimiento de ambulancias, la carga de proveedores locales o cada hora de personal.
El trabajo académico también muestra por qué el impacto es difícil de valorar. Unanálisis de impacto retrospectivo de npj Digital Medicine de 2019utilizó estadísticas de episodios hospitalarios para examinar cancelaciones, admisiones, visitas a urgencias, mortalidad y costos 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 admisiones de emergencia y programadas, y el estudio estimó £5.9 millones en actividad hospitalaria perdida en los trusts infectados. También señaló que no hubo aumento en la mortalidad, advirtiendo que la mortalidad es una medida burda del daño al paciente.
La diferencia entre una estimación de £5.9 millones de actividad hospitalaria perdida en trusts infectados y una estimación más amplia de £92 millones del sector público no es necesariamente una contradicción. Miden cosas diferentes. Una analiza la actividad en hospitales infectados durante un período definido utilizando datos hospitalarios. La otra incluye respuesta más amplia, recuperación y remediación de TI. Para la rendición de cuentas, el punto importante no es elegir el número más grande y llamarlo "el costo".
Es preguntar qué costos eran prevenibles con un parcheo más temprano, cuáles fueron incurridos por la contención necesaria, cuáles eran inversiones que deberían haber ocurrido antes, y cuáles recayeron sobre pacientes y personal sin aparecer nunca en un presupuesto de TI.
Los proveedores pequeños y medianos están dentro de esa misma pregunta. El problema es la continuidad en las organizaciones más pequeñas que se conectan a un servicio nacional: consultorios de médicos de cabecera, hospicios, proveedores comunitarios, contratistas, proveedores de dispositivos, socios locales de soporte de TI e interfaces de atención social. La NAO contó a la atención primaria y otras organizaciones entre las entidades infectadas y señaló que otros proveedores podrían verse afectados a través de sistemas compartidos o información retrasada.
Un incidente cibernético en una gran institución pública se convierte por lo tanto en un shock de continuidad para 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 WannaCrydijo que el Reino Unido consideraba que actores norcoreanos conocidos como el Grupo Lazarus estaban detrás de la campaña. Esa atribución importa para la disuasión, las sanciones, la diplomacia y la seguridad nacional. No absuelve el control operativo doméstico. 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 acciones relativamente simples 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 el lanzamiento del parche para sus productos, y luego la decisión extraordinaria de poner parches disponibles para plataformas no compatibles durante la emergencia. NHS Digital controlaba alertas, orientación, soporte telefónico y asesoramiento específico para el sector. NHS England controlaba la coordinación de incidentes mayores y la escalada de continuidad asistencial.
El Departamento de Salud controlaba la supervisión de políticas y las prioridades de financiación. Los trusts y las prácticas locales controlaban muchas decisiones sobre dispositivos, redes, proveedores y gestión de cambios. Los proveedores controlaban algunos dispositivos heredados, términos de soporte y restricciones de compatibilidad.
Ninguna capa única es toda la historia. Tratar el incidente solo como un evento de un estado hostil lo hace demasiado remoto de la gestión local. Tratarlo solo como 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 proveedores ignora que los sistemas Windows compatibles también estaban sin parchear.
La rendición de cuentas es el mapa de estos controles, no una búsqueda de un solo actor que pueda cargar con todos ellos.
El control más consecuente fue la evidencia. ¿Quién conocía el estado de los parches? ¿Quién conocía el estado de exposición de SMB? ¿Quién sabía qué sistemas no eran compatibles? ¿Quién sabía qué dispositivos médicos no podían parchearse sin 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 qué tan rápido los consultorios de médicos de cabecera podían cambiar a operación manual segura? El registro público muestra que suficientes de esas respuestas no estaban disponibles, eran incompletas o no eran accionables centralmente antes del ataque.
El programa posterior al incidente confirma el diagnóstico
El registro de remediación después de 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 responsabilidad de la junta, roles más claros, estándares de ciberseguridad, resiliencia local, mejor parcheo, reemplazo de software no compatible, mejora de procesos de respuesta y coordinación nacional más fuerte. La actualización de progreso de 2018 del Departamento describió el trabajo en respuesta a incidentes mayores, operaciones de ciberseguridad, estándares de seguridad de datos, expectativas de proveedores e inversión. ElData Security and Protection Toolkit, que reemplazó el 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 y sistemas de pacientes del NHS midieran y publicaran su desempeño frente a los diez estándares de seguridad de datos de la National Data Guardian.
Ese toolkit no es prueba de que el problema desapareciera. La autoevaluación tiene límites, y los incidentes cibernéticos posteriores en los sistemas de salud muestran que el ransomware y las interrupciones de proveedores siguen siendo riesgos graves. Pero es evidencia de que el sistema posterior a WannaCry se movió hacia un aseguramiento explícito en lugar de solo orientación informal. También sacó la ciberseguridad del carril puramente técnico y la llevó a la responsabilidad de la junta, 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 ocurren ataques. La existencia de la estrategia refuerza la lección central de 2017: en la atención sanitaria, la ciberseguridad no es una disciplina separada de back-office. 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 revisión anual de 2017describió el primer año del nuevo centro y su misión de hacer que el Reino Unido sea más seguro en línea. La respuesta a WannaCry hizo que esa misión fuera concreta para hospitales y clínicas. Mostró que la capacidad cibernética nacional tenía que conectarse a operaciones específicas del sector, no solo publicar advertencias para equipos técnicos.
Cinco pruebas de rendición de cuentas
El valor perdurable del caso del NHS es que proporciona a las juntas directivas y a los líderes del sector público pruebas prácticas. Estas pruebas no se tratan de culpar a un administrador por un parche. Se trata de si un servicio público puede demostrar que el 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 no compatibles, versiones de sistemas operativos, servicios expuestos, proveedores y dependencias clínicas. El inventario debe incluir sistemas que son inconvenientes de poseer, como estaciones de trabajo de diagnóstico antiguas, servidores de archivos compartidos y máquinas controladas en parte por proveedores.
2. Aseguramiento del parcheo:Emitir una advertencia no es suficiente. Una alerta crítica debe crear acciones rastreadas, plazos, escalada ejecutiva, excepciones nombradas, controles compensatorios y evidencia de que el parche se ha instalado o la exposición se ha controlado de otra manera. Cuando la autonomía local bloquea los mandatos centrales, el centro necesita al menos una visibilidad confiable y una ruta para escalar el riesgo de seguridad del paciente.
3. Contención de sistemas heredados:Los sistemas no compatibles o difíciles de parchear requieren segmentación, restricciones de acceso, planes de proveedores, financiación de reemplazo y contingencia clínica. Dejar un sistema sin soporte a veces es una necesidad clínica temporal, pero no debería ser un hecho no gestionado descubierto durante un brote de gusano.
4. Continuidad cibernética específica:La planificación de emergencias debe asumir que los sistemas normales de comunicación y registro pueden no estar disponibles. El respaldo manual necesita planificación de capacidad, no solo formularios en papel. Debe especificar qué servicios clínicos se degradan primero, cómo se desvían 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 manera segura.
5. Rendición de cuentas multinivel:El centro, los organismos locales, los proveedores y las agencias de seguridad nacional tienen diferentes controles. Un marco maduro no colapsa estos controles en una sola 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 medible. También protegen al personal de expectativas imposibles. Durante WannaCry, el personal del NHS trabajó horas extra e improvisó para mantener los servicios en funcionamiento. La revisión de lecciones reconoció públicamente esos esfuerzos. La respuesta heroica local no debe usarse como evidencia de que la preparación era adecuada. A menudo es evidencia de que el sistema formal dejó demasiado trabajo a personas bajo presión.
El límite de responsabilidad
Las fuentes públicas respaldan una crítica operativa sólida. No respaldan conclusiones legales no fundamentadas contra un trust, ejecutivo, proveedor u organismo nacional nombrados. El PAC, NAO, NHS England, DHSC, CQC, NCSC, Microsoft y los registros académicos establecen advertencias, aseguramiento perdido, sistemas sin parchear, interrupción del servicio y reformas posteriores al incidente. No prueban negligencia en cada organización local, cuantifican cada pérdida ni muestran exactamente qué dispositivos fueron responsables de cada cita cancelada.
Ese límite importa 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 lucha legal sobre si una entidad incumplió un deber, se pierden el diseño de control. La pregunta del 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 pregunta de continuidad asistencial es si cada organización afectada había ensayado una interrupción cibernética lo suficientemente bien como para mantener los servicios esenciales en movimiento a una capacidad degradada conocida. El registro público dice que esos arreglos no se probaron suficientemente.
WannaCry sigue siendo, por lo tanto, un caso de rendición de cuentas pública porque conectó un atraso de mantenimiento técnico con la resiliencia frente al paciente. El riesgo tenía nombres: MS17-010, SMBv1, sistemas operativos no compatibles, planes de incidentes no probados, organismos locales sin aseguramiento de cumplimiento central, redes compartidas y sistemas clínicos que no podían apagarse casualmente. Pero el daño tenía nombres diferentes: citas canceladas, pacientes desviados, registros no disponibles, información retrasada, horas extra del personal y una estimación de remediación e interrupción de £92 millones.
La forma más responsable de recordar el incidente no es como una moraleja sobre software antiguo. Es una advertencia de que las instituciones públicas pueden saber lo suficiente como para estar preocupadas y aún no saber lo suficiente como para estar preparadas. Un parche puede existir. Una alerta puede enviarse. Una junta puede recibir capacitación en ciberseguridad. Un plan puede redactarse.
Si la organización no puede probar que los sistemas vulnerables están parcheados, aislados, reemplazados o evitados de manera segura, entonces el riesgo todavía lo llevan los pacientes, el personal y los proveedores más pequeños que solo descubren la dependencia cuando el servicio se detiene.