Tunneler o comunicación transparente OPC Cibersegura: Una alternativa robusta a la VPN tradicional


Dada la vulnerabilidad de las comunicaciones y la cantidad de ciberataques a lo que estamos expuestos, nos lleva a pensar que no es posible tener ambas cosas a la vez: Datos de producción y ciberseguridad .

Pero, ¿por qué no podemos tener ambas o como tener datos OT en IT o CLOUD?

Lo normal es que sí queremos datos de producción en tiempo real, podemos comprometer la ciberseguridad industrial pero podemos plantearlo de otra manera y es tener la solución que nos permite bloquear completamente la red industrial contra ciberataques.

¿Cuál es la CLAVE?  

La protección de puertos de firewall abiertos

Proporcionar el más alto nivel de ciberseguridad manteniendo cerrados todos los puertos entrantes de los firewall es algo para lo que la mayoría de los protocolos industriales no han sido diseñados.
Un ejemplo: OPC DA y OPC UA utilizan la clásica arquitectura cliente/servidor donde el cliente se conecta a un servidor y esto supone un riesgo significativo.

¿Por qué las VPN y MQTT no son soluciones fiables?

1.- SOLUCIÓN: REDES VPN

Para empezar, a nivel de comunicación de datos, usar una DMZ y cerrar todos los puertos de firewall entrantes es mucho más seguro que usar una VPN.

Una VPN en realidad no proporciona el nivel de seguridad que necesita un sistema industrial, simplemente extienden efectivamente el perímetro de seguridad más allá de la red de la planta para incluir la red de IT.
Una brecha de seguridad en la VPN expondría todos los sistemas de ambas redes a un ataque como un barco que se hunde si le entra una vía de agua

2.- SOLUCIÓN:  Datos OPC a través de MQTT

El push de datos OPC a la nube es otra posibilidad de comunicaciones.

Probablemente, el enfoque más común para realizar conexiones salientes mientras se mantienen cerrados los puertos del firewall de la planta es mediante el uso de MQTT.
Los dispositivos IoT/IIoT o software se conectan a un servidor llamado «broker» y publican sus datos en él y/o reciben datos de él.

El «BROKER MQTT» no examina lso datos que recibe, sino que simplemente la pasa como un mensaje de cada publicador a todos los suscriptores.

En el ámbito de la seguridad, esta arquitectura «push» evita el problema de la arquitectura cliente-servidor de OPC, lo que permite que los dispositivos realicen conexiones salientes sin abrir ningún puerto de firewall. Y además mediante el uso de un broker central, es posible establecer conexiones de muchos a muchos, lo que permite que varios publicadores se conecten a varios suscriptores.

MQTT resuelve así algunos problemas de comunicación y seguridad de IIoT. A pesar de estas ventajas arquitectónicas, MQTT tiene inconvenientes que deben abordarse si se quiere que sea realmente útil para escenarios de comunicación de OT/IT e IoT industrial.

5 razones a valorar el por qué MQTT puede NO ser la mejor solución:

MQTT es un protocolo de transporte pero no especifica un formato de mensaje especifico, lo que plantea problemas de interoperabilidad entre diferentes aplicaciones de diferentes fabricantes ya que cada uno creará el mensaje MQTT con un formato diferente. Sparkplug B se creó para abordar este problema y está comenzando a ganar terreno entre los proveedores y usuarios.

.

 

Broker MQTT no conserva el orden del tiempo entre los valores de datos sobre diferentes topics MQTT. Esto significa que puede no mantener el orden según el tiempo en el que se ejecute el envío (puede que un evento que ocurren en el orden A, luego B y luego C podrían recibirse en  la aplicación como C, luego B y luego A) y por lo tanto ocasionar problemas en sistemas físicos donde el orden y el tiempo de llegada de mensaje es crítico en muchos casos de uso de control industrial.

Broker MQTT no tienen forma de indicar que una fuente de datos está desconectada.
La aplicación que recibe el dato  no puede diferenciar entre un valor antiguo de un sensor que ha fallado o un valor actual que simplemente no ha cambiado.

QoS y MQTT: Los niveles de calidad de servicio (QoS) de MQTT no son adecuados para su uso en una DMZ, ya que solo se aplican a conexiones individuales.
Dado que la conexión a través de una DMZ requiere varios saltos, el emisor de datos nunca sabrá si un mensaje MQTT ha llegado a un usuario, independientemente del QoS que se seleccione.

Broker MQTT no manejan bien las situaciones de sobrecarga. Si los datos llegan más rápido de lo que un subscriptor puede procesar, es probable que se pierda la consistencia de los datos y el orden o timing de tiempo entre el  «publicador y el subscriptor» de datos.

 

En resumen, MQTT mantiene cerrados los puertos de firewall entrantes, lo que lo hace útil para algunas aplicaciones de IoT industrial, en particular, la recopilación de datos de dispositivos de campo IoT o embebidos. Pero su incapacidad para garantizar la consistencia de los datos entre el «publicador y el subscriptor», particularmente a través de una DMZ, no lo convierte en un candidato ideal para las conexiones OT/IT.

NUESTRO CONSEJO: Utilizar la tunelización segura de datos industriales con Cogent DataHub.

———————————————————————————————————————————————

El TUNNELLER es un túnel de datos en tiempo real:

Un túnel de datos bien implementado, garantiza una comunicación óptima de datos históricos y en tiempo real y facilita la implementación y ayuda a cumplir los requisitos más exigente respecto a la comunicación de datos a través de una DMZ según las normativas de ciberseguridad actuales como por ejemplo la utilización de una DMZ (práctica recomendada por organismos como INCIBE por ejemplo).
El tunneler es una herramienta transparente que establece una conexión TCP punto a punto entre dos o más DataHub a través de una conexión con certificados y encriptación SSL. De esta forma, todo el tráfico que recorre la planta y pasa por la DMZ hasta acabar en IT, se traspasa de una forma transparente y lo menos intrusiva y lo más segura posible para garantizar la máxima fiabilidad ya sea en la trasmisión como en la encriptación y propagación del dato.
Mediante el túnel de datos, Los servidores OPC y otras fuentes de datos en el lado de OT hacen conexiones locales a un componente de middleware (software Cogent DataHub), mientras que los «clientes receptores» en el lado de IT hacen lo mismo sin necesidad de redirigir puertos ni abrir puertos de entrada a la red, incluso pudiendo trabajar a través de proxies. Una vez configurado el túnel, los datos fluyen bidireccionalmente entre ambos extremos de una forma transparente, segura y optimizada.

En muchos casos de uso, esta característica proporciona lo mejor de ambos mundos: Acceso remoto a los datos de producción, además de seguridad,
En definitiva, el Tuneller es la mejor solución sin necesidad de abrir puertos en la zonas vulnerables y trabajar mediante DMZ sin exponer los datos directamente a servicios CLOUD y en tiempo real.

OTRAS UTILIDADES VENTAJOSAS DEL TUNNELER:

1.- Conversor de Protocolos: Al actual como cliente y servidor OPC UA y DA así como Master Modbus TCP, puedes hacer una conversión directa entre los diferentes protocolos.
2.-Registrador: Puedes usar Cogent DataHub como un simple registrador de datos OPC o Modbus en una base de datos ODBC. Por otro lado, también puedes usarlo a la inversa y leer datos de una base de datos y exponerlo como un dato OPC.
3.- Como historiador: Cogent DataHub incorpora una base de datos en influx DB que permite hacer un store and fordward del dato.
4.- Como comunicador de datos y herramienta segura para comunicar datos de forma ciber segura entre diferentes arquitecturas de redes.
5.- Como enviador de datos: Está diseñado para mandar datos por MQTT a la mayoría de servicios cloud en la nube.
6.- Como Broker MQTT: Actúa como un broker MQTT por lo tanto los dispositivos MQTT se podrán conectar a DataHub para recoger esos datos. Sería una conversión transparente entre MQTT y OPC por ejemplo.
7.-Como visualizador: Dispone de la herramienta Grafana para Visualizar datos OPC y MQTT.
8.- Como servidor de Redundancia de datos para servidores Redundantes.