Pruebas de ciberseguridad de productos sanitarios
Sytance · Actualizado
Las pruebas de ciberseguridad de productos sanitarios comprueban si los requisitos de seguridad y los controles de riesgo funcionan en la configuración prevista del producto. Los resultados deben mostrar las condiciones de prueba y el comportamiento observado para que los revisores puedan valorar qué demuestran las pruebas sobre el producto.
Finalidad de las pruebas
El alcance de las pruebas se deriva de las amenazas y los requisitos de seguridad del producto. Si solo una cuenta de servicio autorizada puede cambiar la configuración, pruebe la interfaz directa tanto con cuentas permitidas como prohibidas y compruebe si cambian los ajustes almacenados.
Evidencia precomercialización
El expediente precomercialización utiliza pruebas para respaldar la verificación del diseño, la validación del diseño, la eficacia de los controles de seguridad y la idoneidad de los controles de riesgo.
Evidencia poscomercialización
El proceso poscomercialización utiliza pruebas para evaluar nuevas vulnerabilidades, verificar correcciones, detectar regresiones y mantener la confianza en las versiones desplegadas.
Alcance de las pruebas precomercialización
La guía precomercialización vigente de la FDA identifica varios tipos de pruebas y análisis de ciberseguridad que pueden incluirse en una presentación. Esta debe explicar por qué las pruebas seleccionadas son adecuadas para los riesgos, la arquitectura y los controles del producto.
Estas pruebas demuestran que se implementaron los requisitos de entrada del diseño y que las hipótesis sobre los límites están justificadas. Deben relacionar los requisitos con los elementos de arquitectura y los criterios de aceptación de los controles de seguridad.
Estas pruebas demuestran que los controles de riesgo funcionan frente a las amenazas identificadas en el modelo de amenazas y las vistas de arquitectura. Deben abordar la eficacia de la seguridad, la estabilidad, la fiabilidad y las condiciones de tráfico o carga de trabajo cuando sean relevantes.
Entre los ejemplos de la FDA figuran casos de abuso o uso indebido, entradas mal formadas e inesperadas, pruebas de robustez, pruebas fuzz, análisis de la superficie de ataque, encadenamiento de vulnerabilidades, análisis de vulnerabilidades conocidas, análisis de composición de software de archivos binarios ejecutables y análisis estático o dinámico del código.
Las pruebas de penetración deben intentar descubrir y explotar vulnerabilidades de seguridad del producto. La FDA espera que los informes expliquen la independencia y experiencia de los evaluadores, el alcance y la duración de las pruebas, los métodos, los resultados, los hallazgos y las observaciones.
Un solo análisis no basta
Un análisis de vulnerabilidades informa de los hallazgos dentro de su cobertura. Puede identificar una debilidad conocida en un servicio de red, mientras que se necesita otra prueba para comprobar si el producto rechaza un comando no autorizado o se recupera tras una actualización fallida. Evalúe el impacto en los pacientes teniendo en cuenta la arquitectura del producto y el análisis de riesgos.
- Un análisis de vulnerabilidades puede detectar problemas conocidos, pero puede pasar por alto defectos de diseño e hipótesis de confianza inseguras.
- El análisis estático puede detectar debilidades en el código, pero no demuestra la configuración desplegada ni el comportamiento de los controles en tiempo de ejecución.
- Las pruebas fuzz pueden revelar cómo se gestionan entradas mal formadas, pero no sustituyen la revisión de arquitectura ni las pruebas de penetración.
- Las pruebas de penetración pueden mostrar vías de explotación, pero siguen limitadas por el alcance, el tiempo, el acceso del evaluador y la metodología.
Los hallazgos alimentan la gestión de riesgos
Los hallazgos de las pruebas deben evaluarse por su impacto en la seguridad y vincularse al proceso de gestión de riesgos de ciberseguridad. La FDA explica que quizá sea necesario mitigar una anomalía de seguridad porque su explotabilidad puede causar un tipo de daño distinto del de un defecto de software ordinario.
Evaluación de los hallazgos
Los informes deben explicar el hallazgo, el componente o la interfaz afectados, la explotabilidad, las versiones afectadas, el estado de los controles y las posibles consecuencias para los pacientes.
Corrección aplazada
Si se aplaza una corrección, el expediente debe explicar la justificación del riesgo, la versión prevista, los productos afectados que ya están en uso y cómo se les entregará la actualización.
Pruebas poscomercialización
La FDA recomienda realizar pruebas de seguridad durante el desarrollo y después de la comercialización con una frecuencia adecuada al riesgo. Por ejemplo, un cambio en el mecanismo de actualización puede requerir nuevas pruebas de integridad y recuperación. La divulgación de una vulnerabilidad de un componente puede exigir una investigación y pruebas de regresión de la corrección.
En la documentación de la UE, los resultados de verificación respaldan la evaluación de riesgos y pueden identificar cambios necesarios en el producto o sus instrucciones. MDCG 2019-16 explica cómo continúa este trabajo tras la comercialización. IEC 81001-5-1 establece un proceso de ciclo de vida para mantener esas actividades.
Fuentes
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, guía final, febrero de 2026
- FDA, Postmarket Management of Cybersecurity in Medical Devices, guía final, diciembre de 2016
- Comisión Europea, MDCG 2019-16 Guidance on Cybersecurity for medical devices
- IEC, IEC 81001-5-1:2021, software de salud y sistemas informáticos sanitarios: seguridad, eficacia y protección