SIEM

Un SIEM hace cuatro cosas en orden, y ese orden explica por qué los despliegues fallan por la mitad.

Recoge. Los registros llegan de firewalls, proveedores de identidad, endpoints, pasarelas de correo, planos de control cloud, bases de datos y aplicaciones, cada uno en su propio formato. Normaliza: los nombres de campo se mapean sobre un esquema común para que un nombre de usuario sea el mismo campo venga de un directorio o de un servidor web, que es la única forma de que una consulta cruce fuentes. Correlaciona: reglas y consultas corren sobre el flujo normalizado, uniendo eventos que por separado no significan nada. Y conserva, que es a la vez la capacidad de investigar y, en la mayoría de los sectores regulados, el motivo por el que se compró.

El valor está por entero en las uniones. Un inicio de sesión fallido es ruido. Un inicio de sesión fallido desde un país que la cuenta no ha usado nunca, seguido de uno correcto, seguido de una regla de buzón que reenvía al exterior, seguida de una descarga desde un repositorio documental, es un incidente, y ninguna fuente por separado ve la secuencia entera. Esa es la pregunta para la que existe un SIEM.

El contenido de detección se escribe, no se compra. Los fabricantes entregan un conjunto inicial, pero las reglas que cazan lo que a ti te pasa son las que alguien escribió contra tu parque: tus convenciones de nombres, tus cuentas de servicio, tu normalidad. Ese trabajo es la ingeniería de detección, y es un puesto continuo y no una fase de un proyecto.

El estado que más encontramos es un SIEM que lo tiene todo salvo la fuente que necesitamos. La ingesta se cobra por volumen, el volumen lo dominan cosas que nadie investiga, y así el presupuesto se va en registros de aceptación del firewall mientras el registro de inicios de sesión del proveedor de identidad, que es donde se ve toda intrusión moderna, va muestreado o directamente falta. En los encargos esto es determinante: nuestra actividad en el plano de identidad del cliente dejó muchas veces un rastro perfecto en un registro que no se estaba recogiendo.

Lo segundo es el conjunto de reglas que no tiene dueño. El contenido de detección envejece. Una regla escrita contra una convención de nombres se rompe cuando la convención cambia; una regla que dependía de un campo se rompe cuando la fuente se actualiza y lo renombra. Una regla rota no levanta un error, no levanta nada, y nada es indistinguible de la calma. Hemos probado parques con varios cientos de reglas donde el número de las que habían saltado en los noventa días anteriores se contaba con los dedos de una mano, y nadie se había dado cuenta.

Lo tercero es que el SIEM registra la intrusión a la perfección y nadie lo lee. Esto no es un problema de tecnología y es el hallazgo que más veces escribimos en esta materia. La consola enseña la secuencia, bien correlacionada, con la severidad correcta, y la alerta se quedó sin abrir porque el analista de turno tenía otras cuatrocientas.

Desde el punto de vista de un atacante, nada de esto exige evasión. Camuflarse en el volumen es más fácil que esquivar los sensores: autenticarse a una hora normal, desde una dirección del país correcto, usando un protocolo que la cuenta ya usa. Lo que derrota eso es una línea de base del comportamiento normal por cuenta, que es cara de construir y es lo único que funciona.

Se venden normalmente juntos y responden preguntas distintas. El SIEM pregunta qué ha pasado. El SOAR pregunta qué hacer al respecto, y hace parte de ello sin esperar a una persona.

El orden importa. Automatizar una respuesta encima de detecciones en las que no confías industrializa tus falsos positivos, y una acción de contención automática que se dispara por error sobre un servidor de producción le enseña a una organización a apagar la automatización. Primero la calidad de la detección, después la automatización de los pasos de enriquecimiento, y la contención automática la última y de forma estrecha.

Comprar por volumen de ingesta y no por pregunta. Parte de las preguntas que tienes que poder responder durante un incidente, vuelve hacia atrás hasta las fuentes que las responden, y recoge esas por completo. Un registro parcial de una fuente crítica es peor que ninguno, porque parece cobertura.

Dejar activas las reglas por defecto del fabricante y llamar a eso detección. Están escritas para un parque promedio. El tuyo no es promedio, y las reglas que importan mencionan tus nombres, tus cuentas de servicio y tu horario de trabajo.

Mandarle la telemetría de endpoint al completo. La telemetría de procesos íntegra es enorme y ya vive en el EDR, que está construido para eso. Manda las alertas y los tipos de evento concretos con los que correlacionas, no todo.

No tener disciplina de sincronización horaria. La correlación entre fuentes depende de los relojes. Máquinas que se desvían minutos hacen que las secuencias no se puedan ordenar, y eso se descubre durante el incidente.

Medir al equipo por alertas cerradas. Premia cerrar, que es lo contrario de investigar. Mide cuánto tardó un verdadero positivo en llegar a una persona y qué pasó después.

Escribe las diez preguntas que necesitarías responder en la primera hora de un incidente grave: qué cuentas se autenticaron y desde dónde, qué se ejecutó en esta máquina, a qué se accedió en este repositorio, qué cambió en el plano de control cloud. Después comprueba, ejecutándolas, si el SIEM puede responder hoy a cada una. Las que no puede son tus huecos de ingesta, y esa lista es mucho más útil que un porcentaje de cobertura.

Prueba las reglas como probarías código. Dispara a propósito una técnica conocida en una ventana controlada y confirma que la alerta aparece, lo que además te dice la latencia de extremo a extremo entre la acción y la consola. Mapea la cobertura contra MITRE ATT&CK para que los huecos se expresen como técnicas y no como impresiones, y repite el ejercicio después de cada actualización de la plataforma, porque las actualizaciones renombran campos.

Mantén la retención alineada con la obligación y con la realidad de que las intrusiones se descubren tarde. Una retención que termina antes del tiempo medio de permanencia significa que la evidencia del comienzo del incidente ha desaparecido antes de que nadie la busque.

Rara vez probamos un SIEM como producto. Probamos si nos vio. En un informe de red team o de purple team, el entregable es una línea temporal con dos columnas: qué hicimos y cuándo, y qué guarda la consola del cliente para ese momento. Hay tres resultados y se escriben de forma distinta. No registrado es un hallazgo de ingesta, y la remediación es una fuente. Registrado pero sin regla es un hallazgo de ingeniería de detección, y la remediación es contenido. Registrado, alertado y nadie actuó es un hallazgo de operación, y no lo va a arreglar ningún cambio de producto.

La severidad se escribe contra la consecuencia del punto ciego, no contra la plataforma. Un registro de firewall que falta es un hallazgo bajo. Un registro de inicios de sesión del proveedor de identidad que no se recoge, en un parque cuyo perímetro entero es la identidad, es crítico.

Esa comparación de nuestra línea temporal contra la propia consola del cliente es un entregable fijo del trabajo de emulación de adversarios que hacemos.

¿En qué se diferencian un SIEM y un SOC? El SIEM es la plataforma. El SOC es el equipo y el proceso que la usan. Comprar lo primero sin dotar de personal a lo segundo produce un archivo de registros carísimo.

¿Hace falta un SIEM si ya tenemos EDR y XDR? Si tienes cualquier obligación de conservar registros de sistemas que no llevan agente, o cualquier necesidad de correlacionar eventos de identidad, red y aplicación con los de endpoint, entonces sí. Los productos de endpoint cubren máquinas; buena parte de una intrusión ocurre donde no hay ninguna máquina.

¿Por qué nuestro SIEM produce tantas alertas? Casi siempre porque se activaron reglas sin ajustarlas al parque. La corrección es poco vistosa: establece la línea de base de lo normal para cada regla, suprime lo conocido como bueno con un motivo documentado y una fecha de caducidad, y borra las reglas sobre las que nadie ha actuado nunca.

¿Puede un SIEM detectar a un atacante que usa credenciales válidas? Solo con líneas de base de comportamiento por cuenta, y aun así es difícil. Un atacante que se autentica con normalidad, desde una ubicación verosímil y con un protocolo que la cuenta ya usa genera eventos que parecen correctos en todos los campos. Por eso la detección no puede ser el único control.