Ciberseguridad de dispositivos médicos

STRIDE es una metodología de modelado de amenazas desarrollada originalmente en Microsoft y popularizada luego por el investigador de seguridad Adam Shostack. Ofrece a los equipos de ingeniería una forma estructurada de recorrer la arquitectura de un sistema y preguntarse, de manera sistemática, qué podría salir mal, en lugar de apoyarse en la intuición o en una lista de control genérica. El nombre es un acrónimo de seis categorías de amenazas:

• Suplantación de identidad (Spoofing) — un atacante se hace pasar por un usuario, dispositivo o componente legítimo (p. ej., una app móvil falsa que se presenta como la app compañera emparejada con el dispositivo).
• Manipulación (Tampering) — se modifican datos o código sin autorización (p. ej., un paquete de actualización de firmware alterado en tránsito).
• Repudio (Repudiation) — se realiza una acción y el sistema no puede demostrar quién la ejecutó, por registros de auditoría ausentes o poco confiables (p. ej., un cambio de dosis sin un registro verificable de quién lo emitió).
• Divulgación de información (Information Disclosure) — datos sensibles quedan expuestos a quienes no deberían verlos (p. ej., datos de pacientes enviados por un canal sin cifrar).
• Denegación de servicio (Denial of Service) — se degrada o se bloquea la disponibilidad del sistema (p. ej., una interfaz inalámbrica saturada de modo que los comandos legítimos no pasan).
• Elevación de privilegios (Elevation of Privilege) — un atacante obtiene capacidades que no debería tener (p. ej., eludir la autenticación para emitir un comando reservado a los clínicos).

Aplicado a un diagrama de flujo de datos del dispositivo —sus procesos, almacenes de datos, entidades externas y los límites de confianza entre ellos—, STRIDE hace aflorar amenazas concretas y específicas del dispositivo de forma temprana, antes de ejecutar una sola prueba sobre una versión real.

El modelado de amenazas y las pruebas de penetración responden preguntas distintas, y el orden importa. El modelado de amenazas es un ejercicio de diseño, a nivel de arquitectura: pregunta qué podría salir mal según cómo está construido el sistema, antes de que esté terminado. Las pruebas de penetración ocurren en la etapa de implementación: intentan efectivamente romper un sistema en ejecución. Hacer primero el modelado de amenazas es una práctica estándar de desarrollo seguro, reflejada en guías como el marco de desarrollo seguro de software del NIST y las propias guías de pruebas de OWASP, por varias razones concretas:

• Acota el pentest. Sin un modelo de amenazas, un pentest tiende a explorar de forma genérica; con uno, los evaluadores pueden apuntar a las rutas de ataque específicas que la arquitectura hace posibles —el emparejamiento BLE, un endpoint concreto de la API, el mecanismo de actualización de firmware— en lugar de adivinar.
• Detecta fallas de diseño cuando corregirlas es barato. Un error en los límites de confianza hallado en una pizarra cuesta un cambio de diseño; el mismo error hallado en un informe de pentest después de la implementación cuesta un retrabajo.
• Es lo que esperan ver los reguladores. Las expectativas de ciberseguridad premarket de la FDA para dispositivos médicos piden un proceso documentado de modelado de amenazas como parte de un marco de desarrollo seguro del producto; un informe de pentest por sí solo no se considera evidencia equivalente.
• Le da al pentest un criterio de finalización. Sin un modelo de amenazas es difícil afirmar que un pentest fue exhaustivo; con uno, los evaluadores pueden marcar cada amenaza identificada como probada, mitigada o aceptada.

Antes de identificar amenazas hay que describir el sistema con precisión. Eso empieza con un diagrama de flujo de datos: qué datos se mueven, hacia dónde, a través de qué procesos y dónde se almacenan. Los límites de confianza se dibujan donde los datos pasan de un nivel de confianza a otro —por ejemplo, de la radio BLE del dispositivo a su lógica de aplicación, o de una app móvil a un backend en la nube—. Cada límite de confianza es un lugar que un atacante podría intentar cruzar, y por eso es también donde corresponden los controles de seguridad: autenticación, autorización, cifrado y verificaciones de integridad.

Mapear esto en un dispositivo real define además su superficie de ataque —el conjunto completo de puntos (interfaz BLE, puerto de depuración, app móvil, API en la nube, mecanismo de actualización de firmware) que un atacante podría apuntar—, de modo que nada se pase por alto solo porque no figuraba en la lista mental de nadie.

Bluetooth Low Energy es la interfaz inalámbrica más común en los dispositivos médicos conectados, y tiene puntos débiles conocidos y bien documentados si no se configura con cuidado:

• Emparejamiento — BLE admite varios métodos de emparejamiento (Just Works, Passkey Entry, Numeric Comparison, Out-of-Band). Just Works, el más simple y frecuente en dispositivos sin pantalla ni teclado, no ofrece protección frente a un atacante intermediario activo (man-in-the-middle) durante el emparejamiento: es una limitación real que hay que resolver en el diseño, no dar por superada.
• Cifrado — una vez emparejado, BLE Secure Connections cifra el enlace con AES-CCM según lo define la especificación central de Bluetooth. El cifrado protege los datos en tránsito, pero solo desde el momento en que el emparejamiento tiene éxito, y por eso el propio paso de emparejamiento requiere escrutinio.
• Autorización de comandos — el cifrado a nivel de enlace no es lo mismo que la autorización. Un dispositivo debe verificar, en la capa de aplicación, que un par conectado esté realmente autorizado a emitir un comando determinado (p. ej., cambiar un ajuste de terapia), y no solo que el enlace esté cifrado.
• Ataques de proximidad y de retransmisión — el alcance de BLE es limitado, pero no es una garantía: se han demostrado ataques de retransmisión y de intermediario que extienden el alcance efectivo contra productos BLE reales, por lo que la proximidad no debe tratarse como un control de seguridad por sí sola.

La mayoría de los dispositivos médicos conectados se entregan con una app móvil compañera y una API de backend, y ambas están dentro del alcance de una revisión de seguridad.

• OWASP MASVS (Mobile Application Security Verification Standard) es el estándar de referencia para la seguridad de aplicaciones móviles: cubre almacenamiento local de datos, criptografía, autenticación y gestión de sesiones, comunicación de red, interacción con la plataforma y resistencia a la ingeniería inversa. Ofrece una lista concreta contra la cual verificar, en lugar de una vaga sensación de que "la app debería ser segura".
• OWASP IoT Top 10 enumera las clases de vulnerabilidad más comunes en dispositivos conectados/IoT: credenciales débiles o incrustadas en el código, servicios de red inseguros, interfaces inseguras del ecosistema, falta de un mecanismo de actualización seguro, uso de componentes inseguros o desactualizados, protección de la privacidad insuficiente, transferencia y almacenamiento de datos inseguros, falta de gestión del dispositivo, configuraciones por defecto inseguras y falta de endurecimiento físico. Es útil justamente porque se construyó a partir de incidentes reales de IoT, no de riesgos teóricos.

La ciberseguridad no es un frente de trabajo separado del resto del cumplimiento de un dispositivo: se integra directamente en los mismos procesos que ya existen para la seguridad del paciente (safety).

• IEC 62304 rige el ciclo de vida del software. Los requisitos de seguridad (security) y los controles que los implementan se gestionan como requisitos de software y controles de riesgo de software dentro de ese mismo ciclo de vida, no como un añadido al final.
• ISO 14971 es la norma de gestión de riesgos que ya se usa para evaluar los peligros para la seguridad del paciente, y es el mismo marco que se usa para evaluar los riesgos de ciberseguridad: una amenaza que permita a un atacante causar daño a un paciente es un riesgo como cualquier otro, evaluado por su severidad y probabilidad y tratado con controles de riesgo.
• Las expectativas de ciberseguridad premarket de la FDA para dispositivos conectados («cyber devices»), vigentes desde 2023, piden a los fabricantes presentar un plan para identificar y abordar vulnerabilidades, una lista de materiales de software (SBOM) y evidencia de un marco de desarrollo seguro del producto, que incluye un proceso documentado de modelado de amenazas.

Así como un requisito de seguridad del paciente en IEC 62304 debe ser trazable hasta su evidencia de verificación, un control de ciberseguridad debe ser trazable hasta la amenaza que mitiga. Eso implica documentar, para cada amenaza identificada: el requisito o control que la aborda, cómo se verificó ese control (revisión, prueba o análisis) y el riesgo residual que queda después. Esto es lo que permite a un revisor, auditor u organismo notificado seguir la cadena desde «esta es una amenaza que identificamos» hasta «esta es la prueba de que está resuelta», sin tener que darlo por cierto.

• Desarrollo de modelos de amenazas y arquitecturas de seguridad para dispositivos médicos conectados (IoT / Software como Dispositivo Médico)
• Auditoría y mejora de procesos de verificación de firmware, incluida la identificación de vulnerabilidades originadas por brechas en la cobertura de pruebas
• Pruebas de seguridad de BLE con herramientas de captura y análisis de tráfico