Securización del IoT Legacy, entornos críticos

Retos específicos en IoMT/IIoT

En OT/ICS e IoT es habitual operar activos 10–20+ años, sin parches de seguridad y con firmware susceptible a vulnerabilidades conocidas, lo que impide aplicar controles “tradicionales” de TI y obliga a diseñar contenciones en red y compensaciones técnicas.

Muchos dispositivos hablan Modbus/TCP, DICOM, HL7, u otros protocolos sin cifrado/autenticación por defecto; cuando se exponen a redes planas, facilitan movimientos laterales y exfiltración. Marcos como MITRE ATT&CK for ICS documentan tácticas y técnicas reales contra entornos industriales, útiles para priorizar controles defensivos. (1, 4)

En entorno sanitario, la GDPR (art. 32) exige cifrado y garantías de confidencialidad/integridad; la FDA refuerza requisitos de ciberseguridad en el ciclo de vida del producto (incluido SBOM) en sus guías de 2023 y 2025; en la UE, NIS2 eleva obligaciones de gestión de riesgo y notificación de incidentes para sectores esenciales. (5, 6, 7)

Marcos y normativas a tener en cuenta

Aislamiento de red cuando solo se requiere contención (sin cifrado)

Cuando el objetivo es minimizar el alcance de posibles compromisos (p.ej., equipos legacy que no procesan datos personales), la prioridad es aislar y controlar los caminos entre dispositivos y consumidores de sus servicios.

• Segmentación y microsegmentación
  • VLANs dedicadas por tipo de activo, función y criticidad; ACLs y firewalls L3/L7 entre VLANs para whitelisting de puertos/protocolos estrictamente necesarios. Este patrón encaja con las zonas/conductos de IEC 62443 y las topologías recomendadas por NIST SP 800‑82. (2, 1)
  • Microsegmentación adicional (p. ej., listas por IP/MAC o políticas basadas en identidad del dispositivo) para impedir broadcast lateral; usar controles a nivel de switch/hipervisor si es posible. (10)
• Control de acceso a puertos (NAC)
  • IEEE 802.1X en el borde para autenticar el dispositivo antes de darle conectividad (EAPOL + RADIUS), aplicando VLAN dinámica o perfiles específicos. (13, 14)
  • Donde 802.1X no sea viable (sensores muy simples), se puede combinar MAB (MAC Authentication Bypass) con listas de permit estrictas y perfiles de seguridad. (14)
• V isibilidad y control de tráfico
  • Firewalls/IPS con inspección de protocolos industriales para filtrar funciones peligrosas (p. ej., bloqueo de escritura en Modbus excepto desde estaciones autorizadas), alineado con estrategias de mitigación OT. (1)
  • Baselines de comportamiento y reglas de detección de anomalías que mapeen con tácticas ATT&CK for ICS (p. ej., Lateral Movement, Impair Process Control). (4)

Diagrama de referencia (aislamiento por zonas)

Fig. 1 - El diseño refleja zonas separadas (VLAN) interconectadas únicamente a través de firewalls/IPS, con plano de gestión y telemetría centralizados. (1)

Cuando también se requiere cifrado de datos en tránsito

En IoMT y en IIoT con propiedad intelectual sensible, el cifrado y la autenticación mutua son obligatorios para cumplir protección de datos y preservar la integridad de los procesos. (5, 1)

Opciones prácticas:

• Túneles IPsec site-to-site o host-to-gateway para encapsular protocolos inseguros (Modbus, DICOM, HL7) entre la VLAN IoT y los consumidores (HIS/SCADA). Recomendado cuando el dispositivo no soporta TLS y es viable insertar un gateway. (1)
• TLS/DTLS nativo en protocolos application-layer:
  • OPC UA incorpora autenticación basada en certificados, firma y cifrado de mensajes, con políticas de seguridad y perfiles definidos por la OPC Foundation. (15)
  • MQTT sobre TLS (puerto 8883) con validación de certificados del broker y, preferiblemente, mutual TLS para clientes (mTLS). (1, 6)
• Cifrado de enlace L2 con MACsec (IEEE 802.1AE) para proteger tramos Ethernet/metropolitanos donde se desee confidencialidad/ integridad a línea de puerto, complementando o sustituyendo IPsec según el caso. (17, 18)

Añadiendo seguridad a equipos legacy: Para dispositivos que no soportan TLS/IPsec, se pueden interponer gateways de seguridad (hardware/software) que ofrezcan: terminación de túneles (IPsec/DTLS), conversión de protocolo (p. ej., Modbus→OPC UA), control de comandos y gestión de certificados centralizada. (1, 15)

Diagrama de referencia (túneles seguros/“crypto gateways”) Fig. 2 - El gateway cifra el tráfico de equipos que no pueden hacerlo y valida identidades mediante certificados. (15)

Fig. 2 - El gateway cifra el tráfico de equipos que no pueden hacerlo y valida identidades mediante certificados. (15)

¿Aislamiento solo o aislamiento + cifrado?

Gestión centralizada, línea base y XDR

La gestión de activos conectados empieza con un inventario exhaustivo (tipo, versión, vulnerabilidades conocidas) y la evaluación de las capacidades mínimas del dispositivo siguiendo por ejemplo NISTIR 8259A (identidad única, registro, actualización segura, configuración protegida). (3)

Para TLS/mTLS y OPC UA, se establece una PKI (o servicio gestionado) y políticas de emisión/rotación y revocación; en OPC UA, por ejemplo, se deben gestionar las listas de confianza y certificados de instancia de aplicación de forma centralizada. (15)

Es importante consolidar los logs de red, endpoint y aplicaciones en una plataforma XDR para:

• Correlacionar telemetrías (FW/IPS, NDR, EDR, IoT/OT) y priorizar incidentes.
• Modelar la baseline por dispositivo/zona y detectar desviaciones (e.g., nuevas IP destino, volumen anómalo).
• Orquestar respuesta (aislar VLAN, bloquear conducto, revocar certificado).

Recomendaciones prácticas por capas

• Capa 0 – Gobierno y riesgo
  • Es necesario definir zonas y conductos (IEC 62443) y asignar niveles de seguridad (SL) por criticidad del proceso y exposición. (2)
  • En sanidad, se debería aplicar IEC 80001‑1 para gestionar los riesgos de seguridad/efectividad sobre la seguridad del paciente; alineado con GDPR y, si aplica, con la FDA. (11, 5, 6)
  • Desplegad ISMS (Sistemas de gestión de la seguridad de la información) con ISO 27001:2022, anexando controles de red, cifrado, gestión de vulnerabilidades y continuidad. (12)
• Capa 1 – Red y acceso
  • VLAN por función (dispositivos de imagen, laboratorio, HVAC, PLCs) y firewalls con política “deny‑all + allow‑list” entre VLANs. (1)
  • 802.1X en puertos de acceso; perfiles con QoS y VLAN dinámica según identidad del dispositivo/rol; fallback con MAB controlado si es imprescindible. (14)
  • MACsec en troncales/enlaces WAN si se requiere confidencialidad a nivel 2 sin encapsular IP, o para ocultar metadatos de red. (17, 18)
• Capa 2 – Transporte cifrado / aplicación
  • MQTT: usar mínimo TLS 1.2 y mTLS, separación por topics con controles de autorización; desactivar conexiones anónimas en el broker. (16)
  • OPC UA: seleccionar unas política de seguridad robustas y gestionar los certificados desde global discovery server cuando escale el entorno. (15)
  • Gateways IPsec/DTLS delante de equipos legacy; restringiendo comandos peligrosos y protocol break para inspeccionar y registrar. (1)
• Capa 3 – Operación y mantenimiento
  • Gestión de parches: donde el fabricante ya no da soporte, es necesario documentar la compensación (segmentación estricta, solo lectura, supervisión reforzada) según IEC 62443/NIST. (1, 2)
  • SBOM y vulnerabilidades: para IoMT, incorporar SBOM y un plan de coordinated vulnerability disclosure tal y como espera FDA. (6)
  • Baselines y D&R conectados a XDR: por ejemplo, alerta si un equipo de radiología inicia conexiones salientes poco habituales o si un PLC cambia su patrón de escritura. (19)

Casos prácticos

• Hospital: aislamiento + cifrado para equipos médicos (IoMT)
  • Reto: Tomógrafo legacy que envía DICOM en claro y no admite TLS; debe integrarse con PACS/HIS cumpliendo GDPR y políticas de seguridad clínica.
  • Solución:
    1. VLAN IoMT-Imagen con firewall que solo permite DICOM hacia el gateway (deny-all al resto). (1)
    2. Gateway de seguridad que encapsula DICOM en IPsec hasta la VLAN de servicios del PACS; autenticación vía certificados mTLS gestionados en PKI. (1)
    3. 802.1X en el switch del tomógrafo y NAC para aplicar perfil de confinamiento si falla la autenticación. (14)
    4. Monitoreo XDR: baseline de volumen DICOM; alerta por desvíos y correlación con eventos de firewall. (19)
    5. Gobierno: riesgo gestionado bajo IEC 80001‑1 y medidas técnicas alineadas con GDPR art.32. (11, 5)
• Fábrica: microsegmentación para PLCs con protocolos mixtos (IIoT)
  • Reto: Celdas de producción con PLCs antiguos (Modbus) y nuevas estaciones OPC UA; prioridad en disponibilidad y seguridad del proceso.
  • Solución:
    1. Zonas 62443 por celda y conductos controlados por firewalls con políticas de allow-list por función y horario. (2)
    2. OPC UA con cifrado y firma entre servidores y HMI; para Modbus, gateway que hace protocol break y registra comandos write. (15)
    3. MACsec en troncales entre switches de la zona para proteger datos de ingeniería y prevenir sniffing en el taller. (17)
    4. Detección de anomalías basada en ATT&CK for ICS (p.ej., intentos de Inhibit Response Function); respuesta orquestada por XDR (aislamiento de la celda). (4, 19)

Buenas prácticas clave

• Inventario vivo y clasificación por riesgo/criticidad; verificar capacidades básicas del dispositivo según NISTIR 8259A. (3)
• Arquitectura de confianza cero: autenticación/ autorización continua de usuarios y dispositivos, mínima exposición de servicios, verificación explícita y segmentación perimetral interna. (8)
• Zonas y conductos (IEC 62443) con política de mínimos privilegios y allow‑list de flujos; microsegmentación allí donde la celda sea heterogénea. (2)
• Cifrado por defecto para datos personales/sensibles; TLS 1.2/1.3 en MQTT/HTTPS y OPC UA Security; IPsec/MACsec cuando el trayecto o el dispositivo lo exijan. (16, 15, 17)
• NAC (802.1X) y control de puerto; evitar puertos abiertos y redes planas. (14)
• Gestión de certificados/PKI y rotación periódica; evitar certificados perpetuos y confíe en almacenes de confianza gestionados. (15)
• Registro y telemetría unificados en XDR, con detecciones alineadas a ATT&CK for ICS. (19, 4)
• Cumplimiento: mapear controles a ISO 27001:2022, GDPR, NIS2 y, en IoMT, a IEC 80001‑1/FDA. (12, 5, 7, 11, 6)

Tabla de protocolos y opciones de securización

Protocolo Soporte nativo de seguridad Recomendación MQTT No cifra por defecto; debe usarse TLS; soporta mTLS. (16) Broker en 8883 con TLS 1.2+ y mTLS; autorización por topics. OPC UA Sí: autenticación por certificados, firma y cifrado, políticas de seguridad. (15) Aplicar SecurityPolicies robustas y gestionar TrustLists. Modbus/TCP No (legacy) Encapsular en IPsec/DTLS vía gateway; filtrado por función en firewall/IPS. (1) DICOM/HL7 Varía según implementación Túneles IPsec o TLS en aplicaciones modernas; segmentación estricta en legacy. (1) Enlace Ethernet MACsec disponible (L2) para confidencialidad/ integridad. (17) Usar en troncales/metro cuando se requiera cifrado a línea.

¿Cómo empezar?

1. Descubrir y clasificar activos IoT/OT; identificar gaps frente a NISTIR 8259A. (3)
2. Modelar zonas/conductos (IEC 62443) y definir políticas de conectividad mínimas. (2)
3. Desplegar segmentación (VLAN + firewalls/IPS) y NAC 802.1X. (14)
4. Implementar cifrado donde corresponda: TLS/mTLS (MQTT/OPC UA), IPsec para legacy, MACsec en troncales. (16, 15, 17)
5. Centralizar gestión (PKI, parches, configuración) y activar XDR con detecciones basadas en ATT&CK for ICS. (19, 4)
6. Alinear cumplimiento con ISO 27001:2022, GDPR, NIS2, IEC 80001‑1/FDA según el sector. (12, 5, 7, 11, 6)

Conclusión

Securizar IoMT e IIoT no es elegir entre red o criptografía, sino equilibrar aislamiento inteligente y cifrado/autenticación según el riesgo y los requisitos normativos. Los dispositivos legacy no tienen por qué quedar fuera: con gateways de seguridad, túneles y microsegmentación se puede contener su riesgo y seguir operándolos con garantías. Finalmente, la gestión centralizada y la observabilidad con XDR—apoyadas en marcos como NIST SP 800‑82, IEC 62443 y Zero Trust—permiten detectar, responder y demostrar cumplimiento de forma sostenible. (1, 2, 8)

Referencias

• NIST SP 800‑82 Rev.3 – Guide to OT Security (2023). (1)
• NIST SP 800‑207 – Zero Trust Architecture (2020). (8, 9)
• NISTIR 8259A – IoT Device Cybersecurity Capability Core Baseline (2020). (3)
• IEC/ISA 62443 – Zonas y conductos; SL; requisitos (resúmenes). (2, 10)
• IEC 80001‑1:2021 – Risk management for IT-networks with medical devices. (11)
• GDPR art. 32 – Seguridad del tratamiento. (5)
• NIS2 (UE 2022/2555) – Ciberseguridad en la UE. (7)
• FDA (2023/2025) – Cybersecurity in Medical Devices: Quality System Considerations. (6)
• OPC UA Part 2 – Security (2024-11-29). (15)
• MQTT + TLS – Best practices (HiveMQ, 2024). (16)
• MACsec IEEE 802.1AE – Overview (IEEE/Cisco). (17, 18)
• MITRE ATT&CK for ICS – Matriz y técnicas. (4)