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 |
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