Cuéntame cómo haces el triaje de una alerta de seguridad desde el momento en que cae en tu cola.

Empieza confirmando sobre qué disparó realmente la detección y luego enriquece antes de juzgar. Saca el log en crudo, identifica el host, el usuario, el proceso y el contexto de red, y comprueba la criticidad del activo. Compara con el comportamiento normal conocido y con los tickets de cambio recientes. Decide si es verdadero positivo, falso positivo o verdadero positivo benigno, documenta el razonamiento y cierra con feedback de tuning o escala con una línea de tiempo.

Lo primero que hago es leer la lógica de la regla, no solo el título de la alerta, porque el título suele estar desactualizado. Después enriquezco: host, usuario, proceso padre e hijo, línea de comandos, IP de destino y su reputación, y si el usuario tiene un ticket de cambio abierto. En mi trabajo anterior tuve una alerta por PowerShell codificado en una estación de trabajo de finanzas. La línea de comandos decodificaba a un blob que resultó ser el instalador legítimo de un proveedor, pero el proceso padre era Outlook, que es justo el patrón que me importa, así que no lo cerré ahí. Revisé el buzón, vi que el mensaje venía de un dominio de proveedor conocido con firma válida y lo confirmé con el usuario por teléfono en vez de por correo, por si su cuenta estaba comprometida. Verdadero positivo benigno. Lo documenté y luego le sugerí al ingeniero de detección que excluyera ese hash concreto del proveedor en lugar de toda la regla de PowerShell codificado, que nos habría dejado ciegos.