Introducción

Ubiquémonos hace 30 años, digamos 1995, en ese entonces un equipo de ingenieros estaba encargado de crear un sistema de control para una planta petroquímica. La arquitectura diseñada era impecable para su época, controladores industriales conectados mediante cables especiales del fabricante, computadoras que nunca tocaban internet, acceso físico controlado por guardias y tarjetas magnéticas, y cero conexión con las oficinas corporativas. El sistema era, en su contexto, virtualmente impenetrable, no por tener controles de ciberseguridad sofisticados, simplemente no los necesitaba. La seguridad residía en el aislamiento.

Treinta años después, esa misma planta sigue operando con gran parte de esa infraestructura original. Pero el mundo cambió radicalmente. Ahora los ejecutivos requieren dashboards en tiempo real desde sus oficinas corporativas. Los proveedores necesitan acceso remoto para diagnosticar incidencias. La integración con sistemas ERP (Sistema de Planificación de Recursos Empresariales) es esencial para optimizar la cadena de suministro. Lo que no cambió fue la arquitectura de seguridad del sistema, que sigue asumiendo un mundo aislado que dejó de existir hace dos décadas.

En nuestro artículo anterior, “9 tipos de vulnerabilidades que deberías conocer si te dedicas a seguridad en OT“, identificamos las manifestaciones visibles de inseguridad en entornos industriales, desde código deficiente hasta configuraciones inseguras. Pero identificar síntomas no es lo mismo que diagnosticar la enfermedad. Las vulnerabilidades no necesariamente aparecieron por negligencia o incompetencia. Son consecuencias sistemáticas de causas raíz profundas.

Así como un árbol, las vulnerabilidades visibles en la superficie tienen raíces profundas que las alimentan. La Cybersecurity and Infrastructure Security Agency (CISA) identifica cinco causas raíz fundamentales que explican por qué sistemas diseñados brillantemente para su época se han convertido en blancos vulnerables en la nuestra. Estas causas son consecuencias de un cambio radical en el entorno operacional para el cual estos sistemas nunca fueron diseñados.

Las cinco causas raíz que exploraremos son:

Causa Raíz	Descripción
Sistemas de Control Legacy	Diseñados para ciclos de vida de 15-30 años en entornos que ya no existen
Migración a COTS (Commercial Off-The-Shelf)	Heredando vulnerabilidades del mundo IT al adoptar sistemas comerciales estándar
Programación de Dispositivos	Funcionalidad embebida sin controles de seguridad
Conectividad y Arquitectura de Red	Del aislamiento físico a la hiperconexión sin controles adecuados
Cultura de Ciberseguridad	Eslabón organizacional difícil de cambiar

Cada causa raíz no funciona sola. Se alimentan entre sí, creando un círculo vicioso donde las vulnerabilidades son prácticamente inevitables sin un esfuerzo consciente y estructurado para detenerlas.

Sistemas de Control Legacy

El Problema del Ciclo de Vida Extendido

Los sistemas de control industrial con frecuencia se utilizan entre 15 y 30 años en operación, algunos superan fácilmente las tres décadas. Reemplazar una central eléctrica o una refinería cuesta millones de dólares y puede interrumpir operaciones críticas, por eso que duren tanto tiempo siempre fue considerado una ventaja. El problema es que un sistema instalado en el año 2000 se diseñó cuando el término “ciberseguridad” apenas empezaba a mencionarse, cuando conectarse remotamente a una planta industrial era algo excepcional, cuando Stuxnet todavía no existía (más sobre Stuxnet en el artículo de Ciberataques y Catástrofes). Ese mismo sistema opera hoy prácticamente sin cambios importantes en su seguridad, en un mundo donde los ataques cibernéticos son comunes, las herramientas para atacar están disponibles gratuitamente en internet, y cualquier cosa conectada es un blanco potencial. CISA documenta cómo las características de diseño originales de estos sistemas antiguos, que tenían perfecta lógica cuando todo estaba aislado, se han convertido en vulnerabilidades críticas ahora que todo está conectado.

Característica del Sistema	Por Qué Tenía Sentido Antes	Qué Significa Hoy
Comunicaciones sin cifrar	Transmitir datos tan pronto como se generan	Un atacante puede leer toda la información y mapear la infraestructura completa
Todos los usuarios con permisos totales	Los operadores solo accedían físicamente después de pasar filtros de seguridad, no se requerían más controles	Si un atacante logra entrar, puede controlar cualquier dispositivo sin necesitar permisos adicionales
No se verifica qué aplicaciones se instalan	Solo personal de confianza físicamente presente instalaba software	Es más fácil instalar malware sin que el sistema lo detecte o bloquee
No se verifica si los datos mostrados son reales	Las comunicaciones estaban en red cerrada sin acceso externo	Se puede engañar a los operadores mostrando información falsa en sus pantallas
El sistema nunca se detiene	Las operaciones críticas no pueden parar ni siquiera para mantenimiento	Para garantizar que nunca se detenga se sacrificó seguridad en el diseño del código
Conexión directa con oficinas corporativas	Necesidad de reportes y análisis en tiempo real para toma de decisiones	Cada conexión crea una puerta de entrada potencial para ataques desde la red corporativa

Cada característica de la tabla anterior empezó como una decisión de ingeniería lógica optimizada para que el sistema funcionara bien, fuera fácil de usar y estuviera siempre disponible.

Comunicaciones sin cifrar
Los protocolos fueron diseñados para ambientes completamente aislados donde lo más importante era que el sistema nunca se detuviera. Las comunicaciones sin cifrar facilitan conectar equipos de diferentes fabricantes y hacen más fácil diagnosticar problemas, un ingeniero puede ver exactamente qué está pasando en la red sin complicaciones.

Hoy, un atacante con acceso a la red puede analizar todo el tráfico en tiempo real. Como estos sistemas confían entre sí, un atacante que captura una contraseña sin cifrar puede hacerse pasar por equipos legítimos, inyectar información falsa, o interceptar comunicaciones.

Contraseñas predeterminadas y codificadas (Hardcoded)
Como estos sistemas están siempre encendidos, la mayoría de las empresas usan una contraseña fácil de recordar que todos los operadores comparten, onunca cambian las contraseñas que vienen de fábrica. Los operadores deben acceder rápidamente en caso de emergencia.

Algunos fabricantes diseñaron contraseñas permanentemente programadas en el código que no se pueden cambiar. Descubrir estas contraseñas es fácil, se transmiten sin cifrar por la red, están en los manuales que se descargan de internet, o están documentadas en foros técnicos. Existe malware diseñado específicamente para explotarlas.

Todos los usuarios con permisos totales
Estos sistemas fueron programados para que todo se ejecutara con permisos ilimitados. En ambientes aislados donde todos eran empleados autorizados físicamente presentes, esto no representaba un riesgo. Hoy, si un atacante entra, tiene control total para manipular y dañar todo el sistema.

Sin verificar qué aplicaciones se instalan
Como estos sistemas tienen muy poco tiempo de inactividad, el personal local de confianza debía poder instalar software sin demora. Las únicas personas que podían instalar aplicaciones eran ingenieros autorizados físicamente presentes.

A medida que los sistemas se volvieron más complejos, se integran aplicaciones de terceros que no siempre son confiables. El grupo de malware Havex reemplazó archivos de instalación de software legítimo con versiones infectadas, instalando secretamente programas espía en sistemas industriales usados desde subestaciones eléctricas hasta plantas nucleares.

Sin verificar si los datos mostrados son reales
Las verificaciones de integridad aseguran que la información que un operador ve en su pantalla es correcta y no ha sido modificada. Cuando los sistemas estaban aislados, había poca duda de que las lecturas eran precisas. Ahora que los sistemas están interconectados, si una pantalla de operador es comprometida, podría mostrar que una válvula crítica está cerrada cuando en realidad está abierta, causando un incidente catastrófico. Esto fue lo que atacantes lograron en Stuxnet y en los ataques a la red eléctrica de Ucrania, los operadores veían lecturas normales mientras el sistema estaba siendo saboteado.

El sistema nunca se detiene
Diseñar un sistema para que nunca se detenga es diferente a diseñar uno seguro. Si el sistema no verifica que los datos de entrada sean normales, puede ser atacado mediante denegación de servicio o inyección de datos. El código de ataque disponible públicamente aumenta el número de atacantes potenciales.

Conexión directa con oficinas corporativas
Las empresas necesitan información en tiempo real para tomar decisiones. Conectar sistemas industriales con oficinas ha mejorado la productividad, pero cada canal de datos crea una vulnerabilidad potencial.

El ataque a Colonial Pipeline en 2021 es claro, el ransomware entró por credenciales VPN comprometidas que conectaban oficinas con la red de control.

Migración a COTS (Commercial Off-The-Shelf)

De Sistemas Propietarios a Sistemas Comerciales Estándar

A medida que los sistemas computacionales desarrollados para negocios aumentaron en poder y velocidad, la comunidad ICS comenzó a adoptar hardware y sistemas operativos comerciales estándar conocidos como COTS (Commercial Off-The-Shelf, por sus siglas en inglés). COTS se refiere a productos de software y hardware que están disponibles comercialmente, son ampliamente usados, y no son desarrollados específicamente para un propósito único.

En el contexto de OT, esto significó migrar de:

Sistemas operativos propietarios → Windows, Linux
Hardware especializado → Servidores x86 estándar
Protocolos propietarios → TCP/IP, Ethernet
Bases de datos propietarias → SQL Server, Oracle

Esta migración también introdujo vulnerabilidades del mundo IT directamente en los sistemas industriales. CISA es clara al respecto, muchas de las vulnerabilidades en sistemas industriales son similares o idénticas a las vulnerabilidades de tecnología de información.

Vulnerabilidades de plataforma heredadas
Cada vulnerabilidad descubierta en un sistema operativo popular afecta automáticamente a todos los sistemas industriales que lo usan. Esto incluye problemas en hardware, software, firmware y aplicaciones.

Vulnerabilidades de red heredadas
Los protocolos desarrollados para automatización industrial fueron diseñados para confiabilidad y facilidad de uso en entornos aislados. Muchos carecían de contramedidas de seguridad porque la protección del sistema dependía de la disponibilidad y el acceso físico controlado. Cuando estos protocolos se adaptan para redes modernas, simplemente se montan sobre las comunicaciones existentes sin mejorar su seguridad, incrementando los riesgos.

El caso WannaCry
El ejemplo más claro fue el ransomware WannaCry en 2017. Explotó una vulnerabilidad de Windows (EternalBlue) que afectó sistemas corporativos y también sistemas industriales en hospitales, plantas de manufactura e infraestructura crítica globalmente. La vulnerabilidad fue heredada del sistema operativo comercial que ejecutaban. Microsoft había lanzado un parche meses antes del ataque, pero muchos sistemas industriales no pudieron aplicarlo debido a restricciones operacionales.
La comunidad industrial adoptó sistemas comerciales estándar para obtener la madurez y el rendimiento del mundo IT. Lo que no anticiparon completamente fue heredar también todo el perfil de amenazas, la velocidad de descubrimiento de vulnerabilidades y los desafíos de gestión de parches, aplicados a sistemas que no pueden ser fácilmente actualizados o reiniciados.

Programación de Dispositivos (Funcionalidades embebidas)

Los fabricantes incluyen servicios adicionales en sus sistemas como servidores Web, FTP y SNMP para mejorar las operaciones. Un operador puede abrir un navegador y acceder directamente a la configuración de un controlador, un técnico puede usar FTP para cargar nuevos programas. Muchos dispositivos traen estos servicios habilitados por defecto sin que los ingenieros lo sepan, creando formas para que un atacante configure remotamente estos dispositivos o modifique el firmware.

Los dispositivos de campo fueron desplegados asumiendo que estarían en un entorno seguro, por eso usan protocolos sin autenticación ni autorización. En muchas arquitecturas, cualquier equipo puede comunicarse y enviar comandos a cualquier otro dispositivo. Son vulnerables a fallos catastróficos debido a tormentas de datos, inundación de paquetes o datos malformados que pueden resultar en pérdida de control del proceso.

Las redes modernas hacen posible acceder remotamente para solucionar problemas y modificar programas, pero también para atacar el sistema emitiendo comandos no autorizados o reseteándolo. A diferencia de dispositivos IT, los activos dentro de sistemas de control fueron diseñados asumiendo que el control de acceso sería manejado por aislamiento físico. Cuando estos dispositivos son expuestos a redes más amplias, carecen de mecanismos defensivos como autenticación fuerte, registros de auditoría o detección de comportamiento anómalo.

Conectividad y Arquitectura de Red

Los ingenieros pueden conectar redes industriales y redes de negocio. A medida que los requisitos corporativos para monitoreo en tiempo real se han vuelto comunes, las arquitecturas conectan directamente ambas redes. El problema es que si la red industrial confía en la red corporativa, y la red corporativa está conectada a internet, un atacante que compromete la red corporativa puede usar esa conexión para llegar a la red industrial.

Medios de comunicación vulnerables
Los sistemas industriales usan varios medios de comunicación que introducen riesgos. El acceso inalámbrico (WiFi, radio, microondas) es una vía significativa de ataque, muchas soluciones comerciales tienen medidas de seguridad débiles o que han sido quebradas públicamente. Los módems analógicos todavía se usan en sistemas antiguos y tienen vulnerabilidades como números telefónicos de acceso público y controles de acceso deficientes. Las redes corporativas conectadas a internet crean un camino que un atacante puede usar para llegar a los sistemas industriales. Las líneas de comunicación físicas como fibra óptica o líneas arrendadas pueden ser saboteadas con un simple corte.

Cultura de Ciberseguridad

¿Qué es una cultura de ciberseguridad?
Cultura es “una forma de pensar, comportarse o trabajar que existe en un lugar u organización”. Considere las actitudes compartidas, valores, metas y prácticas asociadas con la ciberseguridad en su organización. ¿Cuáles son las actitudes de sus operadores? ¿De sus proveedores? ¿De sus consultores? ¿De sus integradores de sistemas?

Históricamente, el personal responsable de sistemas industriales provenía de ingeniería u Operaciones y Mantenimiento. Entendían el proceso y cómo controlarlo de manera segura y confiable. Hace quince años, la idea de que alguien externo intentara atacar un sistema industrial era extraña para la mayoría de ingenieros. El campo de la ciberseguridad industrial estaba en su infancia y no era un conjunto de habilidades familiar.

A medida que las arquitecturas transicionan de sistemas cerrados propietarios a estándares abiertos, los ingenieros de sistemas de control necesitan desarrollar nuevas habilidades en redes, sistemas operativos y bases de datos.

El choque de mundos entre ingenieros OT y profesionales IT
El personal con experiencia en IT frecuentemente es traído para soportar la transición, y en algunos casos, reemplaza a ingenieros de sistemas de control. Cuando esto sucede, el personal enfocado en IT puede no tener el conocimiento de procesos que poseía el personal de OT, presentando una dificultad para mantener la confiabilidad y disponibilidad.

Esta brecha de conocimiento funciona en ambas direcciones. Los ingenieros OT son expertos en física de procesos, control de lazos, instrumentación y confiabilidad, pero frecuentemente carecen de entrenamiento formal en ciberseguridad, arquitectura de redes modernas o gestión de vulnerabilidades. Los profesionales IT son hábiles en ciberseguridad, gestión de parches, arquitectura de redes y respuesta a incidentes pero frecuentemente carecen de comprensión de las restricciones operacionales de OT, los requisitos de disponibilidad y las consecuencias de seguridad física de fallos en sistemas de control. El resultado es una fricción organizacional profunda donde ambos grupos tienen razón dentro de sus marcos de referencia, pero luchan por encontrar terreno común.

¿Quién protege el sistema industrial?
Las organizaciones luchan con cómo proteger mejor sus sistemas industriales mientras garantizan safety (Prevención de accidentes industriales), disponibilidad e integridad. ¿Debe el personal de soporte estar en la división industrial donde trabajan estrechamente con el personal operativo, o debe el departamento IT manejar esta responsabilidad? Cuando el departamento IT es asignado para asegurar el entorno del sistema de control, la solución usualmente es desplegar tecnologías de seguridad comerciales diseñadas para entornos corporativos tradicionales, que no abordan los requisitos del dominio de sistemas de control. La falta de claridad organizacional sobre quién es responsable lleva a responsabilidades fragmentadas, soluciones IT aplicadas sin consideración de restricciones operacionales, resistencia de equipos operativos, y falta de presupuesto dedicado.

El panorama de amenazas que cambió
Múltiples elementos de amenaza ahora se están combinando para incrementar significativamente el panorama de amenazas. Los grupos están usando motores de búsqueda especializados como Shodan para identificar sistemas de control expuestos a internet, aprovechando el creciente arsenal de herramientas de explotación desarrolladas específicamente para sistemas industriales.

Hace quince años, atacar un sistema de control requería conocimiento especializado de protocolos propietarios, acceso físico a las instalaciones y motivación extraordinaria. Hoy, el conocimiento técnico necesario está disponible en tutoriales de YouTube, las herramientas de ataque son de código abierto en GitHub, la inteligencia artificial puede ayudar a entender y diseñar ataques, y el acceso se obtiene vía VPN comprometida, phishing o sistemas directamente expuestos a internet.

Cómo se relacionan las causas raíz con las vulnerabilidades
Las cinco causas raíz no operan de manera aislada. Se alimentan mutuamente y generan las nueve vulnerabilidades que analizamos en el artículo anterior. Comprender esta interrelación es esencial para diseñar soluciones efectivas.

Matriz de Interrelaciones

Vulnerabilidad	Causas Raíz Contribuyentes (1° = primaria, 2° = secundaria)
Calidad de Código Deficiente	Legacy (1°) – código antiguo sin actualizar Cultura (2°) – falta de prioridad en seguridad desde diseño
Servicios Web Vulnerables	Programación de dispositivos (1°) – funcionalidad embebida sin análisis COTS (2°) – servidores web estándar con vulnerabilidades conocidas
Implementación Deficiente de Protocolos	Legacy (1°) – protocolos sin autenticación/cifrado Programación de dispositivos (2°) – protocolos asumen confianza
Gestión Deficiente de Parches	Legacy (1°) – sistemas difíciles/costosos de actualizar Cultura (2°) – “no tocar lo que funciona” Conectividad (3°) – complejidad de arquitectura híbrida
Autenticación Débil	Legacy (1°) – contraseñas codificadas, diseño sin autenticación Programación de dispositivos (2°) – protocolos sin autenticación Cultura (3°) – contraseñas compartidas para acceso rápido
Violación de Mínimos Privilegios	Legacy (1°) – diseñados con privilegios ilimitados Cultura (2°) – operadores requieren “control completo”
Divulgación de Información	Legacy (1°) – tráfico en texto plano Conectividad (2°) – exposición a redes no confiables Programación de dispositivos (3°) – servicios que divulgan información
Diseño de Red Inadecuado	Conectividad (1°) – redes planas, confianza transitiva Cultura (2°) – falta de segmentación por conveniencia
Configuraciones Inseguras	Cultura (1°) – configuraciones por defecto nunca cambiadas Conectividad (2°) – complejidad de arquitectura Programación de dispositivos (3°) – servicios habilitados por defecto

Ejemplos Concretos de Interrelación

Ejemplo 1 – Gestión deficiente de parches

Un sistema SCADA ejecuta Windows Server 2012 (sistemas comerciales estándar COTS) con software de supervisión de 15 años de antigüedad (legacy). Microsoft publica un parche crítico de seguridad. El fabricante del software de supervisión no ha certificado compatibilidad con el parche (legacy), la planta opera 24/7 sin ventanas de mantenimiento planificadas (cultura), y no hay redundancia para probar el parche en entorno no productivo (conectividad con arquitectura sin separación). El resultado es que el parche no se aplica y la vulnerabilidad persiste.

Ejemplo 2 – Autenticación débil

Un PLC Siemens de 20 años (legacy) tiene un servidor web embebido habilitado por defecto (programación de dispositivos) usando credenciales predeterminadas que nunca fueron cambiadas (cultura). Está conectado a la red corporativa mediante un switch no gestionado (conectividad). Un atacante que compromete una laptop corporativa vía phishing puede escanear la red, descubrir el PLC, acceder con credenciales predeterminadas documentadas públicamente, y modificar la lógica del PLC.

Ejemplo 3 – Divulgación de información

Una planta química usa el protocolo Modbus TCP sin cifrado (legacy) para comunicación entre pantallas de operador y controladores. La red industrial está conectada a la red corporativa sin segmentación (conectividad). Un analista de datos corporativo instala Wireshark para diagnosticar problemas de red (cultura con falta de control sobre herramientas). Accidentalmente captura tráfico Modbus que incluye parámetros críticos de temperatura y presión, y contraseñas en texto plano (programación de dispositivos donde protocolos asumen confianza).

Estos ejemplos demuestran que abordar vulnerabilidades individuales sin atacar las causas raíz es como cortar las ramas de un árbol sin eliminar las raíces. Las vulnerabilidades simplemente se manifestarán de nuevas formas.

Conclusión: Entender las Raíces para Diseñar Soluciones Efectivas

Las cinco causas raíz que hemos analizado no son secretos. CISA las ha documentado, los estándares de la industria como ISA/IEC 62443 las reconocen, los profesionales de seguridad industrial las conocen. Entonces, ¿por qué persisten?

Décadas de historia no se pueden “parchear”. La cultura organizacional no se reescribe con un memo ejecutivo. Miles de millones de dólares en infraestructura legacy no se reemplazan de la noche a la mañana. Y la operación de infraestructura crítica no se puede pausar mientras se rediseña su arquitectura de seguridad.

Lo que sí podemos hacer es, antes que nada, tomar conciencia de estos defectos de origen y, con base en ello, diseñar controles compensatorios basados en la comprensión profunda de estas causas raíz. Cuando entendemos que los sistemas legacy usan tráfico en texto plano porque fueron diseñados para entornos aislados, podemos implementar segmentación de red rigurosa y monitoreo de tráfico anómalo. Cuando entendemos que la cultura industrial prioriza disponibilidad porque el tiempo de inactividad tiene consecuencias catastróficas, podemos diseñar estrategias de gestión de parches con redundancia y ventanas de mantenimiento planificadas. Cuando entendemos que la migración a sistemas comerciales estándar heredó vulnerabilidades del mundo IT, podemos aplicar controles IT probados adaptados para entornos industriales.

La responsabilidad de proteger infraestructura crítica es compartida entre propietarios de activos, fabricantes, reguladores y la comunidad de ciberseguridad. El conocimiento de estas causas raíz es el primer paso hacia soluciones sistémicas que aborden las condiciones fundamentales que permiten que las vulnerabilidades persistan.

Referencias

CISA Cybersecurity and Infrastructure Security Agency, Department of Homeland Security – 210W-07 ICS Cybersecurity Vulnerabilities (Root Causes Section). Recuperado en enero de 2026.
ISA/IEC 62443 Series of Standards – Industrial Automation and Control Systems Security. Recuperado en enero de 2026.

CISA Cybersecurity and Infrastructure Security Agency, Department of Homeland – ICS Focused Malware. Recuperado el 01 de marzo 2026.

CONGRESS.GOV – Attacks on Ukraine’s Electric Grid: Insights for U.S. Infrastructure Security and Resilience. Recuperado el 01 de marzo 2026.

U.S. DEPARTMENT OF ENERGY – Colonial Pipeline Cyber Incident. Recuperado el 02 de marzo 2026.