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:
- Tolerancia a fallos
Aumento de las vías de comunicación que permitan reconducir el tráfico por alguna de las restantes.
- 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!