Los informes sobre la muerte de SIEM han sido muy exagerados

Hay una frase que sigo escuchando últimamente en los círculos de ciberseguridad, en conferencias presenciales, en LinkedIn, prácticamente en todas partes:

"SIEM está muerto".

Entiendo por qué es pegajosa. Pero SIEM ha muerto más veces que el villano de una telenovela de protocolo SOAP, y siempre vuelve para la siguiente temporada. Antes de SIEM, lo que estaba muerto era el perímetro. Después el antivirus. Después las contraseñas. (Las passkeys van tras ellas, pero muchas todavía viven en notas adhesivas bajo los teclados.)

Esto es lo que pienso: la forma en que muchas empresas han estado comprando y alimentando su SIEM merece desaparecer. El SIEM en sí, no. Así que antes de que alguien mande flores, veamos qué está cambiando en realidad.

Sigue el dinero (y el marketing)

Hay tanto marketing de ciberseguridad por ahí que es difícil saber qué herramientas y controles importan de verdad frente a las amenazas actuales. Todos los stands de la feria tienen "IA" impreso en algún lado. Algo es impresionante. Otra cosa es un chatbot disfrazado con gabardina.

"X está muerto" es uno de los trucos más viejos del marketing. Si la categoría antigua está muerta, mejor compra la nueva. Queda genial en una diapositiva de keynote. Pero se salta la pregunta que yo querría responder primero: ¿qué hacía por nosotros lo anterior, y todavía necesitamos que se haga?

En el caso de SIEM, el trabajo era dar visibilidad en todo el entorno, detectar atacantes, hacer investigaciones y mantener registros para el cumplimiento normativo. Los atacantes siguen aquí. Los auditores también. La pregunta abierta es si existe una forma más inteligente de hacerlo.

La era del "envíalo todo"

Durante años, los grandes proveedores tradicionales (piensa en Splunk y QRadar) cobraban según cuántos datos ingerías y cuántos almacenabas. Ese modelo les permitía cobrar lo que cobraban.

Y el consejo que venía con eso siempre era el mismo: envía todo. Registros de firewall, consultas DNS, renovaciones DHCP, cada vez que una impresora tenía "sentimientos". Mete todo y ya después descubres qué es útil.

Ese "después" casi nunca llegaba. Lo que llegaba en cambio era una factura gigante, una pila de alertas que nadie tenía tiempo de revisar, y un cajón de trastos carísimo. 

Si tu proveedor gana más dinero cada vez que envías otro registro, por supuesto que te va a decir que envíes más.

El mercado se dio cuenta. Cisco compró Splunk, e IBM le vendió su negocio de QRadar SaaS a Palo Alto Networks. Cuando los nombres más grandes de una categoría empiezan a cambiar de manos, algo se está moviendo.

Llegan los retadores nativos de IA

Esa sacudida del mercado abrió la puerta a una ola de SIEM nativos de IA y lagos de datos de seguridad. El discurso más nuevo que sigo escuchando es más o menos así:

"¿Para qué almacenar todo tú mismo? Deja los registros donde están. Nuestra IA llamará a las API de tus fuentes, traerá lo que necesite bajo demanda y solo conservará las señales que importan".

Seré justo. Suena muy bien, y parte del razonamiento detrás es inteligente. A nadie le gusta pagar por almacenar terabytes de ruido, y usar IA para encontrar la señal es una idea útil.

El problema es la factura.

Cambiaste una factura de almacenamiento por una factura de tokens

Cuando la IA consulta todo bajo demanda, sigues pagando. Solo moviste el costo de almacenamiento a cómputo, específicamente los token de autenticación que se necesitan para extraer, procesar y razonar sobre esos datos cada vez. Durante un incidente activo, cuando estás lanzando pregunta tras pregunta, ese medidor corre rápido. Es como cancelar el cable y luego suscribirte a nueve servicios de streaming.

Además, los token de autenticación ahora están tan baratos y subsidiados como lo estarán alguna vez. Los proveedores de IA están fijando precios para ganar participación de mercado, y eso no va a durar.

Ya pasamos por esto: mover todo a la cloud nos iba a ahorrar una fortuna, ¿recuerdas? Para muchas empresas así fue, hasta que llegaron las tarifas de salida de datos y las facturas sorpresa, y alguien tuvo que contratar un equipo de FinOps. Los precios se asentaron en su nivel real. Espero que la inferencia de IA siga un camino similar.

El costo no es el único problema:

• Retención: si el sistema de origen solo guarda 30 días de registros, tú también, lo cual duele cuando te enteras de una brecha el día 45. 

• Disponibilidad: tus investigaciones dependen de que la API de alguien más esté activa y sin límites de tasa, justo en el momento en que necesitas respuestas. 

• Cumplimiento normativo: decirle a un auditor o a tu aseguradora de ciberseguridad "podemos ir a buscarlo si lo necesitamos" hace que la conversación sea muy difícil.

Un mejor enfoque: almacena lo que importa, conserva lo que debes conservar

En mi opinión, la mejor forma de sacarle valor real de seguridad a los registros está en un punto intermedio entre acumularlo todo y no guardar nada. Solo almacena los registros que importan.

Así es como lo abordamos en Huntress. Nuestro filtrado inteligente elimina los registros que no son relevantes para la seguridad antes de que lleguen al almacenamiento, así que pagas por señal y no por ruido. Los registros que impulsan las detecciones e investigaciones se quedan.

Filtrar no significa ignorar el cumplimiento normativo. Si HIPAA, PCI DSS, CMMC o tu póliza de ciberseguridad exigen conservar ciertos registros durante cierto tiempo, consérvalos. Esos registros quizá no atrapen a un atacante en tiempo real, pero después de un incidente son la forma de demostrar que hiciste las cosas bien.

Cuando hablo con equipos sobre esto, suelo sugerir pasar cada fuente de registros por un filtro sencillo:

1. Detectar: ¿esto nos ayuda a detectar o investigar una amenaza? Consérvalo.

2. Demostrar: ¿una regulación, un auditor o una aseguradora lo exige? Consérvalo.

3. Descartar: ¿ninguna de las dos? Descártalo. A nadie le van a hacer falta los registros de la impresora.

La factura se reduce, claro. La ganancia más grande son menos falsos positivos, investigaciones más rápidas y analistas que pasan el día cazando amenazas en lugar de desplazándose por basura.

Entonces, ¿dónde encaja la IA?

La IA no es la villana aquí. Sin duda tiene un lugar en un SIEM moderno. Lo que me importa es si se ejecuta sobre cada registro, todo el tiempo, con el medidor corriendo, o si alguien decidió dónde realmente ayuda.

Una vez que filtraste hasta quedarte con los datos relevantes para la seguridad, la IA se vuelve mucho más útil y mucho más barata, porque tiene mucho menos que revisar.

La correlación es donde creo que más brilla. Un inicio de sesión de VPN desde un país donde el usuario nunca ha estado es interesante por sí solo. Ahora agrega un comando de PowerShell codificado que se ejecuta en un servidor que esa misma cuenta tocó diez minutos después, y luego una nueva regla de bandeja de entrada en su cuenta de Microsoft 365 que reenvía correo a una dirección externa. Por separado son tres datos. Juntos son un incidente. Combinar la telemetría de EDR e ITDR con los registros que llegan del resto de TI, y alinear todo en una sola línea de tiempo, es un gran trabajo para la IA.

También ayuda con el trabajo pesado de una investigación, como resumir lo que hizo un usuario en las últimas 24 horas en lugar de entregarle a un analista 4.000 líneas de registro sin procesar. Puede añadir contexto durante el triaje, como si una IP tiene mala reputación o si este proceso normalmente se ejecuta en este endpoint. Y puede redactar hallazgos en español claro para las personas que no dominan ES|QL, que es la mayoría del liderazgo y todos los auditores que he conocido.

En cada uno de esos casos, la IA aparece después del filtrado, en un punto específico donde ayuda a alguien a tomar una mejor decisión. Las detecciones y los analistas reales del SOC siguen decidiendo si algo es malicioso. Ese control es lo que mantiene las cosas predecibles. Sabes dónde se usa la IA, así que tienes una idea razonable de cuánto costará, y no está inventando alertas de la nada, lo cual mantiene bajos los falsos positivos.

¿Quién es responsable de qué? La responsabilidad compartida que nadie pone en la diapositiva de ventas

SIEM es una pieza más del panorama más amplio de operaciones de seguridad, junto con EDR, detección de amenazas de identidad, security awareness training, copias de seguridad y un plan de respuesta a incidentes que ojalá hayas probado al menos una vez. Así que cuando decidas qué manejar internamente y qué delegarle a un socio, ten en cuenta que incluso con un Managed SIEM, parte del trabajo sigue siendo tuyo.

Los proveedores de cloud resolvieron esto hace años. AWS asegura el centro de datos, pero si dejas un bucket de S3 abierto a internet, eso es responsabilidad tuya. Managed SIEM funciona de la misma manera.

Lo que tu socio debería manejar

Hay actividad que se ve maliciosa prácticamente en cualquier red. Credential stuffing. Un usuario bombardeado con solicitudes de MFA hasta que finalmente presiona "aprobar". Copias shadow que se borran. Alguien extrayendo credenciales de la memoria con Mimikatz.

Aquí es donde deberías poder confiar por completo en un socio como Huntress. Nuestro SOC observa las tácticas de los atacantes en cientos de miles de entornos, así que cuando aparece una técnica o un IOC nuevo en un lugar, lo buscamos en todos los demás. Un equipo interno por sí solo no puede tener esa visión. La ingeniería de detección, el ajuste, el triaje 24/7 y la remediación activa (aislar endpoints, cerrar sesiones, bloquear cuentas, limpiar la persistencia) son cosas que asumimos nosotros, en endpoint, identidad y SIEM. No solo te entregamos una pila de alertas.

Lo que solo tú puedes detectar

Luego está lo que podría ser totalmente normal o una señal de alarma enorme, y la única forma de saberlo es si tu equipo lo esperaba.

• Una herramienta de acceso remoto que no aprobaste. Que aparezca ScreenConnect en una estación de trabajo podría ser tu mesa de ayuda. También podría ser un atacante, o un proveedor "servicial", instalándose. Solo tú sabes qué herramientas RMM están autorizadas en tu entorno.

• Una cuenta de administrador nueva. ¿Ese nuevo administrador de dominio formaba parte de un ticket de cambio, o apareció de la nada un viernes por la tarde?

• Un inicio de sesión fuera de horario en un sistema crítico. Para una empresa es el proceso por lotes nocturno. Para otra es la primera señal de que alguien tiene las llaves del ERP.

• Una cuenta de servicio que se sale de su rutina habitual. Las cuentas de servicio deben ejecutarse en segundo plano, no iniciar sesión en la VPN desde un laptop. Si una aparece en tus registros de VPN, puede que alguien esté usando sus credenciales como puerta trasera.

• Cambios en reglas de firewall o políticas de grupo fuera de una ventana de mantenimiento. Si nadie de tu equipo hizo el cambio, lo hizo alguien más.

Tu lista de software aprobado, tu calendario de cambios y tus ventanas de mantenimiento son responsabilidad de tu equipo. Nosotros podemos decirte que una cuenta de servicio acaba de iniciar sesión en la VPN. Solo tú puedes decir si Jim, de TI, configuró eso como una solución "temporal" hace tres años.

Ahí es donde entran tus propias consultas guardadas y detecciones personalizadas. Tú sabes cómo se ve "algo raro para nosotros", así que escribes la lógica, y decides qué hacer cuando se activa. El SIEM te da los datos en un solo lugar para hacerlo.

La respuesta también es un deporte de equipo

Un socio como Huntress puede detener la hemorragia y limpiar después. Pero algunas decisiones solo las puedes tomar tú. ¿Sacas de línea la producción? ¿Avisas a los clientes? ¿Involucras a legal, a la aseguradora o a RR. HH.? ¿Qué servidores se pueden aislar un martes por la tarde, y cuáles necesitan primero una llamada telefónica?

Pon de acuerdo a tu propio liderazgo, TI, legal y RR. HH. antes de un incidente. Decide quién toma qué decisiones, a quién se le llama y qué acciones están preaprobadas. Con Huntress, tú eliges dónde y cómo respondemos en tu entorno, así que esas decisiones se trasladan directamente a cómo actuamos. Revísalas después de cada incidente. Créeme, no quieres estar averiguando a las 2 a. m. quién tiene permiso para deshabilitar la cuenta del CEO.

Las asociaciones que mejor he visto funcionar no son del tipo "configúralo y olvídalo". Es más bien "configúralo, dinos qué importa, y los dos dormiremos mejor".

Entonces, ¿SIEM está muerto?

No. Si hay algo que quisiera que te lleves, es que seas intencional.

Sé intencional con lo que almacenas. Conserva los registros que te ayudan a detectar y los que te ayudan a demostrar, y descarta el resto. Sé intencional con dónde usas la IA. Apúntala a los puntos donde agudiza la visión, como vincular los datos de endpoint, identidad y registros, en lugar de usarla en todas partes solo porque puedes. Y sé intencional sobre quién vigila qué. Apóyate en un socio para las amenazas que se ven mal en cualquier lado, y crea tus propias detecciones para lo que solo tu equipo sabría que está fuera de lugar.

La pregunta que yo haría no es si SIEM está muerto. Es si el tuyo se está ganando su lugar.

¿Quieres ver cómo se ve un SIEM que solo conserva lo que importa? Mira Huntress Managed SIEM en acción.