Seguridad SCADA: amenazas, arquitectura y buenas prácticas

La seguridad SCADA protege los sistemas que supervisan y controlan procesos físicos críticos: redes eléctricas, plantas de tratamiento de agua, oleoductos, líneas de fabricación y subestaciones. Un sistema SCADA (Supervisory Control And Data Acquisition) no gestiona datos abstractos, gobierna turbinas, válvulas, bombas y relés cuyo fallo tiene consecuencias en el mundo real. Esa diferencia lo cambia todo: en SCADA la disponibilidad y la integridad del proceso pesan mucho más que la confidencialidad, y un error de seguridad puede traducirse en un apagón, un vertido o una parada de producción con coste millonario.

Este artículo es una inmersión específica en la seguridad SCADA, complementaria a nuestra visión general de la ciberseguridad IoT y OT. Recorremos la arquitectura de un sistema SCADA, su modelo de amenazas particular, las buenas prácticas de defensa en profundidad y cómo se ejecuta un pentesting OT profesional sobre estos entornos.

Qué es SCADA y cómo es su arquitectura

Un sistema SCADA es la capa de supervisión y control que conecta a los operadores humanos con la maquinaria industrial distribuida en el terreno. Sus componentes fundamentales son:

• HMI (Human-Machine Interface): la estación desde la que el operador visualiza el estado del proceso y envía comandos. Suele ser un PC con Windows y software especializado (por ejemplo Wonderware, WinCC, Ignition o FactoryTalk).
• PLC (Programmable Logic Controller): el controlador que ejecuta la lógica de automatización en tiempo real, leyendo sensores y accionando actuadores. Modelos habituales incluyen la familia Siemens S7 o los Allen-Bradley de Rockwell.
• RTU (Remote Terminal Unit): equipo de campo, similar a un PLC pero optimizado para telemetría en ubicaciones remotas y dispersas, como estaciones de bombeo o subestaciones.
• Historian: base de datos de series temporales que registra millones de valores de proceso para análisis, cumplimiento y optimización. Es también un puente frecuente entre la red OT y la red corporativa.
• Servidor SCADA o MTU (Master Terminal Unit): el nodo central que agrega datos de PLCs y RTUs y distribuye la lógica de supervisión.

Estos componentes se comunican mediante protocolos industriales diseñados décadas atrás para redes aisladas y confiables, no para Internet. Modbus (TCP en el puerto 502) carece por completo de autenticación y cifrado: cualquiera que alcance el puerto puede leer o escribir registros. DNP3 (puerto 20000), extendido en el sector eléctrico y del agua, nació igualmente sin seguridad, aunque más tarde incorporó la extensión Secure Authentication (SAv5). Otros protocolos habituales son IEC 60870-5-104 e IEC 61850 en subestaciones, OPC UA, PROFINET y EtherNet/IP. La lección clave es que, en su forma nativa, la mayoría no valida quién envía un comando ni protege su contenido.

Modelo de amenazas específico de SCADA

El modelo de amenazas SCADA no es una copia del de IT. Aquí el objetivo del atacante no suele ser exfiltrar datos, sino manipular o interrumpir el proceso físico. La historia reciente lo demuestra con casos que ya son referencia obligada:

• Stuxnet (2010): el primer malware diseñado para causar daño físico. Reprogramó PLCs Siemens S7-300 en la planta de enriquecimiento de Natanz alterando la velocidad de las centrifugadoras mientras enviaba a los operadores lecturas normales falsificadas. Demostró que un sistema aislado (air-gapped) también es alcanzable.
• Industroyer / CrashOverride (2016): malware modular que provocó un corte eléctrico en Kiev hablando de forma nativa los protocolos IEC 101, IEC 104, IEC 61850 y OPC DA. Su sucesor, Industroyer2, reapareció en 2022 contra infraestructura ucraniana.
• TRITON / TRISIS (2017): atacó los sistemas instrumentados de seguridad (SIS) Triconex de Schneider Electric, es decir, la última barrera diseñada para prevenir accidentes catastróficos. Es el ejemplo más inquietante de un adversario apuntando directamente a la seguridad funcional.

Más allá de estos ataques dirigidos, la amenaza cotidiana es más prosaica. Motores de búsqueda como Shodan y Censys catalogan miles de HMIs, servidores VNC sin contraseña y puertos Modbus 502 expuestos directamente a Internet. Muchos son fruto de accesos remotos mal configurados o de conexiones olvidadas de un integrador. El framework MITRE ATT&CK for ICS documenta cómo se encadenan estas debilidades: técnicas como T0812 (Default Credentials), T0855 (Unauthorized Command Message) o T0836 (Modify Parameter) permiten a un atacante con acceso de red enviar comandos legítimos a un PLC sin explotar ninguna vulnerabilidad de software. El protocolo simplemente obedece.

Este panorama enlaza con la exposición regulatoria del sector energético frente a NIS2, donde operadores de red y utilities están obligados a demostrar controles efectivos sobre sus sistemas de control industrial.

Buenas prácticas de seguridad SCADA

Proteger SCADA exige defensa en profundidad adaptada a las restricciones operativas del entorno. Estas son las prácticas que consideramos irrenunciables.

Segmentación según el modelo Purdue

El modelo Purdue (basado en ISA-95) organiza la arquitectura en niveles, desde los dispositivos de campo (nivel 0) hasta la red corporativa y de negocio (niveles 4 y 5). Entre la zona OT y la IT debe existir una DMZ industrial (IDMZ) que impida el tráfico directo. Ningún historian, ninguna estación de ingeniería y ningún HMI deberían ser accesibles desde la red corporativa sin pasar por controles intermedios. El estándar IEC 62443 formaliza este enfoque mediante zonas y conductos, asignando a cada zona un nivel de seguridad objetivo (SL1 a SL4).

Acceso remoto seguro

El acceso remoto de fabricantes e integradores es uno de los vectores más explotados. La regla es no permitir nunca VPN directa hacia la red OT. En su lugar, se canaliza el acceso a través de un jump host o bastión en la IDMZ, con autenticación multifactor obligatoria, sesiones grabadas, aprobación explícita por ventana temporal y credenciales de un solo uso. Para flujos de datos que solo salen de OT hacia IT (por ejemplo, el envío del historian a analítica), los diodos de datos o gateways unidireccionales eliminan físicamente la posibilidad de un comando entrante.

Gestión del parcheado y controles compensatorios

En SCADA no se puede reiniciar un PLC a voluntad ni instalar parches de forma inmediata: una actualización mal probada puede detener la planta. La estrategia realista combina ventanas de mantenimiento planificadas, pruebas previas en un entorno espejo y, cuando el parcheado no es viable, controles compensatorios: virtual patching en el firewall industrial, listas de aplicaciones permitidas (allowlisting) en HMIs y estaciones de ingeniería, y aislamiento estricto de los activos que no pueden actualizarse.

Monitorización OT pasiva

La visibilidad es la base de todo lo demás. La monitorización OT debe ser pasiva, escuchando el tráfico mediante port mirroring o TAPs sin inyectar paquetes que puedan perturbar el proceso. Plataformas especializadas como Nozomi Networks, Claroty o Dragos, y herramientas abiertas como Zeek con parsers ICS, construyen un inventario de activos vivo, detectan comunicaciones anómalas y alertan sobre comandos de escritura no habituales. Un inventario de activos completo y actualizado es, de hecho, el primer control que echamos en falta en la mayoría de auditorías. El estándar NIST SP 800-82 (Guide to Operational Technology Security) recoge este conjunto de recomendaciones como referencia técnica reconocida.

Pentesting SCADA: validar la seguridad sobre el proceso real

El pentesting de un entorno SCADA no se parece a una auditoría web. Un escaneo agresivo con Nmap puede tumbar un PLC antiguo y un paquete Modbus malformado puede disparar una parada de emergencia, así que la metodología prioriza la seguridad del proceso sobre la exhaustividad del test: se empieza por la fase pasiva (captura de tráfico con Wireshark y sus disectores industriales, sin enviar un solo paquete al proceso) y solo después se aplican pruebas activas controladas sobre un entorno de laboratorio o réplica. Los objetivos típicos son validar la segmentación IT/OT real (no la del diagrama), localizar credenciales por defecto en PLCs y HMIs, comprobar si los protocolos aceptan comandos no autenticados y evaluar el acceso remoto de proveedores.

El arsenal técnico completo, las reglas del compromiso, la gradación de las pruebas activas y su alineación con MITRE ATT&CK for ICS e IEC 62443 los desarrollamos en la guía dedicada de pentesting industrial y auditoría OT/ICS. En Secra ejecutamos estos ejercicios dentro de la auditoría IoT/OT, siempre con acuerdo explícito del cliente, dentro de ventanas de mantenimiento y con un enfoque que empieza siendo no intrusivo.

Preguntas frecuentes

¿Cuál es la diferencia entre SCADA, ICS y OT?

OT (Operational Technology) es el término más amplio: engloba toda la tecnología que interactúa con procesos físicos. ICS (Industrial Control System) es el subconjunto de sistemas de control industrial, y SCADA es un tipo concreto de ICS orientado a la supervisión y adquisición de datos de procesos geográficamente distribuidos. Dicho de forma simple: todo SCADA es ICS y todo ICS es OT, pero no al revés. Ampliamos esta jerarquía y sus implicaciones defensivas en la guía qué es la seguridad OT/ICS.

¿Por qué son inseguros los protocolos SCADA como Modbus?

Porque se diseñaron para redes serie aisladas y de confianza en los años ochenta y noventa, cuando la conectividad a Internet no formaba parte del modelo. Modbus, DNP3 en su versión original o IEC 104 no incluían autenticación ni cifrado, de modo que aceptan como legítimo cualquier comando que reciban. La seguridad debe añadirse por encima, mediante segmentación de red, control de acceso y monitorización.

¿Se puede hacer un pentesting SCADA sin parar la producción?

Sí, pero con precauciones estrictas. La fase pasiva de análisis de tráfico no toca el proceso y aporta muchísima información. Las pruebas activas se reservan para entornos de laboratorio o réplica, o para ventanas de mantenimiento acordadas, nunca para escaneos improvisados sobre producción. La regla de oro es que la seguridad del proceso físico prevalece siempre sobre la profundidad del test.

¿Qué estándares rigen la seguridad SCADA?

Las referencias principales son IEC/ISA 62443 para la seguridad de sistemas de automatización y control industrial, NIST SP 800-82 como guía técnica de seguridad OT, y en el sector eléctrico norteamericano las normas NERC CIP. En Europa, la Directiva NIS2 impone además obligaciones de gestión de riesgos y notificación a los operadores de infraestructura crítica.

¿Cómo empiezo a proteger un entorno SCADA existente?

El primer paso es la visibilidad: un inventario completo de activos y un mapa real de las comunicaciones y de los puentes IT/OT. A partir de ahí se prioriza la segmentación según el modelo Purdue, el control del acceso remoto y la monitorización pasiva. Una auditoría OT profesional acelera este diagnóstico y entrega un plan de remediación ordenado por riesgo.

Recursos relacionados

• Qué es la seguridad OT/ICS
• Pentesting industrial y auditoría OT/ICS
• IEC/ISA 62443: estándar de ciberseguridad OT
• Ciberseguridad IoT y OT: amenazas críticas en 2026
• Ciberseguridad industria 4.0 y OT: protección NIS2

Seguridad SCADA y auditoría OT con Secra

Secra evalúa entornos SCADA con sensibilidad operativa: partimos del descubrimiento pasivo y del inventario de activos, validamos la segmentación IT/OT y el modelo Purdue, revisamos el acceso remoto de proveedores y mapeamos los hallazgos a IEC 62443, todo sin comprometer la producción. Cada prueba activa se acuerda, se acota y se reserva para laboratorio o ventanas de mantenimiento.

Si operas redes eléctricas, plantas de agua, oleoductos o líneas de fabricación y necesitas validar tu superficie de ataque real antes de que lo haga un atacante, conoce nuestra auditoría de seguridad IoT/OT o contacta con nuestro equipo para una conversación inicial sin compromiso.