Microsoft 365 / Enquêter sur les alertes de sécurité et répondre aux incidents
Lorsque vous recevez une alerte de sécurité Microsoft 365, ne la fermez pas immédiatement en vous basant uniquement sur la gravité. Vous devez vérifier le moment de l'occurrence, la source de détection, les utilisateurs/appareils/emails affectés et les alertes connexes. Plusieurs alertes pour le même incident peuvent être regroupées en un seul incident, donc examinez à la fois les alertes individuelles et l'ensemble de l'incident.
Différence entre les alertes et les incidents
Une alerte enregistre une activité suspecte détectée. Un incident rassemble les alertes et preuves liées pour comprendre le déroulement d’une attaque. Le guide de Microsoft sur l’investigation des incidents Defender explique comment examiner ensemble alertes, activités, ressources et preuves. Les vues et fonctions d’investigation automatisée disponibles dépendent des produits et licences de votre organisation.
Préparez l'accès et choisissez l'écran d'enquête
Ouvrez Incidents & alertes → Alertes dans le portail Microsoft Defender. Même si vous pouvez les visualiser avec des permissions de lecteur de sécurité, cela ne signifie pas que vous pouvez effectuer des actions de réponse comme le blocage de compte ou l'isolation de périphérique. Vérifiez d'abord le modèle d’autorisation Defender de votre organisation, le champ de responsabilités et les licences produit, et désignez le personnel d’investigation et de réponse.
La nouvelle vue des cas d’incident est en préversion ; la vue historique reste disponible. Dans l’interface en anglais, ouvrez Cases → Incident, sélectionnez le cas et examinez ses alertes, ressources, preuves et activités. Une navigation différente ne signifie pas à elle seule que des journaux manquent. Consultez le guide de Microsoft sur l’investigation des cas d’incident pour vérifier la vue et les autorisations disponibles. Dans le modèle unifié de contrôle d’accès en fonction du rôle (RBAC), Security Data Read permet la lecture et l’investigation ; Security Data Manage permet aussi la gestion des cas. Les actions de réponse exigent des autorisations adaptées à chaque action et au service concerné.
Liste de contrôle de la réponse initiale
- Ouvrez la liste des incidents ou des alertes dans le portail Microsoft Defender. Désignez le personnel responsable au sein de l'équipe et enregistrez le numéro de l'incident afin d'éviter le traitement en double du même cas.
- Vérifiez la gravité, l'heure de détection et les comptes, e-mails et appareils affectés. Ne confirmez pas une violation réelle uniquement sur la base du titre de l'alerte.
- Dans les détails de l’incident, examinez les alertes liées, la chronologie, les preuves et les résultats des actions automatisées. Le guide de Microsoft sur l’investigation des alertes précise le sens des états et des classifications.
- S'il existe une forte probabilité d'une menace réelle et que des dommages sont en cours, informez immédiatement le personnel responsable conformément aux procédures de réponse aux incidents de l'organisation, et déterminez l'étendue de l'impact ainsi que les mesures d'isolement/de blocage approuvées. Préservez les preuves nécessaires pour l'enquête tout en contenant la menace ; ne retardez pas inutilement le confinement urgent.
- Enregistrez la cause et les actions entreprises, et vérifiez si la même activité existe pour d'autres utilisateurs ou dispositifs. Surveillez pour vous assurer que les alertes ne se reproduisent pas après la mise en œuvre des mesures.
Enregistrez les preuves et établissez une chronologie de l'enquête
Enregistrez non seulement le nom de l'alerte mais aussi l'identifiant de l'alerte/de l'incident, le produit de détection, les heures d'activité initiales et récentes ainsi que les fuseaux horaires, et les informations d'identification de l'utilisateur, de l'appareil ou de l'e-mail ciblé. Vérifiez les entités réelles afin d'éviter de confondre des fichiers portant le même nom ou des comptes similaires. N'ouvrez pas directement les URL ou pièces jointes malveillantes sur les ordinateurs de travail quotidiens.
Reliez chronologiquement les événements confirmés tels que 'mail reçu → alerte liée au lien → connexion → accès aux données'. Ne supposez pas que tous les événements ont eu lieu ; distinguez entre les preuves existantes et les faits inconnus. Par exemple, même si un utilisateur nie avoir cliqué, les journaux pertinents doivent être vérifiés, et une fuite de mot de passe ne doit pas être confirmée uniquement sur la base des enregistrements de clics.
Recherchez s’il existe des alertes affectant d'autres utilisateurs liées au même expéditeur, fichier ou URL. Cela est nécessaire car même si une alerte touchant un compte est fermée, la même activité peut continuer sur un autre compte. Stockez les documents dans un emplacement approuvé de gestion des incidents et ne publiez pas l'e-mail original, les informations utilisateur ou les journaux d'accès sur des canaux publics.
Comment évaluer une alerte de phishing
| Situation confirmée | Ce qu'il faut vérifier ou faire en premier |
|---|---|
| Le message est mis en quarantaine et n'est pas livré à l'utilisateur | Vérifiez le résultat de la quarantaine et si le message a été livré à d'autres destinataires. Déterminez s'il s'agit d'une attaque détectée/bloquée |
| Arrivé dans la boîte de réception, mais l'action de l'utilisateur n'est pas confirmée | Enquêter sur l'identifiant du message et la portée de la livraison, et laisser le personnel de sécurité déterminer la nécessité de supprimer ou de bloquer le message |
| Confirmé que l'utilisateur a saisi un mot de passe sur la page liée | Prioriser la réponse en raison d'un potentiel compromis du compte. Procéder au blocage de l'accès, à la vérification des sessions et des méthodes d'authentification selon les procédures approuvées |
| Exécution malveillante ou dommage en cours sur l'appareil confirmés | Transférer immédiatement à la personne responsable de prévenir les dommages en cours et vérifier l'état d'achèvement de l'isolation et des actions approuvées. |
Des actions sur plusieurs services peuvent être nécessaires. Pour la livraison des e-mails, consultez le suivi des messages, et pour la connexion et l’authentification, consultez les journaux de connexion Microsoft Entra. Il ne suffit pas de changer le mot de passe de l’utilisateur ; le personnel concerné doit définir la portée de l’enquête afin de s’assurer que les méthodes d’authentification suspectes, les règles de transfert et les autorisations des applications ne restent pas en place.
Même lorsque des actions automatiques apparaissent, faites la distinction entre les états demandé, en attente, échoué et terminé. Selon le produit, les fonctionnalités d'investigation ou de réponse automatiques peuvent ne pas être disponibles, et le simple fait de voir un bouton de réponse sur le portail ne signifie pas que la tâche a été effectuée. Conservez les preuves et exécutez le blocage urgent simultanément, sans retarder inutilement la prévention des dommages en cours.
Pouvons-nous l'ignorer immédiatement s'il semble s'agir d'un faux positif ?
Non. Comparez les preuves avec l'explication de la personne responsable pour déterminer si un changement de politique ou une tâche opérationnelle normale a provoqué l'alerte. Si vous classez une alerte comme un faux positif, enregistrez les preuves et la portée correspondantes. Évitez de désactiver les règles d’alerte à grande échelle, car cela pourrait empêcher la détection de véritables attaques. Lorsque le même faux positif se reproduit, envisagez un ajustement à portée restreinte soutenu par l'enquête.
Distinguez une alerte qui a correctement détecté et bloqué une véritable menace d'une alerte qui a incorrectement identifié une activité normale comme malveillante. L'absence de dommages ne rend pas en soi une alerte un faux positif. Pour un test ou une tâche opérationnelle approuvée, comparez la demande de travail, le temps d'exécution, la cible et les preuves, puis enregistrez la classification et la détermination appropriées. Dans la vue des alertes, Vrai positif, Activité attendue, à titre informatif et Faux positif représentent différentes conclusions. Si un ajustement ou une suppression est justifié, limitez les cibles affectées et définissez une date d'expiration ou de révision.
Vérifiez la récupération avant de clôturer l'incident
- Statut actuel des comptes/appareils affectés et présence d'alertes supplémentaires
- Actions automatisées/manuelles effectuées et actions à annuler le cas échéant
- Achèvement des notifications aux utilisateurs et des enregistrements internes des incidents
- Personnes responsables des tâches de prévention de la récurrence telles que les politiques, la formation et les méthodes d'authentification
Le rapport de clôture de l'incident doit inclure les symptômes initiaux, l'étendue de l'impact, les preuves à l'appui, les résultats réels des actions automatisées et manuelles, ainsi que le suivi restant à effectuer. Modifier une alerte pour la passer en Résolue ne supprime pas en soi une menace. Clôturez l'incident après avoir vérifié que les comptes et appareils affectés sont protégés et que les opérations commerciales ont repris. Passez en revue séparément tout blocage temporaire ou changement de politique; la personne responsable ne doit annuler une mesure que si son annulation est justifiée par les preuves et respecte le périmètre approuvé.
