Triatge d'alertes en un SOC: en quin ordre mirar el que salta

El primer que s'aprèn en un SOC és que la cua no es buida. Sempre hi ha més alertes que hores, i la feina no consisteix a mirar-les totes sinó a encertar l'ordre. Això és com ho enfoco jo.

La severitat no és la prioritat

Tota alerta arriba amb una severitat posada pel fabricant. És un punt de partida útil i un mal criteri únic, perquè aquesta etiqueta es calcula en el buit: descriu com de greu seria aquell esdeveniment en abstracte, sense saber res de la teva organització.

La prioritat real surt de creuar aquesta severitat amb el context:

• Quin actiu és. El mateix esdeveniment no pesa igual en un portàtil de becari que en un controlador de domini.
• Quin usuari. Un compte amb privilegis d'administració canvia la conversa sencera.
• Quan. Activitat normal a les onze del matí; la mateixa a les quatre de la matinada d'un diumenge mereix una mirada.
• Què hi ha al voltant. Una alerta mitjana aïllada és soroll. Tres alertes mitjanes sobre el mateix host en deu minuts són una cadena.

Aquest últim punt és on una plataforma XDR se separa d'un SIEM clàssic. Treballant amb Trend Micro Vision One, el que més m'ha canviat el triatge no és detectar més coses, sinó que els esdeveniments arribin ja correlacionats. Veure la cadena completa (correu, execució, connexió de sortida) evita l'error de tancar tres alertes per separat com a poc rellevants quan juntes expliquen una altra història.

Les tres preguntes

En obrir una alerta vaig sempre en el mateix ordre, i en aquest ordre concret:

1. És real? Distingir detecció d'incident. La major part del volum mor aquí, i està bé que sigui així.
2. És rellevant? Pot ser perfectament real i no importar. Un escaneig bloquejat al perímetre és real i no és un incident.
3. Està contingut? Si ha passat alguna cosa, el que és urgent no és entendre-ho del tot: és que deixi d'estendre's. Entendre ve després.

L'ordre importa perquè l'error car és saltar-se la tercera per continuar investigant la primera. La curiositat tècnica estira molt, i contenir és avorrit comparat amb reconstruir. Contenir primer.

Enriquir abans d'escalar

Una alerta escalada sense context trasllada la feina al nivell següent i no estalvia res. Abans de moure alguna cosa cap amunt intento portar respost:

• Què fa normalment aquell host o aquell usuari, per tenir amb què comparar.
• Si l'indicador apareix en fonts d'intel·ligència i des de quan.
• Si això ja s'havia vist abans i com es va tancar llavors.
• Què s'ha fet ja i què està pendent.

El tercer es paga sol. La meitat de les alertes que arriben són variacions d'alguna cosa ja resolta, i sense registre de la decisió anterior l'anàlisi es repeteix sencera cada vegada.

Un fals positiu recurrent és un error de la regla

Aquesta és la part que més es descuida, perquè tancar ràpid sempre sembla més productiu que arreglar. Si una alerta es tanca com a fals positiu per sistema, el problema ja no és l'alerta: és la regla. Cada repetició costa atenció, i l'atenció és el recurs escàs d'un SOC.

Pitjor encara: una cua plena de soroll conegut educa l'equip a tancar de pressa. I el dia que entri alguna cosa de debò, arribarà amb el mateix aspecte que les mil anteriors.

Ajustar una regla no és abaixar la guàrdia. És decidir a consciència què mereix interrompre una persona, en lloc de deixar que ho decideixi un valor per defecte que va posar algú que no coneix la teva xarxa.