Élaborer un plan d'intervention en cas d'incident à partir de zéro

Une cyberattaque ne s'annonce pas. Un matin, une alerte se déclenche, quelqu'un ouvre un ticket, et le temps que la direction soit mise au courant, les dégâts se sont déjà propagés. Ce qui distingue les entreprises qui parviennent à contenir une faille en quelques heures de celles qui restent bloquées dans un processus de rétablissement pendant des mois, ce n'est pas une technologie plus performante. C'est la préparation. Plus précisément : le fait de disposer ou non d'un plan avant que les problèmes ne surviennent.

Un plan d'intervention en cas d'incident (IRP) est une procédure documentée et testée visant à détecter les incidents de sécurité, à les contenir et à assurer la reprise après sinistre. Cela peut sembler bureaucratique. Dans la pratique, c'est ce qui fait la différence entre une intervention maîtrisée et un chaos organisé à 2 heures du matin.

Qu'est-ce qui est réellement considéré comme un incident ?

Toutes les alertes ne constituent pas forcément un incident. Une tentative de connexion infructueuse relève du bruit de fond. Le chiffrement d'un serveur de fichiers par un rançongiciel, en revanche, n'en relève pas. Cette distinction est importante, car elle détermine qui doit intervenir et dans quel délai.

Catégories courantes qu'il convient de définir avant toute chose :

• Fuite de données : accès non autorisé à des données sensibles ou soumises à une réglementation
• Infection par des logiciels malveillants : ransomwares, logiciels espions, « wipers », chevaux de Troie
• Déni de service : attaques visant à perturber le fonctionnement ou à mettre hors service des systèmes
• Menace interne : actions malveillantes ou accidentelles commises par des membres du personnel ou des prestataires
• Compromission de la chaîne d'approvisionnement : attaques s'introduisant via les logiciels des fournisseurs (SolarWinds en est l'exemple type)
• Accès non autorisé : vol d'identifiants, élévation de privilèges, déplacement latéral

Un e-mail de hameçonnage sur lequel on a cliqué mais qui n'a rien installé est différent de celui qui a installé une balise Cobalt Strike. Le plan doit prendre en compte les deux cas de figure et permettre à l'équipe de les distinguer rapidement.

Pourquoi la plupart des projets ne fonctionnent pas vraiment

De nombreuses organisations disposent d'un document de réponse aux incidents. Elles sont toutefois bien moins nombreuses à en posséder un que quelqu'un ait lu. Et elles sont encore plus rares à l'avoir testé dans le cadre d'un scénario proche de la réalité.

Les problèmes habituels : le document date de trois ans, il contient les coordonnées de personnes qui ont quitté l'entreprise, il fait référence à des outils qui ont été remplacés, et aucun membre de l'équipe d'intervention n'y a jamais eu accès. Il s'avère qu'il existe un écart significatif entre disposer d'un document de politique et disposer d'un guide opérationnel. L'un satisfait les auditeurs. L'autre est ce que l'on utilise lorsque le système de production est en panne à 3 heures du matin et que personne ne sait qui est habilité à mettre hors ligne un serveur compromis.

Les six phases et leur signification concrète

Le cadre NIST SP 800-61 décompose la réponse aux incidents en six phases. Le SANS utilise une logique similaire, mais avec des noms différents. Quoi qu'il en soit, la structure reste la même.

Préparation

Tout ce qui précède un incident. C’est là que se déroule le véritable travail : définir ce qu’est un incident, constituer et former l’équipe d’intervention, mettre en place une infrastructure de journalisation et d’alerte, organiser des exercices sur table. Un détail qui est constamment négligé : l’autorisation préalable des actions. Lors d’un incident en cours, attendre l’accord juridique pour isoler un serveur vous fait perdre un temps que vous n’avez pas. Décidez à l’avance de ce qui peut être fait immédiatement, et par qui, sans avoir à remonter l’information.

Identification

Il s'est passé quelque chose. La question est de savoir quoi, exactement. Cette phase consiste à transformer les alertes en incidents confirmés, à corréler les signaux entre les outils SIEM et EDR, à déterminer l'étendue de l'incident et à établir une chronologie. La rapidité de cette étape dépend directement de la qualité de la journalisation mise en place lors de la phase de préparation. Des journaux de mauvaise qualité entraînent un ralentissement de l'identification. Un ralentissement de l'identification réduit les options disponibles.

Confinement

Les mesures de confinement à court terme sont rapides et radicales : isoler les hôtes infectés, bloquer les adresses IP des attaquants, désactiver les comptes compromis. Les mesures de confinement à long terme sont plus ciblées : correctifs temporaires, reconfiguration des systèmes, surveillance renforcée de certains comportements. Une question revient sans cesse : faut-il se déconnecter immédiatement ou observer d’abord l’attaquant ? La déconnexion limite les dégâts. La surveillance permet d’en saisir toute l’ampleur. Les deux approches ont leurs mérites. Ce choix doit être discuté à l’avance, et non improvisé sous la pression.

Éradication

Éliminez complètement la menace. Appliquez les correctifs aux vulnérabilités exploitées, supprimez les logiciels malveillants et leurs mécanismes de persistance, renouvelez les identifiants d'accès et réinstallez les systèmes compromis à partir d'images vierges. C'est en sautant cette étape ou en la bâclant que les entreprises se retrouvent à nouveau compromises par le même vecteur deux semaines plus tard. Cela arrive plus souvent qu'on ne le laisse entendre.

Rétablissement

Rétablissez les services par ordre de priorité. Vérifiez que les systèmes ne présentent aucun risque avant de les reconnecter. Surveillez attentivement toute situation récurrente. Et respectez les obligations de notification : le RGPD prévoit un délai de 72 heures pour signaler toute violation de données à caractère personnel aux autorités de contrôle. Ce délai ne s’interrompt pas sous prétexte que la restauration est encore en cours.

Enseignements tirés

C'est l'étape que la plupart des équipes négligent parce qu'elles sont épuisées. Et c'est justement pour cela qu'elle est essentielle. Une analyse post-incident doit être menée dans un délai de deux semaines : que s'est-il passé, qu'est-ce qui a fonctionné, qu'est-ce qui n'a pas fonctionné, quelles lacunes ont été mises en évidence, quels changements vont être apportés et dans quels délais. Consignez le tout par écrit. Mettez à jour le plan. Puis mettez réellement en œuvre les changements ; sinon, cela n'aura été qu'une simple réunion.

Des outils qui permettent de mettre un plan en œuvre

L'IRP décrit la marche à suivre. Ce sont les outils qui permettent de la mettre en œuvre rapidement, même sous pression.

• SIEM : Splunk, Microsoft Sentinel et IBM QRadar pour la corrélation des journaux à grande échelle
• EDR : CrowdStrike Falcon, SentinelOne, Microsoft Defender pour la détection comportementale et l'isolation des terminaux
• SOAR : Palo Alto XSOAR, Splunk SOAR pour l'exécution automatisée de scénarios d'intervention
• Renseignements sur les menaces : MISP et Recorded Future pour mieux comprendre les TTP des attaquants
• Criminalistique : Velociraptor, Magnet AXIOM et Volatility pour les enquêtes et la conservation des preuves

Les outils importent moins que la capacité des utilisateurs à s'en servir en situation de pression. Une instance Splunk comportant 400 tableaux de bord mais dépourvue de guides d'intervention n'est d'aucune utilité.

Ce qu'il faut savoir sur l'harmonisation réglementaire

Selon le secteur d’activité et la région, un IRP n’est pas facultatif : il s’agit d’une obligation légale. Principaux cadres réglementaires :

• NIST SP 800-61, révision 2 : la norme de référence pour les administrations fédérales américaines et la plupart des environnements d'entreprise
• ISO/IEC 27035 : norme internationale relative à la gestion des incidents
• Article 33 du RGPD : obligation de notification des violations dans un délai de 72 heures pour les données à caractère personnel de l'UE
• Directive NIS2 : obligations de signalement des incidents pour les opérateurs de services essentiels dans l'ensemble de l'UE
• DORA : les exigences de résilience du secteur financier de l'UE sont en vigueur depuis janvier 2025 et prévoient des obligations explicites en matière de tests de résistance aux perturbations.
• PCI DSS v4.0 : documentation relative au secteur des paiements et exigences en matière de tests annuels

Ce sont le NIS2 et le DORA qui prennent actuellement les organisations au dépourvu. Ces deux réglementations rehaussent considérablement le niveau d'exigence en matière de documentation, de fréquence des tests et de délais de déclaration.

Des prestataires à prendre en considération

Certaines organisations développent leurs capacités en matière de réponse aux incidents (IR) entièrement en interne. La plupart ne disposent toutefois ni du personnel ni de l’expérience nécessaires pour le faire correctement, notamment en matière de simulation et de tests. En voici une brève liste :

DXC Technology propose une prise en charge complète du développement de programmes de réponse aux incidents (IR) : conception de plans, exercices de simulation et services de détection et de réponse gérés. L'entreprise dispose d'une expertise particulièrement solide dans les secteurs réglementés (énergie, santé, services financiers), notamment dans le domaine des solutions logicielles pour le secteur de l'énergie, où la conformité réglementaire est intégrée dès le début de la mission.

Secureworks (Atlanta) propose des services de gestion des incidents (IR) en complément de sa plateforme Taegis XDR. Son unité « Counter Threat Unit » publie en continu des informations sur les menaces qui alimentent directement les mises à jour des guides d'intervention, ce qui s'avère utile pour les équipes souhaitant disposer de fonctionnalités de détection et de réponse au sein d'un même environnement.

WithSecure (Helsinki) adopte une approche consultative pour le développement de programmes de réponse aux incidents (IR), en stricte conformité avec les exigences réglementaires européennes. Cette approche convient mieux aux organisations qui mettent en place pour la première fois des capacités de réponse aux incidents qu’à celles qui recherchent un simple service géré.

Trustwave (Chicago) associe des services de sécurité gérés à des prestations de conseil en réponse aux incidents (IR) par l'intermédiaire de SpiderLabs, une « red team » interne qui a publié certains des rapports sur les menaces les plus détaillés du secteur au cours de la dernière décennie.

Orange Cyberdefense (France) assure simultanément la coordination transfrontalière des interventions en cas d'incident (IR) dans plusieurs juridictions de l'Union européenne. Cette solution est utile pour les multinationales qui doivent gérer en parallèle leurs obligations au titre de la directive NIS 2 et du RGPD dans différents pays.

Les erreurs qui reviennent sans cesse

Même les équipes les mieux préparées commettent des erreurs prévisibles. Voici celles qui reviennent le plus souvent :

• Ne pas tester le plan : un document qui n'a jamais été mis à l'épreuve dans des conditions de pression simulées n'est qu'une simple supposition.
• Absence de protocoles de communication définis : qui s'adresse à la presse, qui contacte l'autorité de régulation, qui informe les clients ?
• Partir du principe que les sauvegardes sont intègres sans les vérifier
• Sans faire appel à des tiers : les fournisseurs de services cloud, les éditeurs de SaaS et les MSP doivent être impliqués dans le processus, et non pas simplement informés a posteriori.
• Considérer la gestion des incidents (IR) comme une fonction relevant exclusivement de l'informatique : les services juridiques, la communication, les ressources humaines et la direction ont tous un rôle à jouer en cas d'incident grave

Et surtout : considérer ce plan comme un projet ponctuel. Les menaces évoluent. Les systèmes changent. Les personnes partent. Un IRP qui n’est pas mis à jour régulièrement est obsolète avant même d’avoir été utilisé.

Foire aux questions

Combien de temps faut-il pour développer un IRP fonctionnel à partir de zéro ?

Un plan de base peut être élaboré en quatre à six semaines. La mise en place d'un programme abouti, comprenant des guides opérationnels, des exercices testés et l'intégration d'outils, prend en réalité entre trois et six mois.

À quelle fréquence faut-il le faire contrôler ?

Au moins une fois par an. La DORA et la plupart des cadres de référence d'entreprise préconisent désormais d'organiser des exercices sur table deux fois par an, avec au moins une simulation complète. Après tout incident majeur ou changement important du système, procédez immédiatement à un examen.

Quelle est la différence entre un exercice de simulation et un exercice de « red team » ?

Une session « tabletop » repose sur des discussions ; on passe en revue des scénarios sans intervenir sur les systèmes. Une mission « red team » simule activement les techniques des attaquants contre une infrastructure réelle. Les deux approches sont précieuses et permettent de tester des aspects différents.

Quelle est la première mesure à prendre lorsqu'un incident est confirmé ?

Mobilisez l'équipe d'intervention, consignez l'heure et les premiers indicateurs, puis lancez les mesures de confinement préautorisées. Ne touchez pas aux systèmes infectés pour les nettoyer avant que les preuves numériques aient été préservées ; ce sont ces informations qui permettent de cerner toute l'ampleur de ce qui s'est passé.

• À propos de
• Derniers messages

Milena Baghdasaryan

Spécialiste du contenu chez PowerDMARC

Milena est une rédactrice et créatrice de contenu qualifiée qui possède plus de 7 ans d'expérience dans la création de contenu attrayant sur les technologies de l'information, la cybersécurité, les événements virtuels, etc. Elle est diplômée d'institutions prestigieuses telles que la New York University Abu Dhabi, l'UWC China et le Collège d'Europe.

Derniers messages de Milena Baghdasaryan (voir tous)

• Élaborer un plan d'intervention en cas d'incident à partir de zéro - 8 septembre 2026
• La nouvelle méthode utilisée par les pirates pour tromper les assistants financiers basés sur l'IA - 7 septembre 2026
• Meilleures pratiques en matière de sécurité DNS : une liste de contrôle complète pour le renforcement de la sécurité - 7 septembre 2026