Las recompensas por fallos en sanidad deben llegar antes de la brecha

Un programa de recompensas por fallos en software sanitario permite a los investigadores autorizados encontrar y comunicar vulnerabilidades antes de que las exploten los delincuentes. Solo funciona si el proveedor ya ha publicado qué se puede probar sin riesgo, ha asignado a alguien para evaluar los avisos y ha reservado recursos para corregir los fallos y pagar las recompensas. La inyección SQL descrita en el software polaco Medyc muestra por qué conviene hacer ese trabajo ahora. No sabemos si un programa de recompensas habría evitado esta brecha concreta.

Una clínica polaca ha comunicado a sus pacientes que sufrió dos incidentes distintos en proveedores de software que utilizaba: MyDr y Medyc, de Qbusoft. Su comunicado sobre MyDr y su comunicado sobre Medyc describen cada incidente por separado. Una clínica puede afrontar riesgos simultáneos en varios proveedores sin que haya motivos para pensar que las intrusiones comparten una causa técnica.

¿Qué sabemos del incidente de Medyc?

El aviso de la clínica atribuye los hallazgos técnicos a la investigación de Qbusoft con expertos forenses. Según el texto, un atacante aprovechó una inyección SQL en una interfaz de Medyc los días 22 y 23 de agosto de 2026 y transfirió un archivo cifrado de la base de datos fuera del entorno de Qbusoft. La intrusión se detectó durante la noche del 8 al 9 de septiembre. La clínica afirma que Qbusoft corrigió el fallo ese mismo día, restringió los permisos de la base de datos, renovó los secretos técnicos e informó a la policía y a la autoridad polaca de protección de datos.

En el caso de los pacientes de la unidad de tratamiento diurno de adicciones de la clínica, el aviso señala que los datos descargados incluían con certeza nombres y apellidos, números de identificación polacos PESEL, direcciones, teléfonos y correos electrónicos. El aviso indica que los nombres y los números PESEL estaban cifrados en reposo, pero Qbusoft recomendó a la clínica asumir que los atacantes podían descifrar fácilmente esos dos campos y obtenerlos en texto claro. Los scripts también apuntaban a tablas de datos médicos, por lo que la clínica considera muy probable que se extrajeran informes de alta. El aviso no confirma que se copiaran esos informes.

La autoridad polaca de protección de datos, UODO, dijo el 25 de septiembre que, según informaciones de prensa, podrían verse afectadas hasta cinco millones de personas y que planeaba inspeccionar Qbusoft. No es una cifra verificada de afectados. La autoridad también reprodujo una declaración del ministro de Digitalización del 24 de septiembre: hasta entonces Qbusoft no había notificado el incidente a CERT Polska ni al CSIRT del sector sanitario. El relato de la clínica habla de comunicaciones a la policía y a la UODO, destinatarios distintos. Por tanto, ambas versiones pueden ser ciertas.

La crónica de Zaufana Trzecia Strona vincula el caso Medyc con quien estuvo detrás del incidente anterior de MyDr. Las fuentes públicas disponibles para este artículo no muestran que las autoridades hayan establecido esa atribución. La conclusión operativa no depende de identificar al atacante: según lo comunicado, un fallo de inyección SQL en una interfaz de Medyc permitió que salieran datos del entorno del proveedor.

¿Por qué preparar el canal de avisos y las recompensas antes del primer hallazgo?

Una inyección SQL es un defecto de una aplicación que un investigador externo podría detectar sin acceso privilegiado. Un programa le indica qué sistemas puede probar, cómo demostrar el fallo sin abrir historias clínicas reales, adónde enviar el hallazgo y cuándo recibirá respuesta. La guía del NIST sobre divulgación de vulnerabilidades recomienda un proceso formal para recibir, evaluar, gestionar y comunicar estos avisos. No promete encontrar todos los fallos.

Empieza por un programa de divulgación de vulnerabilidades (VDP): contacto público, alcance, reglas, condiciones de puerto seguro (Safe Harbor), un equipo que atienda los informes y un camino desde el hallazgo aceptado hasta la corrección. Después, ofrece recompensas económicas por fallos cuando el equipo pueda gestionar los avisos adicionales y tenga aprobado un presupuesto. La recompensa anima a los investigadores a dedicar tiempo a tu producto; el proceso de recepción y corrección permite aprovechar ese trabajo. Si tu organización ya puede sostener ambas cosas, publícalas. Una crisis es mal momento para redactar las primeras reglas de participación.

Ninguno de los relatos públicos sobre Medyc indica que un investigador de buena fe encontrara antes esta inyección SQL, intentara comunicarla o la hubiera descubierto dentro de un programa de recompensas. Tampoco sustituiría ese programa a las consultas seguras a la base de datos, la revisión de código, las pruebas de penetración, los registros de actividad, los permisos mínimos en la base de datos ni la respuesta a incidentes. Ofrece a los investigadores una vía para comunicar el fallo mientras aún hay tiempo para corregirlo.

¿Cómo permitir pruebas sin exponer a los pacientes?

Un programa para software sanitario necesita límites concretos. La política de divulgación del Departamento de Salud y Servicios Humanos de Estados Unidos ofrece un modelo útil: probar solo los sistemas enumerados, explotar un fallo únicamente hasta confirmar que existe, detenerse al encontrar datos sensibles y no extraer jamás registros. Cada proveedor puede adaptar esas condiciones a su arquitectura y a su asesoramiento jurídico. La política no autoriza a probar sistemas de otras organizaciones.

Ya hay ejemplos reales. El programa público de recompensas de Doctolib pertenece al sector sanitario y detalla su alcance, sus recompensas y sus condiciones de prueba. Un proveedor más pequeño no tiene por qué copiar los importes ni el volumen del programa. Sí puede publicar con la misma claridad dónde se permite investigar y cómo evitar cualquier interferencia con la atención a los pacientes.

Haz un ensayo interno antes de abrir el programa al público: envía un informe ficticio, comprueba que se recibe y se asigna, verifica los plazos de respuesta, aplica una corrección y comunica el cierre al investigador. Resuelve cualquier fallo en ese recorrido antes de invitar a más investigadores.

¿Qué proveedores de software sanitario deberían planteárselo ahora?

Un proveedor que guarda datos de muchas clínicas independientes tiene una responsabilidad con cada una de ellas: un solo fallo en su producto puede obligar a cada clínica a evaluar la exposición de sus pacientes. Los proveedores de historia clínica electrónica, gestión de consultas y reservas de citas médicas deberían publicar una vía para comunicar vulnerabilidades antes de necesitarla. Los productos alojados por el proveedor y las instalaciones gestionadas por las clínicas pueden requerir límites de prueba distintos; cada programa debe enumerar solo los sistemas que el proveedor posee o tiene autorización para someter a pruebas.

Si diriges la ingeniería o la seguridad de uno de estos proveedores, pregúntate: ¿podría un investigador encontrar hoy el contacto correcto, comunicar un fallo sin poner en riesgo a los pacientes y conseguir que el aviso llegue a alguien con capacidad para corregirlo? Si no tienes clara la respuesta, delimita los sistemas y asigna a esa persona. Una clínica que compra software puede hacer la misma pregunta al evaluar a sus proveedores. Nuestro análisis anterior de MyDr explica los límites de los canales de divulgación ante varios tipos de brecha. El caso Medyc refuerza la necesidad de definir qué interfaces del producto pueden probar sin riesgo los investigadores externos y sobre cuáles pueden comunicar vulnerabilidades.

¿Cómo puede ayudar Kit a gestionar la divulgación en el sector sanitario?

Kit ofrece al equipo de seguridad un portal público para enviar informes y configurar el programa, un archivo security.txt generado, un alcance publicado, asignación y triaje de informes, comunicación con investigadores y seguimiento de los SLA. Si el equipo decide pagar recompensas, puede definir rangos de importe, debatir propuestas, registrar su aprobación y seguir el traspaso para el pago. Empieza por delimitar los sistemas propios y redactar reglas de prueba que protejan a los pacientes. Después, usa un informe ficticio para comprobar todo el recorrido, desde el envío hasta el cierre.

Kit no busca inyecciones SQL, no hace seguras las consultas a bases de datos ni demuestra que un proveedor esté libre de brechas. Eso corresponde al trabajo de ingeniería y respuesta a incidentes. Kit ayuda a quien descubre un fallo desde fuera a llegar al equipo encargado de corregirlo, dejando constancia de quién se ocupa del informe y qué sucede después. Los detalles de configuración están en la guía del programa de divulgación de vulnerabilidades.