Una alerta muestra a un usuario iniciando sesión desde París y, cinco minutos después, desde Singapur. Antes de declarar un incidente, ¿qué compruebas PRIMERO?
Respuesta breve
Valida antes de escalar. Las VPN corporativas, los proxies en la nube (CASB o IP de servicio de M365) y los operadores móviles producen rutinariamente falsos «viajes imposibles»; comprueba las IP de salida, el resultado MFA y el dispositivo/user-agent antes de actuar. Bloquear en cada disparo causa fatiga de alertas y erosiona la confianza de los usuarios en el SOC. Asumir que siempre es un falso positivo deja pasar una apropiación de cuenta real. Escribir al jefe es lento y no es un control — los registros responden más rápido y con más fiabilidad.
Las alertas de viaje imposible son de alto volumen y alto índice de falsos positivos, lo que explica precisamente que se evalúe a un analista junior con ellas: ¿reaccionas o investigas? El primer movimiento correcto es validar la señal con los datos que ya tienes antes de perturbar a un usuario o declarar un incidente.
Por qué la validación va primero
La geolocalización se infiere de la IP, y las IP mienten constantemente en una empresa. El inicio de sesión de «Singapur» puede ser un concentrador VPN corporativo, una salida en la nube (IP de servicio backend de M365, proxy CASB) o un operador móvil que enruta por una pasarela lejana. Así que compruebas:
- La IP de salida / ASN de cada inicio de sesión — ¿alguna es un rango corporativo o en la nube conocido?
- El resultado MFA — ¿tuvo éxito un factor resistente al phishing, o se omitió/falló la MFA?
- El dispositivo y el user-agent — ¿el mismo dispositivo gestionado, o un nuevo cliente desconocido?
Estos campos suelen resolver la alerta en menos de un minuto y te dicen si es benigna o una verdadera apropiación de cuenta que merece escalar.
Por qué las otras opciones son erróneas
- Bloquear y abrir un P1 — bloquear en cada viaje imposible ahoga al SOC en P1s, perturba a usuarios legítimos y enseña al negocio que seguridad da falsas alarmas. Reserva el bloqueo para una compromisión validada.
- Siempre un falso positivo — el espejo perezoso. El viaje imposible es un indicador real de ATO; descartarlo por defecto significa dejar pasar el ataque genuino cuando llegue.
- Escribir al jefe — lento, indirecto y no es un control. La respuesta del jefe no te dice lo que dicen los registros de auth, y has quemado tiempo de permanencia esperándola.
Qué evalúa el entrevistador
Quiere ver un triaje disciplinado de un junior: enriquecer y validar con registros antes de actuar, distinguir una rareza de salida benigna de una apropiación real, y escalar solo con evidencia. Nombrar la explicación de VPN/salida en la nube y la comprobación MFA/dispositivo muestra que entiendes por qué estas alertas son ruidosas y cómo separar la señal del ruido sin ignorarlas ni sobrerreaccionar.
Posibles preguntas de seguimiento
- ¿Qué campos de registro concretos confirmarían o descartarían aquí una apropiación genuina?
- Si la MFA tuvo éxito desde ambas ubicaciones, ¿eso lo hace seguro o más sospechoso?
- ¿Cómo ajustarías esta detección para poner en lista de permitidos las salidas corporativas conocidas sin cegarte ante ataques reales?