La seguridad del IoT industrial consiste en proteger los sensores, controladores, gateways y plataformas en la nube que conectan los equipos físicos a las redes, de modo que las lecturas sean fiables y nadie pueda modificar un proceso físico sin autorización. Abarca la planta y el sistema de control tanto como los servicios en la nube a los que ahora viajan los datos de planta.

Conectar los equipos a la nube merece la pena, y también cambia quién puede llegar hasta ellos. Un responsable de OT o de TI que planifica esa conexión necesita una idea clara de lo que hacen los atacantes en entornos industriales, qué debilidades aprovechan y qué controles marcan la diferencia. Este artículo repasa cada uno de esos puntos, desde las redes SCADA hasta la plataforma en la nube.

Lo esencial

  • Los incidentes industriales más habituales empiezan en TI, mediante phishing, credenciales de acceso remoto robadas o ransomware, y llegan a las operaciones porque las redes no están separadas.
  • Los sistemas SCADA son vulnerables por sus protocolos antiguos sin autenticación, las redes planas, las cuentas compartidas y un software que no se puede parchear con rapidez.
  • Proteger un sistema SCADA empieza por un inventario de activos y la segmentación de la red, y continúa con el control del acceso remoto, las cuentas y las copias de seguridad.
  • IEC 62443 y NIST SP 800-82 son los marcos principales; en la parte de la nube, lo que más importa es el acceso individual por persona, las claves con alcance limitado y un registro de accesos.

¿Cuáles son las principales amenazas de seguridad del IoT industrial?

Los incidentes industriales llaman la atención cuando son espectaculares, pero las amenazas que causan más daño son corrientes. Cada una de las amenazas de seguridad del IoT industrial que siguen tiene un precedente real.

El ransomware que empieza en TI es el problema más frecuente. En mayo de 2021, un ransomware atacó los sistemas de negocio de Colonial Pipeline en Estados Unidos. No se informó de que los sistemas de control del oleoducto se hubieran cifrado; aun así, la empresa detuvo la operación del oleoducto durante varios días por precaución, porque no podía estar segura de que el ataque no se propagara y no podía facturar con normalidad. Siguió una escasez de combustible a lo largo de la costa este de Estados Unidos, todo a raíz de un incidente en la TI de oficina.

El acceso remoto robado o débil le sigue de cerca. Los fabricantes y los integradores a menudo necesitan acceder a los equipos, y una herramienta de escritorio remoto o una cuenta VPN con una contraseña compartida se convierte también en la vía de entrada más fácil para un atacante.

Las credenciales por defecto en los dispositivos conectados son otra vía de entrada habitual. En 2016, la botnet Mirai se hizo con cientos de miles de cámaras, routers y otros dispositivos IoT simplemente probando los nombres de usuario y contraseñas de fábrica, y después los usó para ataques masivos de denegación de servicio. Los gateways y sensores industriales que se entregan con credenciales por defecto conllevan el mismo riesgo.

Los ataques dirigidos contra sistemas de control son más raros y más graves. Stuxnet, descubierto en 2010, manipuló PLC de Siemens para dañar centrifugadoras de enriquecimiento de uranio en Irán mientras mostraba a los operadores valores normales. Triton, encontrado en 2017 en una planta petroquímica de Arabia Saudí, atacó un sistema instrumentado de seguridad Triconex de Schneider Electric, la capa destinada a detener un proceso de forma segura.

Por último, están el factor interno y el accidente: un contratista con más acceso del necesario, o un ingeniero que conecta un portátil a la red de control para «comprobar una cosa un momento».

Los dispositivos conectados añaden una categoría más: el acceso físico. Un gateway montado en un armario exterior sin cerradura, o un sensor cuyo puerto de configuración queda al alcance de un destornillador, puede reiniciarse, sustituirse o usarse como vía de entrada a la red. Los emplazamientos remotos, como las estaciones de bombeo y las subestaciones, se visitan pocas veces, así que una manipulación allí puede pasar inadvertida durante semanas salvo que la notifiquen contactos de puerta o interruptores en los armarios.

Vulnerabilidades de seguridad habituales en sistemas SCADA

La seguridad de los sistemas SCADA es difícil por razones estructurales, no porque los operadores sean descuidados. Las debilidades habituales se repiten en todos los sectores.

Los protocolos sin autenticación son la debilidad más antigua. El Modbus clásico y el DNP3 original se diseñaron para redes serie cerradas; cualquier dispositivo que pueda llegar a un controlador puede enviarle una orden válida. Existen variantes seguras, pero los equipos más antiguos a menudo no pueden usarlas.

Las redes planas lo empeoran. En muchas plantas, la red de oficina, los servidores SCADA y los PLC están en una misma red sin un cortafuegos entre ellos, así que un solo portátil infectado puede llegar a todo.

Las cuentas compartidas en los HMI y las estaciones de ingeniería hacen que cada operador inicie sesión como «operador», lo que impide saber quién hizo qué.

La aplicación de parches es lenta. Los servidores SCADA suelen funcionar con sistemas operativos antiguos porque el software SCADA o un driver solo está certificado para esa versión, y una planta no puede reiniciar un proceso en marcha cada mes.

La exposición a internet es un hallazgo recurrente. Los buscadores que rastrean internet, como Shodan, encuentran con regularidad HMI, PLC y gateways de acceso remoto accesibles directamente desde cualquier lugar.

Los soportes extraíbles y los portátiles de ingeniería son una vía más discreta. Las estaciones de ingeniería contienen el software capaz de reprogramar todos los controladores de la planta, y a menudo son las máquinas a las que los contratistas se conectan con sus propios portátiles y memorias USB. Se cree que Stuxnet llegó a su red objetivo aislada a través de soportes extraíbles, y por eso muchas plantas analizan ahora los dispositivos USB en un quiosco antes de permitir que se acerquen a un sistema de control.

El ataque de diciembre de 2015 contra distribuidoras eléctricas ucranianas usó varias de estas debilidades a la vez. Los atacantes entraron mediante correos de phishing en las redes de oficina, recopilaron credenciales, pasaron al entorno de control y abrieron interruptores a distancia, lo que dejó sin electricidad a unos 225 000 clientes durante varias horas.

¿Cómo se protege un sistema SCADA?

Ningún producto por sí solo protege un sistema SCADA. Los pasos siguientes siguen el orden que recomiendan la mayoría de los marcos, porque cada uno facilita el siguiente.

  1. Elaborar un inventario de activos. Enumere todos los controladores, servidores, estaciones de trabajo, gateways y conexiones de red, con sus versiones de firmware.
  2. Segmentar la red. Separe la red de negocio de la red de control, con una DMZ (una zona intermedia de separación) entre ambas para todo lo que necesiten las dos partes, como una copia del historiador. Permita solo el tráfico necesario y solo en el sentido en que se necesita.
  3. Eliminar la exposición directa a internet. Nada de la red de control debería ser accesible desde internet. Los datos que salen hacia servicios en la nube deberían hacerlo mediante conexiones salientes desde un gateway situado en la DMZ.
  4. Controlar el acceso remoto. Use un único punto de entrada gestionado con autenticación multifactor, cuentas individuales para los fabricantes y un acceso que solo se activa cuando hace falta.
  5. Dar a cada persona su propia cuenta. Sustituya los inicios de sesión compartidos por cuentas personales con el mínimo privilegio que requiere cada puesto.
  6. Parchear donde se pueda y compensar donde no. Pruebe las actualizaciones en un sistema de reserva; cuando una máquina no se pueda parchear, restrinja qué puede comunicarse con ella.
  7. Monitorizar la red. Las herramientas de detección de intrusiones industriales aprenden el tráfico normal entre controladores y señalan dispositivos nuevos u órdenes inusuales.
  8. Hacer copias de seguridad y ensayar la recuperación. Guarde copias sin conexión de los programas de los PLC, las configuraciones SCADA y las imágenes de los servidores, y pruebe a restaurarlas.

La ciberseguridad de un sistema SCADA también depende de las personas. Los operadores y los ingenieros deberían saber cómo notificar un correo sospechoso o una memoria USB encontrada en el aparcamiento, y el plan de respuesta a incidentes debería indicar quién decide si se mantiene el proceso en marcha.

Con un presupuesto limitado, el orden importa más que la exhaustividad. Una planta que tiene un inventario, un cortafuegos entre la red de oficina y la de control, ninguna exposición directa a internet y cuentas personales con acceso remoto multifactor ha eliminado las vías utilizadas en la mayoría de los incidentes descritos más arriba. La monitorización de la red y los niveles de seguridad formales merecen añadirse después, no en su lugar.

Normas de seguridad del IoT industrial

Dos marcos dominan las normas de seguridad del IoT industrial. IEC 62443 es una serie de normas internacionales para proteger los sistemas de automatización y control industrial. Introduce las zonas (grupos de activos con las mismas necesidades de seguridad) y los conductos (las conexiones controladas entre ellas), define niveles de seguridad del 1 al 4 frente a atacantes cada vez más capaces y tiene partes separadas para los propietarios de activos, los integradores de sistemas y los proveedores de productos.

NIST SP 800-82, publicada por el Instituto Nacional de Normas y Tecnología (NIST) de Estados Unidos, es una guía sobre la seguridad de la tecnología operativa. La revisión 3, publicada en septiembre de 2023, amplió su alcance de los sistemas de control industrial a la OT en general y vincula sus recomendaciones con el Marco de Ciberseguridad del NIST.

La regulación también avanza. En la Unión Europea, la Directiva NIS2 abarca la energía, el agua, la industria manufacturera y otros sectores, y los Estados miembros debían aplicarla a partir de octubre de 2024. El Reglamento de Ciberresiliencia de la UE añade requisitos de seguridad para los productos con elementos digitales, con la mayoría de las obligaciones aplicables a partir de diciembre de 2027, lo que afectará a los sensores y gateways conectados que se vendan en la UE.

También conviene saber cómo se relacionan con ISO/IEC 27001, la norma más extendida para los sistemas de gestión de la seguridad de la información. ISO/IEC 27001 describe cómo gestiona una organización el riesgo de seguridad en general, mientras que IEC 62443 añade los requisitos técnicos y organizativos propios de los sistemas de control. Muchas empresas industriales usan ambas: la 27001 para la empresa y su TI, y la 62443 para las plantas.

Buenas prácticas de seguridad del IoT industrial

La parte de la nube de una conexión de IoT industrial necesita la misma disciplina que la parte de la planta. Algunas buenas prácticas de seguridad del IoT industrial son válidas en cualquier plataforma. Los datos deberían salir de la planta mediante conexiones salientes y cifradas que inicia el gateway, de modo que no haya ningún puerto de entrada abierto. Las redes de sensores inalámbricos aportan su propia protección: LoRaWAN, por ejemplo, cifra cada mensaje con claves de sesión AES-128, lo que solo sirve si las claves con las que se aprovisionan los sensores se manejan con cuidado. Cada gateway y cada conexión necesitan sus propias credenciales, en lugar de una compartida entre emplazamientos. Esas claves de aprovisionamiento deberían almacenarse cifradas y ser visibles solo para las personas que las necesitan. El firmware de los gateways merece la misma atención en materia de parches que el de un PLC, porque el gateway se sitúa justo en la frontera entre la planta e internet.

En la parte de la plataforma, los controles de acceso de Kilo funcionan por persona y por página, como Editar, Ver o Sin acceso, de modo que un contratista puede consultar los paneles sin poder tocar las reglas ni los conectores. Las claves API tienen un alcance limitado a cada área, con permisos de lectura y de escritura separados, pueden llevar una fecha de caducidad y dejan de funcionar en cuanto se rotan. El Registro de auditoría guarda las invitaciones, los cambios de permisos y las bajas, para que pueda demostrar quién tuvo acceso y cuándo.

Preguntas frecuentes sobre seguridad del IoT industrial

¿En qué se diferencia la seguridad del IoT industrial de la seguridad informática?

En TI, la confidencialidad suele ir primero; en los sistemas industriales, lo primero son la disponibilidad y la seguridad física, porque detener un proceso puede ser peligroso o caro. Además, los equipos industriales a menudo permanecen en servicio de 10 a 15 años, y a veces más de 20, mucho más que la TI de oficina, así que la seguridad tiene que adaptarse a dispositivos que no se pueden sustituir con rapidez.

¿Quién es responsable de la ciberseguridad de un sistema SCADA?

El propietario del activo, es decir, la organización que opera la planta, es quien responde de ella. IEC 62443 reparte el trabajo: los proveedores de productos fabrican dispositivos seguros, los integradores los configuran de forma segura y el propietario del activo opera y mantiene el sistema de forma segura durante toda su vida útil.

¿Qué es el zero trust en la seguridad del IoT industrial?

Zero trust (confianza cero) es un enfoque, descrito en NIST SP 800-207, en el que no se confía en ningún usuario ni dispositivo por su ubicación en la red. Cada solicitud se autentica y se autoriza. En las plantas suele aplicarse de forma gradual, empezando por el acceso remoto y la frontera entre TI y OT.

Antes de conectar nada de una línea de producción, pruebe el modelo de acceso con una señal inofensiva. Instale un sensor de temperatura en una sala técnica con el plan gratuito de Kilo, que no pide datos de pago, invite a un compañero solo con acceso Ver y cree una clave API con alcance de lectura y fecha de caducidad. Después, rote esa clave y compruebe que un script que usa el valor antiguo deja de funcionar.