Seguridad informática: cuando la red también hay que cuidarla

Qué es la seguridad informática en un entorno industrial

La seguridad informática en un entorno industrial no es lo mismo que en una oficina. En una oficina, el peor escenario es que alguien acceda a información que no debería. En una planta, el peor escenario es que alguien actúe sobre un proceso que no debería.

Eso cambia el criterio. No se trata solo de proteger los datos: se trata de proteger el proceso. Y el proceso no es un archivo: es una instalación que puede causar daño si se la opera mal.

Por eso la seguridad industrial no es un tema de tecnología, es un tema de diseño. Empieza en la arquitectura de la red, sigue en los accesos, y termina en la forma en que se opera el sistema.

Acceso remoto: quién, desde dónde, con qué autorización

El acceso remoto es una de las mayores ventajas de un sistema supervisado. También es uno de sus mayores riesgos. Todo depende de cómo se diseñe.

Las preguntas no son técnicas: son de criterio. ¿Quién puede acceder? ¿Desde dónde? ¿Con qué autorización? ¿Para ver o para actuar? ¿En qué condiciones? ¿Con qué registro?

Un sistema que permite acceder a todo desde cualquier lugar, sin restricciones, no es un sistema flexible: es un sistema expuesto. Y un sistema que no permite acceder a nada desde afuera no es un sistema seguro: es un sistema aislado, que pierde las ventajas de la comunicación.

El punto medio no se define por la tecnología, sino por el criterio. Qué necesita la instalación, quién necesita acceder, y para qué.

Autenticación y control de acceso

Autenticar es verificar que alguien es quien dice ser. Controlar el acceso es decidir qué puede hacer esa persona una vez autenticada.

Hay distintos niveles, y cada uno tiene su criterio.

• Ver. Acceder a la información sin modificar nada. Es el nivel más bajo de riesgo: el peor escenario es que alguien vea lo que no debería.
• Consultar. Acceder a información específica, puntual. El riesgo es similar al anterior, pero el acceso es más acotado.
• Operar. Modificar consignas, cambiar modos, resetear alarmas. El riesgo es mayor: una decisión equivocada puede afectar el proceso.
• Configurar. Modificar parámetros, ajustar la lógica, cambiar la configuración del sistema. Es el nivel más alto de riesgo: una decisión equivocada puede dejar el sistema inoperable.

No todo el mundo necesita el mismo nivel de acceso. Un operador no necesita configurar la lógica. Un técnico no necesita operar la planta. Un supervisor no necesita modificar los parámetros del PLC. Cada uno necesita lo que su función requiere, y nada más.

Segmentación: separar para proteger

Una de las ideas más importantes en seguridad industrial es la segmentación: separar la red de control de la red de gestión.

La red de control es donde están los PLC, las HMI, los variadores, los sensores. Es la red que gobierna el proceso. La red de gestión es donde están las PCs, los servidores, los sistemas administrativos. Es la red que gestiona la empresa.

Si las dos redes están conectadas sin control, cualquiera que acceda a la red de gestión puede acceder a la red de control. Y eso es un riesgo. La segmentación separa las dos redes, y permite que la comunicación entre ellas sea controlada.

La segmentación no es un producto: es una decisión de diseño. Y conviene pensarla desde el principio, no agregarla después, cuando el sistema ya está armado y separarlo es mucho más difícil.

Protección de datos: qué se registra, quién lo ve, cuánto se guarda

Un sistema supervisado registra información. Y esa información tiene que estar protegida, igual que el acceso al proceso.

Las preguntas son las mismas que para el acceso: qué se registra, quién puede verlo, cuánto tiempo se guarda, con qué nivel de detalle. No todo el mundo necesita ver todo el registro. No todo el registro necesita guardarse para siempre.

Y hay algo más: el registro no es solo información técnica. Es información sobre el proceso, sobre los equipos, sobre las personas que los operan. Un registro mal protegido puede ser un problema legal, además de técnico.

La protección de datos no es un tema de tecnología, es un tema de criterio. Qué se guarda, quién lo ve, cuánto tiempo, y para qué.

Qué pasa cuando la seguridad falla

Hay tres escenarios posibles cuando la seguridad falla, y cada uno tiene consecuencias distintas.

Acceso no autorizado a la información. Alguien ve lo que no debería. El proceso sigue funcionando, pero la información está comprometida.

Acceso no autorizado al control. Alguien actúa sobre el proceso sin autorización. El proceso puede funcionar mal, puede detenerse, puede causar daño. Es el escenario más grave.

Interrupción del servicio. Alguien interfiere con la comunicación, y el sistema deja de funcionar. No hay daño directo, pero la instalación queda inoperable.

Los tres escenarios son distintos, y los tres tienen que estar contemplados en el diseño. No alcanza con proteger la información: hay que proteger el proceso, y hay que proteger la comunicación.

La seguridad no es un producto, es un diseño

Hay una idea muy extendida de que la seguridad se resuelve comprando un firewall, un sistema de autenticación, un software específico. No es así.

Los productos ayudan. Pero la seguridad no empieza en el producto: empieza en el diseño. En cómo se arquitecta la red, en cómo se definen los accesos, en cómo se registra la información, en cómo se opera el sistema.

Un firewall mal configurado no protege nada. Un sistema de autenticación mal diseñado no impide el acceso. Un software de seguridad mal usado puede dar una falsa sensación de protección.

La seguridad no es un producto que se compra. Es una decisión de diseño que se toma desde el principio, y se mantiene en el tiempo. Como todo lo que venimos diciendo en este cluster: la frontera no es técnica, es de diseño.

Un ejemplo: presión constante

Retomemos el sistema de presión constante que nos acompañó en varios artículos. Una bomba, un variador de frecuencia, un sensor de presión en la cañería, una consigna de 4 bar. Y ahora, con comunicación: alguien puede ver lo que ocurre desde otro lugar, y puede actuar a distancia.

¿Qué preguntas de seguridad aparecen en ese sistema?

• ¿Quién puede ver la presión? Un operador, un supervisor, un técnico. Cada uno con su nivel de acceso.
• ¿Quién puede cambiar la consigna? Un operador autorizado, un supervisor. No cualquiera que tenga acceso al sistema.
• ¿Quién puede detener la bomba? Un operador, un técnico. Y con qué condiciones: no en cualquier momento, no sin verificar el entorno.
• ¿Qué información se registra? La presión, las alarmas, los eventos. Y durante cuánto tiempo.
• ¿Quién puede ver el registro? Un operador, un supervisor, un técnico. Cada uno con su nivel de acceso.
• ¿Qué pasa si alguien accede sin autorización? El sistema debería detectarlo, registrarlo y, si es necesario, bloquear el acceso.

Ninguna de esas preguntas es técnica. Todas son de criterio. Y todas se responden en el diseño, no en la configuración.

Resumiendo...

Una red industrial que no está protegida es una red que cualquiera puede usar. Y en un entorno industrial, eso no es solo un problema de datos: es un problema de proceso.

La seguridad no es un producto, es un diseño. Empieza en la arquitectura de la red, sigue en los accesos, y termina en la forma en que se opera el sistema.

No todo el mundo necesita el mismo nivel de acceso. No todo el registro necesita guardarse para siempre. No todo el proceso necesita estar expuesto a la red. Cada decisión tiene su criterio, y cada criterio depende del proceso.

Y como todo lo que venimos diciendo en este cluster: la frontera no es técnica, es de diseño. La seguridad industrial no es una excepción.

Porque automatizar no es programar. Es convertir conocimiento del proceso en comportamiento controlado. Y también en información útil. Y también en acceso controlado.

El cluster de automatización y control

Es un compendio de criterios de diseño: cada artículo aborda un tema y muestra qué decisiones hay que tomar, por qué se toman de una manera y no de otra, y qué consecuencias tiene cada elección.

El objetivo no es enseñar a usar una herramienta, sino entender qué se está resolviendo antes de elegir con qué resolverlo.