Como he comentado en artículos anteriores, el objetivo primero para entornos OT, es garantizar la disponibilidad de las instalaciones, quedando a un segundo y tercer plano la integridad y confidencialidad de la información manejada. Esto no quiere decir que no sea importante, sino que se establecen prioridades.

Lo que se pretende con la securización de las instalaciones, es reducir los riesgos de sufrir un incidente y que se vea afectado el funcionamiento de las Infraestructuras de automatización y Control, ya sean Críticas o Industriales. Sin embargo conviene recordar, que no es menos importante garantizar la seguridad de tipo “Safety”. Me refiero a las funcionalidades de protección a personas, esas que vienen de la mano de accionadores de emergencia, barreras infrarrojas, detectores de presencia, y demás dispositivos que evitan que un técnico de mantenimiento, operario, etc. sufra un accidente que ponga en riesgo su vida o integridad física.

De todos es sabido que las amenazas, vulnerabilidades, riesgos y negligencias están ahí, y que la seguridad al 100% no existe. Lo que hoy puede tener unos niveles aceptables, mañana con la aparición de un nuevo bug, exploit, etc. puede no tenerlo.  Aparte, considerando la idiosincrasia de estos entornos con funcionamientos en muchos casos 24 X 7 X 365, la puesta en marcha de parches, actualizaciones, mejoras y nuevas soluciones, puede retrasarse a períodos de tiempo realmente largos. Eso teniendo en cuenta que puedan ser aplicados sobre las mismas plataformas, ya que no siempre es así.

Por tanto, teniendo en cuenta que a pesar de haber desplegado un plan de seguridad para nuestro entorno OT, ¿es suficiente para garantizar la disponibilidad? ¿qué ocurre durante el este período de tiempo en el que estamos expuestos por no poder aplicar medidas correctoras? ¿qué va a pasar si en ese intervalo sufrimos un incidente?

Pues bien, garantizar la disponibilidad no es sólo poner en marcha aquellas medidas que reduzcan los riesgos, sino que, si sufrimos un incidente, tengamos la capacidad de recuperarnos en el menor tiempo posible. Para alcanzar este propósito es necesario implementar, junto con el resto, un Plan de Contingencia que permita restaurar dispositivos y sistemas a un estado nuevamente operativo.

Por ejemplo, si un HMI queda infectado o por alguna razón su hardware sufre un daño, y esto desemboca en una sustitución del equipo, mientras dure dicha operación nuestra instalación puede quedar fuera de servicio. O bien, un operario realiza un cambio incorrecto en un autómata y debe cargarse el programa a una versión anterior.

Ejemplos se pueden poner muchos, pero lo cierto es que resulta indispensable la inclusión de un proceso de generación de copias de respaldo para cubrir estos supuestos. Cuando hablo de un proceso me refiero a un método. Aquí hay que considerar muchos puntos. Uno de ellos es el tipo de equipo. No es lo mismo un PC, que un servidor SCADA, que un PLC o RTU. Así cómo en los dos primeros podremos instalar un agente que nos haga una copia del sistema operativo, ficheros, aplicaciones, etc. en el segundo y tercero su naturaleza puede que no nos lo permita y debamos elegir otra solución o vía.

Un aspecto clave es establecer la forma en que se hacen de estas copias. Todo cambio debe de estar documentado y programado, salvo que se trate de un incidente obviamente. Por ello debe seguirse una nomenclatura que permita la identificación inequívoca de los ficheros, catalogar si es software, sistema operativo, versiones, fecha en la que se hizo, control de accesos a los mismos por parte de las personas responsables, control de integridad, etc. Además, dependiendo del número dispositivos puede justificarse la instalación de herramientas centralizadas que permitan automatizar este proceso.

La generación de copias lleva aparejado necesariamente un espacio de almacenamiento adicional. Nuevamente dependiendo del número, puede necesitar de una inversión en nuevo hardware o sistemas. Aquí la estrategia marcará la manera de llevarse a cabo. Me refiero a que éstas sean accesibles bien de forma local o por red, esto es, que en caso de recuperación pueda descargarse la copia desde un servidor o desde un disco duro externo conectado via USB.

Aplicaciones en el mercado hay varias. En mi ejemplo utilizaré una del fabricante Acronis en concreto del producto Backup Advanced 11.7. Con él podremos realizar imágenes de disco de nuestros equipos y, como comentaba,  para recuperarlos en caso de fallo, rotura de hardware, o cualquier otra incidencia que afecte a su funcionamiento.

Esta solución consiste en un servidor central de administración y un agente software que se debe instalar en los equipos sobre los que se quiere hacer los backups. Para administrarlo, necesitamos de un software cliente (consola) con el que conectaremos al servidor y desde ahí llevar a cabo todas las operaciones necesarias como pueden ser:

1. Dar de alta equipos.
2. Organizar lugares de almacenamientos de las copias (Bóvedas).
3. Control de acceso y permisos de usuarios.
4. Programación de copias.
5. Definición de nodos de almacenamiento.

En lo referente al servidor de gestión, a la hora de instalar nos preguntará sobre cómo va a utilizarse el equipo para a partir de ello instalar más o menos componentes.

En el Escritorio del servidor se habrá generado un acceso directo del software con el que nos conectaremos (consola) , en este caso a nosotros mismos contra la IP 127.0.0.1.

Por la parte del cliente, ha de instalarse dos tipos de software. Uno denominado “AcronisAgentCore” y “AcronisAgentWindows”. La instalación es sencilla, un ejecutable más.

Luego, desde el servidor, deberemos dar de alta los equipos para poder dar las órdenes de la generación de las copias. Lo haremos proporcionando el nombre o IP además de las credenciales definidas en el proceso de instalación.

En el apartado “Equipos con agentes – Todos los equipos con agentes” veremos el equipo ya registrado, para este ejemplo, el “HMI-EST-01”.

Allí encontraremos varios parámetros de configuración. Dadas las características de los entornos industriales me centraré en concreto en dos de ellas. La primera es la compresión. La imagen guardada podrá ser comprimida para ahorrar espacio, sin embargo esto podrá afectar no sólo en la generación de la copia sino también la recuperación de la imagen. Esto habrá de tenerse en cuenta ya que aumentará el tiempo en el que el equipo podrá estar disponible de nuevo.

La segunda corresponde la prioridad que tendrá el agente de Acronis con respecto al resto de procesos que corran sobre el equipo final. La generación de la copia consume una serie de recursos, los cuales no podrán afectar al resto aplicaciones control que corre en ese mismo instante. Las copias deberemos programarlas, de ser posible, para su ejecución fuera del horario de funcionamiento pero en el supuesto de que no sea así deberemos dar prioridad al resto en lugar a la de Acronis.

Finalmente, lanzaremos la tarea teniendo una duración variable en función de todos los parámetros configurados y el rendimiento de nuestra red.

Si bien los valores pueden variar bastante, para hacernos idea, una máquina virtual de 60,5 GB de disco duro se quedó en 44 GB y tuvo una duración del entorno a media hora.

Para poder recuperar un equipo, deberemos crear un dispositivo de arranque, esto es un Live CD o USB. Para ello tendremos que instalar la aplicación “Acronis Media Builder” y definir alguno de ellos.

Con anterioridad deberemos tener cambiados los parámetros en la BIOS del sistema para arrancar desde la unidad de CD o medios extraíbles. A partir de aquí el asistente de Acronis nos guiará durante el proceso, teniendo que asignar una IP e indicar el lugar donde se almacena la copia que queremos recuperar.

El mensaje de hoy no es tanto ver la manera de “protegerse” sino de “recuperarse”. O dicho de otra manera no tanto a la seguridad sino  minimizar el tiempo de recuperación en el caso de que tengamos una brecha. Las estadísticas dicen que las vulnerabilidades descubiertas van en aumento y que los ataques cada vez son más diversificados. Que exista un parche, no quiere decir que se pueda implementar nada más publicarse y por tanto, mientras esta situación se mantenga, los equipos son vulnerables. He puesto el ejemplo de un HMI ya que están a la cabeza de ser el objetivo estrella, para desde ahí llevar a cabo distintas acciones sobre la red de control. Estos HMI están basados principalmente sobre sistemas operativos Microsoft Windows, de ahí que en este caso haya puesto como ejemplo una solución como la de Acronis Backup Advanced, y aplicación sobre equipos con esas características.

Espero que haya sido interesante, lo dicho “garantizar la disponibilidad no es sólo poner en marcha aquellas medidas que reduzcan los riesgos, sino que, si sufrimos un incidente, tengamos la capacidad de recuperarnos en el menor tiempo posible”. 

Saludos!