Une alerte SIEM se déclenche pour une connexion suspecte. Détaillez votre démarche de triage.
Réponse courte
Confirmez que l'alerte est réelle avant d'agir : lisez ce qui s'est déclenché et pourquoi, puis enrichissez — qui est l'utilisateur, l'IP/géo/appareil source sont-ils attendus, est-ce un voyage impossible, y a-t-il eu des échecs antérieurs ? Classez en vrai ou faux positif, escaladez ou confinez si c'est réel (désactiver la session, forcer une réinitialisation MFA), et documentez tout pour que le prochain analyste puisse suivre votre raisonnement.
Le triage consiste à répondre efficacement à une question : est-ce réel, et si oui, à quel point est-ce grave ? Les recruteurs veulent voir un processus reproductible, pas un réflexe. Sauter directement à « désactiver le compte » est un signal d'alarme — vous pourriez agir sur un faux positif et brûler de la confiance, ou alerter un attaquant avant de comprendre la portée.
1. Valider
Commencez par lire la détection elle-même. Quelle règle s'est déclenchée, sur quelle source de données, et quelle est la condition exacte qui a correspondu ? Une « connexion suspecte » peut être une simple règle de géovélocité ou une corrélation de plusieurs signaux. Savoir pourquoi elle s'est déclenchée vous dit quelles preuves rassembler.
2. Enrichir avec du contexte
C'est là que se trouve l'essentiel de la valeur. Récupérez les faits environnants :
- Identité : qui est l'utilisateur, quel est son rôle, se connecte-t-il normalement à cette heure ?
- Source : l'IP provient-elle d'une plage d'entreprise connue, d'un VPN, d'un FAI résidentiel, ou d'un hébergeur / nœud de sortie Tor ? Quel pays, et est-ce plausible ?
- Appareil : s'agit-il d'un appareil géré avec le user agent attendu, ou de quelque chose de nouveau ?
- Séquence : y a-t-il eu des tentatives échouées avant le succès (password spray / force brute), et y a-t-il un voyage impossible — deux connexions trop éloignées géographiquement pour être la même personne ?
3. Classer
Avec le contexte en main, décidez : vrai positif, faux positif, ou vrai positif bénin (réel mais autorisé, p. ex. l'utilisateur en voyage). Dites-le explicitement et consignez les preuves qui vous y ont mené.
4. Confiner (si réel)
Si cela ressemble à une compromission de compte, agissez de façon proportionnée : révoquez la session active, forcez une réinitialisation des identifiants et du MFA, et vérifiez ce que la session a fait — règles de boîte mail, autorisations OAuth, accès aux données. Le confinement vaut mieux que l'attente.
5. Escalader et documenter
Passez le relais à la réponse à incident si le rayon d'impact dépasse un seul compte ou si vous voyez un mouvement latéral. Dans tous les cas, écrivez-le : ce qui s'est déclenché, ce que vous avez vérifié, ce que vous avez conclu, et ce que vous avez fait. De bonnes notes sont ce qui permet à un SOC d'affiner ses détections et de survivre à un audit.
Pourquoi c'est important
La structure témoigne de jugement. N'importe qui peut cliquer sur « bloquer » ; un analyste qui peut expliquer pourquoi une connexion était ou n'était pas malveillante — et qui laisse une trace propre — est celui à qui l'on confie des incidents plus importants.
Questions de suivi probables
- Qu'est-ce que le « voyage impossible » et comment le détecteriez-vous ?
- Quand escaladez-vous vers la réponse à incident plutôt que de gérer vous-même ?
- Comment affiner une règle bruyante sans créer d'angle mort ?