La segmentación (microsegmentación) desde una perspectiva práctica

Antes de que entremos de lleno en las mejores prácticas y estrategias, debemos definir nuestra área de acción. La segmentación de la red implica “dividir” la red en partes (segmentos) y definir quién puede acceder a qué y de qué manera (por ejemplo, solo se puede acceder a los servidores web a través de HTTP/S). 

Tradicionalmente, esto se ha logrado mediante las VLAN y los firewalls físicos, pero últimamente cada vez se observan más enfoques basados en software para los firewalls y la segmentación (Guardicore Segmentation de Akamai, por ejemplo). No recomendaremos ni uno ni otro, ya que ambos enfoques presentan ventajas y desventajas. Nuestras políticas y estrategias recomendadas son independientes de los proveedores y se pueden aplicar en cualquier lugar.

Al pasar del control del tráfico mediante VLAN, las listas de control de acceso (ACL) y los rangos de IP al uso de etiquetas personalizadas independientes de los proveedores, se accede al ámbito de la microsegmentación. En todas nuestras estrategias de esta entrada de blog se asumirá que utilizamos la microsegmentación.

Debería ser posible adaptar las estrategias y las directrices de modo que no sea necesaria la segmentación, pero el proceso para definir todas las VLAN, las ACL y las listas de IP y mantenerlas es probablemente irrealizable, o conllevaría el desgaste inmediato de todos los administradores e ingenieros de red. (Intentar definir el rango/grupo de IP de todos los servidores de finanzas, podría ser factible, pero ¿puede mantener esa lista con exactitud durante mucho tiempo? Además, sería solo un grupo de servidores; en una red empresarial, tendrá muchos más: usuarios finales, controladores de dominio, administradores de dominio, impresoras, etc.)

Antes de analizar cómo realizar la segmentación, debemos abordar un requisito importante para hacerla posible: la visibilidad. La microsegmentación no existe de forma aislada. No puede proteger lo que no puede ver. Una buena segmentación solo es eficaz junto con la visibilidad de la red que organiza y resume el tráfico. Por lo general, hay demasiado tráfico para analizarlo todo de forma realista a simple vista.

Antes de pasar a las estrategias de segmentación reales, nos gustaría hablar sobre algunas directrices o principios que creemos que son cruciales para una buena segmentación.

En términos generales, los servidores que tienen mucho tráfico entrante están más en el lado de la gestión de las solicitudes, como los servidores web o de archivos (incluso los controladores de dominio entran dentro de esta categoría). Como tales, no deberían tener mucho tráfico, o al menos debería estar definido de forma estricta. 

Además, si tienen tener restricciones mínimas tanto en la salida como en la entrada, se corre el riesgo de que los atacantes utilicen el servidor como pivote, ya que los servidores son más accesibles para los atacantes y se pueden utilizar para acceder a una parte más amplia de la red.

En algunas máquinas, las políticas tienen que ser permisivas, ya que hay demasiada variabilidad en el tráfico que sale de la máquina, por lo que hay que hacer muchas excepciones. 

Tomemos, por ejemplo, los servidores de solución de salto (diferentes usuarios los utilizan para conectarse a diferentes servidores con diferentes protocolos). No podrá cubrir todos los casos de uso sin ser demasiado permisivo (lo cual acabaría con el todo el propósito de la segmentación). 

En tales casos, creemos que lo mejor es emplear a otros mecanismos de defensa y hacer que sean más estrictos (como utilizar un control de acceso de usuario más riguroso en el ejemplo de la solución de salto, o bien umbrales de alerta más bajos para supervisar los servicios).

El hecho de que ya exista alguna cadena de tráfico cuando se inicia la segmentación no significa que se deba permitir. A veces, tendrá que modificar las configuraciones existentes de las aplicaciones o los servidores si decide que el tráfico que producen es innecesario. En otras ocasiones, también tendrá que consultar las configuraciones existentes para comprender por qué existe determinado tráfico en primer lugar.

En este caso, la segmentación es como el firewall tradicional: se bloquea el tráfico entrante desde fuera de la red que no debería entrar. Normalmente, este procede de Internet, pero también puede proceder de redes de terceros que estén conectadas a la suya. 

Por ello, bloquear los puertos de protocolo de comunicaciones seguras (SSH) o de protocolo de escritorio remoto (RDP) expuestos (o, básicamente, cualquier puerto de la sección de movimiento lateral ) es aconsejable. De hecho, es mejor utilizar una lista de autorización en lugar de una lista de denegación para el tráfico que se origina fuera de su red, especialmente de Internet (considere, por ejemplo, cuántos escáneres de Internet están activos en un momento dado).

Lógicamente, al igual que con cualquier otra herramienta de seguridad, la práctica (o la política) de segmentación no sirve para todas las amenazas. En este caso, la segmentación no puede cubrir todos los vectores de acceso inicial, y confiar únicamente en la segmentación deja la red expuesta a riesgos. Muchas filtraciones comienzan con correos electrónicos de phishing o enlaces u otras formas de ingeniería social. 

Algunas filtraciones también comienzan con vulnerabilidades en los protocolos que deberían permitirse, o con credenciales poco seguras para servicios que están legítimamente expuestos a Internet, como el servidor VPN. Por este motivo, recomendamos no depender únicamente de la segmentación para evitar el acceso inicial y emplear soluciones de seguridad para la protección del host y del correo electrónico, además de la segmentación.

Hay muchas formas de ejecutar el movimiento lateral, y no las cubriremos todas. En concreto, nos centraremos en evitar el movimiento lateral que puede producirse a través de procesos legítimos que ya existen en la máquina, utilizando protocolos como RDP o SSH, servicios basados en RPC como el administrador de servicios o el programador de tareas, herramientas de gestión como PowerShell o WMI, o algunos de los protocolos y las herramientas disponibles en Linux que hemos comentado en una publicaciónaparte.

No hablaremos de vulnerabilidades de un día ni de día cero porque pueden estar en cualquier producto y con diferentes implementaciones, por lo que no resulta práctico tener una estrategia general que sea aplicable a estas. Lo único que podemos recomendar es la segmentación, ya que algo que es inaccesible es mucho más difícil de explotar.

Antes de profundizar en las diferentes consideraciones para cada uno de los diferentes protocolos, hay dos principios que se aplican a todos ellos.

Los usuarios en realidad no necesitan acceder a las máquinas de otros usuarios, especialmente a través de la red. A menos que alguien trabaje en TI, no hay mucha justificación para que se conecte a la máquina de otro usuario de forma remota. Por tanto, debería ser bastante factible restringir el tráfico entre las máquinas de los usuarios sin comprometer excesivamente la operatividad de la red.

Además, dado que los protocolos analizados en esta sección pueden utilizarse para el control o la ejecución remotos, también pueden servir como vectores de acceso inicial. Por eso reiteramos la necesidad de restringir el acceso arbitrario a Internet mediante estos protocolos.

Puesto que estos servicios son interactivos y gráficos, su uso automatizado es bastante limitado. Por lo tanto, puede esperar que no aparezca el uso de estos protocolos entre los servidores con demasiada frecuencia (la palabra clave es "esperar", si aparece, es el momento de investigar por qué). 

El mismo razonamiento se aplica entre las máquinas de los usuarios: los usuarios no tendrían que necesitar conectarse entre ellos. Las excepciones a estas suposiciones pueden ser los servidores de soluciones de salto y de terminales que permiten a los usuarios saltar entornos o acceder a servidores, las conexiones del personal de TI a los equipos de los usuarios o que los propietarios de aplicaciones se conecten al servidor de aplicaciones. 

La gestión de estas excepciones se debe realizar mediante la creación de políticas adecuadas utilizando la segmentación, pero estos esfuerzos también se deben complementar con soluciones adecuadas de gestión de acceso e identidades (IAM).

Aunque SSH es similar en concepto a los RDP, la historia es más complicada. Dado que SSH está basado en terminales (texto), es mucho más fácil utilizarlo para interactuar con el software, y hay programas y scripts que lo utilizan. Además, SSH también se utiliza para encapsular protocolos menos seguros, como SFTP, que es la encapsulación SSH del protocolo de transferencia de archivos.

Por estos motivos, SSH requiere un enfoque mucho más detallado que otros RDP. Sin una visibilidad adecuada del tráfico de red, será muy difícil segmentar correctamente SSH sin que afecte a los usuarios finales ni a la operatividad de la red.

Tanto MS-RPC como SMB no permiten inmediatamente el movimiento lateral; otros protocolos que se crean sobre estos sí lo hacen (consulte la Figura 4). SMB se utiliza para la transferencia de archivos y las comunicaciones, mientras que RPC se utiliza para llamar a funciones remotas desde interfaces definidas. A veces, RPC también se transfiere a través de SMB, por lo que están estrechamente ligados. También resulta extraordinariamente complicado segmentarlos correctamente, ya que están integrados en el sistema de dominio de Windows. 

Por ejemplo, la autenticación del dominio se implementa en Netlogon, un protocolo basado en RPC. Las políticas de grupo de dominios y los scripts de inicio de sesión se almacenan en una carpeta compartida del controlador de dominio denominada SYSVOL, y las máquinas del dominio conjunto acceden a ella a través de SMB.

Es prácticamente imposible bloquear SMB y RPC sin romper todo el dominio. Entonces, ¿qué puede hacer? Con SMB, puede crear políticas basadas en unidades lógicas: la mayoría de los servidores y las máquinas no deberían comunicarse entre sí a través de SMB, a menos que el destino sea un servidor de archivos. Por lo tanto, una segmentación adecuada de acordonamiento debería ayudar a mitigar los riesgos de SMB.

Se puede aplicar un enfoque similar a RPC, pero puede ser aún más restrictivo, ya que no necesitamos permitir el tráfico RPC a los servidores de archivos, a diferencia de SMB. Además, dado que RPC se gestiona en modo de usuario, es posible crear políticas de segmentación basadas en el servicio o el proceso de destino, por lo que solo tiene que tratar con interfaces RPC que se puedan vulnerar para el movimiento lateral (y solo si tiene un agente de segmentación que pueda manejar reglas basadas en procesos o en servicios). 

La siguiente tabla muestra las interfaces RPC que se deben gestionar para evitar el movimiento lateral.

Dado que no todas las operaciones a través de esas interfaces RPC son maliciosas (por ejemplo, algunas soluciones de supervisión y dispositivos de vigilancia interactúan con el gestor de servicios de forma remota para comprobar el estado del servicio), recomendamos inspeccionar las comunicaciones RPC existentes. Si normalmente no se accede a ellas de forma remota (o si puede reducir la lista de fuentes), le recomendamos crear políticas de segmentación en torno a ellas para disfrutar de ventajas de seguridad adicionales.

Tanto PowerShell como WMI son capaces de interactuar con máquinas remotas, y esa interacción se "acciona" mediante la Administración remota de Windows (WinRM). Dado que el uso legítimo suele ser la gestión o la supervisión remotas (con WMI), debería haber pocos casos de uso en su red. Debería ser posible crear políticas de segmentación que restrinjan el uso arbitrario y que solo lo permitan desde servidores de supervisión o máquinas de TI. 

Lógicamente, es posible que haya casos atípicos. Hemos observado algunos casos en los que los desarrolladores utilizaban con frecuencia PowerShell de forma remota por motivos prácticos; probablemente requeriría una decisión caso por caso.

A menos que desee controlar todo el tráfico saliente al estilo de 1984, no puede esperar de forma realista evitar la exfiltración de datos durante los ataques utilizando sólo la segmentación. La red de Internet es grande y extensa, por lo que no sería realista contar con un veredicto exacto para cada sitio y servidor al que se conecten los usuarios desde su red. Por ese motivo, los atacantes pueden camuflar fácilmente sus intentos de exfiltración entre el resto del tráfico saliente.

En lugar de intentar controlar el tráfico saliente, sería más factible controlar quién puede acceder a los datos confidenciales. El único lugar en el que sería posible restringir el tráfico saliente es en los servidores de la red; a diferencia de las máquinas de los usuarios, debería haber mucha menos variabilidad en sus destinos salientes.

El principio general para toda esta sección es"El hecho de que exista no significa que deba permitirse".Al segmentar una parte de la red, ya sea una aplicación esencial para el negocio (como SWIFT), una unidad operativa (como el controlador de dominio) o un entorno (como los servidores de producción), el primer objetivo del negocio es analizar el tráfico existente (Figura 5). 

Después de analizar el tráfico existente, puede crear políticas que permitan los flujos pertinentes y restrinjan el resto (esta es también su oportunidad de encontrar cualquier configuración errónea que deba gestionar el propietario de la aplicación en lugar de la segmentación). 

Recomendamos no implementar una política de bloqueo inmediatamente, sino que se ejecute en modo de solo alertas durante algún tiempo. Debe pasar a una política de restricción únicamente después de considerar que la política se está ejecutando según lo previsto y que la cantidad de alertas de infracción de política se encuentra en un nivel mínimo o controlado. 

También es importante diferenciar su entorno actual (el que existía antes de empezar a segmentarlo) y su entorno futuro (el que queda después de implementar su política de segmentación). Al implementar la segmentación por primera vez, debe tener cuidado y conocer la red para evitar causar interrupciones. 

Sin embargo, las adiciones más recientes deben añadirse teniendo en cuenta la política de segmentación existente. Haga excepciones y asignaciones de políticas donde sea necesario para una operatividad normal, pero no ignore la política existente solo porque esté expandiendo la red.

En el acordonamiento, nos interesan principalmente las interfaces del segmento con el resto de la red y con el mundo. Deseamos controlar lo que entra y sale de la parte de la red que queremos segmentar sin tener en cuenta lo que ocurre dentro del segmento.

Podemos ir un paso más allá en el acordonamiento y aplicar políticas a máquinas individuales en función de su propósito. Así, por ejemplo, si un servidor funciona solo como una base de datos, solo se le debe dar acceso a través de los puertos de base de datos; un servidor web, a través de puertos web.

Sin embargo, no es tan sencillo. Por lo general, hay más servicios que necesitan acceso a esos servidores, como los dispositivos de vigilancia, los monitores de rendimiento o la TI. Por lo general, esos puertos de acceso también tienen un aspecto muy similar a las técnicas de movimiento lateral, ya que suelen girar en torno a algún tipo de control remoto. (Por ejemplo, los dispositivos de vigilancia remotos consultan al gestor de servicios de forma similar a la técnica de movimiento lateral PsExec. La única manera de distinguir entre las llamadas es la inspección profunda de paquetes, que normalmente no está disponible).

Para superar este desafío, siempre que necesite permitir tráfico adicional además del que ya debe acceder al servicio, le recomendamos que limite las fuentes permitidas al segmento que debe realizar la supervisión.

Además, podemos limitar el acceso de los usuarios a ubicaciones confidenciales que no necesiten. Si la base de datos solo sirve a aplicaciones internas, hay pocos motivos para permitir que usuarios arbitrarios la consulten. En nuestra opinión, bloquear el acceso arbitrario de los usuarios es el paso de seguridad más importante, ya que muchos ataques comienzan por usuarios comprometidos.

Con la microsegmentación, aplicamos otra capa de detalle a nuestra política de segmentación: separamos las máquinas del segmento en función de su rol o confidencialidad. Podemos considerarla como un híbrido entre el acordonamiento de aplicaciones y el acordonamiento general. La principal diferencia con el acordonamiento es que ahora también controlamos el tráfico dentro del segmento y no confiamos automáticamente en los vecinos.

Nuestro principio aquí es que no debemos confiar en el tráfico de las máquinas vecinas solo porque estemos dentro del mismo segmento. Los atacantes utilizarán cualquier conexión que puedan para propagarse a través de la red, independientemente de los segmentos. 

Por lo tanto, incluso si tenemos el mismo tipo de servidor de aplicaciones en el segmento, no hay razón para que puedan comunicarse entre sí en cada puerto y protocolo. La microsegmentación significa que aplicamos reglas de políticas en todo tipo de tráfico, incluso dentro del segmento de red y entre máquinas con el mismo rol.

Lógicamente, las máquinas dentro del mismo segmento suelen estar más estrechamente ligadas, por lo que es más difícil añadir políticas sin que sean excesivamente permisivas.

En función de cómo defina los segmentos de la red, los principios del acordonamiento de aplicaciones con frecuencia también se pueden aplicar como principios de microsegmentación. Por ejemplo, si dividimos nuestra red en un segmento de usuario, un segmento de base de datos y un segmento de servidor web, los principios definidos en acordonamiento de aplicaciones también son adecuados para la microsegmentación. La única adición necesaria es la aplicación de los mismos principios dentro de cada segmento de aplicación entre diferentes máquinas.

Sin embargo, si nuestra red se divide en un segmento de finanzas, un segmento de ventas y un segmento de TI, y cada segmento tiene una combinación de servidores y máquinas de usuario, tenemos que ser más creativos. Después de aplicar las estrategias generales de acordonamiento a los segmentos, debemos pasar a crear políticas entre los segmentos y dentro de ellos. Podemos considerar cada segmento como una minired y luego podemos dividir cada uno en las diferentes aplicaciones y tipos de máquinas que lo configuran. (Por ejemplo, para un segmento de ventas, podríamos tener un servidor de archivos, una base de datos y máquinas de usuario). Podemos tratar cada tipo de máquina como un nuevo segmento y seguir de nuevo las directrices de acordonamiento o de acordonamiento de aplicaciones.

En la Figura 6 se resumen las relaciones entre las diversas estrategias de segmentación.

La segmentación de la red es una herramienta útil para aumentar la seguridad de la red y hacer frente a las amenazas basadas en la red. También es una herramienta que puede proporcionar un valor de seguridad inmediato, ya que no es necesario comenzar con proyectos de segmentación largos o arduos, y en su lugar puede dividir su trabajo en varios subproyectos, cada uno de los cuales mejora la estrategia de seguridad de la red paso a paso. 

Hemos proporcionado directrices para varias políticas y estrategias de segmentación para ayudar a los administradores de red a hacer precisamente eso. Esperamos que nuestras recomendaciones sean prácticas y ayuden a mantener más seguras a las organizaciones.

El grupo de inteligencia sobre seguridad de Akamai seguirá supervisando, estudiando y publicando investigaciones sobre una gran variedad de temas de seguridad. Para obtener actualizaciones en tiempo real e información sobre las últimas investigaciones, ¡síganos en Twitter!