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, 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 atención 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 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, cuando 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 causado 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 que las organizaciones pueden ni siquiera saber que existen hasta que un incidente obliga a realizar una auditoría exhaustiva de su ecosistema de proveedores.

«Exigimos a [los proveedores] que nos proporcionen 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 las relaciones con los proveedores más importantes, lo que deja muchas dependencias de 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.

«Realizamos [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 está fuera de servicio al mismo tiempo, los backup habituales (como llamar a los proveedores para solicitar asistencia o cambiar 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, la conversación 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. Piden 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 tomando 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 tercero 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 la continuidad del cumplimiento normativo incluso cuando los proveedores fallan.
• Evolución contractual mejorada: las negociaciones contractuales posteriores a los incidentes ahora abordan explícitamente 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 costos por tiempo de inactividad y compensación financiera tanto por las pérdidas directas como por las sanciones por incumplimiento derivadas de interrupciones causadas por los proveedores.
• Gestión de actualizaciones consciente del 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 atrás» 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 normativa 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 saber que los proveedores pueden 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 la industria de los seguros estos riesgos. Como compartió una responsable de seguridad de una colega 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 dice 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, 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 restaurar 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 tus proveedores, los proveedores de estos y, potencialmente, tus backup se ven afectados. Tal y como hemos explorado en nuestro análisis sobre las amenazas cibernéticas en el sector sanitario y el MVR, la pregunta no es solo «¿cómo recuperamos todo?», sino «¿cuáles son los elementos esenciales que necesitamos para mantener la atención al paciente mientras el ecosistema se reconstruye?».

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 o en backup, tu plan MVR debe tener en cuenta la verdadera independencia del ecosistema más amplio, al menos temporalmente.

Avanzando

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 forma 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 cloud 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 fallos interconectados. ¿Qué grado de confianza tiene en que su plan de MVR funcionaría si sus proveedores habituales y backup 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 al 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.

Blogs relacionados:

• Receta para las ciberamenazas
• ¿Cuánto tiempo permanecerá tu empresa en cuidados intensivos?
• La receta para la ciberresiliencia en la sanidad