Retour à la documentation
Guide public18 minSOC, RSSI et administrateurs

EDR & réponse aux incidents

Traitez une détection de manière structurée, du premier signal jusqu’au retour en production. Ce guide couvre la qualification, la collecte de preuves, l’approbation des actions sensibles et la clôture documentée.

Mis à jour le 26 juillet 2026. Les libellés peuvent varier légèrement selon votre rôle et votre offre.

1

Comprendre le cycle de réponse

Une détection n’est pas automatiquement un incident confirmé. La réponse doit séparer l’observation, la qualification, le confinement, l’éradication, la restauration et le retour d’expérience.

  • Détection : événement ou comportement remonté par une règle.
  • Triage : vérification du contexte, du score, de la cible et des techniques MITRE.
  • Incident : regroupement des éléments qui représentent un risque réel.
  • Confinement : limitation de la propagation sans détruire les preuves.
  • Remédiation : suppression ou neutralisation de la cause.
  • Clôture : preuve de retour à un état maîtrisé et documentation complète.
Bonne pratique. Conservez l’identifiant de corrélation dans les tickets, jobs, playbooks et communications afin de reconstruire toute la chronologie.
2

Qualifier une détection

  1. 1

    Lire le résumé

    Vérifiez la règle, la sévérité, le score, l’endpoint et l’heure exacte.

  2. 2

    Contrôler le contexte

    Consultez l’utilisateur, le processus parent, la ligne de commande, le chemin et les connexions réseau.

  3. 3

    Comparer avec l’activité attendue

    Vérifiez les changements, outils d’administration et opérations planifiées.

  4. 4

    Rechercher les IOC

    Analysez les hash, domaines, IP et chemins associés dans le périmètre de l’organisation.

  5. 5

    Choisir une décision

    Marquez la détection comme confirmée, suspecte, faux positif ou nécessitant une investigation.

  6. 6

    Documenter

    Ajoutez une note courte, factuelle et exploitable par le prochain analyste.

Attention. Ne classez pas une alerte en faux positif uniquement parce que le fichier est signé. Une signature valide ne garantit pas un comportement légitime.
3

Collecter les preuves utiles

  • Chronologie des processus et ligne de commande complète.
  • Hash cryptographique et informations de signature du fichier.
  • Connexions réseau liées au processus ou à l’utilisateur.
  • Événements Windows, journaux système ou audit Linux pertinents.
  • Services, tâches planifiées, autoruns et modifications de registre.
  • Capture d’écran ou état utilisateur uniquement lorsque la politique l’autorise.
Bonne pratique. Collectez d’abord les éléments volatils. Un redémarrage ou un kill de processus peut faire disparaître une partie du contexte.
4

Isoler un endpoint

  1. 1

    Vérifier la cible

    Confirmez l’organisation, l’agent, le hostname, l’utilisateur actif et l’impact métier.

  2. 2

    Obtenir l’approbation

    Suivez la politique SOC et la double approbation lorsque l’action est destructrice ou critique.

  3. 3

    Lancer l’isolation

    Utilisez l’action EDR dédiée ; n’improvisez pas une règle réseau manuelle non suivie.

  4. 4

    Vérifier l’effet

    Contrôlez que le statut de l’endpoint est réellement isolé et que le canal de gestion reste disponible.

  5. 5

    Prévenir les parties concernées

    Informez le support, le responsable métier et le propriétaire de l’incident selon la procédure.

Attention. Une isolation peut interrompre un service critique. Vérifiez toujours le rôle de la machine et conservez une procédure de désisolement testée.
5

Utiliser les playbooks SOAR

  • Définir des conditions précises ; une condition vide ne doit jamais déclencher une action automatique.
  • Tester le playbook en dry-run sur des détections représentatives.
  • Utiliser une clé d’idempotence pour éviter les exécutions répétées.
  • Conserver l’approbation humaine pour l’isolation, le kill, la quarantaine et les scripts sensibles.
  • Configurer les timeouts, retries et actions de compensation.
  • Traiter les résultats partiels comme tels ; ne jamais afficher un faux succès.
Bonne pratique. Commencez par automatiser les actions réversibles : notification, enrichissement, création de ticket et collecte de preuves.
6

Créer une exception EDR

  1. 1

    Prouver le faux positif

    Identifiez la cause exacte et conservez les preuves de légitimité.

  2. 2

    Choisir le critère le plus précis

    Préférez un hash, un signataire ou un chemin contrôlé à une exclusion globale.

  3. 3

    Limiter le périmètre

    Appliquez l’exception à l’organisation, au site ou au groupe réellement concerné.

  4. 4

    Définir une expiration

    Les exceptions temporaires doivent être automatiquement réévaluées.

  5. 5

    Auditer et tester

    Vérifiez que l’exception supprime uniquement le bruit visé sans masquer d’autres détections.

Attention. N’excluez jamais un répertoire utilisateur entier, un interpréteur système ou un processus générique pour corriger une seule alerte.
7

Restaurer et clôturer

  • Confirmer que la persistance et les IOC ont été supprimés ou bloqués.
  • Mettre à jour les systèmes, applications et credentials concernés.
  • Désisoler uniquement après validation du SOC ou du responsable désigné.
  • Surveiller l’endpoint pendant une période renforcée.
  • Clôturer avec une chronologie, une cause racine et les actions correctives.
  • Transformer les enseignements en règle, playbook, durcissement ou procédure.

Checklist de validation

  • La cible et le tenant sont vérifiés avant chaque action.
  • La détection est qualifiée avec des preuves factuelles.
  • Les actions destructrices disposent des approbations requises.
  • L’isolation conserve un canal de gestion et une procédure de retour.
  • Les IOC et techniques MITRE sont documentés.
  • Les playbooks sont idempotents et testés en dry-run.
  • Les exceptions sont précises, limitées et expirables.
  • La clôture contient la cause racine et les mesures préventives.
EDR et réponse aux incidents | Documentation Reap3r