Segmentación de red frente a seguridad

La necesidad de segmentación como estrategia de seguridad evolucionó bastante. Desde los primeros días de las redes hasta los complejos entornos actuales de centros de datos y nube, el enfoque que adoptan las organizaciones para la segmentación no siguió el ritmo. Cualquiera que intente emplear enfoques de segmentación tradicionales para abordar los nuevos desafíos de seguridad descubrirá rápidamente que no cumple con las expectativas y los requisitos de seguridad.

Sin embargo, esto no impidió que los proveedores y algunas organizaciones intenten encajar la proverbial clavija cuadrada de la red en el agujero de seguridad redondo. Alerta de spoiler: simplemente no encaja.

Lo que realmente necesita es segmentación de seguridad.

En esta publicación, exploraré la diferencia entre la segmentación de red y seguridad, concentrándome en el centro de datos y cómo la segmentación de red se dirigió erróneamente para abordar los requisitos de seguridad.

Control en tierra para aplicaciones importantes

Cuando me metí por primera vez en las redes, un segmento era una hebra de RG-58 COAX. ¿Estoy saliendo conmigo mismo? Sí.

A medida que avanzaba mi carrera, trabajé en Xylan, un pionero en la tecnología VLAN "emergente". En ese momento, el desafío consistía en interconectar cualquier medio (Token Ring, FDDI, ATM, Ethernet) con cualquier medio y extender las VLAN, no principalmente por el bien de la seguridad, sino más bien para reducir los dominios de transmisión, para mantener el rendimiento de la red y permitir que las redes escalen. No había conmutadores de capa 3, y los elementos más caros de la red eran los enrutadores basados en software.†Básicamente, un segmento evolucionó hasta convertir en un dominio de transmisión lógico (no físico), y prácticamente permaneció así hasta que las VLAN se entremezclaron con la seguridad.

Hoy en día, a pesar de la cantidad de dinero que una organización gasta en tecnologías de "detección", la mayoría de las organizaciones creen que una violación de alguna forma es inevitable.

Ante la inevitabilidad de una infracción, la única protección realista es construir más muros alrededor de las aplicaciones críticas, o "controlar el terreno" para que los malos actores no puedan mover libremente dentro de su centro de datos y la nube.

Controlar el terreno requiere una nueva forma de segmentación.

Esto es algo a lo que me refiero como segmentación de seguridad, por lo que una organización debe filtrar el tráfico para evitar que un mal actor pueda mover lateralmente (este/oeste) dentro de un centro de datos. Esto es mucho mejor que la "segmentación retro" a través de la red, que requiere nuevas IP, nuevas VLAN y nuevos equipos.

¿Puede o debe? Es un gran problema

La segmentación de seguridad no se trata de reenvío de paquetes en lo que respecta a las redes de capa 2 y capa 3. La segmentación de seguridad se trata de filtrar paquetes , es decir, hacer cumplir lo que debe y no debe permitir entre dos puntos de la red.

Siempre digo que esta es la diferencia entre can (reenvío de paquetes) y should (filtrado de paquetes). Todos los protocolos y el trabajo que se realizó en las redes de capa 2 y capa 3 se centraron en la entrega confiable de paquetes.

• Las redes de capa 2/3 pueden encontrar una ruta para reenviar un paquete entre dos ubicaciones, si existe.
• Las redes de capa 2/3 no saben si deben reenviar el paquete. No fue construido para funcionar de esa manera.

De hecho, pedirle a un dispositivo de capa 2/3 que averigüe qué debería suceder es como pedirle a Ron Burgundy que no lea cada palabra en un teleprompter.

La segmentación de seguridad, por otro lado, comprende lo que debería suceder y promulga filtros de paquetes para garantizar que lo que no debería suceder nunca suceda, como la propagación de una infracción.

De hecho, la entrega confiable de paquetes, algo en lo que trabajamos durante 30 años, y la segmentación de seguridad son como primos hermanos: están relacionados, pero no deberían casar.

KISS: Quieres mantenerlo simple, estúpido (y filtrar todos los días)

Una de las cosas que puso en primer plano la necesidad de la segmentación de seguridad fue la aparición de lo que me gusta llamar el problema del "firewall en un palo". Hace diez años, no veíamos mucho tráfico que se enviara a un firewall (o firewalls) en los centros de datos porque creaba sobrecarga de tráfico, complejidad de configuración y problemas de escala. Sin embargo, con el tiempo, hubo un aumento en esos diseños de "firewall en un palo".

CONSEJO: Cada vez que vea una tecnología en un palo, desconfíe. Se va a interponer en el camino.

En la compañía, los proveedores de redes definidas por software (SDN) están tratando de atacar la complejidad del firewall en un dispositivo mediante la creación de una superposición de redes que canalizarán paquetes a través de un conjunto distribuido de firewalls. SDN se basa en capas subyacentes, superposiciones y túneles para que funcione. Esto creó un nuevo nivel de complejidad que podemos almacenar para otra publicación. Pero basta con decir que atacar la complejidad con más complejidad no es una propuesta ganadora.

La complejidad es enemiga de muchas cosas, y la seguridad es una de ellas.

A diferencia de SDN, la segmentación de seguridad (también conocida como filtrado de paquetes) se basa en el principio KISS de redes: Keep It Simple Stupid. Haga algo demasiado complejo y la probabilidad de error aumenta, al igual que la probabilidad de que las personas busquen formas de tomar atajos, lo último que desea como parte de su estrategia de seguridad. La simplicidad, por otro lado, tiene más posibilidades de producir confiabilidad y la confiabilidad es fundamental en la seguridad.