Del hallazgo al ticket: triage

La primera pregunta del triage no es «qué tan grave es» sino «pasó de verdad lo que la regla cree». Una regla ve un patrón; el contexto dice si ese patrón está autorizado. En una regla de titulares distintos, el contexto clave son las relaciones legítimas entre cuentas (una empresa con varias sedes, una familia con un administrador) y el historial: si el mismo cliente hace lo mismo cada mes, desde el mismo dispositivo, es probable que sea su trabajo.

Un benigno esperado no se ignora: se cierra con una nota que dice por qué, y si se repite se pide ajustar la regla.

La prioridad no se decide por intuición ni por el nivel que trae la regla: se decide con la matriz de la organización, aplicada a lo que muestran los eventos. Dos datos pesan casi siempre: cuántas personas ajenas quedaron expuestas y si la exposición sigue en curso. Un tercero, si la cuenta del cliente parece tomada por otra persona, cambia también lo que se contiene.

Un ticket de seguridad lo van a leer personas que no estaban mirando la consola: quien contiene, quien corrige la herramienta, quien decide si hay que avisar a los clientes. Por eso tiene campos obligatorios y separa los hechos (lo que muestra la evidencia) de las hipótesis (lo que se sospecha y no se ha comprobado). Un ticket que mezcla las dos cosas o que no dice a quién afectó obliga a repetir el triage.

Cada prioridad tiene un plazo de triage, medido desde que la alerta se dispara hasta que el ticket está abierto con su prioridad. Medirlo no es buscar culpables: un plazo que se incumple a menudo dice que la guardia tiene demasiadas alertas, que el contexto tarda en reunirse o que la regla no trae lo necesario.

El proveedor de la plataforma donde corre Chercán pide un resumen en inglés para su equipo de soporte. Un buen resumen cuenta solo hechos comprobados, con quién, cuántos y cuándo, y dice en qué punto está la contención; deja fuera culpables, adjetivos y suposiciones sobre cómo entró nadie.