Líderes de opinión
¿Qué sucede cuando los atacantes se mueven más rápido de lo que el sector de la salud puede parchear?

El sector de la salud ha enfrentado durante mucho tiempo un verdadero obstáculo para parchear problemas de seguridad: el equipo de seguridad de un hospital puede identificar una vulnerabilidad en un sistema clínico en una tarde, pero la instalación segura de una solución suele verse obstaculizada por las realidades prácticas del ritmo frenético diario del hospital. El fabricante del dispositivo puede necesitar validar una actualización, el hospital puede necesitar probarla y programar tiempo de inactividad, y algunos cambios incluso pueden requerir una revisión regulatoria.
Los atacantes no enfrentan ninguna de esas limitaciones. Con herramientas de IA que aceleran la investigación y el reconocimiento de vulnerabilidades, así como el desarrollo de exploits, los procesos de remediación ya sobrecargados del sector sanitario están bajo una presión aún mayor.
Lo que convierte a este problema en particularmente doloroso es que los retrasos en los parches a menudo se prolongan debido a dependencias del proveedor. Mientras que una solución para un sistema de resonancia magnética, por ejemplo, puede necesitar ser validada por el proveedor, a menudo aún debe ser aprobada por el control de cambios del hospital. Y todo debe hacerse sin interrumpir la atención.
Health-ISAC’s Frontier AI in the Health Sector informe nombra el parcheo retrasado como una de las exposiciones definitorias del sector. Lo que deja a los hospitales con una única vía viable: pueden no ser capaces de controlar cada parte del cronograma de parches, pero pueden limitar lo que un atacante puede hacer mientras se despliega una actualización.
El cronograma de parches tiene un límite inferior por una razón
Muchas de las etapas del cronograma de parcheo de un hospital pueden irritar a los profesionales de la seguridad de la información, pero existen para garantizar la seguridad del paciente. Ninguna actualización no probada a un ventilador o a una bomba de infusión que busque cerrar un riesgo de ciberseguridad justifica el costo de obstaculizar la atención al paciente. Por lo tanto, la respuesta es acelerar las partes del proceso que pueden acelerarse sin debilitar los protocolos existentes.
Los auditores y los consejos tienden a tratar las largas ventanas de remediación como un problema de madurez del programa o de presupuesto, y a veces tienen razón. Por lo general, los cronogramas extensos de parcheo son un síntoma de ejecución deficiente, falta de recursos o cuellos de botella fuera del control del equipo de seguridad. Más analistas pueden mejorar la detección de vulnerabilidades, la clasificación y priorización, pero no pueden acortar los plazos del fabricante ni mover las ventanas de inactividad.
Con la explotación de vulnerabilidades emergiendo como la forma más común en que los atacantes acceden a redes objetivo, el Verizon 2026 Data Breach Investigations Report (DBIR) muestra cuán poco margen tienen las organizaciones para desplegar parches. El tiempo medio para remediar completamente una vulnerabilidad conocida explotada aumentó a 43 días en 2026 desde 32 días el año anterior, mientras que la proporción de vulnerabilidades cerradas totalmente cayó al 26 % desde el 38 %. El hecho de que estas cifras no sean específicas del sector sanitario muestra lo difícil que ya es la remediación, sin siquiera considerar las limitaciones clínicas y de proveedores que los hospitales también deben gestionar.
Es hora de mirar más allá de las puntuaciones de gravedad
Aunque las ventanas de remediación se han alargado, los atacantes se han vuelto más rápidos. El DBIR descubrió que la explotación de vulnerabilidades es ahora la principal forma en que los hackers ingresan a los sistemas, representando el 31 % de las brechas, superando las credenciales robadas por primera vez en los 19 años que el informe ha sido publicado.
Verizon afirma que la IA ha ayudado a acelerar el descubrimiento y la explotación de vulnerabilidades, tanto que lo que antes llevaba meses ahora puede tomar horas o días. Y eso fue antes de que se lanzara la generación actual de modelos de frontera, ya que el conjunto de datos del DBIR terminó en octubre de 2025.
Pero hoy en día todos esperan esa velocidad. El informe de Health-ISAC señala algo aún más trascendental: los modelos de IA más recientes pueden encadenar hallazgos de baja gravedad en rutas de ataque críticas, identificando combinaciones de debilidades que pueden parecer menos importantes de forma aislada. Eso genera otro problema para los programas de remediación que priorizan las puntuaciones de gravedad, ya que los hallazgos de baja gravedad que a menudo se ignoran o se relegan al backlog pueden de repente ser mucho más relevantes si afectan el acceso o sistemas críticos.
Los backlogs crecientes solo empeoran la situación. Escribiendo en Nature, el director del Instituto Max Planck, Thorsten Holz describió que Mozilla utilizó un modelo de frontera para encontrar y corregir 271 vulnerabilidades en una sola versión de Firefox, mucho más de lo que sus herramientas y revisores existentes habían detectado en un mes típico del año anterior.
Esa presión de triage también se extiende al lado de la oferta: Linus Torvalds, el mantenedor del kernel de Linux, en mayo señaló que los informes de errores generados por IA están sobrecargando a los mantenedores.
Cuando no puedes arreglar más rápido, reduce lo que es alcanzable
Afortunadamente, un backlog que no se puede eliminar aún puede gestionarse. Si un parche debe esperar, la prioridad debe ser reducir las posibilidades de que alguna vulnerabilidad sea explotada. Eso traslada el trabajo de la velocidad de remediación a la alcanzabilidad, algo que los hospitales pueden controlar.
La segmentación puede servir como una fuerte compensación. Un dispositivo de imagen con acceso amplio puede alcanzar un controlador de dominio, un recurso compartido y la internet abierta. Pero si se limita a un segmento aislado que permite el tráfico a su servidor PACS y al punto de actualización del fabricante, mientras niega el acceso al resto por defecto, cualquier vulnerabilidad que lo afecte puede permanecer contenida durante el tiempo que el parche tarde en aplicarse.
Donde lo permitan los requisitos del dispositivo y del proveedor, los hospitales pueden usar segmentación, controles de salida y reglas de denegación por defecto para estrechar e incluso cerrar los caminos de acceso mientras el parche está pendiente.
Los hospitales no necesitan un inventario completo de activos antes de comenzar a reducir la superficie expuesta. Primero cuenten los sistemas que responden a internet, mantengan ese número actualizado a medida que el inventario más amplio continúe, y prioricen limitar lo que esos sistemas pueden alcanzar dentro de la red.
Los datos de la encuesta de Health-ISAC indican que la industria ya está comenzando a moverse en esa dirección. Aproximadamente el 80 % de los miembros de Health-ISAC dicen que planean aumentar sus presupuestos para herramientas de seguridad impulsadas por IA o evaluación de explotabilidad. Un camino que puede resultar útil es analizar qué rutas de ataque funcionan en su propio entorno: encontrar combinaciones de vulnerabilidades de baja gravedad que puedan merecer atención antes de que una puntuación de prioridad capte su atención.
Las conversaciones con los proveedores también deben superar el lenguaje del acuerdo de nivel de servicio. Los contratos contienen lo que usted y sus proveedores acordaron hace años, pero el modelo de amenaza ha cambiado drásticamente. Por lo tanto, primero identifique cuánto tiempo pueden tardar en emitirse los parches validados después de la divulgación pública, y luego averigüe qué medidas de mitigación están disponibles mientras espera la actualización. También vale la pena preguntar si prueban su producto contra las técnicas de ataque asistidas por IA actuales.
Gestiona la exposición que no puedes eliminar
La mayoría de las organizaciones no pueden decir cuánto tiempo lleva tener una solución validada en producción una vez que un exploit se ha hecho público. Concéntrese en obtener ese número para dejar de debatir sobre las ventanas de parcheo y comenzar a enfocarse en descubrir qué proveedores y sistemas permanecen expuestos más tiempo. Eso le permitirá decidir qué deben priorizar sus esfuerzos de remediación.
Compartir información puede acortar significativamente ese ciclo de decisión. Algunas de las decisiones de remediación más rápidas que he visto ocurren cuando un hospital recibe información de un colega sobre una plataforma de proveedor que está siendo explotada antes de que la vulnerabilidad se divulgue públicamente.
La ventana de validación en sí no se ampliará. Los hospitales seguirán ejecutando sistemas clínicos con vulnerabilidades abiertas, lo que significa que la estrategia de segmentación para esos sistemas debe recibir más importancia que el calendario de parches. Cada hospital debería poder especificar, para cada una de sus plataformas críticas, qué sucedería en la red si esa plataforma fuera vulnerada mañana.












