¿Es «SIEM-less» realmente lo que parece?

Un SIEM es una herramienta polivalente. Integra casos de uso de ciberseguridad como de seguridad física; impulsa la detección, investigación y respuesta ante amenazas (TDIR); sirve como sistema de registro para necesidades de gobernanza, normativas y cumplimiento; y da soporte a casos de uso de observabilidad relacionados con la resiliencia y la degradación del servicio. Y la lista sigue.

En resumen, un SIEM es lo que una organización quiera que sea. Ahí radican tanto sus fortalezas como sus debilidades.

La paradoja del SIEM

Un SIEM puede ser un potente «panel de control único». Pero esa fortaleza viene acompañada de dos retos persistentes: la complejidad operativa y los costes de ingesta de datos.

¿Más datos significan mejores resultados?

Los SIEM almacenan enormes cantidades de datos. A medida que se amplía la superficie de ataque, las organizaciones siguen añadiendo fuentes. Sin embargo, no todos los datos sirven para lo mismo:

• La detección y la prevención requieren un conjunto de datos.
• Las investigaciones necesitan datos contextuales para explicar lo que ha pasado.
• La auditoría y el cumplimiento normativo dependen de las pruebas que se conservan para la elaboración de informes y la revisión.

Como los equipos no siempre pueden predecir lo que necesitarán en el futuro, lo habitual es ingestar todo «por si acaso». Ahí es donde los problemas empiezan a agravarse.

La complejidad es lo primero

Los primeros síntomas son operativos.

Los equipos deben determinar qué datos son útiles, por qué son importantes y cómo deben aplicarlos en un contexto concreto. Después, deben ser capaces de encontrarlos, buscarlos, elaborar informes sobre ellos y convertirlos en información útil cuando llegue el momento.

Luego viene la factura

Una vez que se establece la carga operativa, llega el impacto financiero, a menudo en forma de costes de ingesta cada vez mayores.

Cómo el SIEM se convirtió en el centro del SOC

Con el tiempo, el SIEM también incorporó tecnologías que antes funcionaban de forma independiente, como las plataformas de inteligencia sobre amenazas, el análisis del comportamiento de usuarios y entidades (UEBA) y la orquestación, automatización y respuesta de seguridad (SOAR). Cada incorporación prometía un mejor contexto, una detección más sólida o un ciclo de respuesta más ágil.

En muy poco tiempo, el SOC se construyó en torno al SIEM y este quedó anquilosado en los procesos del SOC, mientras que los proveedores se aprovecharon de ese «bloqueo». Entra en escena la era de la deconstrucción del SIEM y, con ella, las ventajas prometidas de ser SIEM-less.

Deconstruyendo el SIEM

¿Los precios basados en la ingesta te están ahogando? No te preocupes. Añade un canal de ingesta inteligente que filtre lo que no necesitas antes de almacenarlo. Y ya que estás, ejecuta detecciones en el canal. Et voilà: has reducido los costes de almacenamiento y has ganado detecciones por el camino.

¿Necesitas buscar en los datos tal y como están? Añade otro componente que pueda buscar en todas las fuentes traduciendo las consultas para cada una de ellas. ¿Necesitas clasificar e investigar todas esas «detecciones» para determinar qué merece la pena investigar? Añade un SOC basado en agentes que promete automatizarlo todo.

En poco tiempo, la recopilación empieza a parecerse mucho a la gestión de información y eventos de seguridad, un SIEM. La diferencia es que ahora los costes se reparten entre los componentes individuales. Empieza a parecerse a una estructura de precios desagregada, en la que el ahorro en un ámbito genera costes de computación —o concesiones— en otro.

El verdadero factor de coste: la computación

Es importante no confundir los costes de ingesta de datos con los de almacenamiento. Procesar datos para casos de uso posteriores requiere computación; decidir cuántos datos conservar y durante cuánto tiempo requiere almacenamiento. Incluso con los precios actuales del almacenamiento, los costes de computación eclipsan con creces a los de almacenamiento.

La computación es el verdadero factor de coste. Los sistemas consumen computación cuando filtran los datos, los indexan para una recuperación más rápida, los consultan o los utilizan para generar informes. Los sistemas necesitan más computación cuando deben «rehidratar» los datos, es decir, trasladarlos del almacenamiento en frío al almacenamiento en caliente para su análisis. Cualquiera de estos costes, o todos ellos, pueden acabar repercutiendo en el comprador.

Una arquitectura desestructurada no elimina las tareas subyacentes ni los «trabajos que hay que hacer». Siguen existiendo; simplemente se llevan a cabo de forma diferente a como se haría en un SIEM tradicional.

¿Es una mala idea el SIEM-less?

En realidad, no. Puede ser la decisión acertada para una organización que cuente con la experiencia y los recursos necesarios para crear y mantener un sistema de este tipo. Estos nuevos enfoques están redefiniendo la economía del sector y obligando a los proveedores tradicionales a replantearse sus estrategias de comercialización.

Pero, en última instancia, un SIEM-less es un conjunto de capacidades integradas en una arquitectura. Con el tiempo, cada proveedor que ofrezca una pieza del rompecabezas «SIEM-less» irá añadiendo capacidades adyacentes hasta que la oferta resultante empiece a parecerse, lo has adivinado, a un SIEM.

Las organizaciones que necesitan un SIEM, por lo tanto, se enfrentan a una elección práctica: optar por la vía del «hazlo tú mismo» o invertir en un sistema totalmente integrado con la relación calidad-precio adecuada. Al fin y al cabo, esa elección es importante.

Entonces, ¿dónde encaja el XDR en todo esto? Te lo contaré en mi próximo post.