En el ámbito del Servicio de Acceso Seguro Edge (SASE), la integración de Sistemas de Detección y Prevención de Intrusiones (IDPS) es casi universal.
Su papel va más allá de la mera frustración de los exploits conocidos, sirve como centinela vigilante de los IOC (Indicadores de Compromiso, proporcionando una capa integral de protección.
Incluso me atrevería a afirmar que el IDPS está siendo utilizado para Indicadores de Compromiso e Indicadores de Ataque más en los últimos tiempos por las organizaciones.
El poder del IDPS reside en su capacidad para proporcionar una visión rica del tráfico de red; no sólo extrae metadatos de conexión como las 5-tuplas de la conexión, sino que también profundiza en los detalles matizados de varios campos de protocolo.
Esta profundidad de extracción proporciona una información inestimable sobre las características de los datos que atraviesan la red, mejorando el conocimiento contextual.
El IDPS utiliza múltiples métodos para fortificar la seguridad de la red.
Detecta y obstruye de forma competente los exploits y el malware conocidos mediante métodos de detección basados en firmas.
Además, monta guardia contra los datos anómalos empleando reglas que pueden identificar patrones irregulares de paquetes o flujos.
Estas reglas amplían su ámbito para abarcar tamaños de atributos de protocolo anómalos y comportamientos de valores de protocolo imprevistos.
Aunque las características y la eficacia de la seguridad de los IDPS en el marco de SASE pueden presentar ligeras variaciones entre los proveedores de servicios, las capacidades básicas siguen siendo en gran medida similares, debido a la utilización de bases de datos de firmas procedentes normalmente de proveedores de inteligencia sobre amenazas de terceros.
Además, las tecnologías IDPS han madurado y desarrollado capacidades similares incluso frente a las múltiples técnicas de evasión empleadas por los atacantes.
En mi evaluación, la principal diferenciación entre los proveedores radica en el ámbito de la observabilidad y las facilidades que ofrecen para la caza de amenazas, centrándose en minimizar los falsos positivos y los falsos negativos.
La intención de este artículo no es ahondar en la diferenciación de características IDPS entre los servicios SASE.
Más bien, pretende explorar los puntos precisos dentro de la ruta del paquete donde las funciones IDPS son ejecutadas por los servicios SASE y si estos puntos de inserción detectan eficazmente los patrones de ataque dentro del tráfico original.
Hay quien opina que la incorporación de la funcionalidad del Sistema de Detección y Prevención de Intrusiones (IDPS) a nivel de proxy dentro de los servicios Secure Access Service Edge (SASE) es suficiente.
Su razonamiento se deriva del hecho de que muchas organizaciones ya emplean IDPS OnPrem para la detección de intrusiones en el tráfico genérico.
El principal reto con OnPrem IDPS reside en su incapacidad para inspeccionar el tráfico que está cifrado con TLS.
Dado que los proxies SASE realizan la inspección TLS Man-in-the-Middle (MITM), acceden al tráfico no cifrado.
Por lo tanto, la creencia es que tener el punto de inserción IDPS en los proxies es adecuado.
Además, algunos sostienen que un número significativo de sistemas están adecuadamente parcheados contra los ataques a nivel de red (L3/L4) y a nivel de TLS.
En respuesta, los atacantes han cambiado su enfoque hacia el empleo de tácticas más sofisticadas a nivel de aplicación (L7) y de datos.
En consecuencia, prevalece la idea de que no está justificado ampliar la funcionalidad IDPS más allá del nivel proxy dentro de la red.
Sin embargo, este argumento no se sostiene en todos los casos. Considere los dispositivos IoT que siguen funcionando con sistemas operativos más antiguos y actualizados con poca frecuencia.
Estos dispositivos pueden seguir siendo vulnerables a una gama más amplia de ataques, lo que requiere un enfoque de seguridad integral.
Muchos también reconocen que se espera que los servicios SASE incorporen IDPS tanto en el nivel proxy como en el L3 para garantizar la inspección exhaustiva de todo el tráfico de la red.
Para lograr una detección exhaustiva de los ataques, la funcionalidad IDPS debe aplicarse no sólo a nivel del proxy, como se ha comentado anteriormente, sino también a nivel de las interfaces WAN, donde el tráfico entra y sale de las interfaces designadas para el tráfico hacia y desde Internet.
Aunque este enfoque representa una mejora con respecto al despliegue de IDPS únicamente a nivel de proxy, introduce un reto.
En los casos en los que el tráfico fluye a través de los proxies, es posible que el IDPS no tenga visibilidad del tráfico original en ambas direcciones de las sesiones.
Los proxies suelen terminar las conexiones y establecer otras nuevas.
Como se basan en la pila TCP/IP local, reensamblan los paquetes originales, vuelven a secuenciar los datos TCP, recrean las opciones IP/TCP y regeneran los mensajes de enlace TLS.
En consecuencia, el IDPS a nivel de interfaz WAN puede carecer de visibilidad sobre el tráfico original originado en la red interna, lo que puede hacer que pase por alto patrones de ataque que formaban parte del tráfico original.
Cabe señalar que los atacantes no siempre son externos; también puede haber atacantes internos.
Además, los ataques pueden originarse en sistemas internos debido a infecciones previas de malware.
Por lo tanto, es crucial asegurarse de que el IDPS observa constantemente el tráfico original en ambas direcciones para una detección y prevención eficaz de las amenazas.

Buscar servicios SASE con múltiples puntos de inserción IDPS

Abogamos por que los servicios SASE ofrezcan la flexibilidad de insertar IDPS en múltiples puntos, todos activos simultáneamente.
Las organizaciones deben tener la libertad de elegir si despliegan el IDPS en cada interfaz L3 y a nivel de proxy.
Este enfoque permite al IDPS inspeccionar el tráfico original de los puntos finales de las sesiones, tanto del cliente como del servidor, incluso cuando el tráfico está cifrado mediante TLS y atraviesa los proxies.
Además, las organizaciones deben buscar activamente servicios SASE que eviten la generación de alertas y registros duplicados resultantes de múltiples puntos de inserción.
Por ejemplo, el tráfico que no pasa a través de ningún proxy pero atraviesa múltiples interfaces L3 (recibido en una interfaz y enviado a través de otra) puede ser visto por dos instancias IDPS, dando lugar potencialmente a alertas y registros duplicados.
Es aconsejable que las organizaciones se aseguren de que tal redundancia en los registros se minimiza, evitando la inundación del personal administrativo que ya está lidiando con un alto volumen de registros generados por las funciones de seguridad.
Idealmente, los servicios SASE deberían mostrar inteligencia en función de cada sesión de tráfico y evitar de forma inteligente la ejecución duplicada de funciones IDPS si no se producen modificaciones en el tráfico dentro del servicio SASE.
Además, las organizaciones deberían buscar soluciones que permitan la correlación de los registros generados por múltiples funciones de seguridad, incluyendo varias instancias de IDPS, para una sesión de tráfico determinada.
Esta correlación ayuda a mejorar la observabilidad y agiliza el trabajo de los cazadores de amenazas al simplificar el mapeo de los eventos de seguridad.
Reconociendo la naturaleza computacionalmente intensiva del IDPS, las organizaciones también deben esforzarse por conservar recursos siempre que sea posible.
Por ejemplo, si las organizaciones ya emplean IDS de host (HIDS) o IDPS On-Prem, puede que deseen mantener el control sobre la desactivación de IDPS en instancias específicas para ciertos tipos de tráfico.
Los servicios SASE que ofrecen dirección IDPS basada en políticas pueden facultar a las organizaciones para dictar qué tráfico debe someterse a inspección por las diferentes instancias IDPS dentro del marco SASE.
En resumen, la eficacia del IDPS dentro del paradigma SASE va más allá de sus características; depende de la flexibilidad que SASE proporciona en cuanto a los puntos de inserción del IDPS y el grado de control que ofrece a las organizaciones para alinearse con sus requisitos específicos.

  • Blog CTO Insights

    La serie de blogs Aryaka CTO Insights proporciona liderazgo de pensamiento para temas de red, seguridad y SASE.
    Para conocer las especificaciones de los productos Aryaka, consulte Aryaka Datasheets.