Triaje de alertas en un SOC: en qué orden mirar lo que salta

Lo primero que se aprende en un SOC es que la cola no se vacía. Siempre hay más alertas que horas, y el trabajo no consiste en mirarlas todas sino en acertar con el orden. Esto es cómo lo enfoco yo.

La severidad no es la prioridad

Toda alerta llega con una severidad puesta por el fabricante. Es un punto de partida útil y un mal criterio único, porque esa etiqueta se calcula en el vacío: describe lo grave que seria ese evento en abstracto, sin saber nada de tu organización.

La prioridad real sale de cruzar esa severidad con el contexto:

• Qué activo es. El mismo evento no pesa igual en un portátil de becario que en un controlador de dominio.
• Qué usuario. Una cuenta con privilegios de administración cambia la conversación entera.
• Cuándo. Actividad normal a las once de la mañana; la misma a las cuatro de la madrugada de un domingo merece una mirada.
• Qué hay alrededor. Una alerta media aislada es ruido. Tres alertas medias sobre el mismo host en diez minutos son una cadena.

Ese último punto es donde una plataforma XDR se separa de un SIEM clásico. Trabajando con Trend Micro Vision One, lo que más me ha cambiado el triaje no es detectar más cosas, sino que los eventos lleguen ya correlacionados. Ver la cadena completa (correo, ejecución, conexión de salida) evita el error de cerrar tres alertas por separado como poco relevantes cuando juntas cuentan otra historia.

Las tres preguntas

Al abrir una alerta voy siempre en el mismo orden, y en este orden concreto:

1. ¿Es real? Distinguir detección de incidente. La mayor parte del volumen muere aquí, y está bien que así sea.
2. ¿Es relevante? Puede ser perfectamente real y no importar. Un escaneo bloqueado en el perímetro es real y no es un incidente.
3. ¿Está contenido? Si ha pasado algo, lo urgente no es entenderlo del todo: es que deje de extenderse. Entender viene después.

El orden importa porque el error caro es saltarse la tercera para seguir investigando la primera. La curiosidad técnica tira mucho, y contener es aburrido comparado con reconstruir. Contener primero.

Enriquecer antes de escalar

Una alerta escalada sin contexto le traslada el trabajo al siguiente nivel y no ahorra nada. Antes de mover algo hacia arriba intento llevar respondido:

• Qué hace normalmente ese host o ese usuario, para tener con qué comparar.
• Si el indicador aparece en fuentes de inteligencia y desde cuándo.
• Si esto ya se vio antes y cómo se cerró entonces.
• Qué se ha hecho ya y qué está pendiente.

Lo tercero se paga solo. La mitad de las alertas que llegan son variaciones de algo ya resuelto, y sin registro de la decisión anterior el análisis se repite entero cada vez.

Un falso positivo recurrente es un error de la regla

Esta es la parte que más se descuida, porque cerrar rápido siempre parece más productivo que arreglar. Si una alerta se cierra como falso positivo por sistema, el problema ya no es la alerta: es la regla. Cada repetición cuesta atención, y la atención es el recurso escaso de un SOC.

Peor todavía: una cola llena de ruido conocido educa al equipo para cerrar deprisa. Y el día que entre algo de verdad, llegará con el mismo aspecto que las mil anteriores.

Ajustar una regla no es bajar la guardia. Es decidir a conciencia qué merece interrumpir a una persona, en vez de dejar que lo decida un valor por defecto que puso alguien que no conoce tu red.