Reconocer y responder

Nuevos enfoques de defensa: EDR y XDR

La detección y respuesta ampliada de puntos finales (EDR, XDR) está diseñada para detectar sistemas comprometidos y apoyar la respuesta a incidentes. ¿Qué consiguen realmente estas técnicas incipientes?

Incidentes de seguridad destacados, como el ataque de los hackers de Sunburst a instituciones, ilustran de forma impresionante los límites de las medidas de seguridad informática actuales. En este caso, los piratas informáticos penetraron en la empresa SolarWinds y, de forma inadvertida, incorporaron malware en la plataforma común de los productos informáticos de SolarWinds. Los clientes de SolarWinds se infectaron con este malware al aplicar las actualizaciones de los productos de SolarWinds y sus cortafuegos, suites antivirus u otros productos de seguridad que no tenían forma de saberlo o evitarlo. Este y otros muchos ejemplos muestran que las medidas de seguridad preventivas no son suficientes por sí solas para proteger a la propia organización de los ataques. Con un atacante profesional y motivado, es sólo cuestión de tiempo que pueda entrar con éxito en la empresa objetivo. Por lo tanto, la capacidad de reconocer y reaccionar a los compromisos en la propia infraestructura en una etapa temprana es cada vez más importante.

Una variedad de tácticas para no ser detectados

     

La prevención por sí sola no es suficiente

Por supuesto, esto no significa que la prevención pierda su importancia, ya que sin medidas integrales para prevenir el malware y las intrusiones de los hackers, el funcionamiento de los productos de detección no sería factible. De lo contrario, el número de alertas que deben analizarse o verificarse supera la mano de obra que una organización puede permitirse, desde el esfuerzo y el coste de la recuperación hasta el tiempo y el coste del servicio y la limpieza después de los incidentes. Por lo tanto, la prevención sólida es un requisito previo y necesario para poder permitir realmente la detección y la respuesta. Hace veinte años, las empresas esperaban poder detectar a los atacantes con los llamados sistemas de detección de intrusiones (IDS).Por desgracia, esto resultó ser poco práctico en la mayoría de los casos. Demasiadas falsas alarmas llevaron a los costes de explotación a una zona antieconómica. Posteriormente, se intentó corregir los eventos más diversos mediante el uso de sistemas de gestión de información y eventos de seguridad (SIEM) en la empresa para lograr una mejor detección. Pero también en este caso se hizo evidente que muchas empresas se vieron disuadidas por la relación coste-beneficio.

Las empresas más pequeñas, en particular, decidieron no explotar ellas mismas un producto de este tipo, sino, en el mejor de los casos, adquirirlo como servicio de un proveedor de servicios externo. Las empresas más grandes que ya han establecido un SIEM o los proveedores que operan uno para sus clientes se enfrentan al reto de que la comprobación de las alarmas del sistema lleva mucho tiempo y siempre surge la pregunta de qué ha ocurrido realmente en un dispositivo final afectado.

Mejora mediante EDR y XDR

En los últimos años han aparecido en el mercado nuevas tecnologías que prometen un remedio bajo el nombre de “Endpoint Detection and Response” (EDR) o “Extended Detection and Response” (XDR). Las soluciones EDR se instalan en los dispositivos finales y observan inicialmente el comportamiento de todos los procesos en ellos. La atención no se centra en el comportamiento de los usuarios, sino en los procesos técnicos como el acceso a los archivos, el registro, la comunicación, el inicio de procesos, la manipulación de la memoria de los procesos, y mucho más. Si los profesionales de la seguridad detectan un patrón de comportamiento que indica la presencia de malware o hackers, se activa una alarma. A diferencia de un producto SIEM, que suele tener muchos menos detalles a su disposición, una herramienta EDR tiene acceso a todos los detalles del dispositivo final y puede evaluarlos en el contexto general. Por ejemplo, se dispone de información sobre la procedencia de un ejecutable malicioso, quién lo ha lanzado, a qué servidor ha accedido y qué datos ha escrito. Para esta información, ningún analista tiene que definir manualmente las reglas y ajustarlas una y otra vez para reconstruir el contexto, en la medida en que esto sea posible. El software EDR establece automáticamente estos contextos porque se ejecuta en el dispositivo final afectado y conoce todos los detalles. Esto significa que el EDR puede detectar compromisos en los dispositivos finales con mayor precisión y fiabilidad que los enfoques anteriores. Las organizaciones que han implementado el EDR para verificar las alertas de un SIEMS están descubriendo que el EDR no sólo es valioso para la verificación, sino que se está convirtiendo en una fuente principal para la detección.

Como funciona EDR:

Funciones de respuesta a incidentes

Los productos EDR no sólo observan y correlacionan el comportamiento de los procesos en el dispositivo final. Como su nombre indica, también ofrecen funciones de respuesta a incidentes. Dependiendo del producto y del fabricante, incluida la variación desde la intervención activa para detener los procesos maliciosos, pasando por la reversión de las modificaciones realizadas por un malware, hasta el acceso interactivo al sistema afectado para la respuesta a incidentes. La línea entre una herramienta para la detección y una herramienta para la respuesta a incidentes y el análisis forense en vivo se está volviendo borrosa.

La búsqueda activa o automatizada de indicadores de compromiso (loC), a menudo denominada “caza”, es otra función que soportan muchas herramientas EDR. Los proveedores ofrecen sus propias fuentes de información sobre amenazas que proporcionan los valores de los archivos de malware conocidos, las direcciones IP de los servidores de comando y control (C&C) o las entradas de registro del malware, u ofrecen interfaces que pueden emplearse para integrar sus propias fuentes de información sobre amenazas o las públicas. Este es otro punto en el que las herramientas EDR comienzan a solaparse con un SIEM.

Como suele ocurrir en el sector de la seguridad, los proveedores de EDR eran pequeñas empresas emergentes que aplicaban nuevas ideas técnicas de forma dinámica e innovadora. Los grandes fabricantes establecidos de productos de seguridad para puntos finales suelen ser un poco más engorrosos, o compran empresas de nueva creación y amplían así sus conjuntos de productos. Es obvio que el siguiente paso para un gran proveedor es intentar el software EDR adquirido en los productos existentes. productos existentes para que, por ejemplo, una alarma de detección de anomalías en la red existente sea verificada automáticamente por el producto EDR.

Pero no sólo los grandes fabricantes de productos de seguridad persiguen la integración directa de sensores en diversos puntos. Las pequeñas empresas emergentes también han perseguido esta integración desde el principio con sus propios sensores recién desarrollados. Además del dispositivo final, es evidente la integración de un sensor de red o de sensores para actividades en entornos de nube y contenedores.

Una X para el EDR ampliado

 Para distinguir sus propios productos integrados de los de sus competidores, se creó el nombre de External Detection and Response (XDR). La XDR es, por tanto, la evolución obvia de la EDR. Los fabricantes que tienen técnicas de detección en la red o incluso en otras áreas de su cartera además de un producto EDR tienden a anunciarlo como XDR. En algunos casos, XDR se escribe de forma diferente y la “X” se traduce como “cross-layer” en lugar de “extended”. Con ello se pretende dejar claro que el reconocimiento y la reacción se producen a distintos niveles. Hasta ahora, no hay ningún producto que permita utilizar la XDR con herramientas de distintos proveedores. En realidad, la XDR siempre consiste en la integración de un solo fabricante. Pero esto es comprensible, porque la integración necesaria es mucho más compleja que la simple combinación de eventos individuales. Para generar un verdadero valor añadido, las partes individuales de una solución XDR deben estar estrechamente entrelazadas, intercambiar información con el contexto y cooperar activamente.

Alternativa al clásico SIEM

La XDR se convierte así en una alternativa mucho más clara al enfoque clásico del SIEM, que correlaciona los eventos sin contexto para reconstruirlo a partir de ellos. También se puede ver el solapamiento y los contrastes en la automatización. Las soluciones SIEM suelen combinarse con funciones o herramientas de “Orquestación, automatización y respuesta de la seguridad”.

(SOAR) para no sólo generar alarmas y trabajos manuales, sino también para desencadenar automáticamente acciones de enriquecimiento con información adicional, verificación o respuesta a una alarma. Al igual que con SIEM, SOAR debe hacer esto para numerosos productos de diferentes proveedores, actualizando las interfaces cada vez que un producto de terceros cambia. Con el enfoque XDR, los subproductos de un mismo fabricante se unen y el propio fabricante proporciona y controla las interfaces. Por lo tanto, el esfuerzo de integración recae en el propio fabricante y desarrollador y no en el cliente, que debe configurar por sí mismo sus productos SIEM y SOAR.

Además del software, algunos fabricantes también ofrecen el funcionamiento de los productos EDR o XDR junto con el servicio de reacción a los incidentes y lo denominan “Managed Detection and Response” (MDR), aunque este término puede interpretarse de forma muy diferente según el proveedor. Se pueden encontrar proveedores que operan una solución EDR o XDR como MDR, así como aquellos que sólo quieren evaluar los datos de registro con un SIEM y reaccionar ante ellos.

La inteligencia central y la administración de una solución XDR se encuentran casi siempre en la nube del fabricante. Esto encaja con la intención de dejar el esfuerzo en gran medida al fabricante y hacer que el funcionamiento de la XDR sea lo más sencillo posible para el cliente.

¿Todo de una sola fuente?

Para el cliente, esto plantea la cuestión de hasta qué punto quiere depender de un solo fabricante y cuánto dinero y esfuerzo le vale reunir él mismo los productos individuales de diferentes fabricantes: el clásico debate sobre los enfoques “. En el caso de la XDR, sin embargo, la discusión adquiere mayor importancia, porque hasta ahora, operar un cortafuegos del proveedor A con retransmisión de correo del proveedor B y tokens de autenticación del proveedor C no era gran cosa. Por otro lado, para muchas organizaciones no es factible configurar y operar un SIEM y tal vez una solución para ello por sí mismas, y las correspondientes ofertas de servicios gestionados también son muy caras y a menudo no son tan eficaces como se desea.

El XDR como producto “listo para usar” de un solo fabricante, en el que los distintos sensores están coordinados entre sí y trabajan juntos de forma automática, es una perspectiva interesante por un lado. Algunos proveedores van incluso más allá, integrando no sólo la tecnología de detección de com- promisos, sino también la gestión de vulnerabilidades para detectar las desconfiguraciones inseguras o los parches que faltan e incorporarlos al panorama general: Debido a la fuerte y automática integración, que resulta en un número significativamente menor de falsas alarmas, así como la provisión del componente central en la nube del fabricante, la operación interna se vuelve atractiva para muchas organizaciones con tales soluciones.

Por otro lado, la introducción de un producto XDR hace que la empresa dependa aún más de un solo fabricante. Esto puede ser inofensivo si la XDR sólo consiste en software de punto final y sensores de red adicionales. Pero si la XDR requiere que el cortafuegos y la pasarela web y de correo también sean del mismo fabricante, o incluso del sistema operativo de los dispositivos finales, entonces surge una dependencia y un monocultivo que debe ser evaluado críticamente.

En el caso del ataque a través de SolarWinds mencionado al principio, los clientes de algunas herramientas EDR no se habrían visto afectados porque el malware utilizado allí habría comprobado primero si las herramientas EDR o forenses estaban instaladas en el sistema objetivo utilizando una larga lista instalada y , en su caso, no habría existido una infección. Esto demuestra que, desde el punto de vista de los autores de malware, las herramientas EDR y XDR también son adecuadas para detectar actividades irregulares en una fase temprana.

Conclusión:

Por muy atractiva que pueda parecer la idea de la XDR, en realidad el concepto es relativamente joven y los productos aún están evolucionando. Así, ocurre que el rendimiento de reconocimiento efectivo de una herramienta XDR no se acerca al rendimiento de reconocimiento de una buena herramienta EDR en la práctica, a pesar de las promesas conceptuales. La combinación de partes individuales más débiles no conduce automáticamente a un producto global más fuerte. O sucede que el rendimiento de reconocimiento de la solución EDR es sorprendentemente bueno, pero la interfaz de gestión es tan confusa y desconcertante que uno no quiere trabajar con ella en la práctica.

A pesar de todas las ventajas conceptuales de la idea de la XDR, lo importante en cada caso es la calidad real del producto. Sin embargo, para probarlo, una organización suele necesitar el apoyo de expertos que simulen ataques realistas durante la fase de prueba. El simple lanzamiento de algunas muestras de malware o exploits en un entorno de prueba dice poco. Además, el mercado es joven y está en movimiento, por lo que es de esperar que los proveedores más pequeños sean comprados e integrados por los grandes fabricantes y que la estrategia de producto cambie en el proceso. Sin embargo, como se ve en el ejemplo de Avira, uno de los mayores fabricantes de antivirus, esto también puede ocurrir con proveedores grandes y establecidos.