Redundancia en entornos ICS/SCADA

Como hemos hablado en anteriores ocasiones, y no nos cansaremos de repetirlo, la prioridad número uno en entornos industriales es garantizar la disponibilidad. Luego vendrá la integridad y la confidencialidad, pero lo primero es la disponibilidad. Para alcanzarlo, se ha de aplicar una estrategia de Defensa en Profundidad para reducir los riesgos de sufrir un incidente de seguridad y prevenir que algo, o alguien, atente total o parcialmente contra nuestras instalaciones. Dada la limitación y naturaleza de los equipos, así como las debilidades que ofrecen en lo que a materia de seguridad se refiere, muchos de ellos deben delegar en la infraestructura de red la seguridad que por sí mismos no pueden ofrecer. Para ello, ha de comenzarse por la separación de los entornos IT y OT; y más tarde en la segmentación de este último definiendo zonas más pequeñas con el fin de que si una se ve afectada, la amenaza no se propage al resto.

Sin embargo, esto no es lo único que debemos considerar. Si queremos que nuestra red sea resiliente, no sólo debe evitar,  y ser capaz,  de mitigar un ataque sino que debe ser tolerante a fallos, ya sean éstos intencionados o no.

Los enlaces redundantes suponen una medida para evitar puntos únicos de fallo que puedan dejar fuera de servicio toda una instalación. Duplicando las vías de comunicación conseguimos que, en caso de producirse uno, los sistemas comunicarán por caminos alternativos. Así podemos establecer dos posibles propósitos:

  1. Tolerancia a fallos

Aumento de las vías de comunicación que permitan reconducir el tráfico por alguna de las restantes.

  1. Balanceo de carga

Disponiendo de dos o más enlaces entre equipos podemos no sólo lograr el punto anterior sino también un envío alternativo de paquetes por canales distintos de tal manera que consigamos descongestionarlos en caso de saturación de alguno de ellos.

Aunque el punto uno en realidad también está incluido dentro del segundo, el uso de enlaces redundantes en entornos industriales esta usualmente dirigido a éste ya que es más importante garantizar la disponibilidad que el rendimiento. Esto último además se refuerza con que las necesidades de anchos de banda en entornos OT son más pequeñas que en IT.

La tendencia de las comunicaciones industriales es que se basen en tecnologías Ethernet y servicios TCP/IP dejando atrás, o reduciendo el uso,  protocolos basados en buses tipo RS-485 o serie. Sin embargo, el tráfico broadcast propio de la tecnología Ethernet no permite el uso de enlaces redundantes por lo que hemos de implementar protocolos que resuelvan este problema. El más extendido es Spanning Tree Protocol o algunas de sus versiones como RSTP, MSTP o PVSTP, el cual permite disponer de varias rutas físicas, pero bloqueando los puertos de los elementos de la red de tal manera que sólo exista una activa. El resto, permanece en “Standby” hasta que, como digo,  se produzca una caída de alguno de los enlaces que permanecen activos obligando a recalcular una segunda ruta que reestablezca las comunicaciones,  activando alguno de esos enlaces que permanecían en “Standby”. Hasta que esto ocurre transcurre un tiempo que puede ir de uno a varias decenas de segundos según sea el protocolo elegido.

Esto en entornos IT puede no suponer un problema, donde el retraso en décimas de segundo puede pasar inadvertido mientras se manda un correo o se accede a un fichero en una unidad de red. Aparte, claro está, que existan tecnologías más modernas que permitan la supresión de bucles en Capa 2 y por ende, estos protocolos. Pero insisto, aunque estén implementados, los tiempos pueden ser más amplios, algo que resulta inaceptable para entornos OT. Para hacernos una idea, en comunicaciones tipo RT (Real Time) o IRT (Isochronous Real Time) hablamos de latencias por debajo de 10 ms y 1 ms, respectivamente. Es por ello que las medidas de entornos IT no son aplicables, una vez más, a entornos de automatización, por lo que se han de aplicar otras. En resumen, el método para conmutar de un enlace a otro debe ser predecible para determinar el límite tolerable de latencia, y por tanto, conocer de antemano cómo puede afectar a las comunicaciones según sea su naturaleza. El objetivo debe ser que la convergencia sea tan rápida que resulte transparente para las aplicaciones en uso sin sobrepasar los límites tolerables.

Es por esto que en entornos OT no hablamos de Spanning Tree, ni como decía, ninguna de sus variantes. No tienen cabida. Han de emplearse otros. En las próximas entradas veremos estos protocolos y cómo, una vez más, disponer de una arquitectura de red nos proporcionará,  junto con las medidas de seguridad paralelas,  una resiliencia mayor para hacer frente al creciente número de amenazas y riesgos a los que se enfrentan nuestras infraestructuras.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Un saludo!

Copias de Respaldo

Bueno, bueno, bueno, ya estamos de vuelta con otra entrada.

Tener un Plan de Recuperación de Desastres es vital para cualquier organización que desee garantizar la continuidad de sus actividades independientemente de la causa que provoque el fallo. Existen multitud de protocolos y configuraciones (STP, HSRP, VRRP, GLBP, Etherchannel, etc.) que dotan a nuestra infraestructura de una tolerancia a fallos y proporcionan una alta disponibilidad en los servicios que ésta presta.  Pero aunque muy bien que tengamos montado todo, la electrónica, el equipamiento, etc.  puede fallar y aunque todo siga funcionando como si no hubiera pasado nada, hay que solventarlo para seguir manteniendo esa “tranquilidad”.

Si bien tener redundado el equipamiento es la mejor opción, requiere de una inversión mayor algo que pequeñas o medianas organizaciones,  bien porque no pueden permitírselo o  no se justifica el gasto con las necesidades corporativas, no lo implementan. Por tanto, tengamos, o no, el equipamiento por duplicado resulta indispensable, poseer una copia de respaldo tanto de la configuración como de la imagen del sistema operativo de cada uno de nuestros equipos, para así restablecer cuanto antes la funcionalidad  del equipo en cuestión. Pongamos que dañado.

Para ello los dispositivos Cisco con plataforma IOS  nos permiten almacenar la configuración, tanto de forma periódica o cada vez que guardemos la “running-config”, y almacenarla, por ejemplo,  en un servidor FTP accesible en nuestra red.

Con nuestro equipo configurado,

SWITCH_01#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

SWITCH_01(config)#archive

SWITCH_01(config-archive)#path ftp://192.168.10.21/FTP

SWITCH_01(config-archive)#write-memory

SWITCH_01(config-archive)#time-period 5

SWITCH_01(config-archive)#exit

SWITCH_01(config)#ip ftp username switch01

SWITCH_01(config)#ip ftp password switch01

SWITCH_01(config)#ip ftp source-interface vlan 10

SWITCH_01(config)#do wr

Una vez entrado en el submenú “archive” indicaremos la ruta donde se almacenarán las copias. En este caso será por FTP contra el servidor con IP 192.168.10.21 y la carpeta con nombre “FTP”. Con “write-memory” indicaremos que cada vez ejecutemos  “copy running-config startup-config” se realizará una copia. Sin embargo si lo que queremos es que cada cierto tiempo se copie la configuración indicaremos “time-period” seguido de la frecuencia en minutos con un valor entre 1 y 525600.

Finalmente deberemos indicar las credenciales con las que nos loguearemos en el servidor. Para ello con “ip ftp ……..” configuraremos el nombre, la contraseña y la interfaz desde la cual se iniciarán las conexiones FTP. En nuestro caso será la que tenga la interfaz virtual de la vlan 10.

Como servidor FTP he tirado de Filezilla, tanto para un cliente como para el servidor. Pero bueno hay más opciones, eso como veáis.

Dependiendo de nuestro parque esta puede ser una buena solución a las copia de respaldo de nuestras configuraciones pudiéndola ajustar a nuestras necesidades concretas. Sencillo, útil y barato.

Como punto flaco, que FTP manda en texto claro tanto el “usuario” como la “contraseña”. Pero bueno, con FTP es lo que toca.

Espero sea de utilidad.