Redes Zero Trust: El aislamiento y la bidireccionalidad

La relación entre las arquitecturas Zero Trust y la morfología de la redes, aunque pueda parecer evidente, esconde algunos detalles que no son triviales de encontrar en la literatura de ciberseguridad.

La filosofía de diseño de redes basas en los principios Zero Trust persigue un objetivo sencillo de entender: Evitar la posibilidad de que un paciente cero dentro de una red pueda propagar su carga activa al resto de los elementos de la red.

Este contenido salió publicado en el número de Mayo de 2021 de la revista IT Digital Secutity. Descárgatela.

Es decir, una Red Zero Trust tiene exactamente la misma posibilidad que una red normal de tener una máquina infectada. Pero cuando se da este evento, las redes “normales” confían en que los mecanismos de seguridad eviten la propagación al resto de los sistemas. Sin embargo una Red Zero Trust impide por su propio diseño que exista propagación al resto de la red.

La diferencia principal entre estos dos modelos es que todo sistema de protección tiene posibilidad de fallos debido bien a errores de configuración o a la aparición de vulnerabilidades.

Cuando una red se protege por diseño siguiendo modelos Zero Trust no está sujeta a errores de gestión y no pueden aparecer vulnerabilidades que le afecten, salvo las propias de los elementos que estructuran la propia red.

Pero… ¿cómo debería ser la morfología de una red Zero Trust?

Hay que poner en marcha tres reglas básicas en el diseño de las redes Zero Trust.

Separar los puestos de trabajo de los servidores que les dan servicio.

Las redes de los puestos de trabajo deberían estar separadas de las redes en la que se ubiquen los servidores que les den servicio como los Active Directory, Samba, Discos compartidos, proxy…

Entre los puestos de trabajo y los servidores debe ubicarse algún tipo de elemento de control que impida la visibilidad directa entre ellos.

¿Cómo reduce esta medida la capacidad de propagación de un paciente cero?

Aunque pueda parecer obvio, los puestos de trabajo solo deben alcanzar a los servidores que les dan servicio a través de los puertos y los protocolos específicos que necesitan para su trabajo, debiendo están específicamente bloqueados todos los demás puertos y protocolos.

Recordemos en este punto que todo lo que no es intrínsecamente necesario debe estar específicamente prohibido.

Impedir la visibilidad entre los puestos de trabajo.

Todas las redes deben estar configuradas de tal manera que los elementos que las integran no tengan visibilidad entre ellas. Especialmente las redes de puestos de trabajo.

Este principio de diseño de redes Zero Trust muchas veces es difícil de conseguir ya que la forma de diseñar históricamente la comunicación entre los sistemas daba por hecho la visibilidad entre ellos.

Aún hoy nos encontramos con docenas de elementos en nuestras redes que requieren tener una visibilidad muy amplia de los elementos con los que deben comunicarse. Los ingenieros de comunicaciones y sistemas se encuentran a veces con retos complejos de gestionar para cumplir con este principio. Pero no deberíamos dejar de afrontarlo por complejo que pueda parecer.

¿Cómo reduce esta medida la capacidad de propagación de un paciente cero?

Parece evidente. Una red donde los elementos no tienen, por diseño, visibilidad entre ellos va a complicar mucho, no sólo la propagación de un paciente cero, sino los movimientos laterales que requieren habitualmente ataques más sofisticados no basados en propagación de malware.

Impedir la bidireccionalidad entre puestos de trabajo y servidores

Con las dos medidas anteriores tenemos mermada la capacidad de propagación por un lado entre servidores y puestos de trabajo, y por otro lado anulada la propagación entre elementos (especialmente puestos de trabajo) dentro de la misma red.

Una vez separados los servidores de los puestos de trabajo, nos toca trabajar sobre las reglas de comunicación entre ambos.

Es fundamental eliminar la bidireccionalidad entre puestos de trabajo y servidores.

Podemos agrupar los servidores en dos tipos:

- Los que son accedidos por los puestos de trabajo.
- Los que aceden a los puesto de trabajo.

Dentro de nuestros modelos arquitectónicos utilizados para diseñar redes, deberíamos considerar tres tipos de redes excluyentes, las dos anteriores más las redes de los puestos de trabajo.

Es decir, la comunicación entre las redes de puestos de trabajo y las redes de servidores siempre debería ser unidireccional:

. Si una red de puestos de trabajo puede acceder a una red servidores, esta no puede acceder a la red de los puestos.
. Si una red de servidores puede acceder a una red de los puestos de trabajo, esta última no puede acceder a esa red de servidores.

No pueden estar mezclados en la misma red los servidores que necesitan acceder a las redes de los puestos de trabajo (como servidores de Backup, monitorización, gestión de los puestos…) con los servidores que son accedidos por los puestos de trabajo (AD, LDAP, correo, NAS…)

¿Cómo reduce esta medida la capacidad de propagación de un paciente cero?

La utilidad de esta medida es menos evidente que la de los dos casos anteriores, aunque es fundamental para no anular la aportación positiva de ambas.

Esta media persigue evitar que un paciente cero en un puesto de trabajo puede utilizar como elemento de propagación un servidor al que deba tener acceso para su funcionamiento normal, y que este a su vez, si es contagiado, pueda generar una propagación masiva al resto de los  puestos de trabajo. Este es un modelo de propagación utilizado por múltiples malware.

Siguiendo estos tres mecanismos de diseño de redes Zero Trust no sólo reduces drásticamente la capacidad de propagación de un paciente cero, sino que simplificas mucho la complejidad de las reglas de seguridad entre las redes de puestos de trabajo y las redes de servidores.

El volumen de trabajo que genera la implantación de estas medidas en grandes redes hace que haya pocos proyectos en la industria de transformación de redes a modelos Zero Trust. Pero si en algún momento vuestra empresa aborda algún proyecto SDN o de migración a la nube, no lo dudéis… ¡Es el momento de aplicarlas!