Debido a la complejidad del entorno de Tecnología Operacional (OT) y a la frecuente falta de documentación sobre el estado de la red, este informe tiene como objetivo ofrecer una visión clara del estado actual de las redes OT, los protocolos más utilizados y sus problemas, así como los enfoques más eficaces para el monitoreo de este tipo de infraestructuras.
Cuando hablamos de entornos OT, lo habitual es imaginar un conjunto de máquinas de producción conectadas a PLCs (controladores lógicos programables), SCADAs (control de supervisión y adquisición de datos), DCSs (sistemas de control distribuido), CNCs (control numérico computacional) y otros sistemas de control, los cuales gestionan los distintos procesos industriales mediante protocolos que a menudo son propietarios, es decir, sujetos a restricciones derivadas de los derechos de propiedad intelectual/industrial. Si a esto se le añade la gran diversidad de fabricantes y protocolos, se hace evidente que monitorear estas redes representa un reto significativo.
A raíz de estas dificultades surgieron estándares como OPC UA o BACnet, que promueven la interoperabilidad. Sin embargo, muchas soluciones modernas ya no dependen estrictamente del protocolo para ofrecer una monitorización eficaz.
La introducción de la Industria 4.0 ha impulsado una migración hacia protocolos basados en TCP/IP, como Modbus TCP, S7comm, Profinet, entre otros. Esto abre nuevas posibilidades para la monitorización, incluso sin adoptar un protocolo estándar unificado.
Este artículo se organiza en siete secciones, además de la presente introducción:
- Sección 2: relación entre entornos IT y OT.
- Sección 3: arquitectura típica de una red industrial.
- Sección 4: protocolos de comunicación industrial.
- Sección 5: recopilación de logs.
- Sección 6: análisis del tráfico OT.
- Sección 7: conclusiones.
Una red OT típica VS. la realidad
En teoría, uno esperaría que las redes IT y OT están completamente segregadas, como se muestra en la Figura 1. No obstante, la realidad es muy distinta: los entornos están cada vez más integrados, lo que difumina la frontera entre ambos ámbitos.
La introducción de tecnologías IT en OT ha traído consigo amenazas nuevas, para las cuales los equipos industriales no están preparados dado que fueron diseñados con otras prioridades, como la disponibilidad y la estabilidad.
Esto ha generado una necesidad urgente de protección y monitorización continua en el entorno OT.
Arquitectura de red industrial
La arquitectura OT suele comenzar en los PLCs, que funcionan como el cerebro de la red. A partir de ahí, se conectan a sistemas SCADA, servidores IT y demás interfaces de gestión “hacia el norte” (subiendo niveles en la escala Purdue), y con sensores, actuadores y demás maquinaria industrian “hacia el sur” (descendiendo en la escala Purdue).
Tal como muestra la Figura 2, en una red industrial puede haber múltiples subredes que usan distintos protocolos y modelos de comunicación.
Además, es común encontrar comunicaciones máquina a máquina (por ejemplo, entre PLCs) sin necesidad de pasar por switches o routers.
PLC’s y protocolos
Siendo cierto que los fabricantes de PLCs en el mercado (Siemens, Schneider, Allen-Bradley, etc.) suelen todos ofrecer funcionalidades similares, se diferencian en los protocolos de comunicación que soportan.
Algunos protocolos son abiertos y ampliamente documentados, mientras que otros son propietarios, complicando por lo general su análisis. Un ejemplo es S7comm y S7comm Plus, utilizados por equipos Siemens.
La Figura 3 presenta los protocolos industriales más comúnmente utilizados. Estos protocolos varían en compatibilidad y nivel de apertura, impactando en su facilidad de monitorización.
Recolección de logs
Para monitorizar una red OT, el primer paso lógico es recolectar los logs de las máquinas. En algunos entornos, esto se logra mediante sistemas llamados Historians, que almacenan datos de proceso en series temporales.
Sin embargo, especialmente en pequeñas y medianas industrias (PYMEs), estos sistemas no son comunes debido al costo y la falta de actualización tecnológica hacia estándares de Industria 4.0.
Además:
- Los PLCs no guardan logs por defecto, a menos que sean programados específicamente para ello.
- La recolección directa de logs desde los PLCs implica modificarlos individualmente, lo que no siempre es viable.
Por esta razón, muchas soluciones de mercado no recogen directamente los logs, sino que monitorizan el tráfico de red, identificando patrones y eventos directamente desde el tráfico.
Una estrategia efectiva es conectar estos sistemas a TAPs o a puertos espejo (mirroring) de los switches de red, desde donde pueden escuchar todo el tráfico entre los dispositivos industriales.
Este enfoque permite observar comunicaciones desde/hacia los PLCs hacia el norte, pero no típicamente hacia sensores y controladores. Es una técnica no invasiva y ampliamente utilizada en proyectos OT modernos.
Análisis del tráfico
Los protocolos industriales pueden clasificarse en dos grandes grupos: los basados en TCP/IP, como Modbus TCP y S7comm, y los no basados en TCP/IP, como Profibus y CAN.
Dado que muchas redes industriales modernas están migrando hacia IP, nos enfocaremos en tres protocolos relevantes:
- Modbus TCP (abierto)
- S7comm (propietario)
- S7comm Plus (propietario y cifrado)
A. MODBUS TCP
Modbus es un protocolo de comunicación serial creado en 1979 y diseñado para entornos industriales. Es abierto y ampliamente adoptado, tanto en versiones seriales (Modbus RTU/ASCII) como en versión Ethernet (Modbus TCP).
Funciona bajo un modelo maestro-esclavo (o cliente-servidor), donde el maestro/cliente solicita datos o comandos y los esclavos/servidores (hasta 247) responden o ejecutan instrucciones.
Se utiliza comúnmente para:
- Conectar sensores y dispositivos de campo con sistemas de adquisición de datos tipo SCADA.
- Transmitir señales de temperatura, presión, nivel, etc.
1) Entorno de Simulación
Para simular Modbus, usamos herramientas de código abierto:
- ModbusPal: simulador gráfico scriptable de múltiples esclavos.
- Mbtget: script escrito en Perl para hacer peticiones Modbus por consola; da acceso a las versiones TCP y RTU del protocolo
2) Resultados
Como se muestra en la figura 7, se logró simular tráfico Modbus usando modbusPal. Los paquetes muestran campos como el identificador de transacción, el código de función, la dirección del esclavo, los datos (registros o bits), etc. Al estar todo abierto, su monitorización resulta sencilla, pero debido a la falta de cifrado, Modbus puede representar un riesgo de seguridad si no está aislado o protegido adecuadamente.
B. S7comm
S7comm es un protocolo propietario usado por los PLCs Siemens. No existe documentación oficial completa (ni siquiera terminología establecida), pero hay proyectos y librerías como Snap7 y un dissector para Wireshark que ayudan a analizarlo.
Los protocolos S7comm se suelen dividir en dos familias:
- S7comm clásico: aún usado ampliamente.
- S7comm Plus: cifrado y muy poco documentado.
Escenario típico:
Una estación PC se comunica con un PLC mediante el protocolo S7 (por ejemplo, para cargar programas, leer memoria o monitorear estados). Se usa el modelo cliente-servidor: el PC actúa como cliente, y el PLC como servidor.
El protocolo viaja encapsulado en ISO-COTP sobre TCP, utilizando TPKT como envoltura.
El paquete incluye:
- Encabezado (longitud, tipo de mensaje)
- Parámetros (varía por tipo de función)
- Datos (memoria, firmware, etc.)
C. S7comm PLUS
A diferencia del clásico, S7comm Plus está cifrado, lo que impide su análisis con herramientas tradicionales. Se han desarrollado algunas herramientas como disectores Wireshark, pero en pruebas reales los resultados no han sido útiles.
1) Entorno de Prueba
Para analizar S7comm Plus se configuró:
- Un PLC Siemens S7-1200
- Un PC con TIA Portal v15
- Un switch con puerto espejo
- Wireshark + plugin para S7comm Plus
Se ejecutaron distintos escenarios, como:
- Conectar y desconectar el TIA Portal al PLC.
- Descargar o subir configuraciones.
- Poner el PLC en modo «RUN» o «STOP».
2) Resultados
El plugin de Wireshark no logró descifrar o interpretar correctamente los paquetes. El tráfico aparece como cifrado y no hay documentación oficial que permita descifrarlo.
Conclusiones del análisis:
- S7comm clásico es entendible y útil para monitoreo.
- S7comm Plus es una «caja negra» desde el punto de vista de ciberseguridad.
- Se requieren estrategias alternativas (como comportamiento o anomalías en tráfico) para tratar con protocolos cifrados.
Conclusiones
El entorno OT es mucho más complejo de escanear y monitorizar que el entorno IT, debido a la gran diversidad de protocolos, fabricantes y arquitecturas.
Mientras algunos protocolos están bien documentados, otros como S7comm Plus permanecen cerrados, lo que dificulta la visibilidad.
La tendencia actual en soluciones de monitoreo OT es enfocarse en la capa IP, generando visibilidad sin importar el protocolo subyacente.
Recomendaciones:
- Usar tráfico de red como fuente principal de logs.
- Incorporar detección de comportamiento y anomalías.
- Priorizar soluciones pasivas para evitar interrupciones en la operación.
¿Listo para obtener visibilidad real sobre tu red OT?
En InprOTech te ayudamos a identificar riesgos, analizar protocolos industriales y monitorizar tu infraestructura OT sin comprometer la continuidad operativa de tu entorno industrial.
Si este artículo te ha resultado útil o estás buscando una visibilidad real de tu red OT, no dudes en ponerte en contacto con nosotros haciendo clic aquí, o visita nuestra página de InprOTech Guardian y servicios especializados para descubrir cómo podemos ayudarte.
Nuestros expertos en ciberseguridad industrial están preparados para acompañarte en el camino hacia una red OT más segura, eficiente y resiliente.