El turno y los registros

Un SOC trabaja por niveles. El nivel 1 es la puerta: recibe las alertas que disparan las herramientas, decide en minutos si cada una es ruido o merece atención, y pasa hacia arriba solo lo que de verdad lo necesita. El nivel 2 investiga a fondo lo que el 1 escaló; el nivel 3 caza lo que ninguna alerta vio y escribe las reglas. El valor del nivel 1 no está en resolver el incidente entero, sino en no dejar pasar el que importa y no despertar a nadie por el que no.

Por eso el error caro del nivel 1 no es equivocarse en el análisis profundo —para eso está el nivel 2—, sino cerrar como «ruido» una alerta que era el principio de algo, o escalarlo todo y volver inútil la cola.

Cada sistema escribe lo suyo. El servidor Linux anota inicios de sesión y procesos en sus registros de autenticación y de sistema; el cortafuegos anota conexiones permitidas y bloqueadas; el identity provider anota quién se autenticó, desde dónde y si el segundo factor entró. Saber qué fuente escribe qué es la mitad del oficio: buscar un fallo de contraseña en los registros del cortafuegos es perder el turno, porque ahí no está.

Y hay algo que casi ningún sistema escribe: el contenido. Un registro dice que la cuenta jmora inició sesión a las 03:14 desde una dirección de fuera; no dice qué hizo dentro ni qué tecleó. El analista trabaja con metadatos —quién, cuándo, desde dónde, con qué resultado—, no con una grabación.

En el SIEM de Delta Cargo aparece un evento de autenticación de un servidor: registra que la cuenta svc-backup aceptó una sesión remota a las 02:47, desde una dirección que no pertenece a la red interna de la empresa. Leerlo es descomponerlo: qué cuenta (svc-backup, una cuenta de servicio), qué acción (sesión aceptada), cuándo (madrugada), desde dónde (fuera de la red). Cada campo es una pregunta que el analista se hace antes de decidir.

Ninguno de esos campos aislado es una alarma. Una cuenta de servicio que acepta una sesión desde fuera de la red, de madrugada, es la suma de tres cosas raras a la vez —y esa suma es lo que hace que el evento merezca una segunda mirada.

A veces la señal no es un evento, sino su ausencia. Si un servidor que escribe su bitácora cada minuto deja de escribir durante media hora y luego vuelve, ese hueco es información: alguien pudo detener el registro para trabajar sin dejar rastro, y después reactivarlo. El analista que solo busca líneas «malas» no ve el hueco, porque el hueco no es una línea.

Mirar la continuidad —¿el registro tiene la forma regular que debería?— es parte del triaje. Un silencio en una fuente que nunca calla vale tanto como una alerta.

Entre tanto evento y tanta consola es fácil perder de vista para qué está el SOC. Lo que el turno defiende no son las máquinas en sí, sino tres garantías sobre la información que ellas guardan: que no la vea quien no debe, que no la altere quien no debe, y que siga accesible para quien la necesita. Casi toda alerta que valga la pena mirar amenaza una de esas tres. Tener claro el marco evita perseguir rarezas que no ponen en juego ninguna.

Es un criterio, no un adorno teórico: cuando dudas si un evento merece tu tiempo, preguntarte cuál de las tres garantías rompería si fuera real ordena la decisión más rápido que la corazonada.

Abre la consola del SIEM de Delta Cargo y aísla la sesión que la cuenta de servicio aceptó de madrugada desde fuera de la red interna. El dato no está en esta pantalla: sale de leer la fila del evento.