A finales de junio del 2025, la FDA publicó su guía actualizada sobre Ciberseguridad en dispositivos médicos: Consideraciones del Sistema de Calidad y contenido para las presentaciones precomercialización. En esta guía, la FDA enfatiza la expectativa de que los riesgos y vulnerabilidades de ciberseguridad sean abordados en un modelo de amenazas. Se deben implementar procedimientos de ciberseguridad para respaldar los productos desde el diseño inicial hasta el fin de su vida útil. Las protecciones adecuadas de ciberseguridad deben considerarse en las entradas de diseño durante el desarrollo y no ser "añadidas posteriormente" una vez que este haya finalizado.
Si eres un desarrollador o fabricante responsable, o lo serás, de un dispositivo médico conectado, el proceso de ciberseguridad es algo en lo que necesitas invertir esfuerzo ahora.
Existen múltiples normas, como la ANSI/AAMI SW96:2023 y la IEC 81001-5-1:2021, ampliamente reconocidas en EE. UU. y la UE, que detallan las actividades y entregables que deben abordarse en relación con la evaluación de riesgos de ciberseguridad para el software de dispositivos médicos. Este breve artículo se centra en cómo realizar el análisis, que es la parte central del modelo de amenazas de ciberseguridad. El objetivo es proporcionar una perspectiva sobre la realización del análisis de riesgos de seguridad que sea impactante para todo el ciclo de vida de un dispositivo médico o de su software.
Planificación de la ciberseguridad del dispositivo
Desde una perspectiva premercado, los elementos clave de un análisis de seguridad son los siguientes:
Figura 1 – Pasos de ciberseguridad en el análisis de riesgos
Además de planificar la ciberseguridad, las compañías de dispositivos médicos ahora necesitan implementar un marco de trabajo elegido en su sistema de calidad. Para alcanzar un punto de cumplimiento, algunas empresas cometen el error de abordar la conformidad invirtiendo en una opción de software que lo hace todo, pero esto probablemente pasa por alto las verdaderas necesidades para abordar la ciberseguridad en su organización. La solución integral es la aplicación de un Marco de Desarrollo Seguro de Productos que aborde las actividades y tareas a lo largo de todo el ciclo de vida del producto (TPLC). Es necesario asignar recursos para desarrollar y actualizar procesos y SOPs, pero el núcleo para tener un proceso sólido es establecer un método de evaluación de riesgos eficaz y eficiente. Este método se representa como la Evaluación de Riesgos de Seguridad en la sección de análisis de la figura 1.
Enfoque en los Activos en la Tabla de Análisis de Seguridad
La Evaluación de Riesgos de Seguridad se utiliza para identificar controles de riesgo de seguridad potenciales y identificar vulnerabilidades. Deben establecerse dos tablas: una tabla de Evaluación de Riesgos que identifique y mantenga los controles de riesgo de seguridad, y una tabla de vulnerabilidades en curso que realice un seguimiento de las vulnerabilidades actuales. Las dos tablas de análisis pueden estar en hojas separadas de una simple hoja de cálculo, ya que tienen capacidades de filtrado y ordenación que permiten la gestión a largo plazo de las mismas. El contenido de la Tabla de Evaluación de Riesgos se refleja en la Tabla 1, abordando los Controles de Seguridad.
Tabla 1 – Tabla de análisis de Evaluación de Riesgos de Seguridad
El enfoque de la Evaluación de Riesgos de Seguridad deben ser los activos definidos en la arquitectura de seguridad y cómo las amenazas pueden explotar vulnerabilidades para comprometer dichos activos.
Los activos son elementos que tienen valor para el usuario, el paciente, la organización del usuario y el negocio, y que son relevantes para la seguridad. Los activos generalmente pueden incluir:
- Datos manejados y almacenados en el producto (por ejemplo, registros, datos de clientes o operativos, datos de configuración).
- Datos de carácter personal (por ejemplo, Información de Salud Protegida / PHI).
- Información de credenciales (por ejemplo, contraseñas, credenciales, claves).
- Software/firmware del producto.
- Servicios de terceros (por ejemplo, servicios en la nube, bibliotecas de código abierto, API).
El análisis debe incluir amenazas razonablemente prácticas para cada uno de los activos. El modelo STRIDE puede aplicarse para identificar la amenaza potencial en cada fila de análisis. El modelo STRIDE estándar y la propiedad de seguridad deseada se proporcionan en la Tabla 2 a continuación.
Tabla 2 – Definiciones del modelo STRIDE
Identificación de vulnerabilidades
Además de la Evaluación de Riesgos de Seguridad, se debe mantener, como se mencionó anteriormente, la tabla separada de vulnerabilidades en curso. Esta tabla contiene las vulnerabilidades conocidas que se han identificado en el dispositivo. Las vulnerabilidades son fallos o debilidades que podrían ser explotados por las posibles fuentes de amenaza. Las vulnerabilidades pueden identificarse a través de:
- La identificación de vulnerabilidades en la propia Evaluación de Riesgos de Seguridad.
- El análisis de penetración de ciberseguridad y las pruebas del producto.
- El escaneo mediante análisis estático del software desarrollado internamente con una herramienta SAST (Pruebas de Seguridad de Aplicaciones Estáticas).
- El escaneo mediante análisis dinámico con una herramienta DAST (Pruebas de Seguridad de Aplicaciones Dinámicas).
- La revisión de catálogos existentes como la Lista de Vulnerabilidades y Exposiciones Comunes (CVE), la Base de Datos Nacional de Vulnerabilidades (NVD), el National Health ISAC, y las notas de versión de SOUP/COTS.
- La identificación mediante el escaneo de vulnerabilidades usando una herramienta SCA (Análisis de Composición de Software) para componentes OTS o de código abierto.
La evaluación de las vulnerabilidades conocidas es necesaria antes de cualquier lanzamiento del producto y se mantiene hasta que el producto se retira. A medida que las vulnerabilidades se identifican y abordan, pueden eliminarse de la tabla de análisis de vulnerabilidades en curso. Las acciones sobre las vulnerabilidades se rigen por una determinación de la severidad de la vulnerabilidad y la puntuación CVSS. El modelo de puntuación CVSS identifica seis elementos base en su matriz para cada una de las vulnerabilidades identificadas: Vector de Ataque (AV), Complejidad del Ataque (AC), Privilegios Requeridos (PR), Interacción del Usuario (UI), Alcance (S) e Impacto (CIA) que mide la pérdida de confidencialidad, integridad y disponibilidad.
Determinar el impacto de las amenazas
En el análisis de riesgos de seguridad sabemos que el riesgo es la combinación de la severidad y la probabilidad de daño (Riesgo = P x S). Sin embargo, para el análisis de riesgos de seguridad, la FDA recomienda considerar la explotabilidad de una vulnerabilidad potencial versus el uso de la probabilidad de que ocurra un ataque con éxito. La explotabilidad debe basarse en cuán vulnerable es un sistema a ser comprometido. Cuanto mejores sean los controles de seguridad, menor será el riesgo. La evaluación de la aceptabilidad de las amenazas a los activos y vulnerabilidades debe guiarse por una matriz de decisión similar a la de la Tabla 3, impulsada por la severidad del daño y la explotabilidad.
Tabla 3 – Tabla de decisión de explotabilidad y severidad de seguridad
Los riesgos más altos requerirían controles de riesgo documentados en la tabla de Evaluación de Riesgos de Seguridad para reducir su explotabilidad y riesgo general. Los controles de riesgo deberían entonces impulsar requisitos en el diseño y posteriormente ser verificados como efectivos durante la verificación del diseño.
Conclusión
El análisis de seguridad de riesgos y vulnerabilidades debe mantenerse en dos tablas, ya que una es necesaria para identificar y mantener los riesgos de seguridad y la otra es una lista en curso de vulnerabilidades que requieren actualizaciones periódicas después del lanzamiento. Estas dos tablas de análisis deben actualizarse periódicamente, y la lista de vulnerabilidades en curso impulsa la aplicación de parches y la notificación a los clientes durante el mantenimiento del producto.
Ya sea que tu empresa esté comenzando o se encuentre en un punto más alto en el espectro de madurez de ciberseguridad para lograr un marco robusto y eficiente, un enfoque prioritario en las prácticas centrales de formato y análisis conducirá a mejores decisiones sobre herramientas y mejoras en la eficiencia y competencia del proceso.
Foto: Traitov, Getty Images
Bob Barrett, vicepresidente de ingeniería de sistemas en Full Spectrum, es un líder de ingeniería experimentado y constructor de equipos con enfoque en resultados. Posee fortalezas técnicas adquiridas durante más de 30 años en ingeniería de sistemas de dispositivos médicos, validación de sistemas y software, análisis de riesgos de seguridad, gestión de la calidad y gestión de proyectos. Bob pasó 15 años en la división de administración de medicamentos de Baxter, donde dirigió el grupo de ingeniería de sistemas. En Full Spectrum, Bob tiene el rol de ‘player coach’, liderando el equipo de ingeniería de sistemas mientras proporciona su profunda experiencia directamente a los clientes. Bob es un firme creyente en las técnicas de gestión de proyectos basadas en ritmo. Su capacidad para ser práctico o liderar equipos multidisciplinarios acelera los programas de desarrollo médico de los clientes desde el concepto hasta el lanzamiento al mercado.
Este artículo aparece a través del programa MedCity Influencers. Cualquier persona puede publicar su perspectiva sobre negocios e innovación en healthcare en MedCity News a través de MedCity Influencers. Haz clic aquí para saber cómo.