.svg?width=93&quality=80&auto=webp&format=auto&cache=true&immutable=true&cache-control=max-age%3D31536000 "Home"){kind=logo}
.svg?width=7&quality=80&auto=webp&format=auto&cache=true&immutable=true&cache-control=max-age%3D31536000 "Top Navigation - Sign in - Icon")
En mi última entrada, me preguntaba dónde encaja el XDR en el debate sobre entornos sin SIEM. Para responder a eso, empieza por los endpoints. Si pudiéramos detener todas las amenazas ahí, habría menos necesidad de productos de detección y respuesta, como la detección y respuesta en terminales (EDR). Pero los atacantes se han vuelto más hábiles a la hora de eludir incluso la seguridad de los endpoints más robusta, por ejemplo, haciendo un uso indebido de herramientas de doble uso en ataques «living-off-the-land» (LOTL). Eso obligó al sector a dar un giro hacia un enfoque de «recoger datos y analizarlos», que es la premisa fundamental del EDR y donde empieza la historia del «SIEM frente a XDR».
Del EDR al XDR
El EDR se convirtió, en la práctica, en un almacén de datos de endpoints basado en la nube. Para que esos datos sean útiles, hay que hacer muchas cosas:
Hay que correlacionar los datos para sacar a la luz las amenazas y generar alertas.
Debemos priorizar, clasificar y gestionar las alertas para confirmar que son verdaderos positivos.
Debemos tomar medidas para neutralizar las amenazas, con automatización y guiones de actuación para los patrones recurrentes.
Debemos poder consultar los datos a medida que avanzan las investigaciones y generar informes.
El sistema debe integrarse con herramientas de gestión de servicios de TI (ITSM) para encajar en los procesos operativos.
Los atacantes también se centran en múltiples puntos de entrada y se mueven lateralmente una vez dentro. Por eso, el sector llegó a la conclusión acertada de que la detección y la respuesta ante amenazas resultan mucho más precisas y eficaces cuando los datos de los endpoints se combinan con datos de otros vectores y fuentes de amenazas, como la red, la identidad, la nube y el correo electrónico. El resultado fue un sistema integrado y diseñado específicamente, centrado exclusivamente en los resultados de seguridad en lugar de solo en los endpoints. El EDR evolucionó hasta convertirse en detección y respuesta ampliadas (XDR).
Los mismos registros, dos lugares, resultados que se solapan
Si tienes EDR, lo más probable es que cuentes con un equipo de seguridad que se encarga de la clasificación, la investigación y la respuesta, y es muy probable que también tengas un SIEM.
Como mínimo, un SIEM se encarga de la ingesta de datos, el análisis, la gestión de alertas, la investigación y la respuesta. Si te suena familiar, es porque eso es exactamente lo que hace el XDR. El SIEM es la plataforma original de detección y respuesta, la precursora de todos los productos «DR», pero no es ni rentable ni fácil de mantener. Entonces, ¿por qué las empresas utilizan ambos y pagan el doble? En la mayoría de los casos, las razones son sorprendentemente sencillas:
«Si algo funciona, no lo toques».
Existen otros proyectos prioritarios, dedicar recursos a esto impediría atender cualquier otra tarea.
Casi todos los auditores piden un SIEM, y algunos incluso pueden usar la palabra SIEM como término genérico.
El SIEM es una partida presupuestaria consolidada (seguramente por lo que acabamos de mencionar).
Para ser justos, hay una razón legítima por la que el XDR y el SIEM coexisten, y es el endpoint. Para que un SIEM se solape por completo con el XDR, debe haber, por definición, un endpoint, y el SIEM depende de un agente que le proporcione la información necesaria. El sector discrepa sobre cómo debe ser ese agente. Podría ser un agente de endpoint completo con capacidades de protección integradas superiores, o un agente «sidecar» centrado en la detección que se ejecute junto a una solución de protección ya existente y reenvíe alertas y telemetría a un XDR o a un SIEM.
Nota al margen: por qué es importante el agente
Se podría argumentar que un agente de endpoint completo con protección integrada superior constituye la mejor solución XDR, porque cuanto más bloqueas, menos hay que clasificar e investigar. Además, ese agente permite al equipo de seguridad consultar un endpoint casi en tiempo real y tomar medidas exhaustivas para neutralizar las amenazas.
¿Es el XDR realmente un SIEM con otro nombre?
Sí, lo es. El EDR era, en esencia, un mini-SIEM centrado en los endpoints, y el XDR lo amplió hasta convertirlo en un SIEM centrado en la seguridad. El sector rediseñó una herramienta que ya existía, pero la orientó hacia resultados de seguridad en lugar de sobrecargarla con todos los casos de uso imaginables. Liberado de la arquitectura anquilosada de un SIEM tradicional, el XDR salió ganando.
¿Qué lo hace mejor?
Lo más importante es que el XDR solo recopila los datos que se utilizan durante el ciclo de vida de una amenaza, y lo hace a través de integraciones listas para usar. Los expertos en seguridad del proveedor seleccionan previamente esos datos para generar resultados específicos de seguridad y operativos, como detecciones relevantes o información contextual. A continuación, el XDR proporciona a tu equipo de seguridad o al SOC todas las capacidades que necesita para clasificar, investigar y responder. En un SIEM, por el contrario, vale todo. Como ya comenté en mi blog «SIEM-less», los clientes guardan datos «por si acaso». Aquí tienes algunos ejemplos reales de lo que acaba en un SIEM:
Desde la práctica: lo que los clientes envían realmente a un SIEM
Este tiene una intención legítima: es un encabezado de formato de registro, una lista de nombres de campos sin datos de eventos. Pertenece a un repositorio de código, no a un SIEM:
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
Este ejemplo es un fragmento de un programa en Python que algún producto genera a través de syslog:
from __future__ import unicode_literals
Aquí tienes uno que parece un fragmento de archivo de registro, pero que en realidad es una línea de código C# y no nos sirve de nada:
[DllImport("wtsapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]Y aquí tienes uno que te hace llevar las manos a la cabeza:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
¡¡Pero es que ocupaba más de un megabyte!!
Los clientes importaron cada una de esas entradas a un SIEM, y en los SIEM que cobran por importación, es muy posible que hayan pagado por cada una de ellas. Nada de eso ayuda al equipo de seguridad a detectar, investigar o responder a una amenaza. Por eso es importante la curación de datos. Por eso importa quién se encarga de ella. ¿Quién asume esa carga operativa?
¿Deberías comprar un SIEM o un XDR?
Empieza por hacerte unas cuantas preguntas.
Preguntas que debes plantearte antes de comprar
¿En qué punto de la curva de madurez de capacidades te encuentras? ¿Dónde quieres estar y por qué?
¿Qué funciones necesitas sin falta?
Si ya tienes un SIEM y una solución XDR, ¿se solapan mucho en cuanto a funcionalidades?
¿Tienes un equipo de seguridad capaz de ofrecerte los resultados que te importan?
¿Tienes que cumplir con marcos de cumplimiento normativo?
¿Puedes hacer frente a las necesidades operativas continuas y a los costes asociados de tus herramientas?
¿Cuánto podrías ahorrar racionalizando tus necesidades en un único sistema?
Entonces, ¿SIEM o XDR? Sí. El XDR es un SIEM rediseñado para obtener resultados de seguridad, lo que significa que la verdadera decisión gira en torno a las capacidades y la economía.
Con tus respuestas en la mano, sopesa el coste de oportunidad de cada opción: sustituir tu SIEM, comprar un SIEM-less, adoptar XDR o quedarte con ambos y limitar el SIEM a casos de uso ajenos a la ciberseguridad. A continuación, compáralo con las necesidades de tu organización.
Entonces, ¿dónde encaja el SOC basado en agentes en todo esto? Más sobre esto en mi próxima entrada de blog.