Gestión de riesgos de ciberseguridad de productos sanitarios
Sytance · Actualizado
La gestión de riesgos de ciberseguridad de los productos sanitarios evalúa cómo las amenazas y las vulnerabilidades pueden afectar a la seguridad, la eficacia y el funcionamiento. Un modelo de amenazas, una SBOM, un análisis de vulnerabilidades o una prueba de penetración pueden respaldar la evaluación, pero ninguno de ellos constituye por sí solo la evaluación de riesgos.
Función de la gestión de riesgos
La FDA considera la gestión de riesgos de seguridad parte del sistema de calidad y del ciclo de vida del dispositivo. Se distingue de la gestión de riesgos de seguridad conforme a ISO 14971 porque los fallos de seguridad pueden ser intencionados, la posibilidad de explotación cambia con el tiempo y los daños pueden ser indirectos, por pérdida de disponibilidad, integridad, confidencialidad o control. Aun así, ambos procesos deben coordinarse porque un problema de seguridad puede causar daños a pacientes.
MDCG 2019-16 explica que una medida de seguridad también puede afectar a la seguridad del paciente. Por ejemplo, una restricción de acceso puede impedir cambios no autorizados y, a la vez, retrasar una operación legítima. El fabricante debe evaluar ambos efectos en el entorno de uso previsto.
Daños a pacientes
La guía de la FDA para la fase posterior a la comercialización plantea la cuestión central de los daños a pacientes en términos de lesiones o daños a la salud, incluida la muerte, y no solo del impacto empresarial.
Seguridad y funcionamiento
Evalúe si el problema de seguridad modifica el funcionamiento previsto del dispositivo y si un control introduce un nuevo problema de seguridad o funcionamiento.
El modelado de amenazas aporta información a la evaluación
El modelo de amenazas identifica cómo podría un atacante utilizar una interfaz del dispositivo o una dependencia externa para provocar un resultado no deseado. Las condiciones del ataque y sus posibles consecuencias pasan a ser datos de entrada para la evaluación de riesgos de ciberseguridad.
- El modelo de amenazas identifica qué puede fallar y por dónde un atacante o un desencadenante accidental puede alcanzar el sistema.
- La evaluación de riesgos de ciberseguridad evalúa los riesgos, los controles, los riesgos residuales y los criterios de aceptación.
- El proceso de riesgos de seguridad recibe los riesgos de ciberseguridad cuando la explotación puede afectar a los daños a pacientes, el funcionamiento clínico o el funcionamiento seguro.
- El proceso posterior a la comercialización actualiza el modelo cuando nuevas vulnerabilidades, cambios de despliegue, nuevas interfaces o nuevas técnicas de ataque modifican el perfil de riesgo.
La posibilidad de explotación modifica el análisis
La evaluación de riesgos de ciberseguridad no puede basarse únicamente en probabilidades históricas. La FDA explica que la evaluación de riesgos de seguridad se centra en la posibilidad de explotación: la viabilidad, la facilidad y los medios técnicos para explotar una vulnerabilidad. Por eso, una vulnerabilidad detectada en pruebas, una vulnerabilidad conocida y explotada de CISA, un cambio en la vía de red o un nuevo exploit público pueden modificar la evaluación aunque no se haya producido ningún incidente con pacientes.
La evaluación previa a la comercialización utiliza el modelo de amenazas para evaluar ataques y seleccionar controles. Los resultados de verificación muestran si los controles funcionan frente a esos ataques. La FDA permite asumir la peor posibilidad de explotación o realizar una evaluación justificada que tenga en cuenta todo el ciclo de vida del producto.
La evaluación posterior a la comercialización parte de una señal real, como un CVE, un informe de un investigador, un aviso de un proveedor o un exploit observado. La guía de la FDA enmarca la decisión en torno a la posibilidad de explotación, la gravedad de los daños a pacientes, los controles compensatorios y si el riesgo residual de daños a pacientes está controlado o no.
La SBOM no es la evaluación de riesgos
Una SBOM identifica componentes de software y relaciones de dependencia. Ayuda al fabricante a detectar la exposición a vulnerabilidades conocidas de componentes, su estado de soporte y las versiones afectadas. No indica si se puede acceder a un componente vulnerable, si un control impide su explotación, si cambia el funcionamiento clínico ni si el riesgo residual de daños a pacientes es aceptable.
Una SBOM es un inventario formal y legible por máquina de los componentes de software y sus dependencias, información sobre dichos componentes y sus relaciones jerárquicas.
NTIA, Marco para la transparencia de los componentes de software, 2021 (original en inglés)
Aportación de la SBOM
La identidad del componente, la versión, el proveedor, las dependencias y los datos de soporte ayudan a identificar la exposición y respaldan la gestión de vulnerabilidades.
Aportación a la evaluación de riesgos
La arquitectura, el modelado de amenazas, la posibilidad de explotación, las pruebas de los controles y el análisis de daños a pacientes determinan qué significa la exposición para el dispositivo.
Registros vinculados
La FDA recomienda mantener la trazabilidad entre el modelo de amenazas, la evaluación de riesgos, la SBOM y los registros de pruebas. Un revisor debe poder partir de un componente afectado y localizar la decisión de riesgo y el resultado de verificación correspondientes. En un expediente técnico de la UE, explique cómo esos registros respaldan los requisitos aplicables del MDR o el IVDR.
Fuentes
- FDA, Ciberseguridad en productos sanitarios: consideraciones sobre el sistema de gestión de la calidad y contenido de las presentaciones previas a la comercialización, guía definitiva, febrero de 2026
- FDA, Gestión posterior a la comercialización de la ciberseguridad en productos sanitarios, guía definitiva, diciembre de 2016
- Comisión Europea, MDCG 2019-16, guía sobre ciberseguridad para productos sanitarios
- NTIA, Marco para la transparencia de los componentes de software: establecimiento de una lista común de materiales de software