Une alerte montre un utilisateur se connectant depuis Paris puis, cinq minutes plus tard, depuis Singapour. Avant de déclarer un incident, que vérifiez-vous EN PREMIER ?
Réponse courte
Validez avant d'escalader. Les VPN d'entreprise, les proxys cloud (CASB ou IP de service M365) et les opérateurs mobiles produisent régulièrement de faux « voyages impossibles » ; vérifiez donc les IP de sortie, le résultat MFA et l'appareil/user-agent avant d'agir. Verrouiller à chaque déclenchement provoque de la fatigue d'alertes et érode la confiance des utilisateurs envers le SOC. Supposer que c'est toujours un faux positif laisse passer une vraie compromission de compte. Écrire au manager est lent et n'est pas un contrôle — les journaux répondent plus vite et plus sûrement.
Les alertes de voyage impossible sont à fort volume et fort taux de faux positifs, ce qui explique précisément qu'on teste un analyste junior dessus : réagissez-vous, ou enquêtez-vous ? Le bon premier geste est de valider le signal avec les données déjà disponibles avant de perturber un utilisateur ou de déclarer un incident.
Pourquoi la validation passe en premier
La géolocalisation est déduite de l'IP, et les IP mentent constamment en entreprise. La connexion « Singapour » peut être un concentrateur VPN d'entreprise, une sortie cloud (IP de service backend M365, proxy CASB) ou un opérateur mobile routant par une passerelle lointaine. Vous vérifiez donc :
- L'IP de sortie / ASN de chaque connexion — l'une est-elle une plage d'entreprise ou cloud connue ?
- Le résultat MFA — un facteur résistant au phishing a-t-il réussi, ou la MFA a-t-elle été contournée/échouée ?
- L'appareil et le user-agent — même appareil géré, ou nouveau client inconnu ?
Ces champs résolvent généralement l'alerte en moins d'une minute et vous disent si elle est bénigne ou s'il s'agit d'une vraie compromission de compte méritant une escalade.
Pourquoi les autres options sont fausses
- Verrouiller et ouvrir un P1 — verrouiller à chaque voyage impossible noie le SOC sous les P1, perturbe les utilisateurs légitimes et apprend à l'entreprise que la sécurité crie au loup. Réservez le verrouillage à une compromission validée.
- Toujours un faux positif — le miroir paresseux. Le voyage impossible est un vrai indicateur d'ATO ; l'écarter par défaut signifie laisser passer la vraie attaque quand elle survient.
- Écrire au manager — lent, indirect, et pas un contrôle. La réponse du manager ne vous dit pas ce que les journaux d'auth disent, et vous avez brûlé du temps de présence en l'attendant.
Ce que le recruteur évalue
Il veut voir un tri discipliné chez un junior : enrichir et valider avec les journaux avant d'agir, distinguer une bizarrerie de sortie bénigne d'une vraie compromission, et n'escalader que sur preuve. Nommer l'explication VPN/sortie cloud et le contrôle MFA/appareil montre que vous comprenez pourquoi ces alertes sont bruyantes et comment séparer le signal du bruit sans ni les ignorer ni surréagir.
Questions de suivi probables
- Quels champs de journal précis confirmeraient ou écarteraient ici une vraie compromission ?
- Si la MFA a réussi depuis les deux emplacements, cela rend-il la situation sûre ou plus suspecte ?
- Comment ajusteriez-vous cette détection pour mettre en liste d'autorisation les sorties d'entreprise connues sans devenir aveugle aux vraies attaques ?