En conversaciones con tres directores de información médica de distintos sistemas sanitarios, se les preguntó a cada uno de ellos por su incidente de ciberseguridad más reciente. La respuesta fue unánime y reveladora: ninguno había sufrido un ataque directo a sus propios sistemas. En cambio, los tres se enfrentaban a las consecuencias de las brechas de seguridad de proveedores externos que se habían propagado en cadena por sus operaciones. No es una coincidencia, es la nueva realidad de la ciberseguridad en el sector sanitario.
El problema del proveedor del proveedor
«Somos lo suficientemente grandes como para contar con estos expertos en plantilla que nos protegen», explicó un CMIO. «A veces creo que eso puede suponer un obstáculo para la agilidad, debido a lo estrictos y minuciosos que somos en esas evaluaciones. Pero creo que no podemos garantizar que nuestros socios hagan lo mismo».
Este es el reto: las organizaciones sanitarias se han vuelto increíblemente sofisticadas a la hora de evaluar a los proveedores directos. El proceso de contratación es riguroso, las evaluaciones de seguridad son exhaustivas y los requisitos de cumplimiento son innegociables. Pero, ¿qué ocurre cuando tu proveedor llega a un acuerdo con otro proveedor? De repente, te ves expuesto a riesgos que nunca habías evaluado, de empresas de las que nunca habías oído hablar, a través de relaciones que no controlas.
Un responsable de seguridad lo ilustró a la perfección: «Voy a cerrar un acuerdo para que el proveedor X haga algo por mí aquí. Pero el proveedor X puede llegar a un acuerdo con el proveedor Y que le permita realizar su trabajo. Así que, si surge un problema con el proveedor Y —con el que, técnicamente, no tengo contrato—, pero mi proveedor lo necesita para funcionar, no puedo controlar eso».
Cuando el ecosistema falla
El incidente de Change Healthcare es un claro ejemplo de ello. Cuando sus sistemas dejaron de funcionar debido a un ciberataque, no solo se vio afectada Change Healthcare, sino todas las organizaciones sanitarias que dependían de sus servicios de tramitación de recetas. Un CMIO describió el impacto: «Teníamos muchos problemas para enviar recetas y recibirlas; no teníamos claro qué se había tramitado, qué no se había tramitado y quiénes no habían recibido sus medicamentos».
El impacto clínico posterior fue inmediato y grave. Los pacientes no podían obtener medicamentos, los proveedores no podían verificar el estado de las recetas y los equipos de atención médica se apresuraron a identificar qué pacientes podrían verse afectados. Se trataba de un problema directo de seguridad de los pacientes causado por un incidente con un proveedor que escapaba por completo al control de los proveedores de atención médica. Pero el impacto clínico fue solo el principio. Las implicaciones en materia de cumplimiento normativo fueron igualmente graves, lo que puso de relieve un reto fundamental en el panorama regulatorio de la asistencia sanitaria.
La trampa del cumplimiento normativo: cuando los fallos de los proveedores se convierten en tu problema normativo
Las organizaciones sanitarias se enfrentan a una dura realidad normativa: los incidentes de los proveedores no las eximen de sus responsabilidades en materia de cumplimiento. De hecho, a menudo las amplifican. La HIPAA exige a las entidades afectadas que establezcan acuerdos de colaboración empresarial (Business Associate Agreements) con los proveedores que manejan información sanitaria protegida. Aunque estos acuerdos transfieren teóricamente parte de la responsabilidad, la realidad práctica es diferente. Cuando un proveedor sufre una violación de seguridad, el proveedor de asistencia sanitaria sigue enfrentándose a posibles sanciones, al escrutinio regulador y a requisitos de notificación obligatorios.
La carga que supone la presentación de informes por sí sola genera una presión operativa considerable. Las obligaciones de notificación en un plazo de 72 horas propuestas por la HIPAA, similares a normativas como la NIS2 y la DORA de la UE para instituciones transfronterizas, exigen a los proveedores de asistencia sanitaria que comuniquen rápidamente los incidentes, independientemente de si la violación se ha producido en sus propios sistemas o en los de un proveedor.
Como señaló un director médico de informática (CMIO): «De hecho, tenemos que comunicar al Estado, a los Centros de Servicios de Medicaid y Medicare: “Esto es lo que está pasando. Esta es nuestra situación actual en cuanto a la recuperación”».
Esto significa que, durante un incidente activo, mientras los equipos clínicos se esfuerzan por mantener la atención al paciente y los equipos de TI coordinan las tareas de recuperación, los equipos de cumplimiento normativo deben investigar, documentar y notificar simultáneamente incidentes que no han provocado y sobre los que pueden tener una visibilidad limitada. El reto de la soberanía de los datos añade complejidad. Los proveedores que almacenan datos sanitarios fuera de las regiones autorizadas pueden provocar incumplimientos normativos de los que las organizaciones pueden ni siquiera tener conocimiento hasta que un incidente obligue a realizar una auditoría exhaustiva de su ecosistema de proveedores.
«Exigimos a [los proveedores] que nos faciliten todo lo que les pedimos para su revisión», explicó un responsable de seguridad que ha sufrido un ataque de ransomware por parte de un proveedor. «Por lo tanto, en realidad no había limitaciones en cuanto a lo que podíamos pedir». Sin embargo, este nivel de supervisión solo suele ser posible con los proveedores más importantes, lo que deja a muchos proveedores más pequeños, pero igualmente críticos, en puntos ciegos en materia de cumplimiento.
La llamada de atención de CrowdStrike
El incidente de CrowdStrike puso de manifiesto otra realidad: cuando fallan los proveedores de infraestructuras críticas, todo el ecosistema sanitario falla simultáneamente.
«Llevamos a cabo [ejercicios de simulación] partiendo de la hipótesis de que se trataría de un ataque de ransomware… un suceso bastante localizado», reflexionó un responsable. «Y esto estaba afectando a todo el ecosistema. Y ahí fue donde [aprendimos] que necesitábamos contar con más prácticas de resiliencia que tuvieran en cuenta los casos en los que el propio ecosistema se viera ampliamente afectado».
El reto no era solo técnico, sino también operativo y normativo. Cuando todo el mundo queda fuera de servicio al mismo tiempo, las medidas de respaldo habituales (como llamar a los proveedores para solicitar asistencia o recurrir a proveedores alternativos) simplemente no funcionan. Las organizaciones sanitarias se enfrentaron no solo a la interrupción de la atención a los pacientes y a los enormes costes derivados del tiempo de inactividad, sino también a complejos requisitos de presentación de informes de cumplimiento normativo por un incidente que se originó totalmente fuera de su control.
Más allá de la evaluación tradicional de riesgos
Las organizaciones sanitarias están descubriendo que su enfoque tradicional de la gestión de riesgos de los proveedores no es suficiente. El proceso estándar (enviar cuestionarios, revisar la documentación, comprobar las certificaciones de cumplimiento) solo cubre las relaciones directas.
Pero tras el incidente, el discurso está cambiando. En lugar de limitarse a preguntar «¿Hacéis esto? ¿Hacéis aquello?», las organizaciones exigen ver exactamente cómo los proveedores ejecutan los planes de seguridad y recuperación. Solicitan pruebas de las pruebas realizadas, exigen derechos contractuales para revisar las relaciones con los subproveedores y establecen protecciones financieras.
El nuevo modelo de relación con los proveedores
Las organizaciones sanitarias con visión de futuro están adoptando varias medidas concretas para abordar el riesgo del ecosistema:
- Soberanía de los datos:
«Queremos empezar a asumir un mayor control sobre los datos… para disponer de algo con lo que podamos reconstruir el sistema o incluso cambiar a otro proveedor si es posible», afirmó un responsable.
En lugar de permitir que los proveedores conserven todos los datos, las organizaciones exigen exportaciones periódicas de datos y mantienen sus propias copias de la información crítica. Este enfoque ayuda a cumplir los requisitos de residencia de datos y permite mantener el cumplimiento normativo incluso cuando los proveedores fallan. - Mejora en la evolución contractual: las negociaciones contractuales posteriores a los incidentes abordan ahora de forma explícita las obligaciones de cumplimiento normativo. Las organizaciones exigen plazos de notificación que cumplan con los requisitos reglamentarios, garantías de recuperación que minimicen los costes derivados del tiempo de inactividad y una compensación económica tanto por las pérdidas directas como por las sanciones por incumplimiento derivadas de las interrupciones causadas por los proveedores.
- Gestión de actualizaciones con perspectiva de cumplimiento normativo: el incidente de CrowdStrike puso de manifiesto cómo las actualizaciones de los proveedores pueden generar riesgos tanto operativos como de cumplimiento normativo. Muchas organizaciones han implementado políticas de «dos versiones anteriores» para las actualizaciones de seguridad críticas, equilibrando el riesgo de retrasos en los parches con el riesgo de incumplimientos normativos derivados de actualizaciones no probadas que podrían provocar interrupciones generalizadas.
- Integración del cumplimiento normativo en la gestión de proveedores: Las organizaciones están incorporando consideraciones de cumplimiento normativo directamente en la evaluación de proveedores y la supervisión continua. Esto incluye asegurarse de que los proveedores puedan cumplir los mismos requisitos de notificación en 72 horas, mantener la residencia de datos adecuada y proporcionar la documentación necesaria para la presentación de informes normativos.
La perspectiva del sector asegurador
Quizás lo más revelador sea cómo ve el sector de los seguros estos riesgos. Como comentó una responsable de seguridad de una empresa dedicada al modelado de riesgos en seguros: «El riesgo número uno que tenemos es el tipo de interrupción como la de CrowdStrike, en la que dependemos tanto de estas plataformas tecnológicas que, cuando se producen, se producen interrupciones masivas en los servicios y en las operaciones. Ella afirma que ese es el riesgo número uno en nuestro modelo de riesgos. No son los ataques de ransomware».
Este cambio en la evaluación de riesgos refleja un cambio fundamental. La ciberseguridad tradicional se centraba en impedir la entrada de actores maliciosos. La ciberseguridad moderna también debe abordar la realidad de que los proveedores críticos, incluso con las mejores intenciones y sólidas prácticas de seguridad, aún pueden derrumbar ecosistemas enteros debido a fallos operativos.
El reto de la viabilidad mínima en un mundo ecosistémico
La planificación tradicional de la recuperación suele partir del supuesto de que es posible restaurarlo todo de forma sistemática, pero cuando ecosistemas enteros fallan simultáneamente, las organizaciones deben centrarse en la recuperación mínima viable (MVR).
El concepto de viabilidad mínima cobra importancia cuando se ven afectados tus proveedores, los proveedores de estos y, potencialmente, tus copias de seguridad. Tal y como hemos analizado en nuestro estudio sobre las amenazas cibernéticas en el sector sanitario y la MVR, la pregunta no es solo «¿cómo lo recuperamos todo?», sino «¿cuáles son los elementos esenciales que necesitamos para mantener la atención al paciente mientras se reconstruye el ecosistema?».
Esta realidad del ecosistema hace que la preparación para la recuperación organizativa sea más compleja que nunca. Cuando no puedes confiar en tus proveedores habituales ni en los de respaldo, tu plan de MVR debe tener en cuenta la verdadera independencia del ecosistema más amplio, al menos temporalmente.
De cara al futuro
Las organizaciones no pueden limitarse a proteger su propio perímetro; deben comprender y planificar en función de la red interconectada de dependencias de la que depende la sanidad moderna. Esto implica replantearse de manera fundamental la planificación de la continuidad del negocio para tener en cuenta los fallos simultáneos del ecosistema. Significa mantener la soberanía de los datos incluso cuando se recurre a proveedores de SaaS. Y significa aceptar que algunos riesgos simplemente no pueden eliminarse, sino solo gestionarse y preverse.
Los líderes del sector sanitario con los que hablamos no se mostraron pesimistas ante estos retos, sino pragmáticos. Entienden que las ventajas de los sistemas sanitarios interconectados y en la nube superan con creces los riesgos.
Pon a prueba la resiliencia de tu ecosistema
Comprender los riesgos es solo el primer paso. El siguiente es evaluar con honestidad si su organización está preparada para la nueva realidad de los fallos interconectados. ¿Qué grado de confianza tiene en que su plan de MVR funcionaría si sus proveedores habituales y de respaldo también se vieran comprometidos? Las organizaciones sanitarias que se toman en serio la resiliencia del ecosistema deben evaluar su Readiness en tres áreas críticas: priorización de los aspectos críticos para el negocio, respuesta técnica medible y preparación organizativa para la Recovery. La Evaluación de Viabilidad Mínima para el Sector Sanitario de Commvault le ayuda a evaluar sus capacidades actuales y ofrece recomendaciones prácticas para subsanar cualquier deficiencia. No espere a que se produzca el próximo incidente que afecte a todo el ecosistema para descubrir si sus planes de recuperación tienen en cuenta la realidad de la interconexión de las tecnologías de la información sanitarias. Realice la evaluación hoy mismo y desarrolle una verdadera resiliencia para los retos del futuro.
