Firewalls en Capa 2 en entornos OT

En muchas ocasiones se habla que la primera medida técnica a implementar en lo que a seguridad en entornos industriales se refiere es definir los perímetros entre los entornos IT y OT. Para ello empleamos NGFW capaces no sólo de filtrar tanto por IPs y servicios sino realizar DPI (Deep Packet Inspection) a nivel de capa 7 además de otras funcionalidades como Antivirus, IDS/IPS, Anti DoS. Ya dentro del entorno OT, la recomendación es definir áreas, o zonas, más pequeñas y filtrar el tráfico entre ellas por medio de un segundo Firewall. El de “Segmentación”.

Físico o virtual, en el supuesto de que un error humano o acción malintencionada se produjese en alguna de ellas, evitaríamos la propagación al resto provocando un daño mayor. Además, si el daño es menor, el tiempo que necesitaremos para recuperar el conjunto de equipos afectado será menor, como menor será su número.

En la siguiente imagen podemos ver una configuración en la dicha separación la hacemos por medio de la definición de Firewalls Lógicos dentro de uno físico del fabricante Fortinet.

Esquema de uyso de Firewall Virtuales

El tamaño de estas áreas, zonas o celdas según sea la literatura de referencia, podrá albergar un número mayor o menor de equipos. Una de las opciones es definir una VLAN para cada una de ellas con un único dominio de broadcast y direccionamiento. Esto cubriría aspectos como protocolos industriales que operen en Capa 2 o tráfico multicast como LLDP. De esta manera podremos filtrar cualquier comunicación entre subredes, otras áreas, servidores en IDMZ (Industrial DMZ), estaciones de ingeniería, etc. Todo este tráfico pasaría por el Firewall de “Segmentación”.

Esto supone asumir que una acción malintencionada en la misma subred podría tener éxito ya que el control se efectúa cuando llega, al menos, en Capa 3. No en Capa 2. Pero, ¿qué ocurre si por alguna razón tenemos que llevar a cabo un filtrado a nivel de Capa 2 a un nivel más bajo y un número de equipos más reducido? Quizás una de las respuestas sea el cambio, o rediseño, del plan de direccionamiento de la/las área/s OT en cuestión y así escalar hasta el siguiente nivel. Sin embargo, esto no puede ser viable.

Mejor pongamos un ejemplo gráfico:

Arquitectura

Como podemos observar en esta celda disponemos de un convertidor de fibra a cobre hacia un switch (Switch 1) donde se localizan un HMI y del que cuelga otro (Switch 2) al que se encuentran conectados otros controladores, componentes “Safety”, control de movimiento, etc. Si por alguna razón dicho HMI sufriera alguna infección o se quisiera llevar acabo alguna acción malintencionada, podría alcanzar el resto de equipamiento conectado. Vemos que todo se ubica en un mismo dominio de broadcast y con direccionamiento bajo 192.168.0.0/24.

El problema que se plantea es que el HMI sea un equipo con un sistema operativo sin actualizaciones o fuera de soporte. Bien porque la actualización de éstos pueda ser difícil, aunque no imposible, y por otro lado dado, el ciclo de vida elevado, genera más probabilidad de falta de actualizaciones, nuevos desarrollos, pero siguiendo 100% funcionales. Esto puede suponer un riesgo importante a los equipos ubicados en el otro switch de donde cuelgan autómatas, controladores y otros sistemas.

Sin embargo, no podemos olvidar que las intervenciones en entornos OT no sólo deben ser lo menos intrusivas posible sino, que no alteren la operación normal de las instalaciones. El despliegue de soluciones debe ser transparente y con un nivel de riesgo lo más cercano a cero. Como ya sabemos el riesgo igual a cero, no existe.

Cada cambio introduce un riesgo. Por mucho que lo preparemos, planifiquemos, involucremos a todas las personas que puedan responder ante alguna acción no prevista, siempre puede suceder algo que no esté contemplado. La falta de respuesta en tiempo y forma puede desembocar en la pérdida de disponibilidad. Por ello, cuanto menor sea la cantidad de acciones a realizar mejor. Hemos de guardar un equilibrio entre simplicidad y eficiencia.

Es por todo lo anterior que hemos de considerar el uso y funcionalidades a nivel de capa 2 que ofrecen los cortafuegos. Esto es, filtrar el tráfico entre dispositivos que se encuentren en la misma red y tratar de proteger de forma individualizada todos los elementos desplegados en ella sin requerir cambios adicionales. Esto nos permitirá mantener el direccionamiento intacto siendo la única pérdida de servicio, a priori, los segundos que empleemos en conectar el equipo en nuestra red. Obviamente esto introducirá un punto más de fallo, algo que deberemos asumir si lo que queremos es que otro elemento nos proporcione la seguridad que pretendemos.

Por tanto, cuanto más reduzcamos el riesgo sin intervenir en los equipos finales, indudablemente mejor. Claro está esto también dependerá de la criticidad del equipo, su funcionalidad, ciclo de vida, soporte, entre otros factores. Sin embargo, esto no debe ser algo que deba ser así siempre. Para alcanzar unos niveles lo más completos e integrales posibles hemos de aplicar aquellas que estén disponibles en PLCs, switches industriales, entre otros. Aquí os dejo aquellas que podremos encontrar en autómatas modelo S7-1200 del fabricante Siemens.

En el día de hoy he querido destacar la necesidad de uso de modos y funcionalidades a nivel de capa 2 para proteger los entornos industriales, evitando así cambios o interfiriendo en la operativa aunque esto sea tan sencillo como cambiar una dirección IP.

En sucesivas entradas abordaremos este tema y la manera de cubrir estas necesidades. Esto es uso de firewalls a nivel de capa 2, en lugar de 3, como es a lo que estamos más acostumbrados.

¡Nos vemos en la siguiente!