← Volver a Insights

Amenazas y cambios en OT: ¿sabemos qué pasó dentro del control?

Infografía de amenazas OT con estaciones de ingeniería y HMI en nivel 2, servidores OT y SCADA en nivel 3, e IDMZ con servidores y firewalls en nivel 3.5.

Ilustración conceptual aportada por el autor y editada para esta versión. Las amenazas no se limitan al nivel junto al que aparecen dibujadas. Ver imagen completa ↗

Lectura del esquema: El nivel 2 agrupa estaciones de ingeniería y HMI; el nivel 3, servidores OT y SCADA. La IDMZ se muestra separada en el nivel 3.5, con servidores y firewalls. Esta distribución es conceptual y debe ajustarse a las funciones y comunicaciones de cada instalación.

Ilustración del artículo
Infografía de amenazas OT con estaciones de ingeniería y HMI en nivel 2, servidores OT y SCADA en nivel 3, e IDMZ con servidores y firewalls en nivel 3.5.

El nivel 2 agrupa estaciones de ingeniería y HMI; el nivel 3, servidores OT y SCADA. La IDMZ se muestra separada en el nivel 3.5, con servidores y firewalls. Esta distribución es conceptual y debe ajustarse a las funciones y comunicaciones de cada instalación.

Una planta puede detenerse sin que nadie haya vulnerado su perímetro. Un error, un cambio sin control o el uso indebido de una cuenta legítima también pueden afectar al proceso.

Cuando hablamos de ciberseguridad OT, el atacante externo suele concentrar nuestra atención. Conviene ampliar la mirada hacia otras situaciones que pueden terminar en una pérdida de disponibilidad, integridad o seguridad operacional.

Tres situaciones que vale la pena distinguir

Amenazas externas

Un atacante puede intentar acceder desde fuera de la organización, desplazarse entre sistemas y alcanzar activos que soportan la operación. Las consecuencias dependerán de las rutas disponibles, de los permisos obtenidos y de las capacidades del sistema comprometido.

Errores humanos y cambios accidentales

Una modificación incorrecta en la lógica de un PLC —un contacto, un temporizador, un setpoint o un interlock— puede alterar el comportamiento del proceso. El controlador puede seguir comunicándose y la red parecer normal mientras la secuencia ya no funciona como debería.

Cuando falta trazabilidad, investigar implica reconstruir qué cambió, quién intervino y cuándo ocurrió. Detectar que un equipo está disponible no responde a esas preguntas.

Uso malicioso de accesos legítimos

Una persona con privilegios suficientes podría modificar configuraciones o lógica, crear cuentas o retirar accesos. Para algunas de esas acciones no necesitaría evadir la autenticación: el sistema ya reconoce su identidad.

Una acción autenticada puede ser operativamente peligrosa. La autorización técnica de una cuenta y la aprobación de un cambio concreto son controles diferentes.

Estas tres situaciones no son una clasificación exhaustiva ni excluyente. Pueden combinarse, y también existen fallas de componentes o condiciones ambientales. NIST SP 800-82 Rev. 3, apéndice C, considera fuentes adversariales, accidentales, estructurales y ambientales al analizar amenazas para OT.

Visibilidad sobre el cambio, además de la comunicación

Mi propuesta es extender la observación hacia supervisión, control y proceso, respetando las restricciones de cada instalación. No significa añadir sondeos indiscriminados: primero hay que saber qué información existe y cómo obtenerla sin alterar la operación.

El monitoreo pasivo aporta contexto sobre comunicaciones observadas, pero no garantiza conocer cada cambio interno ni identificar a la persona que lo hizo. El cifrado, los segmentos sin cobertura, las cuentas compartidas y las capacidades del controlador limitan la evidencia disponible.

Para reconstruir un cambio, buscaría relacionar:

  • El proyecto y sus versiones: copias conocidas, diferencias de lógica o configuración y respaldo previo a la intervención.
  • La autorización: orden de trabajo, motivo, responsable y resultado esperado.
  • La identidad y la sesión: registros del controlador, la estación de ingeniería y los accesos, cuando estén disponibles.
  • El tiempo y el proceso: marcas horarias coherentes, alarmas y estados operativos para correlacionar lo observado.

El control de cambios y la combinación de registros y monitoreo se desarrollan en las secciones 6.2.4.2 y E.2 de NIST SP 800-82 Rev. 3. La lista anterior es una propuesta de revisión, que debe ajustarse a la tecnología y a las evidencias realmente disponibles.

Una pregunta para la operación

No basta con acumular alertas. La información debe permitir decidir si un cambio era esperado, evaluar su efecto y coordinar una respuesta con quienes conocen el proceso.

Si mañana cambia algo dentro de un PLC o sistema de control, ¿podríamos identificar qué cambió, relacionarlo con una intervención y evaluar su impacto?