Réponse à incident : méthodologie et outils

La réponse à incident désigne l'ensemble des méthodologies et outils déployés pour identifier, contenir, éradiquer et remédier à une compromission d'un système d'information. Ce processus structuré suit généralement le cadre NIST SP 800-61 ou PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned). Chaque phase a un objectif précis. La préparation établit les playbooks et les accès forensiques. L'identification consiste à qualifier l'alerte : est-ce un vrai incident ou un faux positif ? Le containment vise à stopper la propagation latérale sans détruire les preuves. L'éradication supprime les artefacts malveillants : implants, comptes compromis, tâches planifiées persistantes. La remédiation restaure les services dans un état sain. La phase post-incident produit un retour d'expérience factuel. En pratique, une réponse à incident efficace repose sur la qualité de la télémétrie disponible, la rapidité d'action de l'équipe SOC/CSIRT et l'existence de procédures documentées. Un incident non maîtrisé dans les premières heures multiplie la surface de dommages : exfiltration de données, propagation ransomware, persistance longue durée.

La détection précoce d'un incident s'appuie sur la corrélation d'événements issus de plusieurs sources. Côté Windows, les Event IDs clés sont 4624 et 4625 (authentifications), 4688 (création de processus avec ligne de commande si l'audit est activé), 4698 et 4702 (création et modification de tâches planifiées), 7045 (installation d'un nouveau service) et 4103/4104 (logs PowerShell ScriptBlock). Ces événements doivent être centralisés dans un SIEM comme Splunk, Elastic SIEM ou Microsoft Sentinel. Les règles de détection Sigma permettent d'écrire des corrélations portables entre plateformes. Les indicateurs de compromission (IOC) à surveiller incluent : connexions vers des IP de Command and Control connues, exécutions de binaires depuis des chemins inhabituels (ex. APPDATA ou TEMP), modifications de clés de persistance comme HKLM/Software/Microsoft/Windows/CurrentVersion/Run, et dumps LSASS détectés via Sysmon Event ID 10. Les EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) fournissent une télémétrie comportementale essentielle pour reconstituer la chronologie d'attaque. La timeline forensique est l'outil central du SOC durant la phase d'identification.

Côté Red Team, simuler un incident permet de tester la robustesse des procédures de réponse et la couverture de détection. Les frameworks Atomic Red Team et CALDERA permettent de rejouer des techniques MITRE ATT&CK dans un environnement contrôlé. Les scénarios typiques testés en Cyber Range incluent : mouvement latéral via Pass-the-Hash ou PsExec, persistence via tâches planifiées ou clés Run, exfiltration DNS ou HTTPS vers un serveur de test, et simulation de ransomware sans payload destructeur. Côté Blue Team et contre-mesures, le durcissement repose sur plusieurs axes. Activer l'audit de processus en ligne de commande via GPO. Déployer Sysmon avec une configuration type SwiftOnSecurity. Segmenter le réseau pour bloquer les mouvements latéraux. Appliquer le principe de moindre privilège pour limiter l'impact d'un compte compromis. Documenter les playbooks pour chaque type d'incident : ransomware, intrusion APT, compromission de compte privilegié. Les exercices Tabletop et Purple Team permettent de valider ces procédures avant qu'un vrai incident ne survienne. La qualité des runbooks détermine directement le MTTC (Mean Time To Contain).