Regulación de la ciberseguridad de productos sanitarios

Sytance · Actualizado

La ciberseguridad de los productos sanitarios aborda los ataques que podrían afectar al uso seguro y eficaz de un dispositivo. Sus requisitos normativos se refieren al diseño del producto y a la forma en que el fabricante mantiene la protección tras su lanzamiento. Las normas aplicables dependen del mercado en el que se suministre el dispositivo.

Regulación de seguridad y ciclo de vida

Una debilidad de seguridad puede permitir que un atacante altere una medición clínica o interrumpa una función del dispositivo. El análisis debe explicar el efecto sobre el uso previsto del dispositivo y, a continuación, evaluar si el diseño controla ese riesgo. Las nuevas vulnerabilidades y los cambios de software pueden exigir actualizar la evaluación.

Capas normativas

Las presentaciones en Estados Unidos utilizan los requisitos y las guías de la FDA; la documentación técnica de la UE aborda el MDR o el IVDR. Un mismo resultado de ensayo puede respaldar ambos expedientes cuando se aplica a la configuración del dispositivo presentada. Cada expediente debe indicar qué requisito normativo respalda ese resultado.

FDA: fase previa a la comercialización

Explique el diseño de seguridad y las pruebas del dispositivo. Las presentaciones de dispositivos cibernéticos que cumplen los criterios también necesitan la información exigida por la sección 524B.

FDA: fase posterior a la comercialización

Evalúe las nuevas vulnerabilidades, proporcione las correcciones adecuadas y determine si debe notificarse una medida de campo.

MDR y MDCG de la UE

Explique cómo la seguridad del software respalda la seguridad y el funcionamiento del dispositivo y proporcione la información necesaria para el entorno de TI previsto.

Normas y registros

IEC 81001-5-1 describe el desarrollo y el mantenimiento seguros de software sanitario. Los registros del producto muestran cómo se aplicaron esas actividades a un dispositivo.

Registros de ciberseguridad

Los registros explican distintas partes del análisis. Por ejemplo, una SBOM identifica un componente utilizado en el dispositivo, mientras que un modelo de amenazas explica cómo podría aprovecharlo un atacante. El resultado de una prueba ayuda después a determinar si la protección elegida funciona.

  • La arquitectura de seguridad explica los límites del dispositivo, los flujos de datos, los límites de confianza, la vía de actualización y los sistemas conectados.
  • El modelado de amenazas explica cómo el uso indebido, las vías de ataque y los fallos de control pueden afectar a la seguridad o al funcionamiento.
  • Los registros SBOM identifican los componentes de software para poder rastrear la supervisión de vulnerabilidades y las decisiones sobre actualizaciones.
  • El etiquetado y la información para el usuario explican el uso seguro, los requisitos mínimos del entorno de TI, la gestión de actualizaciones y las responsabilidades compartidas.

Fuentes