Parte: 13 — Seguridad móvil, IoT e inalámbrica · Fuente: Practical IoT Hacking (Chantzis et al.), FDA Premarket Cybersecurity Guidance y estándares AAMI/IEC 80001 ⏱️ Duración estimada: 110 min · Nivel: Avanzado
Comprender los riesgos de ciberseguridad únicos de los dispositivos médicos —donde un fallo puede causar daño físico directo a un paciente— y cómo se evalúan y regulan. El alumno estudiará la superficie de ataque de dispositivos implantables (marcapasos, bombas de insulina) y hospitalarios (bombas de infusión, monitores), los estándares y regulaciones aplicables (FDA, IEC 62304/80001, MDR), y el marco ético/legal que hace de esta un área especialmente sensible.
⚠️ Nota ética y legal crítica: JAMÁS pruebes dispositivos médicos en uso clínico, conectados a pacientes o ajenos. La investigación legítima se realiza sobre unidades de laboratorio propias, retiradas de servicio, o mediante programas de divulgación coordinada con el fabricante. El daño potencial es a vidas humanas.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Panorama y safety vs. security | El riesgo es daño físico al paciente |
| 2 | Dispositivos implantables | Telemetría inalámbrica y batería |
| 3 | Dispositivos hospitalarios | Red clínica, bombas, monitores |
| 4 | Vulnerabilidades históricas | Lecciones de casos reales |
| 5 | Regulación (FDA, IEC, MDR) | Marco de cumplimiento obligatorio |
| 6 | SBOM y gestión de parches | Ciclo de vida largo y difícil de parchear |
| 7 | Divulgación coordinada | Cómo reportar sin causar daño |
Un dispositivo médico puede incluir hardware, software, red hospitalaria, servicio remoto y procesos humanos. La pregunta no termina en «¿puede explotarse?»: se rastrea si una pérdida de integridad, disponibilidad o confidencialidad altera terapia, alarma, diagnóstico o continuidad, y qué controles clínicos limitan el daño. Seguridad y eficacia permanecen durante todo el ciclo de vida.
La guía final de FDA de febrero de 2026 aborda diseño, sistema de calidad y contenido de presentaciones previas a mercado para dispositivos con riesgo de ciberseguridad. La legislación estadounidense aplicable a cyber devices incluye planes para vulnerabilidades, procesos de actualización y SBOM; fuera de EE. UU. cambian obligaciones. La clase usa FDA como fuente primaria concreta, no como norma mundial.
Parchar exige comprobar compatibilidad, validación y ventana clínica. Aplazar indefinidamente tampoco es neutral: se documentan riesgo residual y mitigaciones como segmentación, deshabilitar funciones o monitorizar. El fabricante mantiene divulgación coordinada y soporte; el hospital inventario, configuración, red y respuesta; ninguna parte puede trasladar todo el riesgo a la otra.
Las pruebas se realizan en gemelos, simuladores o dispositivos retirados y descontaminados, sin conexión a pacientes ni redes clínicas. Un hallazgo se comunica coordinadamente y evita detalles que aumenten daño antes de existir mitigación.
El fabricante publica una corrección para un monitor. El hospital no la instala de inmediato porque requiere validación con su central, pero segmenta el equipo, bloquea acceso remoto y programa ensayo. Registra riesgo y plazo. La decisión no es «seguridad contra disponibilidad»: es gestión temporal con controles y evidencia clínica.
| Término | Definición útil |
|---|---|
| Cyber device | Categoría legal estadounidense definida por FD&C Act; no todo dispositivo mundial. |
| TPLC | Gestión del producto durante diseño, mercado, soporte y retiro. |
| SBOM | Inventario de componentes que acelera evaluación, sin demostrar seguridad. |
| CVD | Divulgación coordinada de vulnerabilidades. |
| Daño clínico | Consecuencia sobre paciente, diagnóstico, terapia o continuidad. |
El alumno domina la clase cuando conecta una amenaza con una consecuencia clínica, reparte responsabilidades, diseña parche y mitigación temporal y prepara divulgación sin probar sobre pacientes ni producción.
Enfoque de esta clase: mayormente conceptual, regulatorio y de proceso.
El laboratorio práctico consiste en análisis de caso, modelado de amenazas
y redacción de un informe de divulgación coordinada — NO en atacar hardware médico real.
Este laboratorio es de análisis y proceso, no ofensivo sobre hardware clínico.
Elabora un informe de evaluación de riesgo y divulgación coordinada para un dispositivo médico (basado en un caso público o una unidad de laboratorio propia). Criterio de aceptación: el informe incluye un modelo de amenazas con al menos tres vectores, mapea cada riesgo a un requisito regulatorio concreto (FDA/IEC), y propone un proceso de divulgación responsable con plazos, sin publicar ningún exploit funcional.
| Síntoma / problema | Causa y cómo abordarlo |
|---|---|
| Probar hardware clínico activo | Riesgo a vidas y delito; usa solo unidades de laboratorio o análisis de casos |
| Tratar security y safety por separado | En medicina se integran; modela ambas juntas |
| Publicar el exploit sin coordinar | Puede causar daño; sigue divulgación coordinada con el fabricante |
| Ignorar el ciclo de vida largo | Dispositivos operan décadas; planifica parcheo y SBOM |
| Asumir red aislada | Los hospitales están cada vez más conectados; aplica IEC 80001 |
❓ ¿Por qué la seguridad de dispositivos médicos es diferente de otro IoT? Porque el impacto es directo sobre la salud y la vida del paciente, el ciclo de vida es larguísimo, el parcheo es difícil (requiere revalidación clínica) y hay regulación estricta.
❓ ¿Puedo investigar la seguridad de un dispositivo médico legalmente? Sí, sobre unidades propias/retiradas de servicio y siguiendo divulgación coordinada. Muchos fabricantes tienen programas de reporte. Nunca sobre dispositivos conectados a pacientes.
❓ ¿Qué papel juega el SBOM? Permite saber qué componentes de terceros usa el dispositivo para reaccionar cuando aparece una vulnerabilidad en una librería, algo crítico dado su ciclo de vida prolongado.
Clase 274 — Seguridad automotriz y bus CAN