El SIEM, donde todo se junta

Antes del SIEM, investigar un incidente era entrar máquina por máquina a leer registros a mano. El SIEM cambia eso: centraliza. Cuando svc-backup acepta una sesión rara en un servidor, el analista puede, en la misma pantalla, ver qué hizo el cortafuegos con esa conexión y si el identity provider registró algo de esa cuenta. La potencia no es guardar líneas: es poder preguntarle a todas las fuentes a la vez.

Centralizar también significa que el atacante que borra el registro local no borra la copia: el evento ya viajó al SIEM. Por eso los registros se envían fuera de la máquina que los genera.

Un SIEM de una empresa mediana recibe millones de eventos al día. Buscar sin filtrar es inútil: el analista acota. Filtra por ventana de tiempo, por la cuenta que investiga, por la máquina, por el tipo de evento. La consulta «sesiones aceptadas de svc-backup en las últimas seis horas» devuelve tres líneas donde el buscador a ciegas devolvía cien mil. Filtrar bien es lo que convierte el volumen en algo legible.

El error de novato es filtrar de menos y ahogarse, o filtrar de más y esconder justo el evento que importaba. Se empieza amplio y se va cerrando en cuanto aparece un hilo.

Correlacionar es unir eventos de fuentes distintas que hablan del mismo hecho. En Delta Cargo, el identity provider registra que jmora se autenticó desde una dirección de fuera a las 03:10; el servidor de archivos registra que, a las 03:12, esa misma cuenta abrió una carpeta que no le corresponde. Por separado, cada evento es discutible. Juntos —la misma cuenta, dos minutos de diferencia, dos sistemas— cuentan una historia: alguien con las credenciales de jmora entró de madrugada y fue directo a algo que no debía.

La correlación es lo que distingue al analista del buscador. La herramienta encuentra las líneas; la persona las conecta en un relato con sentido.

El SIEM dispara alertas cuando un evento encaja con una regla. Pero una alerta es un punto de partida, no un veredicto: dice «esto encajó con un patrón», no «esto es un ataque». Una regla que marca «inicio de sesión fuera de horario» saltará también con el empleado que trabajó de noche por una entrega. El analista usa la alerta para saber dónde mirar, y luego decide con el contexto que la regla no tiene.

Tratar cada alerta como un incidente confirmado es la receta para quemar el turno y perder la confianza en las reglas. La alerta abre la investigación; no la cierra.

El SIEM te deja ver un pico: de golpe, un servidor de Delta Cargo abre diez veces más conexiones salientes que hace un rato. Un pico no es, por sí solo, un incidente. Para saber si merece una mirada hace falta compararlo con cómo se comporta ese mismo servidor un día cualquiera a esa misma hora. Esa referencia de lo habitual es lo que hace que una desviación resalte en vez de confundirse con el trajín normal.

Sin esa referencia, el analista oscila entre dos errores: alarmarse por cualquier subida o no ver la que importa. El oficio es conocer el pulso normal de cada fuente para que lo anómalo salte solo.

Correlaciona en la consola los eventos de la cuenta que se autenticó desde fuera a las 03:10 y, dos minutos después, abrió una carpeta que no le correspondía. Necesitas identificar en qué máquina ocurrió ese segundo evento.