Expliquez-moi comment vous triez une alerte de sécurité depuis le moment où elle arrive dans votre file.

Commencez par confirmer sur quoi la détection s'est réellement déclenchée, puis enrichissez avant de juger. Sortez le journal brut, identifiez l'hôte, l'utilisateur, le processus et le contexte réseau, et vérifiez la criticité de l'actif. Comparez au comportement connu comme bon et aux tickets de changement récents. Tranchez entre vrai positif, faux positif ou vrai positif bénin, documentez votre raisonnement, et soit vous clôturez avec un retour de tuning, soit vous escaladez avec une chronologie.

La première chose que je fais, c'est lire la logique de la règle, pas seulement le titre de l'alerte, parce que le titre est souvent périmé. Ensuite j'enrichis : hôte, utilisateur, processus parent et enfant, ligne de commande, IP de destination et sa réputation, et si l'utilisateur a un ticket de changement ouvert. Dans mon poste précédent, j'ai eu une alerte pour du PowerShell encodé sur un poste de la finance. La ligne de commande décodée donnait un bloc qui s'est avéré être un installeur légitime d'un fournisseur, mais le processus parent était Outlook, ce qui est exactement le motif qui m'intéresse, donc je n'ai pas clôturé là. J'ai vérifié la boîte mail, trouvé que le message venait d'un domaine fournisseur connu avec une signature valide, et confirmé avec l'utilisateur par téléphone plutôt que par e-mail au cas où son compte serait compromis. Vrai positif bénin. J'ai rédigé le compte rendu, puis envoyé à l'ingénieur détection une suggestion d'exclure ce hachage fournisseur précis plutôt que toute la règle sur le PowerShell encodé, ce qui nous aurait rendus aveugles.